2003年北米大停電：アラームを止めたレース条件

何が起きたか

横にスクロール

2003年8月14日の午後、米国北東部とカナダの一部で大規模な停電が始まった。影響を受けた人口はおよそ5000万人規模に達し、北米の歴史でも最大級の停電として記録されている。真夏の午後、冷房需要で電力系統が高い負荷にさらされるなか、送電線が次々と系統から切り離され（トリップし）、その連鎖が数時間のうちに広大な地域を暗闇へ沈めた。

停電そのものは電力インフラの物理的な事象だが、被害をここまで広げた引き金の一つは、電力を扱う設備ではなくソフトウェアの中にあった。ある送電会社の系統監視システムが、運用者（オペレータ）に異常を知らせる「アラーム機能」を、誰にも気付かれないまま停止させていたのだ。

その日、送電線の一部は高負荷で電流が増え、導体が熱で伸びてたるみ、伸びた電線が下の樹木に接触して短絡し、保護装置が働いて回線を切り離していた。本来ならこうしたトリップはただちにアラームとして運用者の画面に上がり、負荷の再配分や増強といった手を打つ契機になる。ところが監視システムのアラームは沈黙していた。運用者は系統が静かに悪化していく様子を「異常なし」と受け取り、対処の初動が決定的に遅れた。最初の警報が上がらないまま時間が過ぎ、個々のトリップは連鎖的な過負荷へと育ち、やがて制御しきれない広域停電に至った。

注目すべきは、最初の異常がごく局所的な出来事だったことだ。数本の送電線が順にトリップしただけなら、早い段階で気付いて負荷を振り替えれば、影響は一地域にとどまったはずである。電力系統は、どこか一部が落ちても残りで支え合えるよう冗長に組まれている。だがその支え合いは、異常を早く捉えて手を打つ運用があって初めて機能する。監視が沈黙した数十分の間に、系統は自らを守る猶予を静かに使い果たし、局所の乱れが広域の連鎖へと転化していった。情報の遅れはやがて、人の手では追いつけない物理の速さに飲み込まれたのだ。

技術的な根本原因

監視システムの中核にあったのは、GE製のXA/21と呼ばれる系統監視・制御ソフトウェアだ。運用者に系統の状態を見せ、異常が起きればアラームを鳴らす、いわば管制室の「目」にあたる。この目を塞いだのが、プログラムに潜んでいたレース条件（競合状態）だった。

レース条件とは、複数の処理が共有するデータへ同時に近づいたとき、実行の順序（タイミング）次第で結果が変わってしまう不具合である。設計者が「この順序で動くはず」と暗黙に想定していた前提が、まれなタイミングの重なりで崩れる。XA/21では、アラームを処理する部分で複数の処理が同じデータ構造をほぼ同時に更新しようとし、想定外の順序がかみ合った瞬間に内部状態が壊れた。結果として、アラームを処理する仕組みが停止（事実上のハングアップ）し、以後は新しい警報を一切さばけなくなった。

たちが悪いのは、この停止が「静かに」起きたことだ。プログラム全体が派手に落ちたわけではなく、画面はそれまでの表示を保ったまま、新しい警報だけが上がらなくなった。処理されない警報は内部で滞留し続けたが、その滞留そのものを運用者へ伝える仕組みがなかった。運用者から見れば、系統は平穏そのもの——実際には悪化しているのに、平常運転にしか見えなかった。

さらに事態を悪くしたのが、予備系への切り替え（フェイルオーバー）だ。主系のサーバーが不調に陥ったため、待機していた予備系が引き継いだが、予備系も同じ滞留したデータを処理しようとして、同様に行き詰まった。冗長化は普通なら信頼性を高める仕組みだが、故障の原因がデータそのものに宿っていると、予備へ移してもその原因を一緒に持ち越してしまう。二重化されていたはずの監視は、どちらも同時に目を失った。

この一連の流れには、ソフトウェアの故障として最も厄介な性質が二つ重なっている。一つは非決定性だ。競合状態は同じ操作を繰り返しても毎回は起きず、処理の速さや割り込みの入り方といった観測しづらい条件がそろったときだけ姿を現す。開発時の試験を何度通しても引っかからず、本番の負荷のもとで初めて牙をむくことが多い。もう一つは、故障が「出力の誤り」ではなく「出力の欠落」として現れた点だ。誤った警報が出れば矛盾に気付けるが、警報がただ出てこないだけの状態は、正常な静けさと見分けがつかない。だからこそ、欠落は誤りよりも見抜くのが難しい。

こうして運用者は、一時間を超える間、アラームという最も重要な情報源を失ったまま系統を操作していた。競合状態は特定の負荷とタイミングが重ならなければ表面化せず、試験環境で再現するのがきわめて難しい。長年動いてきた実績が「安全だ」という油断を生み、まれな条件が現場で初めて牙をむいた。

教訓

第一の教訓は、競合状態のようなタイミング依存の不具合は、見つけにくく再現しにくいという現実だ。入力や操作が同じでも、負荷の高さや処理の並びといった外から見えない条件で発現するため、通常の試験では素通りしてしまう。共有データへアクセスする箇所を洗い出し、排他制御を設計段階で厳密に定めること、そして負荷をかけた状態での試験を重ねることが欠かせない。コードの目視確認や、並行処理の危うさを機械的に洗い出す静的解析の併用も、こうした欠陥を運用へ出す前に捕まえる助けになる。

第二に、監視・アラームシステムそのものの信頼性が、監視される対象と同じかそれ以上に重要だという点だ。運用者は監視の画面を通して世界を見ている。その画面が嘘をつけば、どれほど有能な運用者でも正しい判断はできない。監視が死ぬと運用者は盲目になる——本件が突きつけたのは、この一点に尽きる。監視の系は「あって当たり前」の裏方として軽く扱われがちだが、その一枚が割れれば運用全体が崩れるのだと肝に銘じたい。

第三に、「警報が無いこと」を異常として検知する仕組みの必要性だ。人は警報が鳴れば異常だと気付くが、警報が鳴らない静けさを異常だとは思いにくい。だからこそ、監視システムが生きていることを定期的に自己申告させ（ハートビート）、一定時間その申告が途絶えたら別系統が警告を出す（ウォッチドッグ）といった、沈黙を検知する二重の仕掛けが要る。健全性は「異常が出ないこと」ではなく「生存信号が出続けること」で確かめるべきなのだ。

第四に、フェイルセーフ設計の考え方だ。予備系が主系と同じ原因で倒れないよう、故障の独立性を確保する。そして万一監視が失われたときには、系統をより安全な側へ倒す初期対応の手順をあらかじめ用意しておく。異常時に何もしないことが最悪の結果を招くなら、「分からないときは安全側へ」という原則を、設計と運用の両方に埋め込む必要がある。電力系統そのものの基礎は電力の各記事が、他の大規模障害の分析はインシデントが参考になる。

まとめ

2003年の北米大停電は、たった一つのレース条件がアラームを黙らせ、運用者の目を塞いだことで、5000万人規模の被害へと膨れ上がった事例だ。物理的な引き金は送電線と樹木の接触だったが、初期の小さな異常を大惨事へ育てたのは、監視が静かに死んでいたという情報の空白だった。

ソフトウェアの規模が大きくなるほど、こうしたタイミング依存の欠陥や「静かな故障」は避けきれない。だからこそ、監視自身を監視し、沈黙を検知し、分からないときは安全側へ倒す——この設計思想が重みを増す。同じ構造の失敗は分野を越えて繰り返される。他の事例は工学の大惨事シリーズから辿ってほしい。