何が起こった?　Googleパブリッククラウドの18分間のダウン

原因は、たった2つのバグ

　2日後の4月13日、Googleはインシデントレポートを公開し、経過、原因、そしてGoogleがとった対応を説明した。レポートを執筆したのは、“24x7担当バイスプレジデント”の肩書きを持つBenjamin Sloss Treynor氏だ。

　Treynor氏によると、18分の間、インスタンスへのインバウンドトラフィックのルーティングがうまくいかず、コネクションが落ち、再接続ができなかったという。インバウンドトラフィックの損失によって、同一ネットワークパスに依存するサービスもダウンするという事態を招き、VPNとL3ネットワーク負荷分散もダウンしたとのことだ。

　長いレポートをまとめると、エンジニアのある作業が引き金となり、ネットワーク管理ソフトウェアの2件のバグが誤作動を招いたということだ。

　GCEでは仮想マシン、ネットワーク負荷分散、Cloud VPNなどユーザーやGoogle外とのやりとりが生じるシステムでIPブロックを利用しているが、GoogleエンジニアがGCEのIPブロックをネットワーク設定から削除した。通常なら悪い影響を与えることはない作業だが、その後、削除後の新しい設定を適用する際、IPブロックの削除のタイミングから問題が起こった。

　そこでネットワーク管理ソフトウェアのバグにぶつかってしまう。既存の安全な設定に戻ることなく、すべてのIPブロックを新しい設定から削除。この設定をネットワーク上に伝播させた。

　新しい設定は安全ではないということは検知できたものの、2つ目のバグにより新しい設定は有効であるとみなされ、ロールアウト（運用開始）を始めてしまった。

　Treynor氏は「われわれは多層防御を基本としており、ネットワークシステムはアップストリームの障害やバグに備えて不適切で有効ではない設定を伝播しないよう数々の安全策を講じている」と説明している。「しかし、重要なこととして2つめのバグがプッシュプロセスに戻るという検知ステップの結論を伝播しなかったため、プッシュシステムは新しい設定が有効であると判断して、段階的なロールアウトに入った」という。

　PaaS（Platform as a Service）の「Google App Engine」、ストレージの「Google Cloud Storage」や、ほかのGoogle Cloud Platform製品は、この障害の影響を受けなかった。仮想マシン、HTTP、HTTPS（L7）負荷分散などのGCCサービス間の内部接続、それにアウトバウンドトラフィックも影響を受けていないとのことだ。

　現時点ではルート原因は完全に解明されており、再発するリスクはないとTreynor氏は言う。「この障害の深刻さを十分理解しており、このような事態を起こしてしまったことについて顧客に謝罪したい」と記している。あわせて、Googleは顧客に最大25％の割引を提供するとしている。