停電が引き金となった7分間のカウントダウン
火曜日のBST午前7時8分頃、ロンドンのGoogle Cloudのeurope-west2-bゾーンで地域の送電網障害が発生しました。UPSバッテリーが即座に作動し、教科書通りの対応を見せました。しかし、主電源とバックアップ電源のどちらのコントローラーもディーゼル発電機を起動できず、施設はバッテリー電力のみに頼る状態となりました。
その7分間が致命的でした。データセンターは約7分間バッテリーで稼働しましたが、電力が枯渇し、ゾーン全体が暗闇に包まれました。重要なのは、バッテリー自体が故障したのではなく、発電機の起動システムが機能しなかったことであり、予期せぬ連鎖的な障害を引き起こした点です。
数百万人のユーザーを抱えるフィンテック大手のRevolutは、即座にその影響を受けました。ユーザーからは広範囲にわたる問題が報告されました：
- ログインの失敗
- 送金の停止
- カード決済の拒否
Revolutは当初「サービスの中断」と説明していましたが、後に長時間のダウンタイムの原因をGoogle Cloudにあるとしました。このインシデントは、発電機コントローラーのような単一障害点（SPOF）が重大な混乱を引き起こす可能性がある以上、どれほど高度なクラウドインフラであっても、それに依存することの脆さを浮き彫りにしました。
「正常」とされた2つのゾーンも十分ではなかった
マルチゾーンリージョンは回復力を約束します。1つのゾーンがダウンしても、ワークロードは他のゾーンに移行するはずです。ロンドンのGoogle Cloudのeurope-west2リージョンには、a、b、cの3つのゾーンがあります。ゾーンbがダウンした際、システムはシームレスにaとcへフェイルオーバーし、サービスを維持すべきでした。
しかし実際には、急激なトラフィックの急増が残りのインフラに過負荷をかけました。これは単純な切り替えではなく、キャパシティの問題であり、調整の悪夢でした。ゾーン間の依存関係により、ゾーンaとcの一部のサービスは、オフラインになったゾーンbに関連するコンポーネントや状態を待ち続け、停止したままでした。
エンジニアリングの教訓は明白です。冗長性は、ゾーンが真に独立しており、現実的なフェイルオーバーの嵐を吸収できる十分な余裕がある場合にのみ有効です。レート制限、グレースフル・デグラデーション、そして厳格にテストされた復旧計画は、「サンダリング・ハード（群れによる過負荷）」がリージョン全体をダウンさせるのを防ぐために不可欠です。
Googleの復旧はRevolutよりも早かった
Googleのインフラ復旧の速さは、顧客のサービス即時復旧には直結しませんでした。Googleは、ほとんどのクライアントがインシデント開始から約6〜8時間後のBST 13:00〜15:00の間にオンラインに戻ったと報告しました。しかし、Revolutがサービスの完全復旧を発表したのはBST 18:40であり、数時間の大きな遅れが生じました。
この格差は、重要な違いを明らかにしています。クラウドのキャパシティを復旧させても、クライアントの運用上のバックログが即座に解消されるわけではないということです。計算リソースやストレージが利用可能になっても、Revolutのような金融機関は複雑な課題に直面します。取引状態の照合、決済バックログの解消、そしてカード決済からログインサービスに至るまで、あらゆるアプリケーションの依存関係を正常化するには、時間と慎重な順序立てが必要です。
この障害の影響はRevolutにとどまりませんでした。以下を含む英国の他の機関やサービスでも広範な混乱が報告されました：
- Lloyds
- Halifax
- 遠隔裁判のビデオリンク
この広範な影響は、共有クラウドインフラストラクチャの根本的な脆弱性を浮き彫りにしました。europe-west2-bでの単一ゾーンの障害が広範囲にわたるサービス問題へと連鎖し、局所的な電源トラブルがいかにして相互接続された依存関係を通じて全国的な問題に発展し得るかを実証しました。インシデントの状況に関する詳細は、Google Cloud Service Health Dashboardを参照してください。興味深いことに、規制当局もこの事態を注視しており、Bank of EnglandおよびFCAは、本インシデントの通知タイミングについて調査を受けています。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
クラウド障害は今や銀行業界のリスクである
7月にGoogle Cloudが英国金融システムのcritical third party（重要第三者）に指定されたことで、状況は根本的に変わりました。障害発生後、財務特別委員会の委員長は直ちにBank of EnglandとFCAに対し、通知のタイミングについて説明を求めました。これは単なる技術的な不具合ではなく、システム上のリスクなのです。
金融機関は今、どれほどのレジリエンス（回復力）があれば十分なのかという厳しい問いに直面しています。クラウドプロバイダー、特定のリージョン、あるいはアプリケーション独自のアーキテクチャが集中点となる場合、企業は自らのエクスポージャーを精査しなければなりません。マルチリージョン設計はリスク低減への道筋となりますが、コスト、レイテンシ、複雑なデータ管理といった大きなトレードオフを伴います。
顧客や開発者にとって、実践的な教訓が得られます。インシデント発生時には、常にGoogle Cloudのservice health dashboardを確認してください。そこには最新の情報が掲載されています。エンジニアリングチームは前提条件を疑い、ゾーン喪失のテスト、フェイルオーバー容量の検証、そして性能が低下した動作モードのシミュレーションを行う必要があります。マルチゾーン展開だけでは、継続性は保証されません。
よくある質問
Google Cloudの障害時にRevolutがダウンしたのはなぜですか？
ロンドンのデータセンターで、主電源およびバックアップ発電機のコントローラーが故障し、停電が発生しました。トラフィックは残りのゾーンに移行しましたが、それらのゾーンも過負荷やオフラインとなったゾーンへの依存関係により影響を受けました。
Google Cloudのロンドン障害はどのくらいの期間続きましたか？
Googleによると、影響を受けた顧客のほとんどはインシデント開始から6〜8時間後に復旧しました。Revolutは、サービスが復旧したのはそれより遅いBST（英国夏時間）の18:40頃だったと述べています。
Google Cloudの他のロンドンゾーンでは、なぜ障害を防げなかったのですか？
残りのゾーンは突然のフェイルオーバートラフィックの急増に直面し、一部のサービスは依然として障害が発生したゾーンに関連するコンポーネントに依存していたためです。
この障害は英国の金融サービスにとって何を意味しますか？
主要なクラウドプロバイダーでの障害が金融サービスにどのような影響を与え得るか、そしてなぜ規制当局が重要な第三者プロバイダーを厳しく監視しているのかを浮き彫りにしています。