20181112 SRE本輪読会#26_22章_カスケード障害

SRE本輪読会 #26
第22章カスケード障害への対応
2018/11/12 インフラ勉強会
nntsugu @nntsugu

自己紹介
● 名前：んんつぐ @nntsugu
● 職業： SaaSやってるスタートアップのインフラENG
● 特技： 24x365 On-Call対応
● 最近の悩みはchromeのタブを閉じきれないこと

Welcome
● ボイスオン、まさかり、何でもwelcomeです。

著者と名言
- 執筆: Mike Ulrich
- The tech lead of the Gmail SRE (2014年当時)
- https://www.usenix.org/conference/srecon14/technical-sessions/presentation/ulrich
- 写真見つからず

著者と名言
- 最初に成功しなかったら、指数的にバックオフすることだ。
- なぜ人々は少しのジッターを加えることをいつも忘れてしまうのか？

22章の内容
● カスケード障害って何？
● カスケード障害を予防するためにできること
○ サーバー過負荷を回避するための戦略・実装を知ろう
○ 高負荷時、フィードバックという複雑系の中で、自分たちのシステムに何が起こるのかを
予測するのは難しい→実際に障害が起こるまで負荷をかけて確認しよう
● それでもカスケード障害は起こる。起こった時の対処方法を準備しておこ
う
○ エラーバジェットの範囲内でサービスを復旧させるための準備をしよう

カスケード障害って何？
22.1 カスケード障害の原因及び回避のための設計
カスケード障害の大部分を占める典型的なケースは3つ
● 22.1.1 サーバーの過負荷
● 22.1.2 リソースの枯渇
● 22.1.3 利用できないサービス

● サーバーが過負荷になる

1000QPS

1000QPS
503 503

● 22.1.2 リソースの枯渇
○ 枯渇しうるリソースは様々(CPU/メモリ/スレッド/ファイルディスクリプタ/ディスクIO…)
○ 枯渇したリソースの種類・原因によって、様々な影響をサーバーに及ぼす
■ 処理遅延によるキューあふれ→新しいリクエストの受け入れを拒否する
■ スローダウンして応答速度劣化→リクエスト元がタイムアウトし、リトライを始める→
リトライの実装次第でさらに状況が悪化する
○ リソース間の依存関係
■ リソースの枯渇は連鎖する
■ そのため、根本原因を特定する事が困難な場合も多い
■ 22.1.2.5の例の場合、バックエンドのリソース枯渇の根本原因が、フロントエンドのGC
チューニングの不味さにあるのだが、そこに辿りつくまでの根本原因っぽい多数の症状
が邪魔をする

○ リソースの枯渇などで一部のサーバーがクラッシュすると、残りのサーバーの負荷が増大
し、”22.1.1 サーバーの過負荷”にあったように、連鎖的にサーバーが落ちていく

○ リソースの枯渇などで一部のサーバーがクラッシュすると、残りのサーバーの負荷が増大
し、”22.1.1 サーバーの過負荷”にあったように、連鎖的にサーバーが落ちていく
○ この状態だと、中途半端にサーバーを復旧させても
■ 上がった瞬間にキャパシティ以上のリクエストを受けてまた死ぬ
■ 応答はできるが、キューがたまりすぎて以降の応答を拒否するレイムダック状態に陥る
■ バランサからのヘルスチェックにタイムアウトしてS-outされる
○ →復旧しようとしたサーバーはモグラたたきのように起き上がろうとする度に倒され続け、
復旧できない状態が続く

過負荷を防ぐための戦略。並びは大まかな優先順位順。
● サーバーのキャパシティの上限のロードテストを行い、過負荷時の障害の状
態を調べる
● 品質を落とした結果を返す
● 過負荷時のリクエスト拒否の仕組みをサーバーに用意する
● サーバーを過負荷に陥らせるよりは、より高レベルのシステムでリクエスト
を拒否する仕組みを用意する
● キャパシティプランニングの実施
カスケード障害を予防するためにできること
22.2 サーバーの過負荷の回避 - 戦略の話

態を調べる
● キャパシティプランニングを実施する

態を調べる
○ 高負荷時、フィードバックという複雑系の中で、自分たちのシステムに何が起こるのかを予
測するのは難しい→実際に障害が起こるまで負荷をかけて確認ておこうというお話
● 大きくわけてやることは3つ
○ 22.5.1 テストによる障害の発生とその後の観察
○ 22.5.2 一般的なクライアントのテスト
○ 22.5.3 重要度の低いバックエンドのテスト
22.5 カスケード障害に備えるためのテスト

● 22.5.1 テストによる障害の発生とその後の観察
○ 障害が起きるまで負荷をかけ、カスケード障害耐性の低いコンポーネントをあぶり出す
○ 様々な負荷のパターンでテストし、情報を集める
■ 負荷を徐々に上げた場合、一気に上げた場合
■ 上限を大きく越える負荷をかけた状態から通常の負荷に落とした時、システムはどうな
っているか？
● 自力でデグレーデッドモードから抜けられるか？
● 複数のサーバーがクラッシュした場合、システムの安定を取り戻すまでにどの程
度の負荷をドロップしなければならないか？
○ 本番環境になるべく近い環境でテストする
■ 場合によっては本番環境でのテストも検討する

● 22.5.2 一般的なクライアントのテスト
○ サービスがダウンしている間、クライアントが処理をキューイングしておけるか。
○ リトライ間隔はジッタでゆらぎを加えた指数的バックオフを使用しているか。
○ クライアントの一斉アップデートでクライアント側のキャッシュがクリアされ、大きな負荷
をかけてくるような脆弱性はないか。
● を、
○ 外部のクライアント／内部のクライアント共に、振る舞いを可能な限り把握／制御しておく

● 22.5.3 重要度の低いバックエンドのテスト
○ 重要度が低い＝それがあってもなくてもサービスの品質がさほど変わらないもの
○ そこに問題が置きた場合でも、サービス全体がひきずられないかを確認するためのテスト

○ グレースフルでグラデーション
○ 過負荷時／高負荷時にレスポンスの品質を落とす
22.2.2 ロードシェディングとグレースフルデグラデーション

E
P
機能A
機能C
機能N
機能B
︙
平常時のAPI

E
P
機能A
機能C
機能N
機能B
︙
過負荷時のAPI

E
P
機能A
機能C
機能N
機能B
︙
過負荷時のAPI
❌
DBアクセスをやめ、キャッシュを使って
処理を行うA

E
P
機能A
機能C
機能N
機能B
︙
過負荷時のAPI
❌
処理を行うA
処理自体をオミットされるB

E
P
機能A
機能C
機能N
機能B
︙
過負荷時のAPI
❌
・タイムアウトの短縮
・EPからのリトライ回数を減らす
その他機能群
処理を行うA
処理自体をオミットされるB

○ ロードシェディング
○ 過負荷になってクラッシュしたり、復旧が困難になるくらいなら、トラフィックをドロップ
してしまう
■ リソースに基づいたタスク単位のスロットリング
■ キューの長さ・タイムアウト値を調整し、過負荷時に頑張って処理してもリクエスト自
体がタイムアウトしてしまい意味がないなどの状態を避ける

● 念頭に置くこと
○ グレースフルデグラデーション
■ キャパシティプランニングの失敗や、予想外の負荷に対して使うもの。
■ →頻繁に行うものではない。(過負荷時に自動でON/OFFできるように)
■ シンプルかつ理解しやすいように保つ
■ 滅多に発生しないものもある。意図的に過負荷状態を作り、動作確認および、運用経験
を培っておくこと
○ デグレーデッドモードになっているかどうかをちゃんと監視しておくこと
○ 複雑なものはそれ自体が問題になりかねない
■ 意図的に、素早くオフにできるようにしておく
■ 必要に応じてチューニングできるようにしておく

態を調べる

○ レートの制限の話。多くの箇所で実装できる
■ リバースプロキシやFW、WAF
● IPアドレスなどの条件に基づき、リクエストの量を制限する
■ ロードバランサー
● 一定量以上のトラフィックを無差別にドロップ
● 選択的にドロップ
■ 個々のタスク
● ロードバランシングによるランダムな変動が発生しても、過負荷に陥らないよう
にする。キューのサイズやタイムアウトを適切なものにする。

○ カスケード障害が発生する可能性を下げるのに有効
■ 実績値から負荷予測を立てつつ、ちゃんとテストする
● データを集めて、未来を予測して、対応できるよう準備する
● ちょっと古いけど攻めの運用の極意のp.31、p.41あたりがわかりやすいかもしれ
ない

● ここまでは戦略の話

過負荷を防ぐための設計の話
● 22.2.1 キューの管理
● 22.2.2 ロードシェディングとグレースフルデグラデーション
● 22.2.3 リトライ
● 22.2.4 レイテンシとタイムアウト
22.2 サーバー過負荷の回避 - 設計の話

● キュー
○ スレッドなどの処理系が渋滞している時のリクエスト置き場
○ あふれたらそれ以上のリクエストを拒否するのが一般的
○ リクエストレートとレイテンシが一定であれば不要なもの
■ Gmailなどの一部タスクではキューが無く、溢れれば他のサーバーへフェイルオーバー
している
○ キューにリクエストをためるということ
■ リソースも消費するし、待ち時間も増える
■ 待たせすぎてリクエストがタイムアウトすると意味が無いので、短めにするのが吉
22.2.1 キューの管理

● リクエストがタイムアウトしたり、エラーが返ってきた場合にすること
● バックエンドが過負荷・不安定時にリトライを繰り返すことで、事態を悪化
させることを避けましょう。というお話
○ “22.5.1”にあるように、障害が発生するまで負荷をかけてテストをしておく
○ リトライ間隔をJitta(ばらつき)を加えた指数的バックオフを利用して散らし、集団死体蹴りを
しない
■ Exponential Backoff And Jitter
○ リトライバジェットの導入
○ リトライが多数のレイヤで行われ、増幅されないようにする
○ リトライを制御するためのレスポンスコード設計
22.2.3 リトライ

● タイムアウト
○ リクエスト元のタイムアウト時間(A)内に処理結果を返せなければ、何の意味もない。
■ フロントエンド、バックエンドといった各レイヤで個別にタイムアウト値を持つと
● (A)を越えてもリソースを消費し続けることになり、無駄。過負荷の要因にもなっ
てしまう
○ 各レイヤでタイムアウトを持つのではなく、リクエストを処理する全体でタイムアウト値を
伝搬し、(A)を越えそうな場合は処理を諦めるなり、レスポンスの品質を下げてでも間に合わ
せるようにする
22.2.4 レイテンシとタイムアウト

● 二峰性のレイテンシ
○ 一部のリクエストがシステム全体の処理を待たせる場合がある
■ Bigtableのある範囲の行が利用できない状態となり、5%のリクエスト(A)がタイムアウ
トする状況になっている。Bigtableを利用しないリクエスト(B)は100msで処理できる。
■ (A)がスレッドを消費しきってしまうと、ひきずられて(B)のレイテンシも大きく遅くな
る
○ 対処ガイドライン
■ レイテンシの平均だけでなく、分散も見て、(A)のようなリクエストを検知する
■ タイムアウトまで待つケースと、すぐエラーを返すケースを明確に分ける
■ 大きすぎるタイムアウト値は使わない
■ 処理が遅くなる可能性のあるリクエストが利用できるリソースを限定する
22.2.4 レイテンシとタイムアウト

● カスケード障害を引き起こす要素
○ 22.4.1 プロセスの停止
○ 22.4.2 プロセスのアップデート
○ 22.4.3 ロールアウト
○ 22.4.4 自然な利用の増大
○ 22.4.5 計画済みの変更、ドレイン、ターンダウン
22.4 カスケード障害を引き起こす条件

● 22.4.1 プロセスの停止
○ 死のクエリ、アサーションの失敗などのアプリケーション内部の問題によるもの
○ クラスタの問題によるもの

● 22.4.2 プロセスのアップデート
○ 新バージョンのバイナリや設定のアップデートにより、一時的にタスク単位での処理能力が
低下し、カスケード障害を引き起こす
○ 一時的にリソースを増やす、トラフィックの低いタイミングにアップデートする、ローリン
グアップデートする

● 22.4.3 ロールアウト
○ なんらかの変更により問題が生じた場合は、すぐにロールバックできるようにしておきまし
ょう。
■ 変更履歴のロギング機能
■ 任意の時点へのロールバック機能
○ があると良い

● 22.4.5 計画済みの変更、ドレイン、ターンダウン
○ 22.4.5.1 リクエストのプロファイルの変化
■ 時間の経過とともにリクエストの傾向は変化する
○ 22.4.5.2 リソースの制限
■ 明示的に確保していないリソースを当てにするのはやめましょう

● カスケード障害が生じていることが判明した場合の対処
○ 22.6.1 リソースの追加
○ 22.6.2 ヘルスチェックが障害を引き起こさないようにする
○ 22.6.3 サーバーの再起動
○ 22.6.4 トラフィックのドロップ
○ 22.6.5 デグレーデッドモードへの移行
○ 22.6.6 バッチ負荷の排除
○ 22.6.7 問題のあるトラフィックの排除
カスケード障害が起こった時の対処方法を準
備しておく
22.6 カスケード障害に対応するためにすぐ行うべき手順

● 22.6.2 ヘルスチェックが障害を引き起こさないようにする
○ 過負荷によって、スケジューラによるヘルスチェックが通らない状態
■ タスクを再起動させると状況が悪化する
■ 一時的にヘルスチェックを停止して、システムの安定を待つ
○ ロードバランサーからのヘルスチェックと、クラスタのスケジューラによるヘルスチェック
はちゃんと区別しましょう
備しておく

● 22.6.4 トラフィックのドロップ
○ カスケード障害から復旧するための対応で、一時的にシステムのキャパシティが低下する際
に検討する
○ 確実にユーザー影響を与えるので慎重に検討する
備しておく

● 22.6.5 デグレーデッドモードへの移行
○ 処理量を軽減するためレスポンスの品質を落とす
○ 重要でないトラフィックをドロップする
■ 22.2.2 ロードシェディングとグレースフルデグラデーション
○ 前提条件
■ サービスに組み込んでおかないと使えない
■ デグレードできるトラフィックが何かわかっている必要がある
■ ペイロードの違いを判別できる状態になっている必要がある
備しておく

● 22.6.6 バッチ負荷の排除
○ 過負荷を悪化させるような処理は止めましょう
備しておく

● 22.6.7 問題のあるトラフィックの排除
○ 死のクエリや、DDoSのような問題のあるトラフィックを排除する方法を準備しておく
備しておく

● デグレーデッドモードはカスケード障害に対して有効
○ 責任者は^への分岐点と、そのときシステムの振る舞いにどのような変化が起こるのかを
知っておく必要がある
● ちょっとした改善活動がシステムのバランスを崩し、カスケード障害を招
くことがある
○ 変更を評価するときは十分注意する
22.7 まとめ

自分のまとめ
● カスケード障害って何？
● カスケード障害を予防するためにできること
○ サーバー過負荷を回避するための戦略・実装を知ろう
○ 高負荷時、フィードバックという複雑系の中で、自分たちのシステムに何が起こるのかを
予測するのは難しい→実際に障害が起こるまで負荷をかけて確認しよう
● それでもカスケード障害は起こる。起こった時の対処方法を準備しておこ
う
○ エラーバジェットの範囲内でサービスを復旧させるための準備をしよう

22.3 起動直後の低パフォーマンスとコールドキャッシュ

20181112 SRE本輪読会#26_22章_カスケード障害

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 20181112 SRE本輪読会#26_22章_カスケード障害

Similaire à 20181112 SRE本輪読会#26_22章_カスケード障害 (20)

20181112 SRE本輪読会#26_22章_カスケード障害

Notes de l'éditeur