##1.Elastic Load Balancing（ELB）とは##
複数のEC2インスタンス間で、アプリケーショントラフィックの負荷を自動的に分散してくれるものです。
単一障害点（SPOF）を無くすためには欠かせないサービスでしょう。
##2.特徴##
・Amazon CloudWatch にメトリクスを送ることもできる。
・インスタンスの異常や特定のメトリクスを検知することができる。
##3.ELBの種類##
- Application Load Balancer
HTTP / HTTPS トラフィックの負荷分散に最適なロードバランサです。Webサイトのロードバランサとして使用するのであれば、このロードバランサをおすすめします。L7レイヤーで負荷分散します。 - Network Load Balancer
TCPトラフィックなどネットワーク系の負荷分散に最適なロードバランサです。 - Classic Load Balancer
複数のAmazon EC2インスタンスにおける基本的な負荷分散を行うのに最適なロードバランサです。L4レイヤーで負荷分散します。
参考：製品の比較
Classic Load Balancer は、複数の EC2 インスタンス間でのシンプルなトラフィックの負荷分散に最適です。
一方、Application Load Balancer は、高度なルーティング機能、マイクロサービス、およびコンテナベースのアーキテクチャが必要なアプリケーションに最適です。
##4.Application Load Balancer##
Classic Load Balancer よりも
- サポートされるリクエストプロトコル、HTTP/2やWebSocketsが追加された。
- メトリクスとより詳細なアクセスログが取得可能になった。
- よりきめ細やかなヘルスチェックを設定できるようになった。
- VPCでのネイティブIPv6サポートがサポートされた。
- AWSアプリケーションファイアーウォールと統合された。
- パスベースやホストベースのルーティングを使用したリクエスト向けの新しいルーティングメカニズムが実現された。CLBしか存在しなかった時代に複数ドメインを運用していた場合は、ドメイン分だけCLBを配置する必要ありましたが、 ALBのホストベースルーティングを利用することによって、複数のドメインを1つのALBで運用可能になりました。URLのパスベースでもルーティングが可能となるため、バックエンドのEC2群をわけることが可能で、ELBのコストを効率化することができます。
- パスベース：リクエスト内のURLに基づいて、ターゲットグループへのルートを設定
- ホストベース：要求されたドメインに基づいて、ターゲットグループへのルートを設定
参考：【新発表】AWS アプリケーションロードバランサー
これではわかりにくいので、具体的にユースケースなどを見ていきましょう！
↑単一のALBからポートによって複数のアプリケーションへとルーティングすることができます。
↑リスナーは送信先（ターゲット）をグループ化（ターゲットグループ）できるようになっています。
##5.Classic Load Balancer##
概要
↓を読めばいいかなと。
参考：Classic Load Balancer の概要
重要なのは、複数のAZに分散させることで、高可用性と耐障害性を確保する、最小限のオーバーヘッドで伸縮性と拡張性を向上させること。
トラフィック分散機能
| プロトコル | 分散 |
|---|---|
| TCP | リクエストの処理にはシンプルなラウンドロビンのアルゴリズムが使用される。 |
| HTTP HTTPS | リクエストの未処理数が最も少ないバックエンドインスタンスを利用します。 なお、バックエンドインスタンスにアクセスするための単一の公開アクセスポイントを作成できます。最も簡単な方法はドメインのCNAMEによってELBのエンドポイントが作成されるようにAレコードを設定することです。 |
デフォルト値
| 作成方法 | デフォルト |
|---|---|
| AWSマネージメントコンソール | 有効 |
| コマンドラインツール、SDK | 無効 |
タイプ
| タイプ | 説明 |
|---|---|
| 外向けロードバランサー | インターネットからアクセスできるELB |
| 内向けロードバランサー | VPC内やオンプレ環境からのみアクセスできるELB |
##6.ヘルスチェック##
draining
ターゲットグループから、EC2インスタンスを削除すると、draining 状態になります。
ELBから切り離されたときに、直ぐに切ってしまうとそのサーバーで処理をしていたものも滑全て止まってしまい、迷惑がかかってしまう。
要するに、やっている処理が終わってからターゲットグループから外すよーというものです。
##7.設計のポイント##
-
AZをまたがったサーバ配置にする。
-
AZ障害に対応できるようにする。
-
アピりケーションをステートフルに構築する。
-
どのサーバーに振られても処理を継続できるようにする。
-
スケールインにも対応できるようにする。
##8.クロスゾーン負荷分散##
ELBの「クロスゾーン負荷分散」を有効にすると複数AZにまたがって登録されたEC2インスタンスに均等に負荷が分散されます。
参考：ELBの「クロスゾーン負荷分散」はどのようなケースで有効化するのか
- ALBは選択不可、常にクロスゾーン負荷分散がELBでは有効になっている
- NLBは属性の編集から選択可能。
- CLBは作成時に選択可能。
##9.Demo##
ELB - Amazon EC2 ハンズオン
##10.スティッキーセッション##
HTTPレスポンスにELBでCookieを埋め込んで、そのCookieを基にバインド先のインスタンスを固定するというものです。
EC2をオートスケールなどで、動的に増減させる場合や、送信先のEC2が障害によってダウンした場合は、送信先のEC2が障害によってダウンした場合は、セッションが途切れる問題が発生するため、ELBによるスティッキーセッションは一時的に利用するのが望ましい。
セッション情報は別データベース（DynamoDBやElasticCache）やキャッシュサーバなどに持たせることが推奨されています。
- ALB
設定は「ターゲットグループ」に対して行う
-
[2020/02/08 update]Application Load Balancer now supports Application Cookie Stickiness
今までALBによって自動的に生成されるCookieを利用することはできましたが、Cookie名を自分で定義できるアプリケーションベースのCookieにはALBは対応しておりませんでしたが、これが利用可能になりました。
設定は、ターゲットグループの属性で設定が可能です。
ひとつのALBで複数のアプリケーションを利用している場合、この機能が役に立ちます。
-
CLB
設定は「CLB自体」に対して行う
参考：ELBとStickySessionについて(2018/03現在)
リクエストにCookieが存在しないときの動作
1.まず、Cookieがサービスリクエストに存在していること確認する。
2.Cookieはリクエストに見つからないため、サービスリクエストをルーティングするインスタンスを決定する。
3.Cookieは応答に挿入される。
##11.Network Load Balancer##
TCPの負荷分散に特化したロードバランサーです。
CLBやALBは、急激なアクセス増加があった場合、CLB、ALB側のオートスケールが間に合わずエラーとなる場合があります。そのため事前にリクエスト量を増やしておくか、AWSサポートに暖気申請（Pre-warming申請）をしておく必要があります。
NLBの場合は暖気不要で、突発的な数百万リクエスト/秒のリクエストを処理できることが特徴です。
- 高スループット、低レイテンシー
- フォルトトレランス機能を備えている。
- SSL Termination 機能はない。バックエンドのシステムで行う必要があります。
- ターゲットにIPアドレスを指定可能。なので、オンプレミスのサーバをバックエンドにすることも可能です。
- 固定のグローバルIPを付与できる。（ElasticIPの利用も可能です。）
- Source IP / Portがターゲットまで保持する。CLBやALBはプロキシと同じ処理を行うため、配下のEC2から見たときに、アクセス元となるSourceIPはCLB、ALBのIPアドレスになります。そのため、アクセス制限などを行う場合は、ヘッダーを参照する必要があります。NLBはSourceIPの書きかえは行いません。プロキシとして利用していたEC2をNLBに置き換えてプロキシとして利用するのも可用性やコスト削減へとつながります。
##12.connection draining##
ELBから切り離してもリクエスト中のインスタンスへ指定秒数の間は通信は切れません。
新規にリクエストがあっても既に切り離されたインスタンスへのアクセスはできません。
デフォルトで300秒になっている。
##13.リンク##
AWS Gateway Load Balancer が東京リージョンに対応したらしいので試してみた