タイムアウトをどの層に置くか確認する
収録 2026-11-02
タイムアウトは正しく扱える層に置きます。早く失敗させるだけでは不十分。
呼び出し経路と現行タイムアウトを渡します。1）各層のタイムアウトが下位より大きいか（上位が先に切ると下位が無駄に待つ）；2）発火後に適切な処理がないもの（再試行・縮退・エラー）；3）タイムアウトに見えて実は資源不足の例；4）妥当な層別タイムアウト案；5）タイムアウトと再試行を併用する際の落とし穴。単に「大きくする」は提案しない。
当サイトオリジナル
中国語の原文
使い方
超时不是越短越好，而是要和下一层对齐。
こう変えてみる
- コードを書く前に要件と制約を復唱させる。
- 全体書き換えではなく、最小の変更とロールバック方法を出させる。
得られる成果物
- そのまま使える最小変更（コピー可能なコード）
- 影響範囲：変更ファイルと追従が必要な呼び出し元
よくある失敗
- 一度に十ファイル変更させ、何が原因か分からなくなる。
- エラーだけ貼ってコードとバージョンを省くと、使えない修正が返る。
出力のチェック
- 変更は動いて戻せて、無関係なコードに手を入れていない。
- 境界条件（空・巨大・同時実行）が説明かテストで押さえられている。
使いどころと注意
- 向いている用途：要件と制約を復唱させてから、最小限の動く変更を出させる。
- 注意：エラーにはバージョンと最小再現を添える。無いと一見もっともらしいが合わない修正が返る。
向いている場面
- 本番で断続的なタイムアウトが出ているが、呼び出し側・呼ばれる側・中間プロキシのどこで起きているか特定できていない。
- 複数のタイムアウト値を調整しようとしていて、失敗点が別の層に移るだけではないか不安なとき。
向いていない場面
- サービスにタイムアウト制御がなく無限に待てる状態——まずタイムアウトを入れ、層の話はその後。
- 遅い下流を特定済みで直接改善できる——タイムアウト変更は問題を隠すだけ。
例
入力
ゲートウェイ 30 秒、A が B を呼ぶ超時 5 秒、B の DB クエリ超時 3 秒、DB 側の文タイムアウトは未設定。症状：A はタイムアウトするが B のログではクエリが実行中のまま。
得られるもの
まず不整合を指摘：A は 5 秒しか待たないが、B は下流で 3 秒まで許し DB 側に上限がないため、A が諦めた後も B は動き続ける。層別に DB 文 2 秒 < B→DB 2.5 秒 < A→B 5 秒 < ゲートウェイ 30 秒を提案し、各層でタイムアウト時に何をするか（再試行・縮退・失敗）を明記。A が諦めた後に B が続行する点も、キャンセルや冪等書き込みで対処が必要と指摘。
よくある誤用
- タイムアウトを大きくするだけ：層の不整合は残り、失敗が後ろにずれて末尾遅延が悪化する。
- 全層を同じ値にする：層別になっていないため、上位が先に切れて下位が空回りする。
こう変えると効く
- 「タイムアウト後は再試行か失敗か」に置き換えると、再試行予算と冪等性の確認に変わる。
- 利用者体験の観点を足し、許容待ち時間から各層の予算を逆算する（経験値で決めない）。