【入門編】 NLBのクロスゾーン負荷分散（Cross-Zone Load Balancing）の有効化とパケット転送 – クラウド＆コンテナネットワーク実践ガイド

NLBの「クロスゾーン負荷分散」って何？郵便配達で学ぶ、コストと速度の最適解

こんにちは！SREとして日々クラウドのネットワークと格闘している筆者です。

AWSで「NLB（Network Load Balancer）」を使おうとしたとき、設定画面の片隅で「クロスゾーン負荷分散（Cross-Zone Load Balancing）」というチェックボックスを目にしたことはありませんか？

「なんだか便利そうだし、とりあえずONにしておこうかな？」と深く考えずにポチッとしてしまうことも多いはず。でも、実はこれ、あなたのAWS利用料やシステムのレスポンス速度に「地味ながらも大きな影響」を与える、非常に重要なスイッチなんです。

今回は、この機能を「郵便配達」に例えて、直感的に紐解いていきましょう！

—

1. そもそも「NLB」と「ゾーン」の関係性とは？

まず前提として、AWSのデータセンターは「アベイラビリティゾーン（AZ）」という単位で区切られています。これは、巨大な「郵便局の支店」のようなものだと考えてください。

NLBは、この郵便局の支店一つひとつに設置される「受付窓口」です。デフォルトの状態では、A支店の窓口はA支店にある荷物しか運ばないし、B支店の窓口はB支店にある荷物しか運びません。

クロスゾーンOFF（デフォルト）: 「自分の支店に来た荷物は、自分の支店内のトラックだけで配送する」
クロスゾーンON: 「自分の支店が混んでいても、別の支店のトラックを呼んで荷物を運んでもらう」

これが、クロスゾーン負荷分散の基本概念です。

—

2. なぜ「クロスゾーンON」で料金がかかるのか？

ここからが本題です。クロスゾーン負荷分散をONにすると、なぜ「クロスターフィック課金」が発生するのでしょうか？

現実世界で考えてみましょう。あなたが東京（AZ-A）の郵便局に荷物を持ち込んだのに、わざわざ別の支店である大阪（AZ-B）のトラックがわざわざ東京まで来て、その荷物を運ぶとしたらどうでしょう？

移動距離: 物理的な距離を移動するため、ガソリン代（ネットワーク転送コスト）がかかりますよね。
手間: 支店間での連携コストが発生します。

AWSの世界でも同じです。「AZ-AのNLB」が「AZ-Bのサーバー」にパケットを転送すると、「AZをまたぐ通信」とみなされ、データ転送量に応じた課金が発生します。逆にOFFにしていれば、常に自分のAZ内で完結するため、この「AZ間転送コスト」はゼロになります。

—

3. 速度（レイテンシ）への影響：ON vs OFF

「じゃあ、お金がかかるならOFFにすればいいの？」というと、そう単純ではありません。

クロスゾーンOFFの場合（職人気質）

自分のエリアのサーバーしか使わないため、もし「AZ-Aのサーバーが急にパンクした！」という状況になると、AZ-AのNLBは行き場を失ったパケットを拒否せざるを得ません。結果として、ユーザーには「つながらない！」というエラーが返るリスクが高まります。

クロスゾーンONの場合（チームプレー）

AZ-Aのサーバーが混雑していても、隣のAZ-Bに空きがあれば、NLBがそちらへパケットをパスしてくれます。「多少コストがかかっても、システムを止めない」という安定性を重視するなら、こちらが有利です。ただし、物理的な距離を跨ぐため、ミリ秒単位で見ればコンマ数秒の遅延が加わる可能性があります。

—

4. 実践：どう設定すればいいの？

AWS CLIを使って、この設定を確認・変更するコマンドをご紹介します。現場では「今の設定がどうなっているか」を確認するのが第一歩です。

現在の設定を確認する

# NLBの属性情報を取得して、クロスゾーン負荷分散が有効か確認します
aws elbv2 describe-load-balancer-attributes --load-balancer-arn <あなたのNLBのARN>

出力結果の中に "Key": "load_balancing.cross_zone.enabled" があり、その値が "Value": "true" ならON、"false" ならOFFです。

設定を切り替える（例：ONにする）

# クロスゾーン負荷分散を有効化するコマンド
aws elbv2 modify-load-balancer-attributes \
    --load-balancer-arn <あなたのNLBのARN> \
    --attributes Key=load_balancing.cross_zone.enabled,Value=true

—

5. 結局、どう使い分けるべき？

現場のSREとしての結論はこうです。

1. 「コスト最優先・サーバーが全AZに均等に配置されている」なら OFF

各AZに同じ数のサーバーを置いていれば、OFFでも負荷は自然と分散されます。無駄なコストを削れます。

2. 「可用性最優先・突発的なアクセス増に備えたい」なら ON

特定のAZが障害でダウンした際、他のAZのサーバーへ即座に逃がすことができるため、運用上の安心感は圧倒的です。

まとめると…

ONにすると: どのAZでも平等に荷物を運べるが、「AZを跨ぐ通行料」がかかる。
OFFにすると: 自分のエリア限定で効率よく運べるが、「特定エリアの混雑に弱い」。

インフラは「完璧な設定」があるわけではなく、コスト・速度・安定性のトレードオフの連続です。「うちのサービスにとって一番大切なのはどれかな？」と考えながらスイッチを切り替えてみてください。

もし不安なら、まずはステージング環境でパケットの流れを監視ツールで見ながら、ON/OFFの挙動を体感してみるのが一番の近道ですよ！

それでは、良いクラウドライフを！