【AWS基礎】ELBのサービス概要

サービス	説明
ALB（Application LB）	OSI基本参照モデルの第7層(アプリケーション層)に向けて、ロードバランシング機能を提供する。
NLB（Network LB）	OSI基本参照モデルの第4層(トランスポート層)に向けて、ロードバランシング機能を提供する。
GWLB（Gateway LB）	OSI基本参照モデルの第3層(ネットワーク層)に向けて、ロードバランシング機能を提供する。
CLB（Classic LB）	ALB及びNLBの前身となる、いわゆるレガシーなサービス。L4およびL7双方に向けたロードバランシング機能を持つ（機能はALB、NLBそれぞれに劣る）。

以降、ALBの詳細と、NLB、GWLBの概要を見ていく。

（CLBは割愛）

２．ALB

ALB（Application Load Balancer）は、

アプリケーション層向けのロードバランシングサービスである。

◎構成コンポーネント

ALBは以下のコンポーネントによって構成される。

コンポーネント	説明
リスナー	あらかじめ設定しておいたプロトコル+ポートをリッスンし、クライアントからの接続リクエストをチェックする。リスナーには1つ以上のルールをあらかじめ定義しておく必要がある。
ルール	「優先度・条件・アクション」の３つから構成される、トラフィックの振り分けルール。リスナーに1つ以上定義しておく必要がある。詳細はルールの設定を参照。
ターゲット	トラフィックの割り振り先となるノード。例：Amazon EC2（オートスケーリング）、AWS Lambda、Amazon EKS、Amazon ECSなど
ターゲットグループ	同じプロトコル+ポートの組合せでルーティングさせたいターゲットの集合体。 1つ以上のターゲットで構成され、各ターゲットは複数のAZ（アベイラビリティゾーン）にまたがって存在しても良い。（むしろAZを分散させたほうが、AZ障害時でも他のAZ内のターゲットでカバーでき、システム全体として可用性が上がる）ターゲットグループ毎にヘルスチェックを実施できる（詳細はALBのヘルスチェック機能参照）。

クライアントからは、最終接続先となるターゲットは見えず、ALBだけが見えている状態となっている。

図示するとこんな感じ↓

※上図のベースとなる図は公式ドキュメントのものを使わせて頂きました

◎ロードバランシングの流れ

ALBでのロードバランシングの流れは、以下のようになっている。

①クライアントがALBに向けてリクエストを送信する。

②指定のプロトコル+ポートの組合せに合致するALBのリスナーが、リクエストを受信する。

③リスナーは、優先度順にリスナールールを照合し、適用するルールを決定する。

④適切なターゲットグループにリクエストを振り分ける。

◎ルールの設定

リスナーに定義するルールには、優先度、条件、アクションを設定する。

複数のルールがリスナーに定義されていた場合、

優先度の高いルールから順に、リクエスト内容と条件が照らし合わされる。

また、リクエスト内容が②条件に合致したら、

指定のアクション（ターゲットグループへのリクエスト転送／リダイレクト／固定レスポンス返却）が実行される。

ルールの条件には、以下の内容を細かく設定できる。（条件は1つ以上必要）

条件	説明
ホストヘッダ	ホストヘッダによって振り分けを変えたい時に、ホスト名を指定。（例：*.example.com）
リクエストメソッド	HTTPリクエストメソッド（GETやPOSTなど）によって振り分けを変えたい時に、メソッド値を指定。
パスのパターン	リクエスト先のページのパスによって振り分けを変えたい時に、パスのパターンを指定。（例：/img/*）
送信元IP	送信元IPによって振り分けを変えたい時に、 CIDRブロックを指定。
HTTPヘッダ	HTTPヘッダ（リクエストの頭部分にある制御情報）によって振り分けを変えたい時に、ヘッダ項目と値を指定。
クエリ文字列	URLパラメータによって振り分けを変えたい時に、キー/値のペアを指定。

◎ルーティングアルゴリズム

ALBのルーティングのアルゴリズム（＝リクエストの振り分け方法）は、

デフォルトではラウンドロビンとなっている。

ラウンドロビンとは、ターゲットグループ内の各ターゲットノードへ、

リクエストを順繰りに割り振っていく方式である。

例えば、3つのターゲットノード（A,B,C）で構成されるターゲットグループにおいて、

1回目のリクエストはノードA、2回目はノードB、3回目はノードC、

4回目は最初に戻ってノードA、5回目はノードB…、

というように割り振る。

ラウンドロビン以外では、LOR (Least Outstanding Requests) というアルゴリズムを指定することもできる。

LORは「最小未処理リクエスト」と訳され、

未処理のリクエスト数が最も少ないターゲットノードに対し、新規のリクエストが割り振られる。

シンプルに順番で割り振り、負荷状況を考慮しないラウンドロビン方式とは異なり、

LORでは負荷が均等に分散する。

ラウンドロビンとLORで、性能の違いがどこまであるのかは分からなかった（かつ、自分で性能検証するにはそれなりのお金が必要なのでやりたくないｗ）が、

本当の意味で負荷分散するのならLORが良いように思われる。

＊補足：スティッキーセッションについて

ALBでは、スティッキーセッション（別名：セッションアフィニティ）を設定することもできる。

スティッキーセッションとは、クライアントの同一セッションを、

特定のターゲットに割り振る機能である。

スティッキーセッション機能を利用すると、同一セッション中の全リクエストが、

同じターゲットに割り振れるため、

クライアントに連続したエクスペリエンスを提供することにつながる。

ただしスティッキーセッションを実現するには、ALBでの設定に加え、

クライアントがCookieを許可する必要がある。

◎ALBのヘルスチェック機能

ALBには、登録されたターゲットの状態を確認するために、

定期的にリクエストを送信するヘルスチェックの機能が備わっている。

リクエストはHTTP GETメソッドで送信され、

応答結果によってターゲットの状態が確認される。

ヘルスチェックで正常とみなされたターゲットにのみ、

クライアントからのリクエストをルーティングする仕組みとなっている。

なお、ヘルスチェックの結果、ターゲットグループ内の全ターゲットが異常だと判定された場合、

クライアントからのリクエストは全ターゲットに割り振られる。

＊ヘルスチェック関連のパラメータ

ヘルスチェック方法を決めるための、主なパラメータは以下の通りである。
（詳細および全てのパラメータは公式ドキュメント参照）

パラメータ	説明
HealthCheckProtocol	ヘルスチェック時に使用するプロトコル（HTTPまたはHTTPS）。
HealthCheckPort	ヘルスチェック時に使用するポート番号。デフォルトでは、ターゲットがALBからトラフィックを受信する際のポートが用いられる。
HealthCheckTimeoutSeconds	ヘルスチェック＝失敗とみなす、ターゲットからレスポンスがない時間 (秒)。
HealthCheckIntervalSeconds	ヘルスチェック実施間隔（秒）。
UnhealthyThresholdCount	ターゲットを異常としてルーティング対象から外すまでの失敗連続回数。

◎ユーザ認証機能

ALBを利用すると、ユーザのアプリケーションアクセス時に、オプションで認証を行うこともできる。

ALBの認証機能を利用するには、HTTPSをリッスンしておく必要（HTTPは不可）がある。

認証機能を利用する場合、ALBは、認証ステータス維持のためのセッションCookieを、

自動でクライアントに送信することになる。

３．NLB

NLB（Network Load Balancer）は、トランスポート層（OSI基本参照モデル第4層）向けのロードバランシングサービスである。

NLBのロードバランシングの流れや、NLBを構成するコンポーネントなど、

基本的な考え方はALBに同じである。

４．GWLB

◎概要

GWLB（Gateway Load Balancer）は、

ネットワーク層（OSI基本参照モデル第3層）向けのロードバランシングサービスである。

GWLBを用いることで、サードパーティ提供の様々なセキュリティ仮想アプライアンスを、

簡単にデプロイ、スケーリング、管理できるようになる。

ここでいう「セキュリティ仮想アプライアンス」とは、例えば、

　・ファイアウォール（FW）

　・侵入検知（IDS）および防止システム（IPS）

　・ディープパケットインスペクションシステム（DPI／パケットの中身自体を検査するシステム）

などのセキュリティ製品を指す。

GWLBは、LB（ロードバランサ）と名のついている通り、

セキュリティ仮想アプライアンスをターゲットにして、

負荷分散やスケーリング（スケールアウト／スケールイン）、ヘルスチェック等の機能を持つ。

◎構成

GWLBの構成コンポーネントとして重要なのは、GWLBの他、GWLBエンドポイントである。

GWLBエンドポイントは、仮想アプライアンス用のVPC（AWSではサービスプロバイダVPCと呼ばれる）と、

アプリケーション本体用のVPC（AWSではサービスコンシューマVPCと呼ばれる）とを、

プライベートに結ぶための接続点となる。

※前提として、セキュリティ仮想アプライアンスを配置するAWS VPCと、

アプリケーションサービス本体を提供するサーバ群を配置するAWS VPCは、別々に分かれている必要がある。

GWLB、GWLBエンドポイントと、各VPCやサービスの配置関係は以下のようになる。

※ベース図は公式ドキュメントより転用。

◎GWLBの大まかな動き

GWLBの大まかな動きを説明する。

ここでは、インターネットからリクエストが来た時の流れを例にする。

※ベース図は公式ドキュメントより転用。

インターネットGW経由でアプリケーション本体用のVPC（サービスコンシューマVPC）に入ってくる全トラフィックは、

まずGWLBエンドポイントにルーティングされる（図の①、②）。

GWLBエンドポイントからGWLBに送られたトラフィックは、

GWLBのルールに基づいて、仮想アプライアンスにてセキュリティ精査される（図の③）。

セキュリティ精査で問題なければ、GWLB→GWLBエンドポイントにトラフィックが戻され、

本来のリクエスト先である、送信先サブネットにルーティングされる（図の④、⑤）。

ちなみに、GWLBでは全ポートで全IPパケットをリッスンすることが決まっている。

GWLBのリスナーに対し、リッスン対象のプロトコルやポートの指定はできない。

今回は以上！（NLBの解説雑でごめんなさいｗ）