Gmail障害詳報
Gmailの障害原因がGoogleから発表されましたね。
Googleが運営するメールサービス「Gmail」やオンラインストレージサービス「Google ドライブ」で3月12日（米国時間）、ファイルを添付したメールが送受信しづらかったり、保存したファイルが開きにくかったりする障害が発生した件で、同社が14日、詳しい原因を明らかにした。
原文はこちら。
概要
2019年3月12日火曜日、Googleの内部BLOBストレージサービスで4時間10分サービスが中断しました。このインシデントによってサービスまたはアプリケーションが影響を受けたお客様にはお詫び申し上げます。私たちは、お客様がGoogle Cloud Platformサービスに依存していることを認識しており、可用性を向上させ、この種の機能停止が再発するのを防ぐための早急な措置を講じています。
影響の詳細な説明
2019年3月12日火曜日の18:40から22:50（PDT）に、Googleの内部BLOB（ラージデータオブジェクト）ストレージサービスはエラー率の上昇を経験し、平均20％のエラー率と、インシデント中の短いピークエラーの31％を記録しました。BLOBストレージサービスを利用するGmail、Photos、Google Driveなどのユーザーに表示されるGoogleサービスでもエラー率が上昇しました。ただし、Google Cloud Service (GCS) の場合と同様に、キャッシュと冗長性が組み込まれているため、ユーザーへの影響は大幅に減少しました。サービス このインシデントの影響を受けるGCP以外のサービスについては、別のインシデントレポートがあります。
最も大きな影響を受けたGoogle Cloud Platformサービスは次のとおりです。
・Google Cloud Storageではロングテールの待ち時間が長くなり、平均エラー率は4.8％でした。すべてのバケットの場所とストレージクラスが影響を受けました。Cloud Storageに依存するGCPサービスも影響を受けました。
・Stackdriver Monitoringでは、時系列データの取得中に最大5％のエラーが発生しました。最近の時系列データが入手可能です。警告は影響を受けませんでした。
・App EngineのBlobstore APIでは、BLOBデータのフェッチに関して、待ち時間が長くなり、エラー率が21％に達しました。App Engineの配置では、90％に達するピークエラーが発生しました。App Engineからの静的ファイルの配信でもエラーが発生しました。
根本的な原因
2019年3月11日月曜日、Google SREは、内部BLOBサービスで使用されるメタデータ用のストレージリソースが大幅に増加することを警告されました。3月12日火曜日に、リソース使用量を減らすために、SREはBLOBデータの場所を探すためにシステムの重要な部分を過負荷にするという副作用を持つ設定変更を行いました。負荷が増加すると、最終的にカスケード障害になります。
改善と予防
SREは18:56 PDTにサービスの中断を警告され、設定変更を行っていたジョブをすぐに停止しました。カスケード障害から回復するために、SREはBLOBサービスへのトラフィックレベルを手動で減らし、高負荷のためにタスクがクラッシュすることなく起動できるようにしました。
このタイプのサービスの中断を防ぐために、障害がグローバルに影響を与える可能性が低くなるように、ストレージサービスの領域間の分離を改善します。高負荷が原因のカスケード障害から回復するために、リソースをより迅速にプロビジョニングする能力を向上させます。システムの主要部分が過負荷になるような構成変更を防ぐためのソフトウェア対策を行います。メタデータストレージシステムの負荷制限動作を改善して、過負荷時に適切に低下するようにします。
こんな感じかな？（全部想像）
ここはGoogle SRE（Site Reliability Engineering、サイト信頼性エンジニアリング）、かっこよく言っているが運用センターだ。
Googleのサービスはもちろん、Google Cloud Platform、通称GCPで動いている。GCPの各サービスを監視しながら、GmailやGoogle Driveなど有名なSaaSも監視、変更作業、障害対応などを行っている。
我々のサービスは世界中で使われているし、ビジネスの基盤となっていることを自覚している。単なる運用はなくサイトの信頼性をいかに高めるかがポイントだ。受け身としての作業ではなく、信頼性を高めるためにソフトウェアやコードを積極的に導入している。
さて、我々は先ほど、重要なアラートを受け取った。GCPではGoogle Cloud Storage（GCS）というサービスがある。いわゆるオブジェクトストレージだ。このサービスが内部的に使っているメタデータを管理するリソースが増加しているらしい。
オブジェクトストレージにおけるメタデータは、下記の記事が詳しいので参照頂きたい。
オブジェクトストレージはデータをファイル単位やブロック単位ではなく、オブジェクトという単位で扱います。オブジェクトにはストレージシステムのなかで固有のID（URI）が付与され、データとそれを扱うためのメタデータによって構成されています。 メタデータは通常のファイルシステムでも作成日や作成者などの情報を持っていましたが、オブジェクトではデータの種類、保存期間やコピー回数など、より多くの情報を付加できます。
また、ディレクトリのような階層構造はなく、ストレージプールというオブジェクトの入れ物のみが作成され、メタデータによって管理されます。オブジェクト同士はフラットな関係で、データの移動で階層構造が変わることはありません。また、オブジェクト数に制限はありません。オブジェクトストレージは、一般的に、汎用ストレージを並列化した分散ファイルストレージで構成されており、スケールアウトが可能です。
このように、オブジェクトストレージはデータそのものと、データを区別するためのデータ（メタデータ）から成り立つ。メタデータがなくてはデータにたどり着けないのだ。
さて、このメタデータを管理するリソースが増加している。我々SREはこの増加の現象に対応しなければいけない。リソースが枯渇すればもちろんレスポンスが悪くなる。SREの討議の結果、リソースを減少させる設定を投入することにしたのだ。
この設定を投入した後、SREルームがざわついた。急激にGCS、つまりオブジェクトストレージへのアクセスに対するエラー率が跳ね上がったのだ。GCSはGmailやGoogle Driveが使っていることもあり、広範な障害となってしまった。
このエラーだが、調査によるとSREが投入した設定によって、データを探し出すためのサブシステムが高負荷になってしまったらしい。メタデータ管理関連の設定変更により、データへたどり着くためのプロセスに負荷をかけてしまったようだ。
もちろん、アプリケーションは毎回ストレージを読みに行くわけではなく、キャッシュや冗長性の機能も持たせているので、アプリが全滅となったわけではないが・・・。このまま放っておくとカスケード障害が発生してしまう。いわゆる連鎖的に次々に障害が起こってしまうことを言う。
我々がまず障害対応のためにやってことは、投入した設定の中止だ。そして中止を行った後、オブジェクトストレージへのトラフィックを制限した。どんどんたくさんのシステムがリトライをかけるものだから、ただでさえ負荷がかかる。オブジェクトストレージについていったんクリーンな状態を作り出してから、トラフィックを再開した。何とか回復できた。
反省点としては・・。今回の設定変更がグローバルに障害を及ぼしたことを考えると、もっとリージョンでストレージを分離したほうが良いと思った。分離していれば、世界中に障害が伝播することはなかった。
また、いくら高負荷からカスケード障害が発生しかかったからといって、回復に何時間もかかるようではいけない。すぐに回復できるように、起動するためのリソースをプロビジョニングする時間を早めないと。
また、もともとのトリガーになった、メタデータの管理部分も手を入れなくてはいけない。高負荷が原因のカスケード障害から回復するために、リソースをより迅速にプロビジョニングする能力を向上させます。システムの主要部分が過負荷になるような構成変更を防ぐためのソフトウェア対策を行います。メタデータストレージシステムのリソースに負荷がかかった場合の動作を改善して、過負荷時に適切に低下させないといけない。
（以上、妄想）
考察
ある問題が起きた時、それを解決するために行ったことがさらに新しい問題を広げることを二次被害と言います。ITの世界では二次被害を引かないことは非常に重要に思います。往々にして、始めの被害より二次被害の方が影響が大きくなったりします。そこには人の判断が入るために、対応する人の心理状態も危険です。二次被害を起こしてしまった人は明らかに冷静ではなくなります。しかし責任者だったりもします。
まずは手を動かす前に、一度関係者で深呼吸することが大切でしょうね。
そこから、システム復旧に向けて、リスタートを防ぐ要素を無くすこと。今回の場合はオブジェクトストレージへのトラフィックを思い切って制限しています。こういう判断こそ一番重要だと思います。下手に動いているサービスを延命させようとして、中途半端な対応を続けると「カスケード障害」となってしまいますね。
また、余談ですが今回はオブジェクトストレージの目線から障害が語られていますが、Gmailなどのアプリ目線からはどのような動きをしていたのかが気になりますね。
