大規模 SaaS 障害の事後分析：単一障害点はどこにあったか

要点

大規模障害の多くは、冗長化の想定から漏れていた単一障害点に起因する。事後分析の価値は個別事象の記録ではなく、再発防止策を構造化することにある。

単一障害点はなぜ見落とされるのか

公開されているポストモーテムを横断的に見ると、障害の多くは冗長化されているはずのコンポーネントが、実は共通の依存先を持っていたことに起因している。個々のサービスは独立して冗長化されていても、認証基盤やDNS解決といった下位のレイヤーが単一の経路に集約されていると、そこが障害点になる。可用性・信頼性設計の標準文献（Google の Site Reliability Engineering 公表資料など）も、依存の隠れた集中を単一障害点の代表的な原因として挙げている。

フェイルオーバーが機能しない理由

ただし、単一障害点を特定するだけでは不十分である。フェイルオーバーの仕組み自体が用意されていても、実際に切り替えテストを定期的に行っていなければ、いざというときに機能しないことが多い。可用性設計の標準的な文献でも、設計された冗長性と検証された冗長性は別物であると強調されている。復旧手順書が形骸化し、担当者の異動によって手順の実態と乖離しているケースも珍しくない。

自社に応用するための視点

他社の障害事例から学ぶ際は、表面的な原因の模倣ではなく、依存関係がどこで隠れて集中しているかを自社のシステムに当てはめて考える視点が重要である。CI パイプラインの間欠障害で見られたキャッシュ肥大のように、平常時には見えない構造的な弱点は多くのシステムに共通する。インフラをセルフホストするかマネージドにするかという選択も、この単一障害点の位置を大きく左右する。

フェイルオーバーは設計するだけでなく、定期的に実際に切り替えて検証しない限り、機能する保証はない。