【入門編】コネクションドレイン（Connection Draining / 登録解除の遅延 Deregistration Delay） – クラウド＆コンテナネットワーク実践ガイド

はい、承知いたしました。クラウドにおけるロードバランサーのコネクションドレインについて、初心者の方にも分かりやすく、実用的な内容を盛り込んだブログ記事を作成します。パケットの流れを郵便配達に例え、親しみやすいトーンで解説しますね。

—

郵便配達員さんがいない！そんな時でもお客様を待たせない！ロードバランサーの「コネクションドレイン」って何？

「インフラって難しそう…」「ロードバランサーって、ただトラフィックを分散するだけじゃないの？」

そう思っているあなた！大丈夫です！今日は、クラウドのロードバランサー、特にAWSのALB（Application Load Balancer）やNLB（Network Load Balancer）、そしてGoogle CloudのGLB（Global Load Balancer）なんかで超重要になる「コネクションドレイン」という仕組みについて、一緒に、そう、まるで郵便配達員さんの仕事に例えながら、楽しく学んでいきましょう！

ロードバランサーって、どんなお仕事？

まず、ロードバランサーの基本からおさらいです。ロードバランサーは、例えるなら「大きな郵便局」なんです。

お客様（クライアント）：インターネットで何かを注文する人たち。
郵便局（ロードバランサー）：お客様からの注文（リクエスト）を受け取って、どこの配達員さん（サーバー）に「この荷物、お願いね！」と指示を出す窓口。
配達員さん（サーバー/ターゲット）：お客様の注文（リクエスト）を実際に処理して、商品（レスポンス）を届ける人たち。

たくさんの注文が一度に来ても、配達員さんが一人しかいないと、お客様はいつまでも待たされますよね？そこで、郵便局（ロードバランサー）は、複数の配達員さん（サーバー）に仕事を均等に振り分けて、お店（サービス）全体がスムーズに動くようにしてくれるんです。

突然のお休み！配達員さんの「登録解除」

さて、ここで問題発生です！
もし、ある配達員さん（サーバー）が、急に体調を崩してしまったり、もっと効率の良い新しい配達ルートに変わることになったりして、お休み（登録解除）することになったらどうなるでしょう？

この時、郵便局（ロードバランサー）は、その配達員さん（サーバー）に新しい荷物（リクエスト）を渡すのをやめないといけません。でも、その配達員さんがちょうど今、配達中のお客さんがいるかもしれませんよね？

もし、新しい荷物を渡さないために、いきなり「はい、もう配達終わり！」と、配達途中の配達員さんを呼び戻してしまったら、どうなるでしょう？

お客様（クライアント）：注文した商品が届かない！「あれ？届くはずなのに…」と、がっかりしてしまいます。
配達員さん（サーバー）：配達の途中で急に呼び戻されて、困惑！「え、この荷物どうすればいいの？！」となってしまいます。

これは、サービス全体で考えると、お客様に「なんかサービスが途中で止まったぞ？」と思わせてしまい、信頼を損なう原因にもなりかねません。

そこで登場！「コネクションドレイン」という優しさ

そこで、ロードバランサーには「コネクションドレイン（Connection Draining）」とか「登録解除の遅延（Deregistration Delay）」と呼ばれる、とっても親切な機能があるんです。

これは、例えるなら、

「配達員さんがお休みする前に、郵便局（ロードバランサー）が『〇〇さん、お疲れ様！新しい荷物はもう渡さないけど、今持ってる荷物は最後までしっかり配達してきてくださいね。それが終わったら、ゆっくり休んでください』と伝えること」

なんです。

つまり、

1. 新しいリクエストは、もうその配達員さん（サーバー）には渡さない。
2. でも、その配達員さんが「ちょうど今」処理している（インフライト）リクエストは、最後まで完了させるのを待ってあげる。
3. その配達員さんが、持っている荷物を全て配達し終えたら、晴れてお休み（登録解除）となる。

この「最後まで配達するのを待ってあげる時間」が、まさに「コネクションドレイン」や「登録解除の遅延」というわけです。

なぜ、この「待つ」ことが大切なの？

この「待つ」という行為には、いくつかの大切な理由があります。

お客様へのサービス品質維持：お客様は、リクエストしたらちゃんとレスポンスが返ってくることを期待しています。途中で切断されてしまうと、不満に繋がります。
サーバーへの負荷軽減：急に接続を切られると、サーバー側でもエラー処理などが発生し、予期せぬ負荷がかかることがあります。
データの整合性：例えば、トランザクション処理の途中だった場合、中断されるとデータが不整合になるリスクがあります。

コネクションドレインの設定を見てみよう！ (AWS ALB/NLBを例に)

AWSのALBやNLBでは、この「登録解除の遅延（Deregistration Delay）」という名前で設定できます。

ALB (Application Load Balancer) の場合

ALBでは、ターゲットグループごとにこの遅延時間を設定します。

デフォルト値：300秒（5分）
設定可能範囲：0秒～ 3600秒（1時間）

例えば、

# ALBのターゲットグループの属性を更新する例
aws elbv2 modify-attribute \
    --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-alb-targets/abcdef1234567890 \
    --attribute-name deregistration_delay.timeout_seconds \
    --attribute-value 60 # 60秒（1分）に設定

【コードの解説】

aws elbv2 modify-attribute: ALBの属性を変更するためのAWS CLIコマンドです。
--target-group-arn: 対象となるターゲットグループのARN（Amazon Resource Name）を指定します。
--attribute-name deregistration_delay.timeout_seconds: 登録解除の遅延時間を設定する属性名を指定します。
--attribute-value 60: 遅延時間を60秒に設定しています。

NLB (Network Load Balancer) の場合

NLBでも、ターゲットグループごとに設定できます。ALBと基本的な考え方は同じですが、NLBはレイヤー4（TCP/UDP）で動作するため、より低レイヤーでの接続維持を考慮します。

# NLBのターゲットグループの属性を更新する例
aws elbv2 modify-attribute \
    --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-nlb-targets/abcdef1234567890 \
    --attribute-name deregistration_delay.timeout_seconds \
    --attribute-value 120 # 120秒（2分）に設定

【コードの解説】

こちらはNLBのターゲットグループに対するコマンドですが、構造はALBとほぼ同じですね。
--attribute-value 120: 遅延時間を120秒に設定しています。

どれくらいの時間を設定すればいいの？

これは、あなたのサービスが「一つのリクエストを処理するのに、どれくらい時間がかかるか」によって変わってきます。

応答が速いサービス（例：静的なWebページの配信）：数秒～数十秒でも十分かもしれません。
応答に時間がかかるサービス（例：複雑な計算、バッチ処理、外部API連携）：数分単位、あるいはそれ以上の時間が必要になることもあります。

重要なのは、設定した時間内に、ほとんどのリクエストが完了するように調整することです。

あまりに短すぎると、まだ処理が終わっていないリクエストが途中で切れてしまうリスクが高まります。逆に、あまりに長すぎると、サーバーを置き換えたいのに、古いサーバーがいつまでも残ってしまい、新しいサーバーへのトラフィックがなかなか流れない、なんていう非効率な状況も起こり得ます。

まずは、デフォルトの300秒（5分）から始めて、実際のサーバーの処理時間や、お客様の利用状況をモニタリングしながら、最適な値に調整していくのがおすすめです。

ヘルスチェックに失敗した場合の挙動

「でも、サーバーがヘルスチェックに失敗したら、どうなるの？」
良い質問ですね！

ヘルスチェックに失敗した場合も、基本的には同じ「登録解除の遅延」の仕組みが働きます。

1. ロードバランサーがサーバーのヘルスチェックに失敗を検出します。
2. ロードバランサーは、そのサーバーに新しいリクエストを送信するのを停止します。
3. ただし、そのサーバーがまだ処理中のリクエスト（インフライトリクエスト）がある場合は、設定された「登録解除の遅延」時間だけ待機します。
4. 遅延時間内に、そのサーバーが再度ヘルスチェックに成功すれば、またトラフィックが流れるようになります。
5. もし、遅延時間内もヘルスチェックに成功せず、さらに遅延時間が経過したら、そのサーバーは「異常」とみなされ、ロードバランサーのターゲットリストから一時的に外されます。（※設定によっては、ここで完全に登録解除される場合もあります）

このように、ヘルスチェックの失敗時にも、いきなり接続を切るのではなく、一定の猶予期間を設けることで、サービスの中断を防いでくれるんです。

まとめ：コネクションドレインは、お客様とサーバーへの「思いやり」

今日は、ロードバランサーの「コネクションドレイン（登録解除の遅延）」について、郵便配達員さんの例えを交えながら解説しました。

ロードバランサーは、お客様からの注文を配達員さん（サーバー）に振り分ける郵便局。
配達員さん（サーバー）がお休み（登録解除）する時は、今、配達中の荷物（インフライトリクエスト）を最後まで完了するのを待ってあげるのが「コネクションドレイン」。
これにより、お客様は安心してサービスを受けられ、サーバーも急な切断で困ることがなくなります。
AWSでは、deregistration_delay.timeout_seconds という設定で、この待機時間を調整できます。

この「待つ」という仕組みは、一見地味ですが、サービスの安定稼働やお客様満足度を大きく左右する、非常に重要な機能なんです。

皆さんのインフラ構築や運用でも、ぜひこの「コネクションドレイン」を意識して、より信頼性の高いサービスを目指してくださいね！

もし、「この設定、うちのサービスだとどうなるかな？」と疑問に思ったら、まずは少なめの遅延時間で試してみて、ログやメトリクスをしっかり確認しながら、徐々に調整していくのがおすすめです。

それでは、また次回のブログでお会いしましょう！