# 過負荷制御 ## 定義 過負荷制御(overload control)とは、負荷分散だけでは避けきれない過負荷状態に対し、「何を単位にキャパシティを測り、誰が(クライアントかサーバか)、何を基準に(重要度)、どれだけリクエストを棄却するか」を設計する取り組みである。負荷分散が事前に負荷を均等化する仕組みであるのに対し、過負荷制御は負荷が既に偏った/超過した状況で、システムを守りながらどのリクエストを受理し続けるかを決める事後的な受付制御(admission control)にあたる。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]]) Google の実装では、この設計問題は4つの軸に分解される。(1) キャパシティの単位を QPS ではなく CPU 秒などのリソース消費量で測ること、(2) グローバルな過負荷を顧客ごとのクォータで特定顧客に閉じ込めること、(3) クォータ超過分をクライアント側の適応スロットリング(adaptive throttling)で局所的に棄却し、棄却処理自体がバックエンドを圧迫することを防ぐこと、(4) criticality(重要度)の4段階でどのリクエストから棄却するかを一貫させ、タスク単体では utilization 信号(executor load average など)に基づいて実際に棄却を実行すること、である。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]]) ## 横断的知見 - **過負荷制御(第21章)とカスケード障害対策(第22章)の境界は「単一サービスの受付側の設計」と「その棄却設計が効かなかったときに系全体で何が起きるか」の分業として、SRE Book 自身が章構成で示している**: 第21章は criticality に基づく選択的棄却・utilization 信号による閾値判定という、1 タスクが自分自身をどう守るかの設計を扱う。第22章はこれを前提とした上で、その防御を通り抜けた過負荷がクラスタ間・系全体にどう伝播するか(あるクラスタの喪失が残りのクラスタを過負荷にする連鎖)、そして防御自体(負荷分散のエラー回避、ヘルスチェック再起動)が悪化要因に転じる場合を扱う。第22章の「過負荷を防ぐ戦略」の節が第21章の内容をそのまま優先順位付きリストの一部として参照しており、両者は独立した設計問題ではなく前者が後者の一部品として組み込まれる階層関係にある。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]) - **タスク単体の過負荷保護(第21章)が有効に機能していても、系全体でのカスケード障害を防ぎきれない具体例が第22章に示される**: 第21章の criticality・utilization に基づく棄却は個々のタスクを守る設計だが、第22章は「一部のサーバがクラッシュすると残りのサーバへの負荷が増え、それらもクラッシュしていく」という雪だるま効果や、「エラーを返したサーバを避ける負荷分散ポリシーが、それらのサーバを利用可能キャパシティから除外してかえって残りへの負荷を増やす」という、個々のタスクの防御が正しく機能した結果として系全体の容量が縮小していく経路を示す。これは、過負荷制御が「1 タスクの生存」を最適化しても「系全体の容量保持」を自動的には保証しないことを意味する。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]]) - **クライアント側の挙動は、SRE Book では意図的に設計する過負荷制御のレバーとして、BSRS ch.10 ではその設計を誤ったときに過負荷を自作してしまうリスクとして、対称的に描かれる**: 第21章はクライアント側適応スロットリング(adaptive throttling, K=2 が既定)を、バックエンドに到達する前にクライアント自身が過剰なリクエストを確率的に棄却する、意図的な自己防衛の仕組みとして提示する。これに対し BSRS ch.10 は、クライアントがエラー応答に対して単純な再試行(バックオフなし)を実装した場合、その再試行ループ自体が需要を膨張させ、サーバの復旧を妨げる自作の DoS になると指摘し、対策として指数バックオフとジッターを挙げる。両者を合わせると、クライアント側の挙動は過負荷制御において付随的な要素ではなく、正しく設計すれば防御に、誤って設計すれば攻撃者不在のまま需要超過を生む、両刃の主要な設計面であることが分かる。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 10 Mitigating Denial-of-Service Attacks]] ch.10 §Client Retry Behavior) - **過負荷制御システム自身の可用性という論点は、SRE Book の criticality ベースの棄却設計にはなく、BSRS ch.10 の fail static 原則が補う**: 第21章・第22章は、過負荷時にどのリクエストを棄却するか(criticality・utilization 信号)という受付制御そのものの設計を扱うが、その制御を行うシステム自体が故障した場合にどう振る舞うべきかは論じない。BSRS ch.10 は、自動 DoS 緩和システムの中央制御が落ちた場合に fail open(攻撃を素通し)でも fail closed(全遮断してアウテージを起こす)でもなく、直前のポリシーを維持する「fail static」を選ぶべきだと明示し、この設計により緩和エンジン自体はフロントエンドほど高可用性を要求されずコストを下げられると述べる。これは、過負荷制御を「何を棄却するかの設計」に加えて「制御システム自体が壊れたときに何もしないことを安全に選べる設計」という、SRE Book が扱わないもう1つの軸として補完する。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 10 Mitigating Denial-of-Service Attacks]] ch.10 §A DoS Mitigation System) - **グレースフルデグラデーションの具体例が、抽象的な criticality 設計(SRE Book)と実際のプロダクト事例(BSRS ch.10)として独立に記録され、同じパターンに収束する**: 第21章・第22章は criticality の4段階という抽象的な優先度付けの仕組みを提示するのに対し、BSRS ch.10 は Blogger のコメント無効化・読み取り専用モード移行、Web Search の機能縮小、DNS サーバの「どんな負荷でもクラッシュしないよう設計する」ベストエフォート応答という具体的なプロダクト事例を挙げる。両者は同一著者組織(Google)による独立した章でありながら、「重要度の低い機能から段階的に落とす」という同一の設計思想を、一方は仕組みのレベルで、他方は個別プロダクトのレベルで裏付けている。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 10 Mitigating Denial-of-Service Attacks]] ch.10 §Graceful Degradation) - **BSRS ch.8 は「棄却する前にコストを削る」という、SRE Book ch.21/22 が扱わない過負荷制御のもう一段階前の設計軸を加える**: SRE Book ch.21/22 は「過負荷になった後、何を棄却するか」(criticality・utilization ベースの受付制御)を設計問題とするが、BSRS ch.8 はその手前で「失敗する操作のコストをどれだけ早く・安く切り上げられるか」を独立の設計軸として立てる。データアクセス要求の妥当性をメモリ確保やディスク読み書きの前に検査する、SYN cookie でスプーフィングされた TCP 接続要求へのメモリ確保を避ける、サーバが自らの健全性低下を検知して呼び出し元にスロットルダウンを促す「lame-duck モード」に自発的に移行する、といった具体策は、棄却の意思決定(criticality・utilization)そのものではなく、棄却に至るまでに消費される計算資源を最小化する設計であり、両者は独立に組み合わせられる。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] ch.8 §Differentiate Costs of Failures) - **fail safe(フェイルセーフ)と fail secure(フェイルセキュア)の選択は、過負荷制御に内在する「可用性か安全性か」という軸を、BSRS ch.10 の fail static とは異なる角度から一般化する**: 過負荷制御の概念はこれまで、制御システム自体が壊れたときに「直前のポリシーを維持する」fail static という BSRS ch.10 の第三の選択肢を、SRE Book ch.21/22 が扱わない補完軸として蓄積してきた(既出)。BSRS ch.8 はさらに一段階上位の一般原則として、不確実な状況に直面したシステムが「できる限り動作を続ける」(fail safe/open、可用性優先)か「完全性を検証できない以上ロックダウンする」(fail secure/closed、セキュリティ優先)かという二者択一を提示し、fail static はこの二者択一のどちらでもない第三の解として位置づけ直せる——fail static は「動作を続ける」でも「ロックダウンする」でもなく「変化を止める」という選択である。BSRS ch.8 はまた、ACL のようなセキュリティ制御は原則としてフェイルオープンにすべきでないと明言し、SRE ch.21 の criticality ベース棄却において「security-critical functions には高い priority を与えるべきだ」という一文に、なぜそうすべきかの理論的根拠(フェイルオープンは攻撃者に DoS だけでセキュリティを無効化する手段を与える)を与える。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] ch.8 §Failing Safe Versus Failing Secure, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 10 Mitigating Denial-of-Service Attacks]] ch.10 §A DoS Mitigation System) - **「変更予算(change budget)」は、自動化された過負荷応答に人間の足場を残すための、SRE Book にもBSRS ch.10 にもない具体的な統制機構を追加する**: SRE Book ch.21/22 は criticality・utilization に基づく自動棄却の仕組みを詳述し、BSRS ch.10 は制御システム停止時の fail static を論じるが、いずれも「自動化が誤った判断を大規模に下すこと自体」への統制は扱わない。BSRS ch.8 は、単一サーバが全 RPC を棄却する、または全サーバが一部 RPC を棄却するといった大規模・広範囲のポリシー変更を無監督の自動化に許さず、変更予算を使い切ったら自動更新を止めて人間の判断を要求すべきだと明示する。これは、過負荷制御の自動化を「棄却の意思決定ロジック」と「その意思決定が及ぼす影響範囲の上限」という2層に分け、後者にだけ人間の承認を挟むという設計であり、過負荷制御の自動化議論に「どこまで人間を外して良いか」という運用統制の軸を加える。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] ch.8 §A Foothold for Humans) - **待ち行列理論の M/M/m/B キュー(有限バッファ)が示す「バッファが尽きたら到着を機械的に棄却する」という最も単純な受付制御は、SRE Book が論じる criticality ベースの選択的棄却の理論的な下限にあたる**: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 31 Analysis of a Single Queue]] §31.4 の M/M/m/B キューは、バッファ数 B を超えた到着をすべて機械的に棄却し(リクエストの種類を区別しない)、実効到着率 λ′=λ(1-pB) と棄却率(ブロッキング確率)pB という量で系を特徴づける。これは、[[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]] が criticality(重要度)に基づいて「どのリクエストから棄却するか」を選ぶ受付制御の対極——リクエストを区別しない一律のバッファ溢れ棄却——にあたる。両者を重ねると、SRE Book の criticality ベース受付制御は、M/M/m/B の一律棄却モデルに「棄却するリクエストを選ぶ」という追加の設計自由度を加えたものと位置づけられる。また、M/M/m/B が示す「有限バッファ系は無限バッファ系の安定条件 ρ<1 を満たさなくても系が破綻しない」という性質は、過負荷制御が目指す「過負荷下でもシステムを守る」というゴールを、待ち行列理論の言葉で最も単純化した形で先取りしている。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 31 Analysis of a Single Queue]] §31.4, [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]]) - **SRE Book が「キャパシティを QPS ではなく CPU 秒などのリソース消費量で測る」と設計する判断は、第33章のサービス需要 $D_i$(ジョブ1件あたりの総サービス時間)と同じ量的基盤――リクエスト数ではなく時間量でキャパシティを測る――に立っている**: 第21章はキャパシティの単位を QPS からリソース消費量(CPU 秒等)へ切り替える理由を明示しないが、[[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] §33.2 の強制フローの法則は、装置の使用率がリクエスト数ではなくサービス需要 $D_i=V_iS_i$(訪問比率×サービス時間、単位は時間)に比例することを示す($U_i=XD_i$)。QPS のようなリクエスト数ベースの指標は、リクエストごとの処理コストが均一でない限り装置の実際の負荷を正しく反映しないという弱点を持つが、CPU 秒のような時間量ベースの指標はこの弱点を持たない。両者を重ねると、SRE Book が経験的に選んだキャパシティ単位が、オペレーショナル法則が示す使用率の理論的な構成要素(サービス需要)と一致していることが分かる。ただし SRE Book はこの対応を明示しておらず、criticality 別に $D_i$ を測定・比較するという具体的な運用は本 wiki 内でまだ検討されていない。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] §33.2) - **第33章のボトルネック解析が導く漸近的上下界(スループット上界・応答時間下界)は、過負荷制御が「いつ棄却を始めるべきか」を判断する閾値の理論的な上限を与えうるが、両ソースはこの接続を明示しない**: 第21章・第22章は criticality・utilization 信号に基づく棄却の仕組みを詳述するが、「どの負荷水準から棄却を始めるべきか」という閾値設定そのものの根拠は示さない。[[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] §33.6 のボトルネック解析は、ボトルネック装置のサービス需要 $D_{\max}$ から、システムが安定に処理できるスループットの理論的上限($X \le 1/D_{\max}$)を導く。過負荷制御の棄却閾値をこの上限より低く設定すれば、ボトルネック装置の使用率が1に達する前に(=キューイングが手に負えなくなる前に)先回りして棄却を始められる。この対応は、待ち行列理論の M/M/m/B(有限バッファでの一律棄却、既出)よりも軽量な、確率分布の仮定を必要としない閾値設定の根拠になりうるが、criticality 別の閾値をどう $D_{\max}$ から逆算するかは両ソースいずれにも記述がない。(Source: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]], [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] §33.6) - **第36章が待ち行列理論の限界として自ら列挙するブロッキング・応答依存到着・キューからの離脱の3項目は、SRE Bookが工学的に解決している過負荷制御の3つの中心的な仕組み(criticalityベースの棄却・クライアント側スロットリング・タイムアウトによる離脱)にそれぞれ対応する、Jain自身が「モデル化できない」と認めた課題である**: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 36 Hierarchical Decomposition of Large Queueing Networks]] §36.3は、「過剰なキューイングがフローオフ信号を引き起こし他の装置でのブロッキングをもたらす」(項目5)、「キューが長いほど再送によって到着が増える正のフィードバックが不安定化を招く応答依存到着」(項目9)、「滞在時間の上限を超えたパケットをキューから破棄する離脱」(項目11)を、いずれも「現在の待ち行列モデルは容易には分析できない」と明記する。これらは既に本concept が扱ってきたSRE Bookの過負荷制御の中心的な仕組み――criticalityに基づく選択的棄却(ブロッキングを一律棄却からリクエスト種別ごとの棄却へ精緻化したもの)、再試行のバックオフ(応答依存到着の正のフィードバックを緩和する仕組み)、リクエストのタイムアウト(キューからの離脱そのもの)――と一対一で対応する。すなわちSRE Bookの過負荷制御は、Jainが1991年に「待ち行列理論では数理的に解けない」と自己申告した3つの課題に対する、数理モデルなしの工学的な解答になっている。(Source: [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 36 Hierarchical Decomposition of Large Queueing Networks]] §36.3, [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]]) ## 未解決の問い - 36.3節の「応答依存到着」が指摘する不安定化(応答時間の一時的増加が負荷と応答時間の継続的増加につながる正のフィードバック)は、SRE Bookの適応スロットリングやクライアント側バックオフがどのようなパラメータ条件下で確実に収束させられるかを、待ち行列理論・SRE Bookのいずれも定量的には示していない。 - QPS ではなく CPU 秒でキャパシティを測る設計は、GPU/アクセラレータのようにリソースの正規化コストが CPU 以上に複雑な環境(推論サービングなど)でどう一般化できるか。 - クライアント側適応スロットリング(K=2 が既定)は、クライアントとバックエンドの間に複数ホップの中継(プロキシ、サイドカー)が挟まる構成でも同じ収束特性を保てるか。 - criticality の4段階は Google の RPC システムに一級市民として組み込まれて初めて機能する仕組みに見えるが、そうした横断的な伝播機構を持たない環境でも同等の効果を得られる代替設計はあるか。 - タスク単体の過負荷保護(criticality・utilization ベースの棄却)は、第22章が示す「クラッシュしたサーバの負荷が残りに付け替わる」系全体の連鎖をどこまで緩和できるのか。個々のタスクの防御パラメータ(閾値・criticality の割り当て)を系全体のカスケード耐性の観点からどう調整すべきかは検討されていない。 - BSRS ch.10 の fail static 原則(制御システム停止時にポリシーを凍結する)を、SRE Book ch.21 の criticality・adaptive throttling を担う制御コンポーネント(criticality の割り当てサービスやクォータ管理システム自体)に適用するとどうなるか。criticality を判定する仕組み自体が過負荷や障害で機能しなくなった場合に何を凍結すべきかは、いずれのソースでも検討されていない。 - クライアント側適応スロットリング(SRE ch.21)とクライアント側の指数バックオフ+ジッター(BSRS ch.10)は、どちらもクライアントが自律的に送信量を調整する仕組みだが、両者を同一クライアントに同時実装した場合に干渉(過剰な抑制や、逆に想定より弱い抑制)が起きないかは検討されていない。 - BSRS ch.8 の変更予算は「大規模・広範囲のポリシー変更」を無監督の自動化から除外するが、何をもって「大規模」「広範囲」と判定するかの具体的なしきい値設計は本章に無い。SRE Book ch.21 の criticality・utilization ベースの棄却ロジックと組み合わせたとき、変更予算の消費単位(棄却したリクエスト数か、影響を受けたサーバ数か)をどう定義すべきか。 - BSRS ch.8 の fail safe/fail secure という二者択一と BSRS ch.10 の fail static という第三の選択肢は、同じ「制御システムが機能しない場合にどう振る舞うか」という問いに答えるが、いずれを選ぶかを決める組織的な意思決定プロセス(誰が最小限譲れないセキュリティ姿勢を定めるか)は具体化されていない。 - M/M/m/B のブロッキング確率 pB のような待ち行列理論の閉形式は、SRE Book の criticality ベースの多段階選択的棄却系に拡張した場合にも閉形式で求まるか。criticality 段階ごとに異なる実効到着率を持つ系のモデル化は本 wiki 内ではまだ扱われていない。 - 第33章のボトルネック解析が導く漸近的上下界($X \le 1/D_{\max}$)を過負荷制御の棄却閾値として使う場合、criticality の段階ごとに異なる閾値をどう $D_{\max}$ から逆算すべきか。単一の $D_{\max}$ から複数段階の閾値を導く方法は本ソースいずれにも示されていない。 ## 関連 - 概念: [[グレースフルデグレーデーション]] / [[カスケード障害]] / [[サービス妨害攻撃とネットワークプロトコルの悪用]] / [[自作のサービス妨害]] / [[影響範囲の制御]] / [[レジリエンス]] / [[待ち行列理論]] / [[オペレーショナル法則]] - ソース: [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]] / [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 10 Mitigating Denial-of-Service Attacks]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 31 Analysis of a Single Queue]] — 有限バッファ待ち行列(M/M/m/B)によるブロッキング(一律棄却)の数理モデル(§31.4)。 / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 33 Operational Laws]] — サービス需要 $D_i$ とボトルネック解析による漸近的上下界(§33.2, §33.6)。 / [[@1991__Wiley__The Art of Computer Systems Performance Analysis - Chapter 36 Hierarchical Decomposition of Large Queueing Networks]] — ブロッキング・応答依存到着・キューからの離脱を待ち行列理論の限界として自己申告する原典(§36.3)。 - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2016__OReilly__SRE Book - Chapter 21 Handling Overload]] - [[@2016__OReilly__SRE Book - Chapter 22 Addressing Cascading Failures]] - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 10. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 8. - Raj Jain, *The Art of Computer Systems Performance Analysis*, John Wiley & Sons, 1991, Chapter 31, §31.4. - Raj Jain, *The Art of Computer Systems Performance Analysis*, John Wiley & Sons, 1991, Chapter 33, §33.2, §33.6. - Raj Jain, *The Art of Computer Systems Performance Analysis*, John Wiley & Sons, 1991, Chapter 36, §36.3.