クラウドのどこかで障害や災害が発生したとしても、その影響はアベイラビリティゾーンを超えることはなく、そのために複数のアベイラビリティゾーン（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ブロックを削除したものを適用して、その設定を伝播させはじめたのだ。

【次ページ】 セーフガードをも障害がくぐり抜けていく