こんにちは！SREとして日夜クラウドの海を泳ぎ回っているインフラエンジニアの私です。
突然ですが、皆さんは「ロードバランサー（負荷分散装置）」と聞いて、どんな姿を思い浮かべるでしょうか？
「たくさんのアクセスを、複数のサーバーに上手に振り分けてくれる頼もしい交通整理のお巡りさん」……そんなイメージを持っている方も多いのではないでしょうか。そのイメージ、大正解です！
クラウドの世界、特にAWSにはいくつかの種類のロードバランサーが用意されていますが、中でも「AWS Network Load Balancer（通称：NLB）」は、いわば「超高速道路のノンストップETCゲート」のような存在です。
今回は、インフラやネットワークの世界に一歩踏み出したばかりのあなたに向けて、このNLBの基本アーキテクチャと、レイヤー4（トランスポート層）で繰り広げられるパケットフォワーディングの秘密を、現実世界の例えを交えながら優しく紐解いていきたいと思います。難しい言葉が出てきても「一歩ずつ理解していきましょう！」大丈夫、一緒に見ていきましょうね。
—
1. 郵便配達で例える「レイヤー4（L4）」とNLBの世界
ネットワークの世界には「OSI参照モデル」という、通信の役割分担を階層にしたルールブックがあります。その中の「レイヤー4（トランスポート層）」で働くのが、今回の主役であるNLBです。
これって、現実世界で例えるとどういうことでしょうか？
そうですね、「巨大な郵便局の仕分けロボット」を想像してみてください。
おなじみの兄弟分である「Application Load Balancer（ALB）」が、手紙の「中身（宛先や手紙の用件、何を買いたいかなど）」をしっかりと封筒を開けて読んでから、「これは経理宛て、こっちはお客さま相談室宛てね」と細かく仕分ける「お利口さんなコンシェルジュ」だとします。
一方、今回解説するNLB（レイヤー4）は、封筒の中身を一切見ません。
表面に書いてある「差出人（送信元IPアドレス/ポート）」と「宛先（送信先IPアドレス/ポート）」の数字の組み合わせだけをチラッと見て、「はい、あなたはこのトラックに乗って！」と、コンマ数秒の超スピードで荷台に放り込んでいく、超効率特化型の仕分けロボットなのです。
中身を見ないからこそ、暗号化されていようが、未知のプロトコルだろうが関係ありません。「とにかく秒速で、大量の荷物を向こう岸（バックエンドのサーバー）へ届ける！」これがNLBの真骨頂です。
—
2. NLBの基本アーキテクチャ：なぜそんなに速いの？
NLBが驚異的な超高スループットと超低レイテンシー（遅延の少なさ）を実現できるのは、その内部構造に秘密があります。
接続をそのままスルーする「パケットフォワーディング」
一般的なプロキシ型のロードバランサー（ALBなど）は、ユーザーからの通信をいったん自分が受け止め（コネクションを終端し）、サーバーと新しく通信を張り直すという「代理人」の仕事をします。
しかし、NLB（特にターゲットグループがIPターゲットやインスタンスの場合）は、ユーザーから届いたTCP/UDPパケットの宛先書き換え（NAT: Network Address Translation）をサラッと行い、ユーザーとバックエンドサーバーの間で直接コネクションが結ばれるようにパススルーしてしまいます。
例えるなら、宅配ボックスに届いた荷物を自分で開けず、「宛先だけ書き換えて、そのまま次の配送トラックに放り込む」ようなものです。これなら荷物の仕分けに余計な時間がかかりませんよね。
安定の極み「固定IPアドレスの標準装備」
ウェブサイトを作るとき、「突然アクセスが増えてもサーバーが耐えられるようにしたい」「でも、ファイアウォール（セキュリティの壁）の都合上、アクセス元のIPアドレスは固定しておきたい」という要件によく直面します。
ALBの場合、変動するIPアドレスのせいでDNS（Route 53など）の力に頼る必要がありましたが、NLBは作成したアベイラビリティゾーン（AZ）ごとに、固定のパブリックIPアドレスを割り当てることができます。
「うちの会社のセキュリティシステムは、決まったIPからの通信しか通さないんだよね」という硬派なシステムでも、NLBなら安心して導入できるというわけです。
—
3. 実践！AWS CLIでNLBを構築してみよう
百聞は一見に如かず。実際にAWS環境でNLBを構築する際のイメージを掴んでみましょう。今回は、インフラのコード化や自動化の第一歩として、AWS CLIを使った作成コマンドの流れを覗いてみます。
# 1. 外部からのトラケットを受け止める「ネットワークロードバランサー（NLB）」本体を作成します
aws elbv2 create-load-balancer \
--name my-super-fast-nlb \
--type network \
--subnets subnet-0123456789abcdef0 subnet-fedcba9876543210 \
--tags Key=Environment,Value=Production
# （解説）--type network と指定することで、お利口なALBではなく、
# 超高速なL4特化のNLBを作ります。また、パケットを受け取るサブネットを指定します。
# 2. 届いたパケットをどのサーバー（ターゲット）に投げ込むかを決める「ターゲットグループ」を作成します
aws elbv2 create-target-group \
--name my-backend-targets \
--protocol TCP \
--port 80 \
--vpc-id vpc-0123456789abcdef0 \
--target-type instance
# （解説）ここでプロトコルに `TCP`、ポートに `80` を指定し、
# レイヤー4の世界でパケットをさばく準備を整えます。
# 3. 最後に「リスナー」を作成し、NLBに届いたポート80番への通信を、先ほどのターゲットグループへ流し込みます
aws elbv2 create-listener \
--load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/net/my-super-fast-nlb/abcdef0123456789 \
--protocol TCP \
--port 80 \
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-backend-targets/fedcba9876543210
# （解説）これで、NLBの「80番ポート」に届いたTCPパケットは、
# 一切の中身の詮索を受けることなく、背後のサーバー群へと秒速で転送されるようになります！どうでしょう？難解な呪文に見えたコマンドも、「どこでパケットを受け取り、どこへ流すか」という道筋を作っているだけだと分かれば、ぐっと親しみやすくなったのではないでしょうか。
—
4. いつNLBを選ぶべき？（使い分けの判断基準）
「じゃあ、これからは全部NLBにすれば速くていいじゃん！」と思ってしまいがちですが、適材適所という言葉があります。最後に、ALBとNLBの使い分けのコツを確認しておきましょう。
- NLBを選ぶべきケース
- 秒間数百万リクエストをさばくような、圧倒的なスループットと超低レイテンシーが求められるシステム
- オンプレミス側のセキュリティ要件で「アクセス元のIPアドレスを絶対に固定したい」場合
- Web（HTTP/HTTPS）以外のプロトコル（ゲームのUDP通信、MQTT、独自のTCPストリームなど）をそのまま通したい場合
- ALBを選ぶべきケース
- 「URLのパス（例:
/imagesや/api）ごとに、行き先のサーバーを変えたい」というルーティングが必要な場合 - Cookieを使ったセッション維持（スティッキーセッション）や、HTTPSの終端・証明書管理をロードバランサー側で手軽にやりたい場合
—
まとめ
今回は、AWS Network Load Balancer（NLB）の基本アーキテクチャと、レイヤー4ルーティングの裏側を解説しました。
- NLBは、パケットの中身を見ずに、宛先と送信元だけで秒速で荷物をさばく「郵便配達の仕分けロボット」のようなもの。
- 接続をスルーするパケットフォワーディングにより、超高スループットと超低レイテンシーを実現。
- AZごとに固定IPアドレスが持てるため、堅牢なネットワーク設計に欠かせない存在。
インフラやネットワークの世界は、最初は専門用語が多くて圧倒されてしまうかもしれません。ですが、身の回りの仕組みに例えて一歩ずつ紐解いていけば、必ず「なるほど！」と腑に落ちる瞬間がやってきます。
皆さんのクラウドアーキテクチャの旅が、安全でワクワクするものでありますように。それではまた、次の技術の海でお会いしましょう！
コメント