Google CloudやYouTubeの障害は「数台のサーバへの設定変更のつもりが、誤って複数リージョンの多数のサーバに適用されてしまった」。Googleが説明

6月2日の午前11時45分（米国太平洋時間。日本時間の6月3日午前3時45分）から15時40分（同日本時間午前7時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.

警告が出された後、エンジニアリングチームはネットワークの輻輳の原因を迅速に突き止めました。しかしサービス低下をもたらしているこのネットワークの輻輳自体が、エンジニアリングチームが正常な設定を行うための復旧作業そのものを長引かせたのです。

時間はかかったものの、最終的にエンジニアリングチームの作業によって障害が復旧されました。

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