【負荷分散（ロードバランシング）】
サービスの利用者が増えてくると、単一のリソースでは全てのリクエストを処理しきれなくなり、結果としてレスポンスの遅延が起こります。このような場合、リクエストを処理するリソースを複数配置し、それらのリソースにリクエストの処理を分散することでレスポンスの遅延が発生しないようにできます。
このような仕組みを「負荷分散（ロードバランシング）」といいます。

【Elastic Load Balancing（ELB）】
Elastic Load Balancing（ELB）は、AWSが提供する負荷分散サービスです。マネージドサービスであり、ユーザーは負荷分散機能を利用する際にアプリケーションのインストールやバージョンアップなどを考慮する必要がありません。

ELB配下の負荷分散先リソースのことを「ターゲット」といい、一つのELB配下で管理されるターゲットの集合を「ターゲットグループ」といいます。ターゲットにはインスタンス、IPアドレス、Lambda関数を指定できます。ターゲットグループ単位で負荷分散を行い、適切なターゲットにリクエストがルーティングされるようになります。
ターゲットは、可用性を向上させるためにマルチAZ（複数のAZに配置する構成）にするのが一般的です。これにより一部のAZに障害が発生した場合でも、他のAZに配置されたターゲットで引き続きリクエストが処理されます。また、ELB自体もマルチAZ構成で動作するので、高い可用性と冗長性を確保できます。


【ELBの種類】
ELBにはロードバランシングの方式によって複数の種類があります。

■Application Load Balancer（ALB）
・レイヤー7（アプリケーション層）で負荷分散を行う
・HTTP、HTTPS、gRPCベースのルーティングをサポート
・ホストベースやパスベース、URLクエリ文字列でのルーティングなど高度なルーティング機能を提供する
・WebSocketや同一インスタンス内の複数ポートへの負荷分散に対応

○ALBが対応している主なルーティング
・ホストベース
ホストベースのルーティングとは、クライアントがリクエストした接続先URLのFQDNに従ってルーティングできる機能のことです。例えば、クライアントの接続先URLが「http://www1.example.com」の場合はWebサーバー1にアクセスさせて、「http://www2.example.com」の場合はWebサーバー2にアクセスさせることができます。

・パスベース
パスベースのルーティングとは、クライアントがリクエストした接続先URLのパスに従ってルーティングできる機能のことです。例えば、クライアントの接続先URLが「http://www.example.com/web1/」の場合はWebサーバー1にアクセスさせて、「http://www.example.com/web2/」の場合はWebサーバー2にアクセスさせることができます。

・URLクエリ文字列
URLクエリ文字列でのルーティングとは、クライアントがリクエストした接続先URLのクエリ文字列に従ってルーティングできる機能のことです。URLクエリ文字列とは、ブラウザがWebサーバーに送信するデータをURLに表記したものです。URLが「http://www.example.com/web?lang=jp」であれば「lang=jp」がURLクエリ文字列に該当します。
例えば、クライアントの接続先URLが「http://www.example.com/web?lang=jp」の場合は日本語サイトのあるWebサーバーにアクセスさせて、「http://www.example.com/web?lang=en」の場合は英語サイトのあるWebサーバーにアクセスさせることができます。

○WebSocket
一つのコネクション内で永続的にサーバー/クライアント双方からデータ送信できる技術です。通常のWebアプリケーションの場合、クライアントからのリクエストにサーバーがレスポンスを返して接続終了となりますが、WebSocketを使うと、一度接続したコネクションではクライアントからのリクエストがなくてもサーバー側からデータを送信できます。WebSocketはチャットや株価情報のような、リアルタイムな情報提供を必要とするアプリケーションで使用されます。

■Network Load Balancer（NLB）
・レイヤー4（トランスポート層）で負荷分散を行う
・TCP、UDP、TLSベースのルーティングをサポート
・高スループットかつ低レイテンシー（低遅延）で、数百万パケット/秒のトラフィック処理に対応
・WebSocketや同一インスタンス内の複数ポートへの負荷分散に対応

NLBはElasitc IPアドレス（固定のパブリックIPアドレス）と関連付けることができます。これによりクライアントからNLB配下のサーバーに、NLBに関連付けられたElastic IPアドレスでアクセスできるようになります。サーバーへのアクセスをドメイン名ではなくIPアドレスで行いたい場合や、クライアントのアクセス先をIPアドレスで管理・制限している環境などで有用です。
Elasitc IPアドレスと関連付けられるのはNLBのみですが、NLBのターゲットにALBを指定すると、クライアントからALB配下のサーバーにNLBのElastic IPアドレスでアクセスできるようになります。

■Classic Load Balancer（CLB）
・レイヤー7（アプリケーション層）およびレイヤー4（トランスポート層）で負荷分散を行う
・TCP、SSL/TLS、HTTP、HTTPSベースのルーティングをサポート
・旧世代のELBなので、機能や柔軟性の観点からALBやNLBの利用が推奨される

■Gateway Load Balancer（GWLB）
・レイヤー3（ネットワーク層）およびレイヤー4（トランスポート層）のトラフィックを対象とする
・すべてのIPトラフィックを透過的に処理する
・ファイアウォール、侵入検知・防止システム（IDS/IPS）などのサードパーティ製ネットワーク仮想アプライアンスをデプロイ、スケーリング、管理できる

[ELBの比較表]


【ELBの機能】
ELBには負荷分散に関する様々な機能があります。下記では代表的な機能を紹介します。

■ELBのヘルスチェック
ELBはターゲットグループ内の各ターゲットが正常に動作しているかを定期的にヘルスチェックで確認します。ターゲットから正常に応答が返ってくれば、ELBはそのターゲットへのルーティングを継続します。もしターゲットが異常であると判断された場合は、ELBはそのターゲットへのルーティングを停止します。


ELBのヘルスチェックにはターゲットの復旧機能が含まれていないため、稼働するターゲット数を維持するにはAuto Scalingを用いて自動的に復旧する設計が必要です。

[ヘルスチェックの主な設定項目]


■アクセスログ
ELBに送信されるリクエストを記録しログをAmazon S3に保存します。記録されたログはトラフィックの分析やコンプライアンスの監査に利用できます。アクセスログには、クライアントのアクセス日時、接続元IPアドレス、ポート番号、ステータスコードなどクライアントの接続情報が記録されます。

■ELB自身のスケーリング
ELBにはリクエスト数の増減に応じてELB自身が自動的にスケーリングする機能があります。リクエスト数が増加したらELB自身を自動的にスケールアウト（追加）し、リクエスト数が減少したらスケールイン（削除）して元の状態に戻ります。

■リダイレクト
ALBには、ALBに送られてきたリクエストを別のURLにリダイレクトする機能があります。例えば、ユーザーから「http://www.example.com」（HTTP）へ送られたリクエストを「https://www.example.com」（HTTPS）に変換することで、セキュアな通信が可能になります。
HTTPのリクエストをHTTPSに変換するには、ALBでHTTPリスナーを作成し、HTTPSへリダイレクトするルールを設定します。下記の図は、HTTPリスナーのルール設定の例です。


■スティッキーセッション
ALBではCookieベースのスティッキーセッションが利用可能です。これは、ユーザーのブラウザに保存されたCookieの値をもとに、ALBが後続のリクエストを同じEC2インスタンスに継続的にルーティングする仕組みです。たとえば、WebアプリケーションがセッションIDを含むCookieを発行しておけば、ALBはその情報を参照して同じインスタンスにルーティングできるため、インスタンスのローカルメモリに保存されたショッピングカートの中身やログイン情報などのセッション状態を維持しやすくなり、ユーザーにとっての利便性が向上します。

[スティッキーセッションの仕組み]


スティッキーセッションを利用すると、ユーザーごとにセッション情報を保持できるため利便性が向上しますが、アクセス量が特定のユーザー群に偏った場合、一部のインスタンスに過剰な負荷がかかり、全体のパフォーマンスに悪影響を及ぼすことがあります。そのため、スティッキーセッションの有効期限は、永続的に維持するのではなく、セッション管理に必要最小限の期間で期限切れとなるよう設定し、特定インスタンスへの張り付き状態を解消しやすくすることが推奨されます。
また、より信頼性の高いシステム構築を目指す場合は、スティッキーセッションを使用せずにセッション管理を行う方法も有効です。アプリケーション側でCookieを用いてセッションの識別のみを行い、ショッピングカートの中身やユーザーのログイン情報などのセッションデータ自体は、ElastiCacheやDynamoDBなどの外部ストアに保存します。このようにセッション情報を外部ストアに保存しておけば、どのインスタンスにリクエストが振り分けられてもユーザーのセッション情報を維持・復元できるため、ALBのスティッキーセッション機能をオフにしても、インスタンス間で負荷を均等に分散しやすくなります。

【ELB経由の暗号化通信】
ELB経由でクライアントとターゲット間の通信を暗号化させるには、暗号化する通信の範囲とサーバー証明書（SSL/TLS証明書）の配置によって3つの方法があります。サーバー証明書とは、ユーザーとの通信をHTTPSで暗号化するとともに、ドメイン（ping-t.com など）の使用権を確認してアクセス先のサーバーが本物であるという証明する電子証明書のことです。ELB経由の暗号化通信に利用するサーバー証明書は、AWS Certificate Manager（SSL/TLS証明書を管理するサービス）で管理されている証明書を利用できます。

■クライアントとELB間の通信を暗号化する
○ELBにサーバー証明書を導入する
クライアントとELB間で通信を暗号化し、ELBとターゲット間は平文の通信（暗号化されていない通信）を行う方法です。クライアントとELB間での通信の暗号化・復号をELBが行うため、ターゲットに暗号化・復号による負荷が発生しません。すべてのELBが対応しています。


■クライアントとターゲット間の通信を暗号化する
○ELBとターゲットにサーバー証明書を導入する
クライアントとELB間、ELBとターゲット間で別の暗号化通信を行う方法です。暗号化接続はELBが終端となり、ELBから別の暗号化接続を確立して通信します。ELB、ターゲットに暗号化・復号による負荷がかかりますが、クライアントからターゲットまでの通信すべてを暗号化できます。ALB、CLBが対応しています。


○ターゲットにサーバー証明書を導入する
ELBでは暗号化・復号せず、直接クライアントとターゲット間で暗号化通信を行う方法です。ターゲットに暗号化・復号による負荷が発生しますが、ELBによる暗号化・復号の遅延を発生させずに通信全てを暗号できます。NLB、CLBが対応しています。


【SNIを利用したELB経由の暗号化通信】
通常のサーバー証明書は、一つのパブリックIPアドレスを持つサーバーに対して一つのドメイン名が紐づきます。例えば「example.com」と「example.co.jp」の2つのドメイン名を持つWebサーバーの場合、ドメイン名ごとに異なるパブリックIPアドレスを取得してサーバー証明書を導入する必要があります。しかしELBからドメイン名を複数持つWebサーバーへ通信を転送しようとすると、クライアントから見たWebサーバーのパブリックIPアドレスは窓口であるELBのパブリックIPアドレスしかないため、通常のサーバー証明書では対応できません。
SNI（Server Name Indication）は、暗号化通信で使用するサーバー証明書をパブリックIPアドレスではなくドメイン名によって判断する技術です。SNIに対応したELBに複数のサーバー証明書を導入すると、ELBが宛先ドメイン名から適切なサーバー証明書を判断してサーバーへ通信を転送します。SNIはALBとNLBが対応しています。