OCI Network Load Balancer

解決する課題

L7 の機能（パスルーティングや TLS 終端）が不要で、とにかく低遅延・高スループットに TCP/UDP を捌きたいケースに応えます。

• HTTP の中身を見ずにL4 のまま高速に振り分けたい
• バックエンド側でクライアントの送信元 IP をそのまま受け取りたい
• UDP や ICMP を含むプロトコルを分散したい
• ロードバランサ自体の追加コストをかけずに冗長化したい

主要概念と用語

• Network Load Balancer（NLB / L4）: TCP・UDP・TCP/UDP 同時・ICMP を扱う L4 ロードバランサ。HTTP のような L7 処理は行わず、フロー（コネクション）単位で転送する
• リスナー（Listener）: 受信するプロトコルとポートの待ち受け定義。バックエンドセットに紐付く
• バックエンドセット（Backend Set）: バックエンド群＋ヘルスチェックポリシー＋負荷分散ポリシーをまとめた論理単位（AWS のターゲットグループ相当）
• バックエンド: 振り分け先となる実体。コンピュートインスタンスの IP アドレス＋ポート、またはインスタンス OCID で登録する
• 送信元 IP の保持（preserve source IP）: 既定で有効。バックエンドにクライアントの実 IP が届くため、アクセス制御やロギングで実 IP を扱える
• 負荷分散ポリシー: 5-Tuple / 3-Tuple / 2-Tuple のハッシュベース。送信元・宛先の IP/ポート/プロトコルの組み合わせでフローを一貫した同一バックエンドへ割り当てる
• パブリック / プライベート: インターネット向け（パブリック IP 付与）か、VCN 内部専用（プライベート IP のみ）かを作成時に選ぶ
• NSG / セキュリティリスト: NLB やバックエンドへの受信通信を制御する仮想ファイアウォール

仕様・制限・クォータ

• 扱えるのは L4（TCP / UDP / TCP かつ UDP / ICMP）。HTTP のパス・ホストルーティングや Cookie ベースのセッション永続性などの L7 機能は持たない
• 送信元 IP の保持が既定で有効。無効化するとバックエンドには NLB の IP が送信元として見える
• 負荷分散ポリシーはフローのハッシュ（5-Tuple / 3-Tuple / 2-Tuple）から選択し、同一フローは同一バックエンドへ一貫して送られる
• ヘルスチェックは TCP / UDP / HTTP / HTTPS プロトコルで実施可能
• リージョン内で冗長化され、可用性ドメイン／フォルトドメインをまたいで配置される
• リージョン／テナンシ単位の**サービス制限（リミット）**があり、コンソールやサポートから引き上げ申請が可能

内部の仕組み

Network Load Balancer は受信したパケットをフロー単位で L4 のまま転送します。リスナーのプロトコル／ポートに一致した通信を、バックエンドセットのハッシュポリシーで正常なバックエンドへ割り当て、同一フローのパケットは常に同じバックエンドへ届きます。HTTP の中身を解釈しないため、L7 ロードバランサより処理オーバーヘッドが小さく低遅延です。

送信元 IP を保持する構成では、バックエンドはクライアントの実 IP をそのまま受け取れます。実体はリージョン内で冗長構成となっており、可用性ドメインやフォルトドメインにまたがって配置されることで単一障害点を避けます。ヘルスチェックで異常を検知したバックエンドは自動的に振り分け対象から外され、復旧すると再び組み込まれます。

設計パターン / ベストプラクティス

• NLB + インスタンスプール + 複数 AD/FD で、低遅延を保ちつつバックエンドを自動スケール
• 送信元 IP を使ったアクセス制御やロギングが必要なら送信元 IP の保持を有効にし、戻り経路を設計する
• ヘルスチェックのプロトコル／ポート／閾値／間隔を実トラフィックに合わせて設定し、誤検知と切り離し遅延を避ける
• TLS が必要でも L4 のまま通したい場合はバックエンド側で TLS 終端する（NLB は復号しない）
• HTTP のルーティングや WAF 連携が必要になったら、無理に NLB で対応せず L7 の Load Balancer を選ぶ

運用・監視

• OCI Monitoring で NLB のメトリクス（処理バイト数・接続数・正常／異常バックエンド数など）を監視
• **バックエンドの健全性（Health Status）**をコンソールや API で確認し、OK / WARNING / CRITICAL / UNKNOWN を切り分け
• OCI Logging へログを出力して通信状況を分析。ヘルスチェック失敗時はバックエンドの応答・経路・ファイアウォール設定を確認
• メトリクスに対するアラームを設定し、異常バックエンド数が増えたら通知する

コスト

Network Load Balancer はロードバランサ自体が無料で、課金はバックエンドの計算・ストレージ・データ転送など付随リソースに限られます。帯域シェイプを時間課金する L7 の Load Balancer と比べ、コスト面のシンプルさが大きな利点です。

セキュリティ

• NSG / セキュリティリストで NLB の受信と許可ポートを最小化（AWS のセキュリティグループ相当）
• 送信元 IP を保持する構成では、バックエンド側のファイアウォールでクライアント実 IP を使ったアクセス制御を適用できる
• TLS が必要な場合は L4 のまま通してバックエンドで終端する。NLB は復号しないため、鍵をバックエンドで管理する
• バックエンドはプライベートサブネットに置き、NLB 経由でのみ到達可能にする

関連サービス・比較

最も比較されるのは同じ OCI の L7 ロードバランサである Load Balancer です。用途で明確に使い分けます。

ハンズオン / CLI例

# Network Load Balancer を作成（パブリック、超低遅延の L4）
oci nlb network-load-balancer create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name tcp-nlb \
  --subnet-id ocid1.subnet.oc1..aaaa \
  --is-private false

# バックエンドセットを作成し、送信元IP保持を有効化（5-Tuple ハッシュ）
oci nlb backend-set create \
  --network-load-balancer-id ocid1.networkloadbalancer.oc1..xxxx \
  --name tcp-bset \
  --policy FIVE_TUPLE \
  --is-preserve-source true \
  --health-checker '{"protocol": "TCP", "port": 80}'

# バックエンド（実サーバー）をバックエンドセットに登録
oci nlb backend create \
  --network-load-balancer-id ocid1.networkloadbalancer.oc1..xxxx \
  --backend-set-name tcp-bset \
  --target-id ocid1.instance.oc1..yyyy \
  --port 80

# TCP リスナー（待ち受け）を作成してバックエンドセットへ紐付け
oci nlb listener create \
  --network-load-balancer-id ocid1.networkloadbalancer.oc1..xxxx \
  --name tcp-listener \
  --default-backend-set-name tcp-bset \
  --port 80 --protocol TCP