(こちらの記事はCAM Advent Calendar の３日目の記事でもあります。)
最近、AWSのロードバランサーのNetwork Load Balancer(NLB)にふれる機会があったのでそれについて。
Application Load Balamcer(ALB)と比較しながら書いていこうと思います。
AWSのロードバランサー
AWSのElastic Load Balancer(ELB)には以下の3つが存在します。
・Classic Load Balancer(CLB)
・Application Load Balamcer(ALB)
・Network Load Balancer(NLB)
上記、古い順に並べてみました。
CLBとALBに関しては一般的なイメージのもので、requestを受付け、各アベイラビリティーゾーン内のターゲットグループにトラフィックを分散させていくものです。
NLBに関してはだいぶ毛色が違います。
NLBに移行することでより多量のリクエストに対応できたり、静的IPアドレスが割り当てられ、route53でAレコード*1が使えるため、名前解決*2が早い、などのメリットがあります。
以下では両者を比較していきましょう。
通信経路
ALBがクライアントからサーバーへの通信の端を保証するプロキシとしての働きとは変わって、NLBは送信先のIPのみを変換します。
NLBはターゲットとクライアントが直接通信するように見えますが、実際はNLBを経由しています。
下記で詳しく説明します。
送信元のアドレスの保持
ALBの場合だとパケットの送信元のIPをロードバランサーのものに置き換えていますが、NLBを用いてインスタンスIDでターゲットを指定すると送信元のIPを保持してくれます。*3
従来だとXFF*4で送信元のIPアドレスをチェックしていましたが、その必要がありません。
セキュリティ的に必要な機能です。
通信手段(リスナーの設定)
ALBはHTTP、HTTPSをサポートしていますが、NLBはTCP、TLS、UDP、TCP_UDPしかしていません。
NLBはUDPも対応していることから、 応答性の良さを優先したい通信や、リアルタイム性が重要視される通信に用いることができます。
セキュリティグループがない
一番大きい点かもしれません。
セキュリティグループとは、インスタンスレベルで設定されるVPC内でのトラフィック制御に用いられるもので、
通常はALBのセキュリティグループをターゲットとなるEC2のセキュリティグループのインバウンド*5に設定することで通信を可能にしていましたが、NLBにはセキュリティーグループが存在しないのでこの方法ではできません。
これに対する対策としてはVPCのプライベートネットワーク内でEC2のセキュリティグループのインバウンドにIPとして0.0.0.0を指定する方法があります。
クロスゾーン負荷分散
ALBではクロスゾーン負荷分散はデフォルトで有効化されていますが、NLBではデフォルトで無効化されています。注意。
そもそもクロスゾーン負荷分散とは。
従来なら クライアントからのリクエストをロードバランサーのアベイラビリティーゾーンと同じ登録済みターゲットに分散させますが、クロスゾーン負荷分散が有効な場合は、ロードバランサーが有効なすべてのアベイラビリティーゾーンの登録済みターゲットに分散させます。
上記の図を見てみるとわかるように、クロスゾーン負荷分散が無効の場合は各アベイラビリティーゾーンに50%ずつトラフィックを割り当てたとして、そのアベイラビリティーゾーン内でトラフィックが割り振られているので、ターゲット単位で見るとすべてのターゲットに対して等しくトラフィックは分散されていません。
一方、クロスゾーン負荷分散が有効な場合は、アベイラビリティーゾーンにの枠に捕らわれずに各ターゲットに等しくトラフィックが分散されています。
もし片方のアベイラビリティーゾーン内のターゲットが全滅した場合にでも、クロスゾーン負荷分散が有効な場合はLBに来たアクセスはもう片方のアベイラビリティーゾーン内のターゲットに行くため、可用性が高いことがわかります。
まとめ
一般的な認識のALBとは若干違う部分がNLBには多く、クセがあるように感じました。
設定する際はこちらをよく確認しましょう。
・ElasticLoadBalancingV2 リソースタイプのリファレンス
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/AWS_ElasticLoadBalancingV2.html
