え、私？また「え、私？」へようこそ！このコラムの以前の記事をまだ読んでいない方のために説明すると、これは読者が自分のものを壊してしまった体験談を語る告白コーナーです。しかも、ひどいものです。
今週、「バート」という読者から、「90年代半ば、アメリカ・オンライン（AOL）が世界最大のオンラインサービス、そして最大のインターネットサービスプロバイダーだった頃を思い出してください。なんと500万人ものユーザーがいたんですよ！」という質問を受けました。
バートはAOLメールの維持を任されました。それは非常に困難な任務でした。1995年の就任初日に、彼は会社で4台目の受信メールゲートウェイサーバーを立ち上げたのです。
それから 1 年余り後、バート氏は AOL が「受信用のインターネット メール サーバーを何十台も抱えており、どうすれば問題を起こさずに、それらのサーバーをすべて稼働させ、利用可能であると宣伝できるかを必死に考えていた」と語っています。
システム管理者が間違ったサーバーをシャットダウンし、ヨーロッパのすべてのオペレーションがシャットダウンされました
続きを読む
MX レコードが彼の主な問題でした。「MX の数が非常に多くなり、DNS パケットが 512 バイトの UDP 応答パケットに収まらなくなり、切り捨てられるようになった」ためです。
バート氏によれば、切り捨てられたパケットはさまざまな問題を引き起こし、その中にはひどく不均衡な負荷も含まれているという。
ごく一部のサイトでは、DNS応答が切り捨てられているとシステムが誰とも通信を拒否するため、メールを全く受信できませんでした。割合は小さいとはいえ、それでもかなり大きな数でした。明らかに何らかの対策を講じる必要がありました。
それでバートはそれをやった。
ドメイン名の圧縮を最大限に活用するために、少数の一般的なドメイン名に複数のIPアドレスを登録するという素晴らしいアイデアを思いつきました。こうしてa.mx.aol.comが誕生しました。そしてb.mx.aol.com、c.mx.aol.comと、次々と誕生しました。災害発生時には、DNSに9つのドメイン名をMXとして登録し、それぞれに5つのIPアドレスを割り当てていました。45台すべてのメールサーバーをAOLのMXとしてDNSに登録しても、512バイトのUDP応答パケットにギリギリ収まりました。DNSのトランケーションなしでメールが再び送受信できるようになり、ほぼ全員が満足していました。
Bertに不満を持つ人たちは、MXの前にロードバランシングスイッチが必要だと指摘しました。しかしBertは、「当時存在していたスイッチは10Base-Tインターフェース1つだけで、トラフィックが膨大だったため、メールサーバーのバックエンドでは既にFDDIに移行していた」と説明しました。
「あのトラフィックすべてを、たった 10Mbps の小さなイーサネット ポートに詰め込むことは不可能でした。」そこで彼はそうしませんでした。
しかしバートは、AOL DNSチームにオフサイトのネームサービスプロバイダのバックアップを用意し、「長期間の障害発生時にユーザーが引き続き情報を参照できるようにしました。これもANSによって行われました。」
最も綿密に練られた計画でも軌道から外れる可能性があり、バート氏の計画は 1996 年 8 月 7 日に実際にそうなった。
「AOL ネットワークスタッフと子会社/バックボーンサービスプロバイダー ANS 間の計算ミスとコミュニケーションミスにより、19 時間のネットワーク停止が発生しました。」
障害の原因は、「キュー内の最初のメールメッセージを配信しようとすると、MXを検索し、45個のIPアドレスのリストを取得し、通常通り接続を試行します。まず、名前の最初のIPアドレスに接続しようとし、…待機します。RFCに従い、接続がタイムアウトするまで2分間待機します。その後、次のIPアドレスを試します。そして、2分間待機します。その後、次のIPアドレスを試します。」
「計算してみろ」とバートは提案した。「1通のメールを配信するのに90分もかかる計算になる。その間、メール処理は他のことは何もしていないんだ」
しかし、インターネット上の人々は別のことをしていました。それは、より多くのメールを送信することでした。そして、それらのメールはAOL（1996年当時、インターネット人口の大きな割合を占めていたことを思い出してください）に届かなかったため、メールサーバーは「キューランナーを60分または30分ごとに（デフォルトで）起動し、キューをフラッシュしていました。キューランナーはキュー全体を吸い込み、すべてのメッセージを1つずつ処理しようとしていました。」
「しかし、AOL への 1 つのメッセージを処理しようとしている間に 90 分間停止した場合、30 分または 60 分後に別のキュー ランナーが開始され、キュー全体が吸い込まれ、すでに処理中の 1 つのメッセージを処理できなくなりますが、その後、おそらく AOL への 2 番目のメッセージを送信しようとしている間にも 90 分間停止することになります。」
やがて、サーバーのRAMが不足し、データをディスクにスワップし始め、ディスク上のスワップ領域が不足するでしょう。そして――1996年、サーバーがまだ弱かった頃を思い出してください――サーバーは再起動し、ファイルシステムの修復を試み、再びメールの送信を開始するでしょう。そして、メールがAOLに届かなくなるので…どうなるか、お分かりでしょう。
バートは、自分のミスが原因で、迷惑メールの有名な配信業者から嫌がらせメールが届いたと話してくれました。彼らは親切にも彼の電話番号を世界に公開し、怒りの電話を歓迎すると示唆しました。そのうちのいくつかは届いてしまい、バートは殺害予告を1、2回受けたと思うと話してくれました。
彼も怒りのメールを多数受け取ったと想定しているが、メールが届かなかったためにどれほど多くの人が彼を嫌っていたかには全く気づいていなかったのだ！
「あの日、メールにアクセスできず、送られてきた重要なメッセージに返信できなかったために倒産した企業がどれだけあったか、聞いたことがありません」とバート氏は語った。「私ですか？」AOLは19時間後にオンラインに復帰した。バート氏によると、「メールトラフィックが最終的に正常に戻るまで約1週間かかりました」。世界中が「インターネット全体がメールのバックログに追いつくのを」待っていたという。
バートは、この事件からいくらか良い結果が生まれたと考えている。対応策の中には、メール転送エージェントの開発があり、qmailこれpostfixによって世界中の電子メール システムの耐性がかなり強化されたからだ。
スケールの大きさでバートの物語を超えるのは難しいですが、きっと他の読者の方々も素晴らしい失敗談をお持ちだと思います。もしそのような話をお持ちでしたら、こちらをクリックしてご連絡ください。もしかしたら、今後の月曜日にご紹介させていただくかもしれません！®
