結論：readinessの猶予は短い切替だけに使い、DB障害を隠す設定にしない
Claude Apps Gatewayには、短いPostgres outageやdatabase failoverの間も/readyzをreadyに保つstore.readiness_grace_secondsが追加されました。ただしこれはDB接続を直す設定ではありません。store.connect_timeout_secondsの接続待ち、readinessの猶予、リクエスト受付の停止条件を分け、復旧時間の上限を決めて使います。
読者の課題は、DB切替の数十秒でロードバランサーから外れることと、逆にDBへ保存できないまま「ready」と見なしてしまうことです。readinessを維持する時間は、実際のfailover測定値と監視・再試行の設計から決め、可用性の数字だけで延長しません。
一次情報はClaude Code公式changelogの追加項目とClaude Apps Gateway公式文書です。既存の接続待ちとの比較はPostgres接続待ちの記事、観測はOTLP転送の記事を参照します。公式に既定値やSLOがない箇所は、環境の実測値として扱います。
readyz猶予・接続timeout・停止を比較する
| 設定・判断 | 役割 | 誤用すると起きること |
|---|---|---|
store.connect_timeout_seconds | DB接続を待つ上限 | 到達不能や認証失敗を長く待つ |
store.readiness_grace_seconds | 短いDB outage中もreadyzを保つ猶予 | 保存不能なのに受付継続と誤認する |
| readinessを落とす | 新規trafficを止め復旧を優先 | 切替で不要な再起動や失敗が増える場合がある |
readinessの猶予を延ばしても、DBの認証、TLS、DNS、security group、connection poolが直るわけではありません。Gatewayの公式文書で示されるPostgreSQL、private network、TLS、バックアップなどの前提を満たし、readyz、アプリケーションエラー、DBの書き込み成功を別の信号として監視します。
また、readinessはロードバランサーやコンテナオーケストレーターがtrafficを送る判断に使う信号です。Gateway自身が「短い障害なので復旧を待つ」と判断していても、クライアントのrequestが成功することや、認証・rate limitの状態が保存されることを意味しません。運用表には、readyzがreadyの時、DB接続は失敗している時、書き込みが失敗した時の三つを別の行で書きます。
復旧後には、単にreadyzが戻った時刻ではなく、DBへの新規接続、保存処理、重複しないretry、監査イベントの再開を確認します。猶予時間の変更は可用性のチューニングとして扱い、incident後のレビューで実測値と比較します。値の根拠がないまま大きくすることは、障害の発見を遅らせるだけです。
読み取りと書き込みを同じ成功条件にしないことも有効です。短い切替中に表示だけ許可できるなら、保存を伴う操作には明示的なエラーを返し、復旧後に再送できる情報だけを安全に保持します。再送できない操作を「readyだから成功」と扱わない運用が必要です。
担当者は、猶予中の表示を「正常」と報告せず、「切替待ち」と報告します。ダッシュボードの色や通知文も、復旧待ちと完全復旧を区別できる表現にしてください。
設定変更は段階的に適用し、変更前後のreadyzと書き込み結果を比較します。
切替演習の結果は、次回の猶予値を決める一次記録として保存します。
これにより、運用者が数値の意味を再確認できます。
短い設定名でも、復旧責任は別途明確にします。
通知先と再開承認者も切替前に決めます。
平常時の値と障害時の値をrunbookに並べ、レビュー時に差分を確認します。設定変更の承認履歴も残します。
切替前に設定値を決める8手順
- 依存する保存処理を列挙する。identity、rate limit、spend、監査、sessionなど、DBが使えない時に失ってはいけない状態を書き出します。
- 通常の接続時間を測る。DNS、TLS handshake、認証、pool取得を分け、平常時とfailover時のp95・最大値を記録します。
- 短い outageの定義を置く。managed databaseの切替通知や過去の復旧時間から、猶予を超えたら障害とする境界を決めます。
- connect timeoutを先に確認する。既存の
store.connect_timeout_secondsが短すぎて切替を待てないのか、長すぎて失敗を隠しているのかを分けます。 - readiness猶予を限定する。
store.readiness_grace_secondsは測定したfailover時間に安全余裕を加え、無期限の待機にならない値にします。 - 受付条件を定義する。readyzがreadyでも、保存必須の処理が失敗した場合は新規受付を止めるか、読み取り専用へ切り替えるかを決めます。
- 監視を三系統で置く。readyz、Gatewayの5xx・timeout、Postgresのconnection・write・replicationを同じ時刻軸で見ます。
- 切替を演習する。安全なstagingでprimary切替を行い、readyzの状態、既存request、retry回数、復旧後の再接続、監査ログを確認します。
運用チェックリスト
- 猶予の根拠となる過去のfailover時間がある。
- connect timeoutとreadiness graceを別項目で変更・承認できる。
- 猶予中に保存できない操作を分類した。
- readyzだけで復旧判定せず、書き込み成功とエラー率を確認する。
- 猶予超過時にtraffic停止、通知、調査、再開のownerが決まっている。
- retryが重複書き込みを起こさないidempotencyを確認した。
- 設定変更と切替結果を同じincidentへ記録する。
よくある質問と次の行動
猶予を長くすれば可用性が上がりますか？
短いfailoverで不要なreadyz低下を防げる可能性はありますが、保存不能な受付を長くする副作用があります。可用性だけでなく、データ完全性と復旧時間で判断します。
Postgresが完全停止してもreadyzを維持しますか？
短いoutage向けの設定です。長時間停止、認証失敗、設定ミス、破損は猶予で解決しません。上限を超えたらfail-closedの手順へ移します。
retry回数も同時に増やすべきですか？
同時に増やすと復旧直後の負荷や重複書き込みを増やします。requestの種類ごとに再試行可能性とidempotencyを確認します。
GatewayのDB接続境界はconnect timeoutの切り分け、テレメトリーはOTLP collector設計、外部通信の制御はegress boundaryとheadersも確認してください。Miraigentの無料診断では、readyz・データ保存・障害停止の判断表を業務要件に合わせて整理します。