タイムアウトPC回路制御

1）なぜそれを必要とします

システムは1つの「致命的な」失敗からではなく、遅延と「波」リトレースの蓄積から落ちます。タイムアウトは待ち時間を制限し、リソースを解放し、回路制御（ブレーカ+シェッド+アダプティブ競争）により、依存関係のチェーンに沿って劣化が広がるのを防ぎます。目標は、p95/p99をターゲット境界内に保ち、部分的な障害の可用性を維持することです。

2）基本的な定義

2.1タイムアウトの種類（L7/L4）

「タイムアウトを接続」（Connect timeout）-TCP/TLS接続を確立します。
TLS/ハンドシェイクタイムアウト-握手TLS/HTTP2序文。
書き込みタイムアウト-リクエスト（本文を含む）を送信します。
タイムアウトを読む-応答の最初のバイト、または全身を待ちます。
Idle/Keep-Aliveタイムアウト-非アクティブ接続。
全体の締め切り-リクエスト全体の「ハード」締め切り（エンドツーエンド）。

2.2締め切り予算

ターゲット'deadline_total'を選択し、ステージごとに分割します：

'ingress（ゲートウェイ）+authZ+app+DB/cache+outbound PSP'。

支払いの例'POST' （400 msターゲット）：

ゲートウェイ：30 ms、
アプリケーション：120 ms、
DB： 120ミリ秒、
PSP： 100ミリ秒、
マージン：30 ms。

2.3伝播とキャンセル

'deadline'/'timeout'はチェーン（context、 headers、 gRPC Deadline）に渡されます。有効期限-バックグラウンド操作をキャンセル（abort/ctx cancel）、ロック/セマフォーをクリアします。

3）タイムアウト設定戦略

1.トップダウン：SLOとp95に基づいて-エンドツーエンドの期限を設定し、サブタイムアウトに分割します。
2.「高価な」パス（ファイルダウンロード、レポート、外部PSP）を特定する-個々の長さは長くなりますが、限られています。

3.Idempotentとwrite：

idempotent （GET/ステータスの繰り返し）-より短く、より攻撃的。
write/monetary-わずかに長くなりますが、単一の繰り返しとidempotencyがあります。

4.計画/テナントによる卒業（企業はタイムアウトが長く、並列性が低い）。

4）遮断器： モデルおよび変数

4.1トリガーポリシー

Failure-rate：クエリ/タイムNウィンドウのエラー率≥ X％です。
結果的な失敗：M連続失敗。
スローコールレート-スレッショルドT。より長いコールの割合。
エラークラス：timeouts/5xx/connection-reset→「fatal」、 4xx-考慮しないでください。

4.2条件

クローズ-すべてをスキップし、統計を蓄積します。
オープン-インスタント障害（リソースを保存し、依存関係を破棄しません）。
半開き-「水テスト」のための小さい「サンプル」（Nの要求）。

4.3便利な追加

隔壁：依存関係ごとにスレッド/接続のプール。すべてを「吸い取らない」ようにします。
適応並行性：観測されたレイテンシーによる自動並行性の制限（AIMD/Vegas風アルゴリズム）。
Load Shedding：ローカルリソース（キュー、CPU、 GCが一時停止）が不足している場合の早期障害/劣化。

5）相互作用： タイムアウト、後退、限界

最初の締め切り、次に再試行：各繰り返しは共通の締め切りに収まるはずです。
リプレイ用のバックオフ+ジッタ。respect 'Retry-After' and retry-budget。
レート制限：ブレーカが開いている場合-嵐を激化させないように制限を下げます。
Idempotency：書き込み操作に必須（「dumb」タイムアウトでのtakesを避けるため）。
リトラクトする場所：内側の深さではなく、エッジ（クライアント/ゲートウェイ）でできれば。

6）実用目標値（ベンチマーク）

公開読み取りAPI：エンドツーエンド'200-500 ms'、読み取りタイムアウト'100-300 ms'。
重要な書き込み（支払い）：'300-800ミリ秒'e2e；外部PSP ≤ '250-400ミリ秒'。
接続/TLS： '50-150 ms'（より多く-ネットワーク/はんだ付けする問題）。
アイドル状態：'30-90 s'（モバイルクライアント-バッテリーを節約するために短い）。
p95/p99とリージョンの値を調整します。

7）構成と例

7.1 Envoy（クラスター+ルート、擬似）

yaml clusters:
- name: payments_psp connect_timeout: 100ms type: STRICT_DNS lb_policy: ROUND_ROBIN circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 2000 max_requests: 2000 max_retries: 50 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

routes:
- match: { prefix: "/api/v1/payments" }
route:
cluster: payments_psp timeout: 350ms        # per-request deadline idle_timeout: 30s retry_policy:
retry_on: "reset,connect-failure,refused-stream,5xx,gateways"
num_retries: 1 per_try_timeout: 200ms

7.2 NGINX（周囲）

nginx proxy_connect_timeout 100ms;
proxy_send_timeout  200ms;  # write proxy_read_timeout  300ms;  # read (первый байт/все тело)
keepalive_timeout   30s;
send_timeout     15s;

Быстрый отказ при перегрузке limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 50;

7.3 gRPC（クライアント、Go-pseudo）

go ctx, cancel:= context.WithTimeout(context.Background(), 350time.Millisecond)
defer cancel()
resp, err:= client.Pay(ctx, req) // Deadline передается вниз

7.4 HTTPクライアント（Go）

go client:= &http.Client{
Timeout: 350 time.Millisecond, // общий дедлайн на запрос
Transport: &http.Transport{
TLSHandshakeTimeout: 100 time.Millisecond,
ResponseHeaderTimeout: 250 time.Millisecond,
IdleConnTimeout: 30 time.Second,
MaxIdleConnsPerHost: 100,
},
}

7.5 Resilience4j （Java、擬似）

yaml resilience4j.circuitbreaker.instances.psp:
slidingWindowType: TIME_BASED slidingWindowSize: 60 failureRateThreshold: 50 slowCallDurationThreshold: 200ms slowCallRateThreshold: 30 permittedNumberOfCallsInHalfOpenState: 5 waitDurationInOpenState: 30s

resilience4j.timelimiter.instances.psp:
timeoutDuration: 350ms

8）観察可能性および警報

8.1メトリクス

'http_client_requests {endpoint、 status}'、 'client_latency_bucket'

'timeouts_total {stage=connect	読む	書くこと	締め切り}'
'circuit_state {dependency}'： 0/1/2（閉じる/半分/開く）
'slow_call_rate'、 'failure_rate'
'active_concurrency {route、 dependency}'
'shed_requests_total {reason}' （load shedding）
'retry_total {reason}'、 'retry_budget_used'

8.2トレイル

スパン：ingress→handler→DB/Redis→external。
属性：'timeout_ms_target'、 'circuit_state'、 'queue_time_ms'。
Examplars： P99ピークを特定のトレースIDに結び付けます。

8.3アラート

'p99_latency {critical}'>行のX分をターゲットにします。
'timeout_rate {dependency}' hopped> Y％。
'open'/'flapping'ブレーカへの頻繁な遷移。
'shed_requests_total'の高いCPU/GCとの成長。

9）適応的な同時性及び負荷取除くこと

9.1アイデア

自動化により、レイテンシテイルが増加するにつれて並列性が低下します：

AIMD：ゆっくり増加し、急激に減少します。
ラスベガスのように：キューの時間を保ちます。
トークンベース：各リクエストはトークンを「燃焼」します。トークンは測定された速度に基づいて発行されます。

9.2インプリメンテーション

ルートごとのローカル・セマフォー；目標は'queue_time'をしきい値の下に保つことです。
ゲートウェイ上のグローバル「ヒューズ」（限界RPS/競合）。
CPU/接続が不足している場合、ロジック実行前の早期障害（'Retry-After'で429/503）。

10）テストとカオスシナリオ

レイテンシーインジェクション：依存関係ごとに50〜300ミリ秒を人工的に追加します。
パケット損失/dup/drop （tc/tbf、 Toxiproxy）。
ノブの回転：関係プールを減らして下さい、飽和への負荷を高めて下さい。
Kill/Degrade one zone/shard（一部利用不可）。
チェック：リトレイストームを「失敗」しません。ブレーカーは予測可能に開きます。キューが成長しているかどうか。

11） Antipatterns

1つのグローバルな「読み取りタイムアウト」の詳細は、/TLS/ステージごとに接続しません。
共通の締め切り→レトレイの欠如はSLOを超えています。
ジッタなしで再試行予算なしでレトライ。
アイドル状態のタイムアウト→リーク記述子のない「永遠」接続。
ブレーカーは致命的な間違いとして4xxを数えます。
クライアントのタイムアウト後もundo/abort→background作業は継続しません。
モバイル/不安定なネットワークではタイムアウトが長すぎます。

12） iGaming/Financeの詳細

Critical write （deposits/outputs）： Idempotency-Keyを使った1つの短いリピート、そして'202 Accepted'+ポーリング。
PSP/banking：プロバイダ/リージョン別のポリシー（一部遅い）。
責任ある支払いと制限：ロック/レビューの場合-高速'423/409'、「ハング」トランザクションを伸ばしないでください。
レポート/集計-非同期（バッチ+ステータスリソース）で実行します。

13） Prod Readinessチェックリスト

エンドツーエンドの重要なルート期限（GET/POST）が定義されています。
ステージ別の予算。期限伝播が有効になります。
ゲートウェイとクライアントで/TLS/read/write/idle構成を接続します。
故障率とスローコールしきい値を持つサーキットブレーカ。正しいハーフオープンロジック。
依存関係の隔壁；ルートごとの同時通行制限。
ビジネスロジックが過負荷時に実行される前にロードシェードする。
後退との統合：バックオフ+ジッタ、再試行予算、尊重'Retry-After'。
Idempotency write、 'Idempotency-Key'、およびイベントのアウトボックス。
メトリクス：timeout/slow-call/breaker/queue time/competitive。
カオステスト：遅延/損失/失敗の注入、ゾーンの劣化。
顧客ドキュメント：サンプルタイミング、レスポンスコード、リプレイのヒント。

14） TL；DR（ドクター）

各要求に厳しい締め切りを与え、段階的に整理し、チェーンに広げます。サーキットブレーカ+バルクヘッド+アダプティブコンカレンシー+ロードシェッドで障害を管理します。リプレイ-ジッタと予算で、期限内にのみ。write-idempotentのみ。タイムアウト/スローコール、ブレーカ状態、および'queue_time'を測定し、定期的にカオステストを実行します。

タイムアウトPC回路制御

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です