はじめに
NLB を利用した構成でハマったポイントがあったため、ALB との違いを交えて紹介します。
構成図はこちらです。
NLB を選んだ理由は L4 でトラフィックルーティングしたかったからです。
ALB を挟んで SSL オフロードしたりせず、HTTPS のまま EC2 まで到達させます。
ポイント
ポイントとなる ALB との相違点は下記になります。
- NLB は Security Group をアタッチできない
- NLB はクロスゾーン負荷分散はデフォルトで無効
ハマリポイント1 ｜ NLB からのヘルスチェックに失敗する
事象
ターゲットグループで設定しているヘルスチェックが成功せず、Unhealthy 状態になっていました。
ヘルスチェックのプロトコルは TCP 、ポートは Traffic port となっており意図した通り設定されていました。
試しに外部からリクエストしたところ、正常なレスポンスが返っていました。
よって、ヘルスチェックにだけ問題がある状態でした。
原因と対応
原因は NLB が設置されているサブネットの IP アドレスを許可していないことでした。
NLB には Security Group をアタッチできないため、アドレス制限の観点では Client からのリクエストは直接 EC2 に到達します。
EC2 の Security Group は Client の IP アドレスのみ許可する設定になっていました。
Client からのアクセスの場合は、Client の IP アドレスが評価されるため問題なくリクエストが処理されます。
一方で NLB からのヘルスチェックの場合は、
NLB が配置されているサブネットの CIDR を許可していないため Security Group によって弾かれてしまいます。
EC2 の Security Group でサブネットの CIDR を許可することでヘルスチェックが通るようになりました。
ALB ではこのような事象は基本起きないです。
ALB は Security Group をアタッチ可能であるため、EC2 の Security Group で、
ALB にアタッチされた Security Group からのアクセスを許可するのが一般的です。
こうすると、「Client からのリクエスト」と「 ALB からのヘルスチェック」はネットワーク的に差分がありません。
ハマリポイント2 ｜ クロス AZ でトラフィックルーティングされない
事象
NLB にアクセスしたとき、配下の EC2 に負荷分散されることが想定でした。
しかし、実際には、AZ1 の NLB にアクセスしたときには AZ1 の EC2 、
AZ2 の NLB にアクセスしたときには AZ2 の EC2 しかレスポンスを返しませんでした。
つまり、片側の NLB から見た EC2 は実質1台になっており、フェイルオーバーが実現できないことになります。
原因と対応
原因は NLB の設定漏れでした。
Application Load Balancer では、クロスゾーン負荷分散が常に有効になっています。
Network Load Balancer と Gateway Load Balancer では、クロスゾーン負荷分散はデフォルトで無効になっています。ロードバランサーの作成後は、いつでもクロスゾーン負荷分散を有効または無効にできます。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html
ロードバランサーの属性 load_balancing.cross_zone.enabled を True にすることで解決しました。
相違点まとめ
| ALB | NLB | |
|---|---|---|
| レイヤ | L7 | L4 |
| Security Group | アタッチ可 | アタッチ不可 |
| クロスゾーン負荷分散 | デフォルト有効 | デフォルト無効 |
| EIP | アタッチ不可 | アタッチ可 |
↑ きっと他にもありますが、この記事で触れた部分だけになります。