本質は、「多数のコンピューターがあること」と「独立した逃げ道があること」は違う、という点です。一台ずつは壊れにくくても、同じ仕組みに依存していれば、一つの不具合で一斉に使えなくなります。
まず、今回確認されていること
202611月12〜13日の障害について、報道で紹介されたマイクロソフトの説明では、安全な接続を確立するサーバー上の処理が過負荷となり、要求を処理できなくなったとされています。発生時期と相関する設定変更を戻す作業も進められていますが、それだけで最終的な根本原因が確定したとはいえません。また、同社の表現は「悪意ある活動やサイバー攻撃を示す兆候はない」です。The Guardian
以下は、この障害の詳細な内部構造を断定するものではなく、なぜこの種の大規模障害が成立するのかを説明する数学的なモデルです。
1．確率――「予備があれば安心」の隠れた条件
ある時間内に、一台のサーバーが故障する確率を仮に1％とします。
二台の故障が独立なら、両方が故障する確率は、
です。予備を置く意味があります。
しかし、二台とも同じ不具合のある設定を受け取るなら、故障は独立ではありません。
極端な例として、「共通設定の不具合が起きる確率が1％で、起きれば全台停止する」とすれば、サーバーを何台増やしても、この原因による全停止確率は1％のままです。
台数を増やすことは、同じ間違いへの耐性を増やすことではない。
必要なのは機械の複製だけではなく、障害原因の共有を減らすことです。マイクロソフト自身の設計指針も、障害の影響を閉じ込める独立した配置単位や、障害時に負荷を引き受ける余剰能力を重視しています。Microsoft Learn
2．論理――機能が多数あっても、成立条件は「かつ」
仮に、ある業務機能が使える条件を次のように置きます。
「」は「かつ」です。不可欠な条件のどれか一つが欠ければ、その業務は使えません。
つまり、画面上ではメール、予定表、共同作業が別々の機能に見えても、裏側で同じ基盤を必須としていれば、まとめて影響を受け得ます。実際、今回の報道でも、Exchangeに接続するサービスへの影響が大きいと説明されています。The Guardian
ここでの本質は、製品名の数ではなく、依存先がどれだけ重なっているかです。マイクロソフトの障害分析指針も、動作に不可欠な「強い依存関係」を特定し、その信頼性を確認するよう求めています。Microsoft Learn
3．引き算――少しの能力低下で、急に止まる
毎秒届く要求を 、毎秒処理できる能力を とします。
なら、平均的には要求をさばく余地があります。
例えば、毎秒100件の要求に対し、処理能力が毎秒110件なら、余裕は10件。しかし不具合によって処理能力が90件に落ちると、
ずつ未処理が増えます。処理できなかった要求を待ち行列に残す単純なモデルなら、1分で600件です。
さらに利用者やアプリが再試行すると、
遅延→再試行→負荷増加→さらに遅延
という循環ができます。不具合が最初の引き金でも、途中からは再試行と負荷集中が障害を維持するわけです。Googleの運用技術書でも、この連鎖と、復旧直後のサーバーが再び過負荷になる問題が解説されています。Google SRE
だから、原因となった設定を戻せば即座に全復旧する、とは限りません。
4．掛け算――便利さの集中は、被害の集中でもある
社会全体の影響を考えるなら、単純化して、
期待損失 = 障害の発生確率×発生した場合の損失
と捉えられます。
共通基盤にまとめることで、運用を効率化し、個別の障害確率を下げられる場合があります。一方で、そこに依存する業務が増えれば、一度止まったときの損失は大きくなる。これはマイクロソフトだけに限らない、集中型の基盤が抱える設計上の問題です。
したがって、「普段どれだけ止まらないか」だけでは足りません。止まったとき、どこまで巻き込むかも評価する必要があります。
結論――本当に設計すべきなのは「壊れ方」
数学から見えるのは、むしろ次の構造です。
効率を上げるために共通化した仕組みが、障害時には共通の弱点になる。そこに処理能力の限界と再試行が重なると、局所的な不具合が大規模障害へ育つ。
対策の中心は、単にサーバーを増やすことではありません。変更を一斉配布せず段階的に適用する、障害を小さな範囲に閉じ込める、再試行を抑える、一部機能を落として重要機能を残す、といった「全停止に至らせない設計」です。Microsoft Learn／Google SRE
「絶対に壊れない巨大な一つ」を目指すより、「一部が壊れても、残りで仕事を続けられる構造」をつくる。これが本質です。
コメント