6月2日午前11時45分〜午後3時40分（米国太平洋時間）までの約4時間、Googleの米国内ネットワークで障害が発生し、Google CloudのCompute EngineやCloud Storage、さらにYouTubeやG Suiteなどもその影響を受けて動作が遅くなったり利用できなくなったりしました。

幸いなことに、障害の状況および時間帯の関係で日本のユーザーへの影響はそれほど大きなものではありませんでしたが、Googleの24x7担当VPであるBenjamin Treynor Sloss氏がGoogle Cloudのブログに記事「An update on Sunday’s service disruption」を投稿。今回の障害について説明を行っています。

ネットワークの輻輳そのものが復旧作業を長引かせた

報告によると、障害の根本的な原因は、サーバの設定操作を誤った結果、想定よりも広範囲のサーバに間違った設定が行われてしまったことだと説明されています。

In essence, the root cause of Sunday’s disruption was a configuration change that was intended for a small number of servers in a single region. The configuration was incorrectly applied to a larger number of servers across several neighboring regions, and it caused those regions to stop using more than half of their available network capacity. 日曜日に発生した障害の原因の根本は、単一リージョン内の数台のサーバに対する設定変更を意図した操作でした。この設定変更が、隣接する複数のリージョンの多数のサーバに対して適用されてしまったことで、これらのリージョンのネットワーク帯域の半分以上を埋めてしまったことにあります。

間違ったサーバ設定が拡散された結果、ネットワークが輻輳を起こし、それが障害の原因になったわけです。ただしなぜ隣接する複数のリージョンにまで拡散してしまったのかについては説明されていません。

そして障害の原因となったこのネットワークの輻輳は、その後の復旧作業をも困難にしていました。サーバの過負荷やネットワークの輻輳という障害の原因そのものが復旧作業も難しくするという状況は障害対応でよくあることではありますが、Googleであっても同じことになるのですね。

Once alerted, engineering teams quickly identified the cause of the network congestion, but the same network congestion which was creating service degradation also slowed the engineering teams’ ability to restore the correct configurations, prolonging the outage. 警告が出された後、エンジニアリングチームはネットワークの輻輳の原因を迅速に突き止めました。しかしサービス低下をもたらしているこのネットワークの輻輳自体が、エンジニアリングチームが正常な設定を行うための復旧作業そのものを長引かせたのです。

時間はかかったものの、最終的にエンジニアリングチームが障害を解消しました。

エンジニアリングチームは現在、今回発生したネットワーク帯域が失われた要因と復旧に時間がかかった要因などをあらためて分析しており、今後の対応に生かすとしています。