Google Cloud Platformで起きた障害から学ぶこと
~マルチリージョン、マルチクラウド環境の整備

による投稿 2019年6月8日
2019年6月10日

重要なアプリケーションやサービスのクラウド移行により、実質的なインフラ構築と運用の負荷を軽減することができます。しかし一方、クラウドは、インターネットとの接続性が非常に複雑であるため、予測が困難な事象が頻繁に発生しています。不運にもその事象により自社のサービスに影響が及んでしまった場合には、その現実を思いしらされます。

2019年6月2日の午後12時頃(米国西海岸標準時)、ThousandEyesはGoogleのネットワーク障害を検知、Google Cloud Platformの米国の一部の地域でホストしている社内サービスに影響が生じました。最終的にサービス停止は4時間以上続き、YouTube、G Suite、Google Compute Engineなどのさまざまなサービスへのアクセスにも影響を及ぼしました。以下は、ThousandEyesから見えた世界と、クラウドに移行する際のレジリエンスと可視性についてどのように考えるべきかをまとめたものです。

障害発生初期

ThousandEyesは、6月2日午後12:00過ぎに発生したGCPでの障害時に、ユーザー側で受けた影響とマクロ的なネットワーク側への影響の両方を検知しました。それとほぼ同時に、ソーシャルメディアとDowndetectorでも、ユーザーからの最初の投稿が開始されていました。図1は、CDNのエッジネットワークを介して配信されているコンテンツ(GCP us-east4-cのGCEインスタンス上にホスト)へのアクセスを監視していた図ですが、ThousandEyesが170都市に配置した249のグローバル監視エージェント(クラウドエージェント)から見た障害状況を示しています。

図1:6月2日午後12時に障害発生、GCP us-east4-cに接続している世界中のユーザーに影響
図1:6月2日午後12時に障害発生、GCP us-east4-cに接続している世界中のユーザーに影響

図2は、世界各国からGCP us-west2-aにホストされているサイトにアクセスした際のパケットロス(100%)を示しています。

図2:ThousandEyesのグローバル監視エージェントとGCP us-west2-aのGCEインスタンスでホストされているコンテンツ間のパケットロス
図2:ThousandEyesのグローバル監視エージェントとGCP us-west2-aのGCEインスタンスでホストされているコンテンツ間のパケットロス

さらにマクロレベルでも、Ashburn、Atlanta、Chicagoなど、米国東部のネットワークの問題を確認することができました。 例として、図3にGoogleネットワークのトポロジマップを示します。 左側の水色のノードは、Googleにホストされている一番右側の2つのドメインにアクセスする送信元インターフェイスの数を示しています。 これらの2拠点間にある15のインターフェース上で、ソースインターフェースからサービスドメインへの到達を妨げる深刻なパケットロスが発生しています。 興味深い補足として、図3のトポロジマップの下段では、インドのGoogleネットワークでもネットワーク接続の問題が発生していることがわかります。

図3: 15のインターフェイスでのパケットロスが、左に表示されている米国東部からのアクセスに影響。
図3: 15のインターフェイスでのパケットロスが、左に表示されている米国東部からのアクセスに影響。

下の図4に示すように、パスの可視化により右側のGoogleのネットワークエッジでトラフィックが落ちていることがわかりました。 実際、4時間以上のサービス停止のうち3.5時間の間、GCP us-west2-aにホストされているサービスへのアクセス上で100%のパケットロスが検知されました。 また、us-east4-cを含むGCP US 東部のその他のリージョンにホストされているサイトでも同様のロスが見られました。

図4:Googleのネットワークエッジでのパケットロスが多い状況
図4:Googleのネットワークエッジでのパケットロスが多い状況

ただし、本障害の影響を受けた全てのリージョンでの現象が一様なわけではありません。 たとえば、下の図5は、GCP us-west1にホストされている別のサービスが、この障害の間も問題なく利用可能であることを示しています。

図5:障害の影響を受けていないGCP us-west1でホストされているサービス
図5:障害の影響を受けていないGCP us-west1でホストされているサービス

さらに、米国だけでなくヨーロッパや他の地域でも、ほとんどのGCPリージョンで障害の影響を受けませんでした。 たとえば、図6は、オランダにあるeurope-west4リージョンが、障害発生中も到達可能なままであったことを示しています。 緑色のステータスは、ThousandEyesのグローバル監視エージェントがそのリージョンへのアクセス中にパケットロスを検知していないことを示しています。

図6:GCP Europe West 4リージョンにアクセスしているユーザーには影響なし。
図6:GCP Europe West 4リージョンにアクセスしているユーザーには影響なし。

Googleによる分析

Googleは早い段階でこの問題を認識しており、図6に示すように、午後12時25分にGoogle Compute Engineでの問題発生を発表しました。その後、午後12時59分にサービスの影響がより広範なネットワークの問題に関連していると更新しました。 午後1時36分までに、Googleはこの問題を米国東部で発生した重度のネットワーク輻輳に関連していると発表しました。この発表は初期の段階で見られたパケットロス増加の現象と一致しています(図2参照)。

図7:グーグルは午後12:25に最初に問題をステイタスページに報告。
図7:グーグルは午後12:25に最初に問題をステイタスページに報告。

サービス復旧

午後3時30分ごろから、図8に示すように、GCP us-west2-a上のサービスへのアクセスにおいて、パケットロスの緩和とサービスへの到達性の改善が見られ、さらに次の1時間にわたって復旧に向かいました。

図8:us-west2-a上のサービスへの到達性は、午後3時30分頃から改善され始める。
図8:us-west2-a上のサービスへの到達性は、午後3時30分頃から改善され始める。

図9に示すように、サービスは午後4時45分までには完全に復旧したようです。

図9:午後4時45分のus-west2-a上のサービスの可用性。
図9:午後4時45分のus-west2-a上のサービスの可用性。

午後5時9分、Googleは、図10に示すように、影響を受けたすべてのユーザーについて、午後4時の時点でネットワークの輻輳問題が解決されたと発表しました。そしてこの問題のさらなる内部調査も約束しました。

図10:Googleは、午後4時に問題が解決したことを発表。
図10:Googleは、午後4時に問題が解決したことを発表。

クラウドユーザーが取るべきアクション

今回の事象のように、クラウド障害が及ぼす影響はアクセス先やホスト先によって様々です。クラウド障害事例から学ぶサービス継続のための最も重要な対策の1つは、将来の再発回避のために、クラウドアーキテクチャを、マルチ・リージョンベースでもマルチ・クラウドベースでも十分なレジリエンスを備えているかを確認することです。システムをオンプレからクラウドに移行したとしても、ITインフラやサービスの停止を常に想定することが必要です。

クラウドとインターネットは、大規模なインフラである上、複雑で無数に相互接続されているため、その構造の性格上予測不能になりがちです。クラウドはビジネスのあらゆるシーンで、ITを実行するための有効な手段であることは間違いありませんが、万全な準備無くして利用するにはリスクがあります。ビジネスを支えるインフラやソフトウェア、そしてネットワークの複雑さと多様性が増していることを考えると、その時その時の事象を瞬時に把握し、迅速に解析を行うためのタイムリーな可視性が必要です。

ただし、だからと言って、FAANG (Facebook/ Amazon.com/Apple/Netflix/Google) のような巨大企業規模のインフラ・エンジニアリングチームが必要というわけではありません。ThousandEyesのような可視化ソリューションの導入により、自社インフラのみならずインターネットを超えたクラウドインフラからSaaS、サードパーティーAPIプロバイダの監視が可能になります。

なお、その後のGoogleからの説明につきましては下記の記事をご参照ください。https://japan.zdnet.com/article/35138018/