AWSのロードバランサ機能・使い分けについて（ALB作成手順付き）

3. Application Load Balancer (ALB)

ALBはHTTPやHTTPSのトラフィックに対応する単一のロードバランサです。アプリケーションレイヤー（レイヤー7）で機能します。HTTP リクエストの負荷分散を行う必要がある場合はALBの利用が推奨されています。

ALBの特徴は以下の通りです。

コンテンツベースのルーティングが可能

トラフィックのコンテンツに基づいてリクエストを転送するリスナーのルールを設定することが可能です。リスナーとは、設定したプロトコルとポートを使用して接続リクエストをチェックするプロセスです。

リスナーに対して定義したルールの条件によって実行するアクションを決定できるので、高度なルーティングを設定することができます。

設定可能な条件は以下の通りです。

• リクエストURLのパスパターン

• HTTP ヘッダ内のホストフィールド

• 各リクエストのHTTP ヘッダ条件

• 標準またはカスタムのHTTP メソッド

• クエリ文字列のパラメータ

• 送信元IPアドレス

ユーザ認証機能

ALBではユーザがアプリケーションにアクセスした際のユーザ認証を設定できます。ALB側で安全に認証してくれるので、アプリケーション側で認証のロジックを考慮することがなくなります。

ユーザ認証は、Amazon Cognito による認証もしくはOpenID Connect (OIDC) に準拠する ID プロバイダー (IdP)による認証が可能です。

4. Network Load Balancer (NLB)

NLBはレイヤー4で機能し、TCPやUDPのトラフィックを負荷分散します。非常に高いパフォーマンスで低レイテンシを維持することが可能です。大量のアクセスが想定されるアプリケーションにおいてはNLBの利用が推奨されています。

NLBの特徴は以下の通りです。

IPアドレスを固定

ALBやCLBではIPアドレスを固定することができません（※DNSで定義することは可能です）が、NLBではIPアドレスを固定することができます。

NLB作成時に自動割り当てされたIPアドレスまたは持っているIPアドレスを指定して固定します。

IPアドレスを指定したい場合は事前に作成しておく必要があります。NLB作成後はIPアドレスを変更することはできません。

パフォーマンスが高く、低レイテンシ

NLBでは毎秒数百万のリクエストを処理することができます。突発的なアクセス上昇にも対応することが可能です。またIPアドレスを固定したまま動的にスケールします。

同一のアベイラビリティゾーン内でTCP負荷分散を行うので、レイテンシが低いのも特徴です。

クライアントのSource IPとPortを保持

リクエストをターゲットにルーティングする際、クライアントのSource IPとPortがそのまま届くため、クライアントと直接通信しているように見せることができます。

5. Gateway Load Balancer (GWLB)

GWLBはファイアウォール、侵入検知および防止システム、ディープパケットインスペクションシステムといったサードパーティー仮想アプライアンスを簡単にデプロイ、スケーリング、管理することができます。

インターネットゲートウェイ経由で入る全てのトラフィックはGWLBエンドポイントにルーティングされ、検査されます。リスナールールに指定されたターゲットへトラフィックを分散しながら、仮想アプライアンスを需要に応じてスケーリングします。

レイヤー3で機能しますが、レイヤー3のゲートウェイ機能とレイヤー4の負荷分散機能の両方を備えています。

GWLBの特徴は以下の通りです。

サードパーティー製の仮想アプライアンス製品で高可用性を発揮

AWS上でサードパーティー製のセキュリティアプライアンス製品などを利用する場合、可用性の高い構成をとることが可能です。

全てのレイヤー3トラフィックをサードパーティーの仮想アプライアンスに透過的に渡すため、トラフィックの送信元と送信先からは見えません。

トラフィックフローを正常な仮想アプライアンスを介してルーティング

仮想アプライアンスのフリート間でトラフィックの負荷分散を行うことで、仮想アプライアンスを自在にスケーリングできます。アプライアンスが異常になるとフローを再ルーティングします。

6. Classic Load Balancer (CLB)

CLBは複数のEC2インスタンスの負荷分散をします。ほとんどの機能についてはALBとNLBでカバーできますが、以下のような特殊なケースの場合はCLBを利用することができます。

• EC2-Classicのアプリケーション

• TCPおよびSSLリスナーの設定が必要

• アプリケーションで生成されたCookieを使用したスティッキーセッション

上記のケースに当てはまらない場合、既存のCLBについてはALBかNLBに移行することを推奨されています。

7. ALBの作成手順

ここまで4種類のロードバランサについて説明しましたが、ALBの作成を実際に行ってみたいと思います。

AWS CLIでも作成することが可能ですが、今回はAWS Management Console を使用して作成してみます。

■構成の内容

今回は以下の図のような構成を作成します。実際にサービスを提供する際は2台構成で提供するので、冗長構成 + ALBで組んでみて最後に切り替えのテストを行います。

■事前準備

・VPCの作成（インターネットゲートウェイをアタッチ）

・EC2インスタンスを3台作成（2つのアベイラビリティゾーンにて、片方は1台、もう片方は2台配置。全てのインスタンスにテスト用としてWordpressをインストール）

・ALBに適用するターゲットグループを2つ作成（ターゲット1にServer1とServer2を登録、ターゲット2にServer3を登録）

■構築手順

①ロードバランサ選択

Amazon EC2コンソールを開き、[ロードバランシング] の [ロードバランサ]を選択します。[ロードバランサの作成]をクリックします。

ロードバランサのタイプにて、Application Load Balancerの欄の[Create]をクリックします。

②Basic configuration の設定

[Load Balancer name]にロードバランサの名前を入力します。

• 英数字とハイフンのみの最大32文字で、リージョン内のALBとNLBの中で一意である必要があります。

• 先頭および末尾にハイフンまたは「internal-」を付けることはできません。

[Scheme]を選択します。

• [Internet-facing]はクライアントからインターネット経由でリクエストをルーティングします。今回はこちらを選択します。

• [Internal]はプライベートIPアドレスを使ってリクエストをルーティングします。

[IP address type]では、IPv4を選択します。

③Network mapping の設定

[VPC]にはEC2インスタンスと同じVPCを選択します。

※[Scheme]にて[Internet-facing]を選択している場合にはインターネットゲートウェイを持つVPCだけが選択できます。

[Mappings]にて対応するパブリックサブネットを選択します。

④Security groups の設定

[Security groups]のプルダウンから事前に作成したセキュリティグループを選択します。

⑤Listener and routing の設定

 [Default action]にて、事前に作成したターゲットグループを設定します。

※今回は不要ですが、HTTPSリスナーを利用する際はロードバランサにSSL証明書をデプロイする必要があります。

⑥ロードバランサ作成

[Create load balancer]をクリックするとALBのロードバランサが作成されます。

⑦リスナールールの更新

作成したロードバランサを選択し、[リスナー]タブの[ルールの表示/編集]を設定します。

[ルールの挿入]より、以下のルールを追加します。

・条件（IF）：HTTPヘッダの[User-Agent]が”*Edg*”であるとき

・アクション（THEN）：ターゲットグループ2にトラフィックを転送する

トラフィックをターゲットグループ1に転送するデフォルトのルールはそのままで、特定のブラウザからアクセスがあった場合はターゲットグループ2に転送するという設定が完了しました。

※ 今回は例としてHTTPヘッダでの条件を設定しましたが、前述した通りURLのパスパターンやホストヘッダなど、コンテンツベースでのきめ細やかな条件設定が可能です。

以上でALBの作成手順は完了です。

続いてロードバランサのテストを行います。

■確認

①ターゲットグループに登録されているインスタンスの確認

[ロードバランシング] > [ターゲットグループ] にて作成したターゲットグループ1をクリックし、[Targets]タブからインスタンスが2台登録されていることを確認します。

2台とも[Health status]が「healthy」であることを確認します。

②Webページへのアクセス

作成したロードバランサのDNS名をコピーし、Chromeブラウザに貼り付けてアクセスします。

WordPressのページが表示されることを確認します。

③切り替えの確認

Server 1のインスタンスを停止し、ターゲットグループ1の[Health status]が「unused」となることを確認します。

再度ロードバランサのDNS名からChromeブラウザでアクセスすると、2台起動している場合と変わらずWordPressのページが表示されることを確認します。

これで冗長構成が正常に機能していることが確認できました。

④インスタンスの停止

ターゲットグループ1のインスタンスServer 1とServer 2を両方とも停止します。

[Health status]が「unused」となることを確認します。

ターゲットグループ2のインスタンスServer 3は停止しないので、[Health status]が「Healthy」であることを確認します。

⑤特定のブラウザからのアクセス確認

ロードバランサのDNS名をChromeブラウザに貼り付けてアクセスすると、ターゲットグループ1にルーティングされるため、エラーが表示されることを確認します。

ロードバランサのDNS名をMicrosoft Edgeブラウザに貼り付けてアクセスすると、ターゲットグループ2にルーティングされるため、WordPressのページが表示されることを確認します。

これでリスナーのルールによってトラフィックを振り分けできていることが確認できました。

以上、ロードバランサが正常に機能していることを確認できました。

8. さいごに

ELBで提供されている各ロードバランサについてその特徴を見ていきました。AWSはロードバランサが4つもあるので、用途や要件によって使い分けすることが可能です。

Application Load Balancer (ALB)

 … レイヤー7のHTTPリクエストの負荷分散、およびコンテンツベースのきめ細やかなルーティング

Network Load Balancer (NLB)

 … レイヤー4のTCP/UDPの負荷分散、および高パフォーマンスで低レイテンシ

Gateway Load Balancer (GWLB)

 … レイヤー3のサードパーティー製の仮想アプライアンス導入およびデプロイ

Classic Load Balancer (CLB)

 … レイヤー4または7のALBやNLBでカバーできない特殊ケース

他クラウドのロードバランサと比較する際の材料となれば幸いです。

最後までご覧いただきありがとうございました。

参考資料

関連サービス