800km 밖 에 못 가는 이메일
글이 짧아서 전문을 번역한다.
500마일 이메일 사례 (원래는 SAGE 가장 불가능한 임무?)
몇 년 전, 저는 캠퍼스 이메일 시스템을 관리하는 일을 하고 있었을 때, 통계학과 학과장의 전화를 받았습니다.
"우리 학과에서 이메일을 보내는 데 문제가 있어요."
"어떤 문제인가요?" 저는 물었습니다.
"우리는 500마일 이상 멀리 이메일을 보낼 수 없어요," 학과장이 설명했습니다.
저는 내 라떼를 삼키며, "다시 말씀해 주시겠어요?" 라고 말했습니다.
"500마일 이상 멀리 이메일을 보낼 수 없다는 거예요," 그가 반복했습니다. "사실 조금 더 멀리는 갈 수 있어요. 520마일 정도까지요. 하지만 그 이상은 안 돼요."
"음... 일반적으로 이메일은 그렇게 작동하지 않아요," 저는 목소리에 당황함을 감추려고 하며 말했습니다. 학과장에게 당황한 모습을 보여주지 않는 것이 좋습니다. 특히 통계학과 같이 상대적으로 부족한 자원을 가진 학과에서는 더욱 그렇죠. "500마일 이상 보낼 수 없다고 생각하시는 이유가 뭔가요?"
"제가 생각하는 것이 아니라," 학과장이 짜증 섞인 목소리로 대답했습니다. "이 문제가 처음 발생했을 때 며칠 전부터—"
"며칠이나 기다리셨어요?" 저는 목소리에 떨림을 느끼며 끼어들었습니다. "그 동안 이메일을 전혀 보내지 못했나요?"
"이메일은 보냈어요. 그냥 500마일 이상은—"
"—네, 알겠어요, 500마일이요," 저는 그를 대신해 말을 끝냈습니다. "하지만 왜 더 일찍 전화하지 않으셨죠?"
"확실한 데이터를 수집할 때까지 기다렸어요." 아, 이건 통계학 학과장이시군요. "어쨌든, 저희는 지리통계학자에게 이 문제를 조사하도록 했어요—"
"지리통계학자들이..."
"—네, 그리고 그녀는 우리가 이메일을 보낼 수 있는 반경이 500마일 조금 넘는다는 것을 보여주는 지도를 만들었어요. 그 반경 내에도 도달하지 못하는 목적지가 몇 군데 있긴 하지만, 저희는 절대로 이 반경보다 멀리 이메일을 보낼 수 없어요."
"알겠습니다," 저는 말하며 머리를 손에 묻었습니다. "이 문제가 언제 시작됐나요? 며칠 전이라고 했지만, 그때 시스템에 변화가 있었나요?"
"글쎄요, 컨설턴트가 와서 서버에 패치를 하고 재부팅했어요. 하지만 그에게 전화를 걸어 물어봤는데, 그는 메일 시스템에 손대지 않았다고 하더군요."
"알겠어요, 제가 한번 살펴보고 다시 연락 드리겠습니다," 저는 거의 믿을 수 없을 정도로 말했습니다. 만우절도 아니고, 누군가가 저에게 장난을 친 것 같은 기분이 들었습니다.
저는 그들 학과의 서버에 로그인하여 몇 개의 테스트 메일을 보냈습니다. 이것은 노스캐롤라이나의 리서치 트라이앵글에서 일어난 일이었고, 제 계정으로 보낸 테스트 메일은 문제없이 도착했습니다. 리치몬드, 애틀랜타, 워싱턴으로 보낸 것도 마찬가지였습니다. 프 린스턴(400마일 거리)으로 보낸 것도 작동했습니다.
하지만 멤피스(600마일)로 이메일을 보내려고 하자 실패했습니다. 보스턴, 실패. 디트로이트, 실패. 저는 주소록을 꺼내 이 상황을 좁혀가기 시작했습니다. 뉴욕(420마일)은 작동했지만, 프로비던스(580마일)는 실패했습니다.
제 정신을 잃은 것 같은 기분이 들기 시작했습니다. 노스캐롤라이나에 사는 친구에게 이메일을 보내려고 했지만, 그의 ISP는 시애틀에 있었습니다. 다행히도 실패했습니다. 만약 문제가 메일 서버의 지리적 위치가 아니라 수신자의 지리적 위치와 관련이 있다면, 저는 눈물을 흘렸을 겁니다.
믿을 수 없게도 보고된 문제가 사실이며 반복 가능하다는 것을 확인한 후, 저는 sendmail.cf 파일을 살펴보았습니다. 파일은 비교적 정상적으로 보였습니다. 사실, 익숙해 보였습니다.
저는 제 홈 디렉토리에 있는 sendmail.cf 파일과 비교해 보았습니다. 그것은 변경되지 않았습니다 - 제가 작성한 sendmail.cf였습니다. 그리고 저는 500마일 이상 이메일을 실패하게 하는 옵션을 활성화하지 않았다는 것을 확신했습니다. 답을 찾지 못한 채, 저는 SMTP 포트에 telnet으로 접속했습니다. 서버는 SunOS sendmail 배너로 쾌활하게 응답했습니다.
잠깐, SunOS sendmail 배너라고요? 당시에 Sun은 여전히 Sendmail 5를 운영 체제와 함께 제공하고 있었는데, 비록 Sendmail 8이 이미 상당히 성숙했음에도 불구하고 말이죠. 좋은 시스템 관리자답게, 저는 Sendmail 8을 표준으로 삼았습니다. 그리고 또한 좋은 시스템 관리자답게, 저는 Sendmail 5에서 사용되던 암호화된 코드 대신에 Sendmail 8에서 사용할 수 있는 긴 자체 설명 옵션과 변수 이름을 사용하는 sendmail.cf를 작성했습니다.
조각들이 한 번에 제자리에 맞춰졌고, 나는 다시 차가워진 라떼의 찌꺼기에 목이 메었습니다. 컨설턴트가 "서버를 패치했을" 때, 그는 SunOS의 버전을 업그레이드했고, 그 과정에서 Sendmail을 다운그레이드 했습니다. 업그레이드는 도움이 되었지만, 이제 잘못된 버전이 된 sendmail.cf 파일은 그대로 두었습니다.
당시 Sun이 출시한 Sendmail 5 버전은 - 몇 가지 조정이 있었지만 - Sendmail 8의 sendmail.cf와 호환될 수 있었습니다. 대부분의 규칙이 그 시점에 변경되지 않았기 때문입니다. 그러나 새로운 긴 설정 옵션들은 Sendmail이 무시했습니다. 그리고 sendmail 바이너리는 대부분의 이러한 설정에 대해 컴파일된 기본값이 없었으므로, sendmail.cf 파일에서 적절한 설정을 찾지 못하면 이들은 제로(0)로 설정되었습니다.
0로 설정된 설정 중 하나는 원격 SMTP 서버에 연결하기 위한 타임아웃이었습니다. 몇 가지 실험을 통해 이 특정 기계가 평소 부하에서 대기시간이 0으로 설정된 경우에는 3밀리초가 조금 넘으면 접속에 실패한 것으로 처리되고 있다는 것을 발견했습니다.
당시 우리 캠퍼스 네트워크의 이상한 특징 중 하나는 100% 스위치되어 있다는 것이었습니다. 나가는 패킷은 POP에 도달하고 반대편 라우터에 도달할 때까지 라우터 지연을 겪지 않았습니다. 따라서 가까운 네트워크에 있는 부하가 적은 원격 호스트에 연결하는 데 걸리는 시간은 사실상 라우터 지연보다는 목적지까지의 빛의 속도 거리에 의해 주로 결정되었습니다.
심호흡을 하고 터미널에 입력했습니다:
$ units
1311 units, 63 prefixes
You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979
"500마일, 아니면 조금 더."
- 트레이 해리스