Google Compute Engine、全世界のリージョンが同時に外部とのネットワーク接続を失うという深刻な障害が発生。ネットワーク管理ソフトウェアにバグ

クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン（Google Compute Engineでは「ゾーン」）にシステムを分散して配置することで、クラウドの障害の影響を受けない高い可用性を備えたシステム構築ができる。これはクラウド（IaaS）に対応したシステム構築におけるもっとも基本的な考え方です。

しかし先週、2016年4月11日にGoogle Compute Engineで発生した通信障害は、アベイラビリティゾーンどころかリージョンの境界も越え、世界中にあるすべてのリージョンのインスタンスが同時に外部とのネットワーク接続を18分間に渡って失うという、Google Compute Engineの利用者にとって防ぎようのない非常に深刻なものでした。

クラウドの運用では高い実績を持つはずのGoogleらしくない障害はなぜ起きたのか。Google Cloud Statusにポストされた報告「Google Compute Engine Incident #16007」で、その背景や経緯が解説されています。

ここではそのGoogleによる報告の概要をまとめました。

障害の概要

4月11日月曜日、太平洋標準時の午後7時9分から午後7時27分まで、Google Compute Engineへのインターネットからのインバウンド通信は正しくルーティングされなかった。その結果、ネットワーク接続に依存しているサービスは動作不良となり、またVPNやL3ロードバランサーも同様に動作不良となった。

加えて、アジア東1リージョンで提供されていたCloud VPNも午後6時14分から接続が失われ、同じく午後7時27分に復旧した。

この障害はGoogle Compute Engineのみで発生し、Google App Engine、Google Cloud Storage、Google Cloud Platformの各種サービスでは発生していない。またGoogle Compute Engine内での仮想マシン相互の通信でも障害は発生しておらず、アウトバウンド通信でも発生していない。

障害の背景とネットワーク管理ソフトウェアのバグの発生

GoogleではIPブロックと呼ぶ一連のIPアドレスを、Google Compute Engineの仮想マシン、ロードバランサー、Cloud VPNなどさまざまなサービスが外部と接続するために利用している。

IPアドレスのブロックがBGPで外部に通知されることで、外部のサービスはGoogleのサービスを見つけることができるようになっている。

このBGPによる通知の性能を最大化するため、Googleのネットワークシステムは複数の異なる場所から同じIPアドレスのブロックをインターネットに通知している。そのおかげでユーザーは自分にもっとも近い場所からこの通知を受け取ることができ、また、万が一もっとも近い場所との接続が途切れても、二番目に近い場所からの通知を受け取れるため、この仕組みは信頼性の向上にもつながっている。

4月11日午後2時50分。Googleのエンジニアは、使われなくなったGoogle Compute EngineのIPブロックをネットワークのコンフィグレーションから削除。その内容をGoogleネットワーク内の自動通知システムに設定した。こうした変更で問題が起きたことはこれまでなかった。

しかしこのとき、ネットワークコンフィグレーション管理用ソフトウェアがコンフィグレーションの不整合を検知する。そのタイミングは偶然にも、あるコンフィグレーションではIPブロックが削除されているものの、もう1つのコンフィグレーション管理ソフトウェアにはまだこの変更が通知されていない、というものだった。

ネットワーク管理ソフトウェアはこの不整合を解決するために、新しいコンフィグレーションを適用せず、直前のコンフィグレーションに戻るよう、フェイルセーフに設計されていた。

ところが、これまで使われることのなかったこの部分のソフトウェアのバグが発生する。直前のコンフィグレーションに戻る代わりに、新しいコンフィグレーションからすべてのIPブロックを削除したものを適用して、その設定を伝播させはじめたのだ。

セーフガードをも障害がくぐり抜けていく

Googleにおける基本原則は「守りを深くしろ」（defence in depth）である。Googleのネットワーキングシステムもこれに則り、数多くのセーフガード機能によって不正確もしくは不正なコンフィグレーションを防ぐようになっている。

セーフガードにはコンフィグレーションの検知工程（Canary Step）も備わっており、コンフィグレーションがあるサイトにデプロイされたらそれが正しく動作するのかが確認され、そのうえで順次展開していく。明らかに不正なコンフィグレーションは、広く伝播される前に検知されるようになっていた。

本件においても、新しいコンフィグレーションは不正であることがこの検知工程によって検知された。しかし致命的なことに、ネットワーク管理ソフトウェアの2番目のバグによって、この検知工程の結果がコンフィグレーションの伝播機構に対して通知されなかった。結果として新しい（不正な）コンフィグレーションが伝播されていく。

新しいコンフィグレーションが展開されるにつれ、IPブロックを外部に通知していたサイトが通知を止めていく。やがてネットワークに組み込まれたフォルトトレランス機構が機能し始め、Google Compute Engineに送られてくる外部からのトラフィックを、生き残っているサイトへ送り始めた。

外部からのトラフィックが失われた

内部モニタリング機能は2つのアラートを発し始めた。

1つ目のアラートは、アジア東1リージョンのCloud VPNが停止したことだった。

2つ目はユーザーのレイテンシが異常値にまで上昇したことだ。これはまだ残っているサイトにトラフィックが集中したためだった。

19時7分に、IPブロックを外部に通知していた最後のサイトも新しいコンフィグレーションを受け取り、通知を停止した。19時9分には95％以上のパケットが失われるようになり、モニタが数秒で大量のアラートを発生しはじめたためにアジア東1リージョンのCloud VPNの調査をしていたGoogleのエンジニアが、障害の影響は幅広く、しかも深刻であることを認識する。

訓練通りにコンフィグレーションを戻すことで復旧

Googleのエンジニアは訓練通り、以前正常動作していた時点のコンフィグレーションに戻すことを決断。すぐさま実行することで18分後に障害から脱した。

復旧直後からすべてのコンフィグレーションを凍結、まずシステムが正常動作しているかを確認し、問題ないことを確認すると、夜を徹して原因調査に取りかかり、翌4月12日午前7時には原因を突き止めた。

さらなる防護策を約束

この報告の冒頭では、次のように謝罪と対応の言葉があります。

We recognize the severity of this outage, and we apologize to all of our customers for allowing it to occur.

私たちはこの障害の深刻さを認識しており、こうしたことを起こしてしまったことをすべてのお客様にお詫びする。

As of this writing, the root cause of the outage is fully understood and GCE is not at risk of a recurrence. In this incident report, we are sharing the background, root cause and immediate steps we are taking to prevent a future occurrence.

この報告を書いている時点で障害の根本原因は明らかになっており、GCEでの再発生のリスクはない。このインシデントリポートにおいて、私たちはその障害の背景、根本原因、そして再発防止のための速やかな取り組みについてをお知らせする。

Additionally, our engineering teams will be working over the next several weeks on a broad array of prevention, detection and mitigation systems intended to add additional defense in depth to our existing production safeguards.

加えて、私たちのエンジニアリングチームは今後数週間、幅広い防止、検知、緩和の機構とさらなる深い守りを、既存の防護策に加えるべく取り組む予定だ。

なお、この障害の影響を受けた顧客には、月額料金の10％から25％に相当する利用権が付与されるとのこと。