大規模障害事例から学ぶ（その２）: Google (Mar, 2019)

話題となった大きなシステム障害を参考にそこから見えてくることを「他山の石」として、学んでみたいと思います。

今回は、2019年3月に発生したGoogle の障害です。具体的な障害内容は、文末の参考リンク（記事一覧）を参照してください。

障害概要（事実ベース）

発生事象

2019/3/12 18:40 - 22:50(PDT) Gmail, Google Drive などが利用不可や処理遅延が発生

障害の原因

BLOB(Binary Large Objects)ストレージサービスが高負荷となったため
- ストレージリソースのリソース枯渇の可能性を検知
- ストレージリソースの設定変更をSREsが実施
- 設定変更を契機にデータを検索するサブシステムが高負荷となってしまった(想定外の事象)
- SREs チームは、設定変更の中止を行い、BLOBストレージの回復処置を実施

今後の対応策

同様なトラブルを防止するため、障害がグローバルに影響を与える可能性が低くなるようストレージサービスの領域の分離を実施
高負荷が原因のカスケード障害から回復するためのプロビジョニングの仕組みの改善
システムの主要部分が過負荷になるような構成変更を防止するソフトウェア対策の実施
メタデータストレージシステムの負荷制限動作を改善（過負荷時を適切に低下）

この障害から得られること（勝手なポストモーテム）

ネット上から得られる情報のみで勝手にポストモーテムを作成してみます。

教訓

カスケード障害発生の前兆を素早く判断し対応できるようにしよう
- この障害では、SREsが実施した設定投入をすぐに取り消し、トラフィック制限を実施してリカバリ処理を行いサービスを再開することができている
監視項目の定期的な棚卸しとアラート発生時のアクションの明確化

想像する真の原因

1. 構造上の問題からカスケード障害発生の可能性があった

この障害でSREsがリソースを減らす設定変更を実施したことが、システムの重要な部分に過負荷を与える副作用が含まれていた。この負荷の増大は次々に障害を引き起こし始めた。ここには２点問題があると思う。

ある設定変更が想定外の領域に影響が与えることが明確になっていなかったのではないだろうか
システム間の影響の波及範囲の広さ

2. 監視しきい値の設定と警告時の初動の妥当性

BLOBストレージサービスのリソース使用量が増加している、と言うアラートが今回のトラブルの起点。SREsはそのアラートに従って、直接的にリソース使用量の設定変更を実施したと思われる。アラートが通知された、と言うことは何らかのしきい値設定がされていたはずで、そのしきい値超過でどのようなアクションを取るのか正しく定義されていたのだろうか

SREs として考慮していくべきこと

この障害に対し、SREsとして考慮すべき点を「SRE本（サイトリライアビリティエンジニアリング―Googleの信頼性を支えるエンジニアリングチーム）」から考えてみます。　※章番号とタイトルは、SRE本の参照箇所です。

12章効果的なトラブルシューティング

12.2.2 トリアージ
12.2.4.2 「何が」「どこで」「なぜ」と尋ねる

問題のレポートを受けたら次に何をすべきかをはっきりさせること

この章では、根本原因を突き止めるのではなく、「行うべきなのはシステムがその環境下でできる限りうまく動作するようにすること」と明言している。この障害でのGoogle SREs はまさにこの行動を取ることができていると思う。

13章緊急対応

13.3 変更が引き起こした緊急事態

Google のインフラストラクチャの規模と複雑さゆえに、すべての依存関係や関連性を予測することは不可能であり、設定変更が完全に計画通りには進まないこともあります。

ここに書いてある障害が発生したこととなる。事例は異なるが、この対応で学習したことを今後へ生かすようにする必要がある、と説明されている。

22章カスケード障害への対応

22.1 カスケード障害の原因及び回避のための設計

カスケード障害を回避するようなシステム設計は、簡単ではない。GitHubの事例も同様である。Google のレポートでは、影響範囲を絞り込む設計をするとなっている。

本家SREsの今回の行動は非常に勉強になります。異常の通知で処置を行った結果、カスケード障害が発生しそうになりましたが、すぐに手作業でリカバリを短時間で完了させており、効果的な緊急対応が冷静にできていると思います。さらに、SREチームとして取り組む今後の対策で挙げられている４点についても参考になる事例と思います。