マルチAZ NLBで一部ENIへの通信がタイムアウトする原因と対策
データ事業本部の荒木です。
今回は、AWSでNetwork Load Balancer(NLB)をマルチAZ構成で利用する際に遭遇した、ネットワーク設計上の気を付ける必要がある設定について紹介します。
はじめに
今回の事象としては、「マルチAZで構築したNLBに付与されたENI（Elastic Network Interface）のうち、片方のENIのIPアドレスには正常に通信できるが、もう片方には通信がタイムアウトする」というものです。
この問題の原因は、NLBの基本設定であるクロスゾーン負荷分散（Cross-Zone Load Balancing, CZLB）の仕様と、バックエンドターゲットのAZ構成の不一致にありました。本記事では、この詳細な原因と、最適な設計パターンについて解説します。
事象の背景と構成
1. 構成の目的
今回構築したリソースは以下の構成となっています。
特定のプライベートサブネットに構築されたAmazon Redshiftクラスターに対し、インターネット経由でアクセスを許可するための中継点としてNLBを利用しました。
他システムで利用しているNLBに相乗りして、Redshiftのインターネット公開にマルチAZのNLBを使用しています。
2. 環境のAZ構成
| コンポーネント | AZ構成 | 配置AZ |
|---|---|---|
| ターゲット (Redshift) | シングルAZ | ap-northeast-1c のみ |
| ロードバランサー (NLB) | マルチAZ | ap-northeast-1c と ap-northeast-1a |
Redshiftクラスターの「拡張されたVPCのルーティング」をONにしていたため、可用性ゾーン(ap-northeast-1c)に自動生成されたRedshift用VPCエンドポイントのプライベートIP(192.168.0.70)をNLBのターゲットグループに登録しました。
NLBは、このターゲットのAZと異なるゾーン(ap-northeast-1a)も含めたマルチAZで構築されています。
発生した接続不可事象
上記の構成でアクセスを試みたところ、以下の事象が発生しました。
NLB ENIのIPアドレスへの直接アクセス
NLBが各AZで持つENIのプライベートIPアドレス（NLBノードのIP）に対し、直接通信確認を行いました。
ap-northeast-1cのENI IP(18.178.XX.XX):正常に通信可能ap-northeast-1aのENI IP(52.197.YY.YY):タイムアウトが発生
NLB DNS名へのアクセス
NLBのDNS名へのアクセスを試みた際も、DNSラウンドロビンによってap-northeast-1aのENIにルーティングされた通信がターゲットに届かず、タイムアウトが発生していました。これにより、BIツールからインターネット経由でRedshiftにアクセスすることができませんでした。
原因：クロスゾーン負荷分散（CZLB）がOFFだった影響
この問題の根本原因は、NLBの「クロスゾーン負荷分散」設定が「有効（ON）」ではなく「無効（OFF）」になっていたことです。
CZLB OFF時のルーティング仕様
NLBは、CZLBが無効（OFF）の場合、以下のような厳格なAZローカルなルーティングルールで動作します。
CZLB OFF時の動作:
NLBノードがトラフィックを受信した場合、そのトラフィックはそのNLBノードが存在するAZ内にあるターゲットにしかルーティングされません。
（他AZのターゲットはルーティング対象外となります。）
今回の構成では、以下の状態でした。
1.Redshiftターゲット（実体）:ap-northeast-1cのみに存在。
2.ap-northeast-1cのNLBノード:自身のAZ内にターゲットを見つけるため、正常に通信可能。
3.ap-northeast-1aのNLBノード:自身のAZ内にターゲットが存在しないため、トラフィックを破棄し、タイムアウトが発生。
ターゲットが単一AZにしかない構成でCZLBをOFFにすると、必然的にNLBノードも単一AZでしか機能しなくなるのです。
解決策と適切な設計について
1. 解決策：CZLBをONにする
最もシンプルかつ即効性のある解決策は、NLBの属性設定でクロスゾーン負荷分散を「有効（ON）」に変更することです。
- 変更後の動作:
ap-northeast-1aのNLBノードで受信したトラフィックも、AZを跨いでap-northeast-1cに存在するRedshiftターゲットにルーティングされるようになり、すべてのアクセス経路で通信が正常化しました。
2. 設計：コストと可用性を考慮した適切な構成
今回の用途（ターゲットがシングルAZ）の場合、CZLBをONにすることで事象は解決しますが、コストと管理のシンプルさの観点から、以下の設計を考慮することが重要です。
| 設計パターン | CZLB設定 | メリット | デメリット/注意点 |
|---|---|---|---|
| マルチAZ NLB + CZLB ON | ON | NLB自体の可用性が高い。 | AZ間通信のデータ転送料金が発生する。コスト増の要因。 |
| シングルAZ NLB | - | AZ間通信が発生せず、通信コストを抑制できる。構成がシンプル。 | NLB自体の可用性がターゲットAZに依存する（ターゲットと同じレベルになる）。 |
今回のケースのように、バックエンドのターゲット（Redshift）がシングルAZである場合、NLBも同じAZに配置したシングルAZ構成にすることが、余分なAZ間データ転送料金（課金）を抑制する上で最適な設計となります。
まとめ
- 現象:マルチAZ NLBの片方のENI IPへの通信がタイムアウトする。
- 原因:クロスゾーン負荷分散（CZLB）がOFFの状態で、ターゲットが単一AZにしか存在しなかったため。
- 技術的結論:CZLB OFFでは、NLBノードは自身のAZ内のターゲットにしかルーティングしない。
- 解決:
1.応急処置としてCZLBをONにする。
2.ターゲットがシングルAZの場合、コスト効率を考慮しNLBもシングルAZで構築するのが望ましい。
NLBを利用する際は、このCZLBの設定がルーティング動作とコストに大きく影響することを理解し、ターゲットのAZ構成と照らし合わせて設定することが重要です。
