Googleは「サーバーレス」をやりすぎたかもしれない：帯域幅を圧迫する設定ミスによる障害

グーグルは、日曜日にアメリカおよび世界の他の地域で４時間にわたって発生した不安定な状況は、サーバーの再設定の失敗が原因だったと発表した。

数時間にわたる障害は、Gmail、YouTube、ドライブ、クラウド仮想マシンホスティングなどのGoogleサービスに影響を及ぼし、UberやSnapchatといったGoogleのシステムに依存するアプリにも影響を及ぼしました。この混乱の間、影響を受けたネットユーザーは、Googleの母体への接続が遅くなり、信頼性が低下し、場合によっては完全に切断されることに気付きました。

エンジニアリング担当副社長のベンジャミン・トレイナー・スロス氏によると、問題はGoogle社員がGoogleのデータセンター地域にある少数のサーバーに新しい設定をプッシュしようとしたことから始まったという。どういうわけか、そのアップデートは他の複数の地域にある多数のサーバーにも適用され、ネットワーク帯域幅の半分以上が失われてしまった。

その結果、システムのパケットが不足し、最終的にはサービスがダウンしたり、ユーザーに対して速度が低下したりするように見えました。

「本質的に、日曜日の障害の根本原因は、単一地域内の少数のサーバーを対象とした設定変更でした」とスロス氏は述べています。「この設定は、隣接する複数の地域にまたがる多数のサーバーに誤って適用され、その結果、これらの地域で利用可能なネットワーク容量の半分以上が使用できなくなりました。その後、これらの地域との間のネットワークトラフィックは残りのネットワーク容量に収まるように試みましたが、うまくいきませんでした。」

Google 24x7のバイスプレジデントは、トラフィックの集中化をほぼ即座に検知したにもかかわらず、ネットワークの過負荷によりエンジニアが壊れた構成を迅速に修復できなかった経緯を説明した。その間、レイテンシの影響を受けにくいトラフィックの優先順位を下げ、インタラクティブでレイテンシの影響を受けやすいパケットを優先的に通過させたという。

「ネットワークが混雑したため、当社のネットワーク システムはトラフィックの過負荷を適切にトリアージし、遅延の影響を受けにくい大規模なトラフィックをドロップして、遅延の影響を受けやすい小規模なトラフィック フローを維持しました。これは、最悪の交通渋滞の中でも緊急の荷物を自転車で配達できるのとよく似ています」と、同氏は続けました。

Googleのエンジニアリングチームは数秒以内に問題を検出しましたが、診断と修正には数分という当初の目標をはるかに上回る時間がかかりました。警告を受けたエンジニアリングチームはすぐにネットワーク輻輳の原因を特定しましたが、サービス低下を引き起こしていたネットワーク輻輳によって、エンジニアリングチームが正しい構成を復元する能力も低下し、障害が長引いてしまいました。

「Google チームは、1 分ごとにユーザーへの影響が 1 分ずつ増えることを痛感し、復旧作業を並行して進めるために追加の支援を求めました。」

その結果、すぐに解決できるはずだった問題が完全に解決するまでに何時間もかかってしまいました。

この間、Slossの推定によると、Google Cloudストレージシステムのトラフィックは30%減少しました（おそらく低遅延の優先順位付けが原因と考えられます）。また、YouTubeの視聴回数は1時間で2.5%減少し、一部の検索クエリも遅くなりました。障害発生中、Gmailユーザーの約1%（約1,500万アカウント）がウェブメールの接続に問題を抱えました。

スロス氏によると、現在、彼のチームはこのインシデントの徹底的な事後調査を行っており、将来の構成の展開時に同様の障害が発生しないように、新しい手順とポリシーを作成することを目指しているという。

「その後、私たちは集中的なエンジニアリングスプリントを実施し、問題の直接的な原因を修復するだけでなく、この事象によって明らかになったあらゆる種類の問題を確実に防ぐようにします」と彼は述べた。®

ブートセクタノート

チョコレート ファクトリーのステータス ページには、現時点ではすべて順調であると報告されていますが、一番下までスクロールすると、次のメッセージを含む警告ボックスがあります。これは、この記事を公開する準備をしているときに発見しました。