この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
この記事は アノテーション株式会社 AWS Technical Support Advent Calendar 2022 | Advent Calendar 2022 - Qiita 23日目の記事です。
困っていること
弊社の管理アカウント内で Classic Load Balancer（CLB）を使用しています。
ユーザーからのセッション中、すべてのリクエストが同じターゲットに送信されるように sticky sessions（スティッキーセッション）を有効化しています。
EC2 インスタンスを CLB から登録解除すると、コネクションを利用しているアプリケーションは突然 503 等のエラーとなり、ユーザーが利用中であれば影響が出る可能性が考えられます。
EC2 インスタンスのメンテナンスなどによって、CLB から EC2 インスタンスを登録解除する際に、セッションを落とさずユーザーへの影響を最小限に抑える方法を教えてください。
どう対応すればいいの?
Connection Draining の利用によりユーザーへの影響を最小限に抑えられます。
簡単に説明すると、登録解除中にある EC2 インスタンスに対する新規リクエストの送信を停止します。
バックエンドの EC2 インスタンスを登録解除しても処理中のリクエストが終わるまで一定期間待ってから対象の EC2 インスタンスを切り離すことが可能となるので、その後 EC2 インスタンスのメンテナンスによるリブートや、基盤のリタイアメント対応をしてください。
To ensure that a Classic Load Balancer stops sending requests to instances that are de-registering or unhealthy, while keeping the existing connections open, use connection draining. This enables the load balancer to complete in-flight requests made to instances that are de-registering or unhealthy. When you enable connection draining, you can specify a maximum time for the load balancer to keep connections alive before reporting the instance as de-registered. The maximum timeout value can be set between 1 and 3,600 seconds (the default is 300 seconds). When the maximum time limit is reached, the load balancer forcibly closes connections to the de-registering instance.
補足
CLB の sticky sessions は、セッション中のユーザーからのすべてのリクエストを同じインスタンスに送信する機能ですが、リクエスト送信対象のインスタンスは healthy 状態である必要があります。
登録解除中のインスタンスは healthy 状態ではなくなりますので、CLB はリクエストを送信しなくなくなります。
If an instance fails or becomes unhealthy, the load balancer stops routing requests to that instance, and chooses a new healthy instance based on the existing load balancing algorithm. The request is routed to the new instance as if there is no cookie and the session is no longer sticky.
5
