コネクションドレイニング

コネクションドレイニングとは

コネクションドレイニング (Connection Draining) は、ロードバランサーがバックエンドインスタンスをターゲットグループから切り離す際に、処理中のリクエストが完了するまで待機してから切断する仕組みである。ALB では「登録解除の遅延 (Deregistration Delay)」と呼ばれる。

ドレイニングなしでインスタンスを即座に切り離すと、処理中のリクエストが中断される。ALB が転送済みのリクエストの応答を待っている最中にターゲット側が接続を閉じた場合、クライアントには 500 番台のエラーが返る (典型的には 502 Bad Gateway)。

動作の流れ

動作の流れを図で示す。

1. インスタンス A をターゲットグループから登録解除
2. ALB は新しいリクエストをインスタンス B, C に振り分け
3. インスタンス A の処理中リクエストは完了まで待機
4. 全リクエスト完了 or タイムアウト → インスタンス A を切断

タイムライン:
t=0   登録解除開始
t=0〜 新規リクエスト → B, C に振り分け
t=0〜 処理中リクエスト → A で完了まで待機
t=30  全リクエスト完了 → A を切断
t=300 タイムアウト (未完了でも強制切断)

設定値	適するケース
0 秒	即座に切断 (処理中リクエストは中断)
30 秒	API サーバー (レスポンスが速い)
120 秒	ファイルアップロード、長時間処理
300 秒	デフォルト (多くの場合は長すぎる)

デフォルトの 300 秒は多くの場合長すぎる。API サーバーなら 30〜60 秒で十分だ。長すぎるとデプロイ時間が延びる。

ゼロダウンタイムデプロイとの関係

ローリングアップデートやブルーグリーンデプロイでは、旧インスタンスの切り離し時にコネクションドレイニングが動作する。

ローリングアップデート:
1. 新インスタンス v2 を起動
2. v2 がヘルスチェックに合格
3. 旧インスタンス v1 を登録解除 → ドレイニング開始
4. v1 の処理中リクエストが完了
5. v1 を停止

ECS + Fargate での注意点

ECS タスクの停止時、ALB のドレイニングと ECS の stopTimeout の両方が関係する。

• ALB の Deregistration Delay: ALB がタスクへの新規リクエストを停止し、処理中リクエストの完了を待つ
• ECS の stopTimeout: SIGTERM 送信後、SIGKILL までの猶予時間

この 2 つは並行して進むのではなく、順番に進む。ALB を使うサービスでは、ECS はまずタスクをターゲットグループから登録解除し、処理中の接続は Deregistration Delay が切れるまで継続を許される。コンテナへ SIGTERM が送られるのはそのあとで、stopTimeout の計時が始まるのも SIGTERM のあとだ。つまり stopTimeout を Deregistration Delay 以上にする必要はない。

そして Fargate では stopTimeout に上限がある。指定できるのは 2〜120 秒で、省略時は 30 秒が使われる (2026 年 8 月時点)。デフォルトの Deregistration Delay は 300 秒なので、「Deregistration Delay 以上に設定する」は Fargate ではそもそも成立しない。stopTimeout は SIGTERM を受けてからの終了処理が収まる長さに合わせ、処理中リクエストを待つ時間は deregistration_delay.timeout_seconds 側で調整する。

Fargate Spot では 120 秒を超える停止タイムアウトを設定できず、EC2 スポットも中断通知から 2 分で停止するため、120 秒より長い stopTimeout は効かない。スポットを使うなら、ドレイニングと終了処理の合計が 2 分に収まる設計にする。

Graceful Shutdown との連携

アプリケーション側でも SIGTERM を受け取ったら、新規リクエストの受付を停止し、処理中のリクエストを完了してから終了する。

process.on('SIGTERM', () => {
  server.close(() => {
    console.log('All connections closed');
    process.exit(0);
  });
});

体系的に学ぶなら関連書籍を参照してほしい。