概要
はじめに
- ここ最近NLBを使ったシステムを構築していますので、本日はALB、NLBロードバランサーの比較と、NLBの特徴を中心に記事にまとめたいと思います。
ALB、NLBとは
- ALB、NLBのどちらもELB（Elastic Load Balancing）の1つです。ELBはAWSが提供するロードバランサーであり、受信したアプリケーションまたはネットワークトラフィックをEC2 インスタンス、コンテナなど、複数のターゲットに分散させることが可能です。
- ALB、NLBは、ヘルスチェックを利用して、異常なターゲットを検出すると、それらのターゲットに対するトラフィックの送信を中止し、残りの正常なターゲットに負荷を分散できます。
- 以下に、ALB、NLBの特徴をピックアップします。
- 詳細は、AWSドキュメントにまとめられている製品比較を参照。
ALBの特徴
- レイヤー 7 に対応、HTTP/HTTPS リクエストの負荷分散。
- クライアントとロードバランサーの間の HTTPS ターミネーションをサポート。
- セキュリティグループによるアクセス制限が可能。
- スティッキーセッションを使って、同一のクライアントからのリクエストを同一のターゲットにルーティングが可能。
NLBの特徴
- レイヤー 4に対応、TCP/UDPトラフィックの負荷分散。
- 高スループット（1 秒間に数百万件ものリクエストを分散可）、低レイテンシ。
- 送信元 IP アドレスの保持。クライアント側の送信元 IP が保持されるため、この情報をアプリケーションで使用して、他の処理を実行できる。
- 静的IPおよびElastic I IP のサポート。
NLBの最大の特長
- 高可用性、高スループット、低レイテンシであること。
- 長時間セッションも維持可能。
- 暖気なしに急激なスパイクにも対応可能（ALBは拡張が間に合わない場合あり）。
- クライアントの送信元IPアドレス/port がターゲットまで保持されること。
- 固定IPアドレスであること（EIPも利用可）。
NLBセキュリティの設定
- NLBには、セキュリティグループを関連付けることができません。インターネットからNLBに流入するトラフィックを制限するには、NLBのバックエンドに配置したインスタンスに関連付けるセキュリティグループによって制御します。
- ターゲットグループのヘルスチェックがHealthyに変わらない場合は、インスタンスに関連付けされているセキュリティグループを再確認します。NLBからインスタンスへ送られるヘルスチェックのPort、ソースIPアドレスが許可されていることをチェックします。
- 以下は、ALB、NLB構成の通信の流れ、セキュリティグループのイメージ図です。説明の便宜上、inbound ルールに、0.0.0.0/0を指定しておりますが、Internet facing の場合、可能な限りアクセス元およびPort を制限します。
- 以下の例では、ソースIPアドレス以外に、NLBからヘルスチェックを受け取れるようにセキュリティグループにVPC CIDR を追加しています。
NLBルートテーブルの設定
NLBをInternet Facingで使う場合、バックエンドとなるターゲットは、デフォルトルーター（Destinationは0.0.0.0/0）のターゲットにInternet GatewayあるいはNAT Gatewayを指定する必要があります。（ALB構成と異なり、ターゲット自身がInternetに到達できることを考慮する） ※2019/12/24訂正- ALB、NLBのどちらもInternet Facingで使う場合は、バックエンドとなるターゲット（Internetに到達できないプライベートサブネットに配置）は、デフォルトルーター（Destinationは0.0.0.0/0）のターゲットにInternet GatewayあるいはNAT Gatewayを指定する必要はありません。よって、NLB を使用した構成においても、NAT Gayeway を準備する必要なし。
- 以下、改めて実機確認の結果を元に、詳細に記載します。いずれの構成も無事200 OK のレスポンスが得られることが確認できました。
デフォルトルーターにNAT Gatewayあり
- パブリックサブネット（デフォルトルーターにInternet Gateway）にInternet facingのALBを配置し、バックエンドにEC2（プライベートサブネットに配置/デフォルトルーターにNAT Gateway） を準備しました。EC2 にはApacheにてテストページを準備し、curlにてhttpの疎通確認が可能です。
niikawa@niikawa1:~$ curl -v http://niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com
* Rebuilt URL to: http://niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com/
* Trying 52.197.xxx.xxx...
* TCP_NODELAY set
* Connected to niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com (52.197.xxx.xxx) port 80 (#0)
> GET / HTTP/1.1
> Host: niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
>< HTTP/1.1 200 OK
< Date: Tue, 24 Dec 2019 00:52:46 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 5
< Connection: keep-alive
< Server: Apache/2.4.41 ()
< Upgrade: h2,h2c
< Last-Modified: Mon, 23 Dec 2019 15:28:24 GMT
< ETag: "5-59a60adaa86a7"
< Accept-Ranges: bytes
<
test
* Connection #0 to host niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com left intact
- パブリックサブネット（デフォルトルーターにInternet Gateway）にInternet facingのNLBを配置し、バックエンドにEC2（プライベートサブネットに配置/デフォルトルーターにNAT Gateway） を準備しました。EC2 にはApacheにてテストページを準備し、curlにてhttpの疎通確認が可能です。
niikawa@niikawa1:~$ curl -v http://niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com
* Rebuilt URL to: http://niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com/
* Trying 18.176.xxx.xxx...
* TCP_NODELAY set
* Connected to niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com (18.176.xxx.xxx) port 80 (#0)
> GET / HTTP/1.1
> Host: niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 24 Dec 2019 00:52:22 GMT
< Server: Apache/2.4.41 ()
< Upgrade: h2,h2c
< Connection: Upgrade
< Last-Modified: Mon, 23 Dec 2019 15:28:24 GMT
< ETag: "5-59a60adaa86a7"
< Accept-Ranges: bytes
< Content-Length: 5
< Content-Type: text/html; charset=UTF-8
<
test
* Connection #0 to host niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com left intact
デフォルトルーターにNAT Gatewayなし
- パブリックサブネット（デフォルトルーターにInternet Gateway）にInternet facingのALBを配置し、バックエンドにEC2（プライベートサブネットに配置/デフォルトルーターなし） を準備しました。EC2 にはApacheにてテストページを準備し、curlにてhttpの疎通確認が可能です。
niikawa@niikawa1:~$ curl -v http://niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com
* Rebuilt URL to: http://niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com/
* Trying 13.114.xxx.xxx...
* TCP_NODELAY set
* Connected to niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com (13.114.134.240) port 80 (#0)
> GET / HTTP/1.1
> Host: niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 24 Dec 2019 00:53:23 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 5
< Connection: keep-alive
< Server: Apache/2.4.41 ()
< Upgrade: h2,h2c
< Last-Modified: Mon, 23 Dec 2019 15:28:24 GMT
< ETag: "5-59a60adaa86a7"
< Accept-Ranges: bytes
<
test
* Connection #0 to host niikawa-test-alb-1111111111.ap-northeast-1.elb.amazonaws.com left intact
- パブリックサブネット（デフォルトルーターにInternet Gateway）にInternet facingのNLBを配置し、バックエンドにEC2（プライベートサブネットに配置/デフォルトルーターなし） を準備しました。EC2 にはApacheにてテストページを準備し、curlにてhttpの疎通確認が可能です。
niikawa@niikawa1:~$ curl -v http://niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com
* Rebuilt URL to: http://niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com/
* Trying 18.176.xxx.xxx...
* TCP_NODELAY set
* Connected to niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com (18.176.xxx.xxx) port 80 (#0)
> GET / HTTP/1.1
> Host: niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 24 Dec 2019 00:53:35 GMT
< Server: Apache/2.4.41 ()
< Upgrade: h2,h2c
< Connection: Upgrade
< Last-Modified: Mon, 23 Dec 2019 15:28:24 GMT
< ETag: "5-59a60adaa86a7"
< Accept-Ranges: bytes
< Content-Length: 5
< Content-Type: text/html; charset=UTF-8
<
test
* Connection #0 to host niikawa-test-nlb-abcdefghijklmnop.elb.ap-northeast-1.amazonaws.com left intact
NLBは送信元IPアドレスを保持
ALB / NLBでは、送信元IPアドレスが異なる
- ALBは送信元IPアドレスをALBのIPアドレスに書き換えますが、NLBはターゲットグループにインスタンスを登録している場合、クライアントの送信元IPアドレスがターゲットまで保持されます。
- この送信元IPアドレスをアプリケーションで使用することで、IPアドレスに応じた処理を実行できます。
パケットキャプチャで送信元IPアドレスを解析する
- 送信元IPアドレスが保持されるのか、実際のパケットキャプチャを元に証明します。構成は、先ほどと同様に、パブリックサブネットにALB / NLB を配置し、バックエンドとしてプライベートサブネットにEC2（プライベートIP: 10.10.2.10）を配置しています。
- 以下、ALB構成のパケットキャプチャとなります。ALBのプライベートIP は、10.10.0.24 です。EC2へのHTTPリクエスト／レスポンスは、ALB～EC2間となります。
- 以下、ALB構成のパケットキャプチャとなります。NLBのプライベートIP は、10.10.0.46 です。EC2へのHTTPリクエスト／レスポンスは、クライアント（210.xx.xx.xxx）～EC2間となります。
NLBにElastic IPを割り当て
静的IPのサポート
- NLBは、AZ（サブネット）ごとに 1 つの静的 IPアドレスが付与され、IPアドレスが固定されます（但し、IPアドレスの指定は不可）。Internet facing、InternalのどちらにおいてもIPアドレスが固定される。
- ALB構成の場合、IPアドレスは動的に変わるため、ELBのDNS名を指定する必要がありました。Route 53では、DNS名をCNAMEとして登録、あるいはALIASレコード（Route 53 Aレコードの機能）として登録します。
- NLBの場合、IPアドレスが不変のため、Route 53のAレコードを使用することが可能です。
Elastic IPのサポート
- NLBは、AWSが自動で割り当てたアドレスの他に、Elastic IP を割り当てることもできます。ファイアウォール側の制約によって、ロードバランサーのIPアドレスを固定しなければいけない場合に便利です。
- 以下は、ALBを使用した場合のリスナーと配置するSubnetの設定です。リスナーには、HTTP、HTTPSのプロトコルを使用します。
- 以下は、NLBを使用した場合のリスナーと配置するSubnetの設定です。リスナーには、TCP、UDPおよびTLSのプロトコルを使用します。
- NLBを配置するSubnetを設定する際に、Elastic IP を選択可。
NLBのアクセスログはTLSプロトコルだけ
- NLBもALB と同じくアクセスログを取得することが可能ですが、NLBにTLSリスナーを設定し、TLSリクエストに関する情報のみログに記録されます。その点がALB と異なりますので、要注意。
- NLBにTCPリスナーを設定する場合、アクセスログではなく、VPCフローログで代替します。
- 以下、AWSのElastic Load Balancingドキュメントに記載あり。
最後に
- NLBをALB と同じと思って扱うと、設計・構築の漏れにつながります。また、ALB、NLBの違いを知ることで、NLBの最大の特長である高可用性、高スループット、低レイテンシが実現されていることも理解できます。
- NLBが暖気不要で拡張できる理由は、AWS Hyperplaneと呼ばれるAWS独自の負荷分散技術を利用しているため。詳細は、こちらの資料を参照。
参考資料
元記事はこちら
「ALB、NLBロードバランサーの特徴比較」
