今回はAWSのシステム構築（インフラ）のカギとなってくるELB（Elastic Load Balancer）について特徴やユースケースをまとめていこうと思います。

概要・特徴等

• マネージド型の負荷分散サービスであり、受信トラフィックを配下の複数のEC2に分散する。
• 負荷に応じて自動的に拡張する。
• 複数のAZに跨って負荷分散ができる。
• AZ-AとAZ-Bに跨るELBを作成しようとすると、共通で使われるDNSが作成される。ELBの実体はAZ-AとAZ-Bにそれぞれ存在し、ELBを経由するアクセスについては、DNSで名前解決されたELBのIPアドレスによって振り分けられる。

ヘルスチェック

• EC2インスタンスの正常性確認（ヘルスチェック）ができる。これは負荷分散装置（ロードバランサー）としては当然の機能である。死んでいるサーバにトラフィックを送るわけにはいかない。

SSLオフロード

• クライアントとAWS上のシステムの間でSSLが利用される場合に、SSLの証明書をEC2インスタンスの代わりにELBに配置することができる。これをSSLのオフロードと呼ぶ。これはプロキシサーバに似ている気がする。ロードバランサもある意味プロキシサーバなので、同様のことが可能と理解した。

Connection Draining

• ELB配下のEC2が削除や登録解除された場合に、新規のリクエストについてはそのEC2へ送信をしないようにし、一方でEC2で処理中のトラフィックについては、その処理の完了を待つ機能がある。これをConnection Drainingと呼ぶ。

スティッキーセッション

• システムにアクセスしているクライアントを特定のEC2インスタンスに紐づける機能があり、これをスティッキーセッションと呼ぶ。
• このスティッキーセッションは、例えばとあるクライアントがEC2-Aでログイン（認証）を済ませている場合に、ELBにEC2-Bに割り振られると、そのログイン情報が消えてしまう（ログアウト状態になる）。このような事象を防ぐことができる機能で、ELBがセッション情報を管理することにより、その特定のクライアントについては常に同じEC2へアクセスさせることができる。
• このスティッキーセッションという機能は、呼び名はともあれ、L7ロードバランサには良くある機能である。
• 注意点として、スティッキーセッションは、特定のユーザを特定のEC2と紐づけてしまうため、例えばAuto Scalingで追加されたEC2へトラフィックが分散されなくなる等の可能性がある。つまり、7つのベストプラクティスである「伸縮自在性を実装」するためには、このようにEC2に特定の状態を持たせない状態（ステートレスな状態）とすることが必要である。
• 上記のケースであれば、セッション情報をElastiCacheやDynamoDBを利用する等して、ELBにセッション情報を持たせないようにすれば、回避できる。

ユースケース

ELBのユースケースはその名の通りロードバランスです。インスタンスを複数配置して冗長性を保つ場合に有効です。同じリージョン内の複数のAZをまたいでロードバランスできます。仮にひとつのAZが使用不可になっても、地理的に異なった別のAZでサービス継続することができます。