自分の理解を深めるためにまとめてみました。21章の続きです。
22章 カスケード障害への対応
カスケード障害とは、時間の経過とともに連鎖していく障害のことである。
カスケード障害の原因となるリソースと二次被害
- CPU
- 処理中のリクエスト数の増加
- キューの拡大
- スレッドのスターベーション
- CPUあるいはリクエストのスターベーション
- RPCのタイムアウト
- CPUキャッシュ率の低下
- メモリ
- タスクの停止
- GC＆CPU使用率の増大
- キャッシュヒット率の低下
- スレッド
- 直接的なエラーやヘルスチェックの失敗
- ファイルディスクリプタ
- ネットワーク初期化によるヘルスチェックの失敗
サーバーの過負荷の回避
- 負荷テストを行い、過負荷時の状態を見る。
- 最低限のレスポンスを返す。
- 過負荷時のリクエスト拒否の仕組みを組み込む。
- キューの仕組みを取り込み、キューからはみ出た場合はアクセス拒否する。
- ロードシェディング（過負荷状態に近づくにつれ、トラフィックを意図的にドロップさせる）
- グレースフルデグラデーション（過負荷状態に近づくにつれ、レスポンスの質を落としていく）
- フロント側でリクエストを拒否させる。
- キャパシティプランニングを実施する。
レイテンシとタイムアウト
起動直後の低パフォーマンスとコールドキャッシュ
起動直後はキャッシュが無い状態であるために、パフォーマンスが低下することが多い。そのためには何かしらの対策が必要である。
カスケード障害を引き起こす条件
- プロセスの停止
- プロセスのアップデート
- ロールアウト
- 自然な利用の拡大
- 計画済みの変更、ドレイン、ターンダウン
カスケード障害に備えるためのテスト
- テストによる障害の発生とその後の観察
- 一般的なクライアントのテスト
- 重要度の低いバックエンドのテスト
カスケード障害に対応するためにすぐに行うべき手順
- リソースの追加
- クラウドであれば即時追加、オンプレであれば調達が必要か。
- ヘルスチェックが障害を引き起こさないようにする
- 二次障害を引き起こさないためにも。
- サーバの再起動
- 原因を特定してから再起動しないと原因がわからなくなる恐れがある。
- トラフィックのドロップ
- サーバが安定するレベルまでアクセスを制限し、徐々に制限を解除していく。
- デグレーデッドモードへの移行
- 最低限のレスポンスを返すだけにする。例えばメンテナンス画面とか。
- バッチの負荷の排除
- 思わぬバッチが原因となる場合があるので、普段からバッチの把握は必要。
- 問題のあるトラフィックの排除
- 特定のアクセス元であればWEBサーバ等でブロックしてしまう。
（22章に続く）