jtwp470’s blog

日記とかプヨグヤミングとか

Google Cloudの障害レポートを読んだ

つい最近、Google Cloudを利用しているサービスで大きな障害が発生していました。有名なサービスとしてはポケモンGoSpotifyなどがサービス不可の状況になっていたようです。日本国内ではインシデント発生時刻が早朝のためあまり大きな障害はなかったようですが、米国時間ではちょうどお昼ごろのため大きな影響があったと推測されます。

障害と影響範囲

障害自体は2018/07/17 12:17 - 12:55 (PDT) です。日本時間だと 7/18 の早朝 5時台に障害が発生した模様です。

当該時刻にはその他のサービスもエラーを上げていたようで、珍しくステータスダッシュボードが燃えていました。

f:id:jtwp470:20180722184006p:plain

Service Outageになっているサービスは、

の4つでインシデントレポートによると、

  • App Engine にデプロイされているサービス
  • Cloud Functions
  • Stackdriver の Web UI
  • Dialogflow
  • Cloud Support Portal/API

が影響を受けていたようです。

根本的な原因

この障害の根本的な原因はGoogle Cloud Load Balancingの障害によるものでした。 Networkingの障害レポートにROOT CAUSEというセクションがあったため読んでみました。

まず前提としてGoogle Cloudのロードバランサ(Google Front End: GFE)は2層の階層構造を持っているそうです。第1層目がユーザーからのリクエストを直接受けつけ、続いてサービスのデプロイされているリージョンか、アベイラビリティゾーンに存在する2層目のロードバランサーに振り分けられるような構成だそうです。この構成になっていることでエンドユーザーが世界のどこにいてもそのユーザーの一番近い第1層のGFEに接続に行き内部でルーティングされ第2層のGFEを経由してバックエンドサービスに繋がってレスポンスを返すとなっている。とのことです。

f:id:jtwp470:20180722191440p:plain GFEの構成図 (想像)

The GFE development team was in the process of adding features to GFE to improve security and performance. These features had been introduced into the second layer GFE code base but not yet put into service. One of the features contained a bug which would cause the GFE to restart; this bug had not been detected in either of testing and initial rollout. At the beginning of the event, a configuration change in the production environment triggered the bug intermittently, which caused affected GFEs to repeatedly restart. Since restarts are not instantaneous, the available second layer GFE capacity was reduced. While some requests were correctly answered, other requests were interrupted (leading to connection resets) or denied due to a temporary lack of capacity while the GFEs were coming back online.

今回はGFEの開発チームが第2層のロードバランサーにセキュリティと性能の向上する機能を追加しているときに起きた。と書かれています。この機能はコードベースにはマージされていますがサービスインはしていなかったそうです。またこの機能の一部にGFEを再起動させるバグが混入されていましたが、テストや初期のデプロイでは検知できなかったとも書いてあります。実際にこの設定を本番環境に適用したところ、GFEが一気に再起動していき、ロードバランサーの容量不足になり処理ができなくなってしまった。というのが今回のインシデントにつながった。とあります。 f:id:jtwp470:20180722192506p:plain

テストを網羅しているつもりでもテストでカバーできていなかったところのバグが世界的な障害の起因となるというのは怖い話ですがあのGoogleでもやるときはやるんだなー(笑)とも思いました。

まとめ

こういう前段の障害をどう回避するか結構難しい問題かな?と思います。もしやるとすると、GCP以外の他のクラウドにもサービスを投入しておいて障害が出次第、DNS等の設定でGCP側に振り分けないようにするくらいしか対応ができないかなーと思います。もし良さげな方法を知っている方がいたら教えてください。

Publickeyにも情報が日本語で出てきました。 www.publickey1.jp