5日前、インターネットは大混乱に見舞われた。世界中の広範囲でYouTubeが途切れ、Shopifyストアは閉鎖され、Snapchatは消えた。そして何百万人もの人々がGmailアカウントにアクセスできなくなった。これらの混乱はすべてGoogle Cloudに起因しており、Google Cloudは長時間の障害に見舞われていた。そのため、Googleのエンジニアは修正プログラムを提供できなかった。こうして、午後から夜にかけて、インターネットは深刻なウロボロスに囚われた。Googleはクラウドを修復できなかった。Googleのクラウドが壊れていたからだ。
Googleが今週説明したように、今回の障害の根本原因はごく平凡なものでした（もちろん、ハッカーによるものではありません）。日曜日の午後2時45分（東部標準時）、同社は通常の構成変更、つまり特定の地域にある複数のサーバーを対象としたメンテナンス作業を開始しました。このメンテナンス作業が発生すると、Googleは定期的に、これらのサーバーで実行されているジョブを他のマシンに再ルーティングします。例えば、Targetでレジが閉まった際に顧客が列を移動するのと同じです。あるいは、重要な点として、メンテナンスが終わるまでこれらのジョブを一時停止することもあります。
その後に起こったことは技術的に複雑で、2つの設定ミスとソフトウェアのバグが連鎖的に発生しました。しかし、結果は単純でした。小規模なサーバー群が一時的に停止する代わりに、Googleの自動化ソフトウェアは複数の拠点でネットワーク制御ジョブのスケジュールを解除しました。Googleのクラウドを通過するトラフィックを、リンカーントンネルに近づく車のようなものだと想像してみてください。その瞬間、トンネルの容量は実質的に6つから2つに減少しました。その結果、インターネット全体が渋滞しました。
それでも、数分間は安定していました。Googleのネットワークは「フェイルスタティック」設計になっており、コントロールプレーンのスケジュールが解除された後でも、短時間であれば正常に動作します。しかし、それだけでは十分ではありませんでした。東部標準時午後2時47分には、次のような事態が発生しました。
日曜日のGoogle Cloudの障害がどこから始まったのか、ぜひ見つけてみてください。ThousandEyes
このような瞬間、すべてのトラフィックが同じように失敗するわけではありません。Googleは、沈み始めると救命ボートが特定の順序で満員になるように、自動化システムを導入しています。「ネットワークが混雑したため、当社のネットワークシステムはトラフィックの過負荷を適切にトリアージし、レイテンシの影響を受けにくい大きなトラフィックをドロップすることで、レイテンシの影響を受けやすい小さなトラフィックフローを確保しました」と、Googleのエンジニアリング担当バイスプレジデント、ベンジャミン・トレイナー・スロス氏はインシデント報告書に記しています。「これは、最悪の交通渋滞の中でも緊急の荷物を自転車で配達できるようなものです」。リンカーントンネルを思い浮かべてください。
様々なサービスで発生したダウンタイムにおいて、Googleがどのように優先順位をつけたかが分かります。Sloss氏によると、Google Cloudはトラフィックの約3分の1を失い、Shopifyなどのサードパーティサービスがダウンした原因となっています。YouTubeは1時間で視聴回数が2.5%減少しました。Gmailユーザーの1%に問題が発生しました。Google検索は問題なく動作し、最悪の場合でも検索結果の表示速度がほとんど感じられない程度に低下しました。
「検索ワードを入力してもすぐに反応がなければ、Yahooとかに行きます」と、デジタルエクスペリエンス・モニタリング企業ThousandEyesの副社長、アレックス・ヘンソーン＝イワネ氏は語る。「だから、それが優先されたんです。レイテンシーに敏感だし、たまたま収益源でもある。ネットワークにおいて、これは驚くようなビジネス上の判断ではありません」。Googleは、顧客よりも自社サービスを優先したのではなく、スロス氏がブログで指摘した各サービスの別の地域からの運用能力への影響だと主張している。
しかし、こうした決定は、先週ご覧になったようなサイトやサービスだけに適用されるわけではありません。こうした状況では、Google はユーザートラフィックだけでなく、ネットワークのコントロールプレーン（ネットワークにトラフィックのルーティング先を指示する）や管理トラフィック（例えば、インターネットの大部分をオフラインにする設定上の問題などを修正するために Google のエンジニアが必要とする管理ツールを含む）も考慮して、優先順位付けを行う必要があります。
「管理トラフィックは非常に膨大になる可能性があるため、常に注意が必要です。管理ツールに何か問題が発生した場合、ネットワークを圧迫する可能性があるため、管理トラフィックを優先するのは少し不安です」とヘンソーン＝イワネ氏は言います。「ネットワーク管理では、一種のジレンマに陥るのです。」
まさに日曜日に起こったことです。Googleは、エンジニアが2分以内に問題を認識したと述べています。しかし、それにもかかわらず！「混雑したネットワークを巡ってツールが競合し、障害が発生したため、問題のデバッグは著しく妨げられました」と、同社は詳細な事後分析で述べています。「さらに、障害の範囲と規模、そしてネットワークの混雑によるツールへの付随的な被害により、当初は影響を正確に特定し、顧客と正確にコミュニケーションをとることが困難でした。」
Google Cloudの障害は世界中のエンドポイントに影響を与えました。ThousandEyes
ヘンソーン＝イワネ氏が「戦場の霧」と呼ぶこの状況により、Googleはトラブル発生から数時間後の東部標準時午後4時1分まで診断結果をまとめることができませんでした。さらに1時間後の東部標準時午後5時3分には、Googleは状況を安定させるための新しい設定を導入しました。東部標準時午後6時19分にはネットワークは回復し始め、東部標準時午後7時10分には通常通りの運用に戻りました。
Googleは、同様のネットワークのブラウンアウトが再発しないよう、いくつかの対策を講じました。メンテナンス中にジョブのスケジュールを解除する自動化ソフトウェアをオフラインにし、「適切な安全対策が講じられるまで」グローバルなインシデント発生を防ぐため、ソフトウェアを復旧させないと発表しました。また、システムが「フェイルスタティック」モードを維持する時間を延長しました。これにより、Googleのエンジニアは、顧客が影響を感じる前に問題を解決するための時間をより多く確保できます。
それでも、Googleをはじめとするクラウドプロバイダーが、今回のようなサービス停止を完全に回避できるかどうかは不明だ。ネットワークの容量は無限ではない。ネットワークは、負荷がかかった際に、何を継続し、何を停止するかを自ら選択する。そして、Googleのクラウド障害で注目すべき点は、同社の優先順位付けの方法ではなく、何が問題だったのかを非常にオープンかつ明確に説明してきた点にある。3月にFacebookが1日に数時間にわたるダウンタイムに見舞われたのと比較してみてほしい。Facebookは、このダウンタイムを「サーバー構成の変更が一連の問題を引き起こした」と説明している。
いつものように、最近のクラウドベースのダウンタイムを思い出すと、インターネットで経験することの多くは、少数の企業が所有するサーバー上に存在し、企業は人間によって運営されており、人間はミスを犯し、その一部は、合理的に思えるよりもはるかに大きな波及効果をもたらす可能性があるということが分かります。
このストーリーは、Google からの背景情報を追加し、サービスがオンラインに戻るまでのタイムラインを修正するために更新されました。
WIREDのその他の素晴らしい記事
- 白人だけの町の暗号通貨を使った分裂的な実験
- エイリアンについて知りたいこと、そして知っておくべきすべてのこと
- 初期段階のVCが投資先を決定する方法
- デジタルライフを守るための4つの最高のパスワードマネージャー
- 室内で安全に投げられるブーメランの作り方
- 🏃🏽♀️ 健康になるための最高のツールをお探しですか？ギアチームが選んだ最高のフィットネストラッカー、ランニングギア（シューズとソックスを含む）、最高のヘッドフォンをご覧ください。
- 📩 毎週配信されるBackchannelニュースレターで、さらに多くの内部情報を入手しましょう
