Googleは、まず不適切なアクセス制御リストを書いた後、BGPにユーロクラウドを忘れるように指示した。

Table of Contents

Googleは、まず不適切なアクセス制御リストを書いた後、BGPにユーロクラウドを忘れるように指示した。

Google は先週、欧州のクラウドの大部分をオフラインにした経緯を説明したが、いつものように問題は自社自身によって引き起こされたものだった。

12 月 9 日のインシデントは短時間で収束しました。18:31 PT (02:31 UTC) に始まり、84 分間続き、europe-west2-a ゾーンにのみ影響を与えましたが、そのゾーン内の VM の 60 パーセントが外部からアクセス不能になりました。

Google によると、VM の作成と削除の操作は停止中に停止し、停止中にハードウェアまたはその他の障害が発生した VM またはホストは修復されず、正常なホスト上で再起動されなかったという。

Googleは今回、何が問題だったのかを説明した。このインシデントレポートでは、同社のソフトウェア定義ネットワークスタックは、複数のサーバー群にわたって実行される分散コンポーネントで構成されており、耐障害性を実現する設計になっていると説明されている。

「これを実現するために、コントロールプレーンはマシンのプールからリーダーを選出し、さまざまなインフラストラクチャコンポーネントに構成を提供します」と説明には記されている。

リーダー選出プロセスは、Googleが「内部ロックサービス」と呼ぶローカルインスタンスに依存しています。このサービスは、サービス内に保存されている様々なファイルの読み書きを制御するためのアクセス制御リスト(ACL)メカニズムを提供します。

YouTube 壊れた猿

Googleがインターネットから消えたため、世界と犬が集団パニックに陥る

続きを読む

しかし、Google の誰かまたは何かが ACL を変更したため、リーダーを選択するプロセスはジョブに必要なファイルにアクセスできなくなりました。

ネットワークを牽引するリーダーがいないため、この地域は危機に陥っていました。

設計上、障害は即座に発生するものではありませんでした。しかし、Euro-cloud がリーダーを選出できなかった数分後、「europe-west2-a と Google バックボーンネットワークの残りの部分との間の BGP ルーティングが停止され、ゾーンが分離され、ゾーン内のリソースにアクセスできなくなりました。」

Googleは、障害の原因について、「以前のメンテナンス中に更新されたプロセスを使用して環境が再構築されたため、本番環境にステージング環境やカナリア環境に存在しないACLが含まれていた」と述べた。

この矛盾は、問題を検出するために設計された「カナリア」リグでも、正しい ACL を使用していると思っていたため、問題を検出できなかったことを意味します。

停止は短時間で、主に地域外からのアクセスに影響しましたが、このインシデントにより App Engine、Cloud SQL も影響を受け、一部の Cloud VPN ユーザーが 8 時間にわたって停止しました。

「europe-west2-aゾーンがネットワークに再接続した直後、同ゾーン内の一部のVPNゲートウェイが古くなってVPNコントロールプレーンに複数のバグを引き起こしました」とGoogleは発表しました。「これにより、主要な障害が回復した後も8時間10分間、europe-west2のClassic Cloud VPNトンネルの4.5%が停止しました。」

Google は謝罪し、一部の顧客がサービスレベル契約を行使して補償を求める可能性があることを認めました。

また、同社は、ネットワークACLの一貫性を確保し、ネットワーク制御プレーンが利用できない場合の回復力を向上させるため、すべてのネットワークACLを監査することを約束しました。「最近の変更に対する可視性を向上させることで、緩和策実施までの時間を短縮します」と同社は約束し、「ロックサービスACLにさらなる可観測性を追加することで、ACL変更時の検証を強化します。また、今後同様の変更を行う際には、カナリアテストとリリースのプロセスを改善し、変更が安全に行われるようにしていきます。」®

追記:インターネット大手グーグルのGmailは火曜日に部分的な障害に見舞われ、インターネットサービスが約1時間停止してから1日以内にメッセージが返送される事態となった。

Discover More