変更管理・自動化 / 信頼性設計
バックプレッシャーとは
Backpressure。処理する側が追いつかないとき、上流へ流量抑制を伝えて全体の破綻を防ぐ考え方です。
用語集内のカードを見る詳細な図解
上流サービスリクエストやイベントを送る
キュー/バッファ滞留量を観測
下流処理処理速度が限界に近づく
制御方針制限、遅延、破棄、429/503
- キューを大きくするだけではない
- リトライ嵐を防ぐ
- 守るデータと捨てるデータを分ける
この記事で学べること
バックプレッシャーを、定義だけで終わらせず、現場で出てくる場面、確認材料、見落としやすい点、関連語とのつながりまで順に確認できます。
- バックプレッシャーの考え方
- 現場で起きる場面
- 確認する材料
- よくある誤解
- 運用での使いどころ
バックプレッシャーの考え方
バックプレッシャーは、処理する側が追いつかないとき、上流へ流量抑制を伝えて全体の破綻を防ぐ考え方です。キュー、ストリーミング、API、ログ転送、マイクロサービス間通信でよく問題になります。
下流が遅いのに上流が同じ量を送り続けると、キューが膨らみ、メモリが尽き、タイムアウトやリトライが増え、さらに負荷が上がります。バックプレッシャーは、この悪循環を早めに止めるための設計です。
現場で起きる場面
ログ基盤が詰まってアプリが重くなる、メッセージキューの消費者が追いつかず遅延が増える、外部APIが遅いのにリトライが殺到する、といった場面で登場します。単なる性能問題ではなく、障害の広がり方を制御する話です。
設計時には、待つ、捨てる、遅らせる、失敗を返す、別経路に逃がす、という選択肢を用途ごとに決めます。
確認する材料
確認では、キュー長、処理時間、消費速度、リトライ回数、タイムアウト、ドロップ件数、上流へのエラー返却を見ます。ログやメトリクスでは、平均値よりもp95/p99や急増タイミングが役立ちます。
- 上流の送信量と下流の処理量を同じ時間軸で見る。
- リトライが負荷を増やしていないか確認する。
- 捨ててよいデータと必ず守るデータを分ける。
よくある誤解
キューを大きくすれば解決、とは限りません。キューは一時的な吸収には役立ちますが、処理能力が足りない状態を隠すだけになることもあります。
また、バックプレッシャーは単にエラーを返すことではありません。利用者影響、データ損失、再試行、順序性を考え、どの層でどのように抑制するかを決める設計です。
運用での使いどころ
バックプレッシャーを設計しておくと、障害時に全体停止ではなく劣化運転へ移りやすくなります。たとえば低優先ログを捨て、重要イベントだけ保存し、APIには429や503を明示的に返す、といった判断ができます。
関連語はレート制限、キュー、スループットです。処理能力、利用者影響、再試行のバランスを見ると、システムの粘り強さを設計しやすくなります。
関連語
同じ主要カテゴリの用語
変更管理・自動化の学習順
同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。