TL

Cloud Service

OCI Load Balancer

受信トラフィックを複数のバックエンドへ分散するマネージド型ロードバランサ。L7 の Load Balancer と L4 特化の Network Load Balancer を用途で使い分ける。AWS の ELB に相当。

中級信頼性パフォーマンス効率セキュリティ
最終更新: 2026-06-03公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.受信通信を複数バックエンドへ振り分ける交通整理役。
  • 2.ヘルスチェックで障害機を外し複数ADに分散し冗長化。
  • 3.Web 用途は L7、超低遅延や IP 保持は L4 を選ぶ。

解決する課題

物理的な負荷分散装置を調達せず、マネージドサービスとして冗長化されたロードバランサをすぐに用意できます。

  • 1台に集中させず負荷を分散したい
  • 障害が起きたバックエンドをヘルスチェックで自動的に切り離したい
  • 複数の可用性ドメイン（AD）/ フォルトドメイン（FD）にまたがって可用性を確保したい
  • TLS 終端や WAF 連携でセキュリティを前段に寄せたい

主要概念と用語

OCI には用途の異なる2系統のロードバランサがあります。

  • Load Balancer（LBaaS / L7）: HTTP/HTTPS/TCP を扱うフレキシブルなロードバランサ。パス・ホストベースのルーティング、TLS 終端、Cookie ベースのセッション永続性などレイヤ7機能を持つ。帯域は最小・最大シェイプ（10Mbps〜8Gbps など）を指定するFlexible シェイプが標準
  • Network Load Balancer（NLB / L4）: TCP/UDP/ICMP を超低遅延で転送する L4 ロードバランサ。**送信元 IP を保持（preserve source IP）**でき、フロー・ハッシュで分散。高スループット用途向け
  • バックエンドセット（Backend Set）: バックエンドサーバー群＋ヘルスチェックポリシー＋負荷分散ポリシーをまとめた論理単位（AWS のターゲットグループ相当）
  • バックエンド / ヘルスチェック / リスナー: 振り分け先サーバー、死活監視、受信ポート＋プロトコルの待ち受け定義
  • 負荷分散ポリシー: ROUND_ROBIN / LEAST_CONNECTIONS / IP_HASH から選択
  • パブリック / プライベート: インターネット向け（パブリック IP 付与）か、VCN 内部専用（プライベート IP のみ）かを作成時に選ぶ
  • ルールセット / パスルートセット: HTTP ヘッダ書き換え、リダイレクト、パスベースの振り分けなどを定義（L7 のみ）

仕様・制限・クォータ

  • 複数の可用性ドメインにまたがって配置され、内部的にプライマリ/スタンバイで冗長化（リージョンに AD が1つの場合はフォルトドメインで分散）
  • Load Balancer（L7）は Flexible シェイプで最小〜最大帯域を設定し、トラフィックに応じて自動的にスケール（旧来の 100Mbps/400Mbps/8000Mbps の固定シェイプから移行）
  • TLS 終端に対応。証明書は LB に直接インポートするほか、OCI Certificates サービスmanaged の証明書を関連付け可能
  • Network Load Balancer（L4）は送信元 IP の保持と超低遅延・高スループットが特徴で、UDP もサポート
  • リージョン/テナンシ単位の**サービス制限（リミット）**があり、コンソールやサポートから引き上げ申請が可能

内部の仕組み

OCI Load Balancer はヘルスチェックで正常なバックエンドだけにトラフィックを振り分けます。L7 の Load Balancer はリクエストの中身（パス/ホスト/ヘッダ）を見てレイヤ7でルーティングし、必要に応じて TLS を終端。Network Load Balancer はコネクション（フロー）を L4 でそのまま高速転送し、送信元 IP を保持できます。

実体は冗長構成で、Load Balancer は2つの可用性ドメイン（または2つのフォルトドメイン）にプライマリ/スタンバイのペアで配置され、障害時にフローティング IP が自動的にフェイルオーバーします。バックエンドの台数をインスタンスプールで増減しても、バックエンドセットへの登録を通じて振り分け対象に反映されます。

Load Balancer（L7）と Network Load Balancer（L4）の選択

L7 のパス/ホストルーティングや TLS 終端、Web 用途＝Load Balancer、超低遅延・送信元 IP 保持・TCP/UDP の高速転送＝Network Load Balancer。この使い分けは設計の基本です。

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

  • Load Balancer + インスタンスプール + 複数 AD/FD が王道。負荷に応じてプールを自動スケール
  • TLS は Load Balancer で終端し、バックエンドへは HTTP（または再暗号化して HTTPS）で転送
  • WAF（OCI Web Application Firewall）を Load Balancer の前段に付けて L7 防御
  • ヘルスチェックのプロトコル/パス/閾値/間隔を適切に設定し、誤検知と切り離し遅延を避ける
  • セッション永続性が必要なら Cookie ベースのスティッキーを使い、可能ならアプリ側をステートレス化して外部ストア（Cache with Redis / Object Storage）へ状態を逃がす

運用・監視

  • OCI Monitoring で oci_lbaas 名前空間のメトリクスを監視。代表例は HttpRequests、ActiveConnections、BackendTimeouts、UnhealthyBackendServers、HttpResponses5xx など
  • **ヘルスチェックの状態（Backend Health / Health Status）**をコンソールや API で確認し、OK / WARNING / CRITICAL / UNKNOWN を切り分け
  • アクセスログ / エラーログを OCI Logging へ出力して分析。タイムアウトや 5xx の急増はバックエンド側の遅延やヘルスチェック設定を確認
  • メトリクスに対するアラームを設定し、UnhealthyBackendServers > 0 などで通知

コスト

L7 の Load Balancer は Flexible シェイプの帯域（最小帯域ぶんは常時課金、超過分は使用量）で課金され、Network Load Balancer は無料（バックエンドの計算/ストレージ/データ転送のみ課金）という違いがあります。

種別課金の考え方向いている用途
Load Balancer（L7, Flexible）最小帯域ぶんを時間課金＋最大帯域までの使用量HTTP/HTTPS、パス/ホストルーティング、TLS終端
Load Balancer（旧 固定シェイプ）100/400/8000 Mbps のシェイプ単位の時間課金帯域を固定したい既存構成（新規はFlexible推奨）
Network Load Balancer（L4）ロードバランサ自体は無料（付随リソースのみ課金）TCP/UDP の超低遅延・高スループット、送信元IP保持

セキュリティ

  • ネットワークセキュリティグループ（NSG）/ セキュリティリストで Load Balancer の受信を制御し、許可ポートを最小化（AWS のセキュリティグループ相当）
  • TLS 終端＋最新の TLS バージョン/暗号スイートを設定。証明書は OCI Certificates で一元管理し、ローテーションを自動化
  • **WAF（Web Application Firewall）**を前段に付けて SQLi/XSS などの L7 攻撃を防御。マネージド/カスタムルールやレート制限を適用
  • バックエンドはプライベートサブネットに置き、Load Balancer 経由でのみ到達可能にする
アンチパターン

TLS 証明書や秘密鍵をバックエンドの各インスタンスに配って終端させるのは NG。Load Balancer で TLS を終端し、証明書は OCI Certificates で集中管理すれば、鍵の散在・更新漏れ・期限切れによる障害を防げます。

関連サービス・比較（AWS との対応）

OCI の2系統は、AWS の ELB ファミリ（ALB / NLB）にほぼ対応します。

観点OCI Load BalancerAWS Elastic Load Balancing (ELB)
L7 ロードバランサLoad Balancer（LBaaS）Application Load Balancer（ALB）
L4 ロードバランサNetwork Load Balancer（NLB）Network Load Balancer（NLB）
振り分け先のまとまりバックエンドセットターゲットグループ
自動スケール（バックエンド）インスタンスプールAuto Scaling グループ
仮想ファイアウォールNSG / セキュリティリストセキュリティグループ
証明書管理OCI CertificatesAWS Certificate Manager（ACM）
L7 防御OCI WAFAWS WAF
L7 帯域モデルFlexible シェイプ（最小〜最大Mbps）LCU（使用量ベース）

ハンズオン / CLI例

# L7 Load Balancer を作成（Flexible シェイプ、2つのサブネットを指定して複数ADに冗長化）
oci lb load-balancer create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name web-lb \
  --shape-name flexible \
  --shape-details '{"minimumBandwidthInMbps": 10, "maximumBandwidthInMbps": 100}' \
  --subnet-ids '["ocid1.subnet.oc1..aaaa","ocid1.subnet.oc1..bbbb"]' \
  --is-private false

# バックエンドセットを作成し、HTTP のヘルスチェックを設定
oci lb backend-set create \
  --load-balancer-id ocid1.loadbalancer.oc1..xxxx \
  --name web-bset \
  --policy ROUND_ROBIN \
  --health-checker-protocol HTTP \
  --health-checker-url-path /healthz \
  --health-checker-port 80

# バックエンド（実サーバー）をバックエンドセットに登録
oci lb backend create \
  --load-balancer-id ocid1.loadbalancer.oc1..xxxx \
  --backend-set-name web-bset \
  --ip-address 10.0.1.10 --port 80

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

# L4 の Network Load Balancer を作成（超低遅延・送信元IP保持）
oci nlb network-load-balancer create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --display-name tcp-nlb \
  --subnet-id ocid1.subnet.oc1..aaaa \
  --is-preserve-source-destination true

OCI Service

OCI Load Balancerを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

ネットワーキング

比較で見る軸

クラウド: OCI / カテゴリ: ネットワーキング / 難易度: intermediate

導入後に効く点

ヘルスチェックで障害機を外し複数ADに分散し冗長化。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
OCI
カテゴリ
ネットワーキング
難易度
intermediate
関連資格
—
設計柱
reliability / performance / security

判断チェックリスト

  • 自社の用途が「ネットワーキング / reliability」に近いか確認する。
  • 強みである「受信通信を複数バックエンドへ振り分ける交通整理役。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

ネットワーキングreliabilityperformancesecurity
参考: 公式ドキュメント

他クラウドの同等サービス

役割が近いサービスです。設計の置き換えや比較検討の参考に。

AWS
Elastic Load Balancing (ELB)
解説を読む →
Azure
Azure Load Balancer / App Gateway
解説を読む →
Google Cloud
Cloud Load Balancing
解説を読む →