AT&T 1990年の崩壊：1つのbreakが電話網を止めた

何が起きたか

横にスクロール

1990年1月15日の午後、米国のAT&Tが運用する長距離電話網が突如として広範囲で機能を失った。市内通話は各地域の電話会社が担うため無事だったが、州をまたぐ長距離通話は次々に接続できなくなり、この状態は約9時間にわたって続いた。失敗した通話は数千万件規模にのぼる。当時のAT&Tは長距離市場で圧倒的なシェアを持っていたため、その影響は経済活動の広い範囲に及んだ。

当初、これほどの規模の障害を前に原因の特定は難航した。交換機のハードウェアはどれも正常に見え、電源も伝送路も生きている。それでいて通話だけが通らない。物理的な破壊ではなく、全台に共通して仕込まれた論理の欠陥が相手だったからこそ、現象は「どこも壊れていないのに動かない」という、掴みどころのないものになった。

当時のAT&T網は、No.4 ESSと呼ばれる大規模なデジタル交換機を全国に多数配置し、それらを高速な信号網で相互接続する構成だった。各交換機は互いに状態を通知し合い、どの経路が使えるかを把握しながら通話を最適な相手へ振り分けていた。個々の交換機は高い信頼性を持ち、内部に異常を検知すると自動で復旧処理に入る仕組みも備えていた。皮肉なことに、この「自動で立ち直る」ための仕組みそのものが、今回の崩壊の引き金になった。

発端は、一台の交換機がごく軽微な異常を検知して、通常どおり短時間の復旧処理に入ったことだった。ここまでは設計どおりの、日常的に起きうる出来事にすぎない。問題は、その交換機が復旧を終えて「また使えるようになった」と隣の交換機へ知らせた、まさにその瞬間から始まった。

技術的な根本原因

核心にあったのは、交換機のソフトウェアに含まれる、ごく短い一区画の処理だった。ある交換機が復旧を告げるメッセージを送ると、それを受け取った側は自分の管理データを更新しようとする。この更新処理の制御フローに誤りが紛れ込んでいた。C言語のswitch文の中に置かれた、誤ったbreakに起因すると広く語られる類の誤りである。

switch文は、値に応じて処理を枝分かれさせる構文だ。ある枝の末尾でbreakを書き忘れたり、意図しない位置にbreakを置いたりすると、処理が想定外の枝へ流れ込んだり、途中で抜け出したりする。こうした構造の取り違えが、更新途中のデータを壊し、交換機を「異常」と自己判断させてリセットへ追い込んだ、と説明される。

switch (state) {
  case READY:
    update_status();
    /* ここで抜けるべきだが、条件次第で
       意図しない枝へ流れ込む構造だった、と語られる */
  case BUSY:
    reset_processor();   /* 本来通るはずのない復旧リセット */
    break;
}

厄介だったのは、この誤りが単独の故障で終わらなかった点だ。リセットした交換機は、復旧するとまた隣へ「復旧した」と通知する。その通知が、受け取った側の同じ誤りを踏み抜く。こうして「復旧の通知が次のリセットを生む」という連鎖が成立した。一台の異常が二台を、二台が四台をと巻き込んでいく、典型的なカスケード障害（連鎖崩壊）である。

この連鎖が厄介だったのは、誤りが必ず踏まれるわけではなく、二つの通知が短い時間差で相次いで届いたときに顕在化した、とされる点だ。交換機が最初の通知を処理し終える前に次の通知が重なると、更新途中の状態のまま例の経路へ流れ込む。網の負荷が高いほど通知は密になり、条件はいっそう成立しやすくなる。障害が波のように広がっては引き、また広がるという不安定な挙動を見せたのも、この時間的な際どさが背景にあったと説明される。

さらに事態を全国規模へ押し上げたのが、全交換機がまったく同一のソフトウェアを動かしていたという事実だ。ある一台だけに固有のバグであれば、被害はそこで止まる。しかし同じコードが全台に載っていれば、同じ引き金で全台が同じように倒れる。これは共通原因故障（common-cause failure）と呼ばれ、単純に台数を増やして冗長化しても守れない弱点だ。何台交換機を並べても、全部が同じ急所を抱えていては意味がない。冗長化が守ってくれるのは、故障が互いに独立しているという前提が成り立つ場合だけであり、共通原因故障はその前提そのものを崩してしまう。

この誤りは、その数週間前に配信されたソフトウェア更新で混入したと広く語られる。更新自体は処理を高速化するための改良だったが、変更が触れたのがまさに障害回復という、平常時にはほとんど実行されない経路だった。そのため通常の試験や運用では表面化せず、現場で最初の交換機が復旧処理に入った瞬間まで、誰にも気づかれずに潜んでいた。最終的な収拾は、皮肉にも各交換機へ加わる負荷を意図的に下げて連鎖の輪を断ち切り、その上で問題の更新を以前の版へ戻すことで果たされた。

教訓

第一に、障害回復コードこそ最も入念にテストすべきだという点だ。回復処理は、平常時にはまず動かない。動くのは、すでに何かが壊れている非常時である。最も過酷な状況でしか実行されないのに、そこでの一つの誤りが被害を桁違いに拡大させる。普段動かないコードほど、意図的に壊して試す価値がある。正常系だけを通す試験では、こうした経路は永遠に踏まれない。過負荷や部分故障をわざと再現し、回復処理そのものを主役に据えた試験がなければ、欠陥は本番の非常時まで生き延びる。

第二に、単純な制御フローの誤りが全国規模の惨事になりうるという事実だ。難解なアルゴリズムではなく、breakの位置という初歩的な取り違えが引き金になった。被害の大きさは、原因の複雑さとは必ずしも比例しない。だからこそ、回復のような重要経路のレビューは、行の一本一本まで丁寧であるべきだ。

第三に、同一ソフトの一斉展開は共通原因故障を招くという点だ。全台に同じコードを載せれば、同じバグも全台に載る。これを避けるには、更新をいきなり全体へ広げず一部から順に広げる段階的ロールアウト（カナリアリリース）や、異常な負荷を模した負荷試験で、本番前に急所を炙り出しておくことが要る。

こうした失敗の型は、この一件だけのものではない。単一の小さな欠陥が全体へ波及する構図は、現代のクラウドやマイクロサービスでも繰り返し現れる。他の実例は実在障害から学ぶに、ネットワークの土台にある交換や経路制御の考え方はネットワークにまとまっている。

まとめ

1990年のAT&T長距離網の崩壊は、たった1つの制御フローの誤りが、約9時間にわたって数千万件規模の通話を止めた事件だった。障害から自力で立ち直るための「賢い」コードが、同一ソフトを載せた全交換機の間で復旧通知の連鎖を生み、全域を巻き込むカスケード障害へと発展した。回復コードの徹底検証、段階的な展開、連鎖を断つ負荷制御。ここで得られた教訓は、規模も技術も様変わりした今日のシステム運用にそのまま生きている。他の「工学の大惨事」は大惨事シリーズから辿れる。