Oracle Cloud Infrastructureドキュメント

Load Balancingの概要

Oracle Cloud Infrastructure Load Balancingサービスは、1つのエントリ・ポイントから仮想クラウド・ネットワーク(VCN)から到達可能な複数のサーバーへの自動トラフィック配信を提供します。 このサービスは、パブリックまたはプライベートのIPアドレスとプロビジョニングされた帯域幅の中から選択したロード・バランサを提供します。

ロード・バランサは、リソースの使用率を向上させ、スケーリングを容易にし、高い可用性を確保します。 ロード・バランサが正常なインスタンスのみにトラフィックを指示するように、複数のロード・バランシング・ポリシーおよびアプリケーション固有のヘルス・チェックを構成できます。 ロード・バランサは、メンテナンスのためにサービスから削除する前に、正常でないアプリケーション・サーバーからトラフィックを流出させることによって、メンテナンス・ウィンドウを減らすことができます。

Load Balancingのしくみ

Load Balancingサービスを使用すると、VCN内にパブリックまたはプライベートのロード・バランサを作成できます。 パブリック・ロード・バランサには、インターネットからアクセスできるパブリックIPアドレスがあります。 プライベート・ロード・バランサには、ホスティング・サブネットからのIPアドレスがあります。これはVCN内でのみ表示されます。 IPアドレスに複数のリスナーを構成して、トランスポート・レイヤー4およびレイヤー7 (TCPおよびHTTP)トラフィックをロード・バランシングできます。 パブリックおよびプライベートの両方のロード・バランサは、VCNから到達可能なバックエンド・サーバーにデータ・トラフィックをルーティングできます。

パブリック・ロード・バランサ

インターネットからのトラフィックを受け入れるには、パブリック・ロード・バランサを作成します。 このサービスは、着信トラフィックのエントリ・ポイントとなるパブリックIPアドレスを割り当てます。 DNSベンダーを通じて、パブリックIPアドレスとフレンドリなDNS名を関連付けることができます。

パブリック・ロード・バランサは、範囲内のリージョンです。 リージョンに複数の「可用性ドメイン」 sが含まれている場合、パブリック・ロード・バランサはリージョン・サブネット(推奨)または「可用性ドメイン」固有(AD固有)の2つのサブネット(それぞれが個別の「可用性ドメイン」内)を必要とします。 リージョンのサブネットの場合、Load Balancingサービスでは、「可用性ドメイン」の停止中でもアクセシビリティを確実に保証するために、プライマリ・ロード・バランサとスタンバイ・ロード・バランサがそれぞれ異なる「可用性ドメイン」に作成されます。 2つのAD固有のサブネットにロード・バランサを作成する場合、1つのサブネットがプライマリ・ロード・バランサをホストし、もう1つがスタンバイ・ロード・バランサをホストします。 プライマリ・ロード・バランサに失敗すると、パブリックIPアドレスはセカンダリ・ロード・バランサに切り替わります。 このサービスでは、2つのロード・バランサが同等のものとして扱われ、どれがプライマリであるかを指定することはできません。

リージョンのまたはAD固有のサブネットのどちらを使用する場合も、各ロード・バランサには、そのホスト・サブネットから1つのプライベートIPアドレスが必要です。 Load Balancingサービスは、プライマリ・ロード・バランサに浮動パブリックIPアドレスを提供します。 フローティング・パブリックIPアドレスはバックエンド・サブネットからのものではありません。

リージョンに1つの「可用性ドメイン」のみが含まれている場合、サービスにはプライマリとスタンバイの両方のロード・バランサをホストするために、リージョンまたはAD固有のサブネットが1つのみ必要です。 プライマリおよびスタンバイ・ロード・バランサには、割り当てられたフローティングIPアドレスに加えて、ホスト・サブネットのプライベートIPアドレスが必要です。 「可用性ドメイン」の停止がある場合、ロード・バランサにはフェイルオーバーはありません。

警告

パブリック・ロード・バランサに「プライベート・サブネット」を指定することはできません。

プライベート・ロード・バランサ

ロード・バランサをインターネットから隔離し、セキュリティの姿勢を単純化するために、プライベート・ロード・バランサを作成できます。 Load Balancingサービスは、着信トラフィックのエントリ・ポイントとして機能するプライベートIPアドレスを割り当てます。

プライベート・ロード・バランサを作成する場合、プライマリ・ロード・バランサとスタンバイ・ロード・バランサの両方をホストするサブネットは1つだけです。 ロード・バランサは、ホスト・サブネットの範囲に応じて、リージョンまたはAD固有になります。 ロード・バランサは、ホスト・サブネットを含むVCN内からのみ、またはセキュリティ・リスト・ルールによりさらに制限されるVCN内からのみアクセスできます。

割り当てられた浮動プライベートIPアドレスは、ホスト・サブネットに対してローカルです。 プライマリとスタンバイのロード・バランサは、それぞれ、ホスト・サブネットから追加のプライベートIPアドレスを必要とします。

「可用性ドメイン」の停止がある場合、マルチADリージョン内のリージョンナル・サブネットで作成されたプライベート・ロード・バランサがフェイルオーバー機能を提供します。 AD固有のサブネットまたは単一の可用性ドメイン・リージョン内のリージョンのサブネットに作成されたプライベート・ロード・バランサに、「可用性ドメイン」の停止に対応するフェイルオーバー機能はありません。

すべてのロード・バランサ

ロード・バランサには、受信トラフィックをComputeインスタンスにルーティングするバックエンドが設定されています。 バックエンド・セットは、以下を含む論理エンティティです:

  • バックエンド・サーバーのリスト。
  • Load Balancingポリシー。
  • ヘルス・チェック・ポリシー。
  • オプションのSSL処理。
  • オプションのセッション永続性構成。

バックエンド・セットに関連付けられたバックエンド・サーバー(Computeインスタンス)は、関連付けられたセキュリティ・リストとルート表が目的のトラフィック・フローを許可する限り、どこにでも存在できます。

VCN内のすべてのサブネットには、セキュリティ・リストおよびルート表が含まれます。 セキュリティ・リスト内のルールによって、サブネットがインターネットまたは別のサブネットからのデータ・トラフィックを受け入れることができるかどうかが決まります。 「バックエンド・サーバーをバックエンド・セットに追加」時には、Load Balancingサービスは適切なセキュリティ・リスト・ルールを提示することも、Networkingサービスを介してユーザー自身を構成することもできます。 詳細については、「セキュリティ・リスト」を参照してください。

Oracleは、ロード・バランサをリージョンのサブネットに作成することをお薦めします。

リージョン内のすべての「可用性ドメイン」にバックエンド・サーバーを配布することをお薦めします。

機能するロード・バランサを備えた最小限のシステムを作成するには、次の作業を行う必要があります:

  • パブリック・ロード・バランサの場合、インターネット・ゲートウェイおよびパブリック・リージョン・サブネットを使用してVCNを作成します。

    警告

    パブリック・ロード・バランサに「プライベート・サブネット」を指定することはできません。

  • プライベート・ロード・バランサの場合、少なくとも1つのプライベート・サブネットを持つVCNを作成します。
  • 別々の「可用性ドメイン」にそれぞれ少なくとも2つのComputeインスタンスを作成します。
  • ロード・バランサを作成します。
  • ヘルス・チェック・ポリシーを使用してバックエンド・セットを作成します。
  • バックエンド・サーバー(Computeインスタンス)をバックエンド・セットに追加します。
  • オプションのSSL処理を使用して、リスナーを作成します。
  • 目的のトラフィックを許可するように、ロード・バランサのサブネット・セキュリティ・リストを更新します。
ノート

プライベートIPアドレスの消費

1つのパブリック・サブネットに作成されたパブリック・ロード・バランサが、ホスト・サブネットから2つのプライベートIPアドレスを使用します。

2つのパブリック・サブネットに作成されたパブリック・ロード・バランサは、2つのプライベートIPアドレスを使用します(各ホスト・サブネットから1つ)。

1つのサブネットで作成されたプライベート・ロード・バランサは、ホスト・サブネットから3つのプライベートIPアドレスを消費します。

単純なLoad Balancing設定を作成するためのステップ・バイ・ステップの手順については、「Load Balancingの開始」を参照してください。

次の図は、単純なパブリックLoad Balancingシステム構成の概要を示しています。 るかに洗練された複雑な構成が一般的です。

単純なLoad Balancing構成の図

Load Balancingの概念

Load Balancingを使用するには、次の概念が不可欠です。

バックエンド・サーバー
受信TCPまたはHTTPトラフィックに応答してコンテンツを生成するアプリケーション・サーバー。 通常は、オーバーレイ(プライベート)IPv4アドレスとポートの固有の組み合わせ(たとえば、10.10.10.1:8080および10.10.10.2:8080)を使用してアプリケーション・サーバーを識別します。
詳細は、「バックエンド・サーバーの管理」を参照してください。
バックエンド・セット
バックエンド・サーバー、Load Balancingポリシー、ヘルス・チェック・ポリシーのリストで定義される論理エンティティ。 SSL構成はオプションです。 バックエンド・セットは、ロード・バランサがトラフィックをバックエンド・サーバーのコレクションに送信する方法を決定します。
詳細は、「バックエンド・セットの管理」を参照してください。
証明書
リスナーにHTTPSまたはSSLを使用する場合は、SSLサーバー証明書(X.509)をロード・バランサに関連付ける必要があります。 証明書を使用すると、ロード・バランサは接続を終了し、受信リクエストをバックエンド・サーバーに渡す前にそのリクエストを復号化できます。
詳細は、「SSL証明書の管理」を参照してください。
健全性チェック

バックエンド・サーバーの可用性を確認するテスト。 ヘルス・チェックは、リクエストまたは接続の試行です。 ロード・バランサは、指定した時間間隔に基づいて、継続的にバックエンド・サーバーをモニターするヘルス・チェック・ポリシーを適用します。 サーバーがヘルス・チェックに失敗すると、ロード・バランサはサーバーを一時的にローテーションから外します。 サーバーがその後ヘルス・チェックに合格すると、ロード・バランサはそれをローテーションに返します。

「バックエンド・セットを作成」でヘルス・チェック・ポリシーを構成します。 バックエンド・サーバーのTCPレベルまたはHTTPレベルのヘルス・チェックを構成できます。

  • TCPレベルのヘルス・チェックは、バックエンド・サーバーとのTCP接続を確立し、接続状況に基づいてレスポンスを検証しようとします。
  • HTTPレベルのヘルス・チェックは、特定のURIでバックエンド・サーバーにリクエストを送信し、返されたステータス・コードまたはエンティティ・データ(本文)に基づいてレスポンスを検証します。

このサービスは、アプリケーション固有のヘルス・チェック機能を提供し、可用性を向上させ、アプリケーションのメンテナンス期間を短縮します。

ヘルス・チェック構成の詳細については、「ヘルス・チェック・ポリシーの編集」を参照してください。
ヘルス・ステータス
ロード・バランサとそのコンポーネントの一般的なヘルスを報告するインジケータ。
詳細については、「ヘルス・チェック・ポリシーの編集」「ヘルス・ステータス」セクションを参照してください。
リスナー
ロード・バランサIPアドレスで着信トラフィックをチェックする論理エンティティ。 リスナーのプロトコルとポート番号、およびオプションのSSL設定を構成します。 TCP、HTTP、およびHTTPSトラフィックを処理するには、複数のリスナーを構成する必要があります。
サポートされるプロトコルは次のとおりです:
  • TCP
  • HTTP/1.0
  • HTTP/1.1
詳細は、「ロード・バランサ・リスナーの管理」を参照してください。
Load Balancingポリシー
Load Balancingポリシーは、ロード・バランサに着信トラフィックをバックエンド・サーバーに配布する方法を指示します。 一般的なロード・バランサ・ポリシーは次のとおりです:
  • ラウンド・ロビン
  • 最低限の接続
  • IPハッシュ
詳細は、「Load Balancingポリシーの仕組み」を参照してください。
パス・ルート・セット
複数のリスナーまたはロード・バランサを使用せずに正しいバックエンド・セットにトラフィックをルーティングする一連のパス・ルート・ルール。
詳細は、「リクエスト・ルーティングの管理」を参照してください。
リージョンと可用性ドメイン
Load Balancingサービスは、リージョン内の「可用性ドメイン」間のアプリケーション・トラフィックを管理します。 リージョンはローカルの地理的なエリアであり、「可用性ドメイン」はリージョン内にある1つ以上のデータセンターです。 リージョンはいくつかの「可用性ドメイン」で構成されています。
詳細は、「リージョンと可用性ドメイン」を参照してください。
セッション永続性
単一の論理クライアントから発生したすべてのリクエストを1つのバックエンドWebサーバーに送信するメソッド。
詳細は、「セッションの永続性」を参照してください。
シェイプ
イングレスとエグレス・トラフィックのロード・バランサのプレプロビジョニングした最大容量(帯域幅)の合計を決定するテンプレート。 使用可能なシェイプには、100 Mbps、400 Mbps、および8000 Mbpsが含まれます。
ヒント

事前にプロビジョニングされた最大容量は、集約された接続に適用され、単一のクライアントが全帯域幅を使用しようとする場合には適用されません。
ssl
Secure Sockets Layer (SSL)は、クライアントとサーバーの間に暗号化されたリンクを確立するためのセキュリティ技術です。 ロード・バランサに次のSSL構成を適用できます:
SSLターミネーション
ロード・バランサは、着信SSLトラフィックを処理し、暗号化されていないリクエストをバックエンド・サーバーに渡します。
エンド・ツー・エンドのSSL
ロード・バランサは、着信トラフィック・クライアントとのSSL接続を終了し、バックエンド・サーバーへのSSL接続を開始します。
SSLトンネリング
TCPトラフィックのロード・バランサ・リスナーを構成すると、ロード・バランサはアプリケーション・サーバーへの着信SSL接続をトンネリングします。
Load Balancingは、strong暗号強度のデフォルト設定でTLS 1.2プロトコルをサポートしています。 デフォルトでサポートされている暗号は次のとおりです:
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • DHE-RSA-AES256-SHA256
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES128-SHA256
詳細は、「SSL証明書の管理」を参照してください。
サブネット
10.0.0.0/24および10.0.1.0/24など、VCNで定義する細分化。 サブネットは、1つのリージョンにまたがることも、1つの「可用性ドメイン」内に存在することもできます。 サブネットは、VCN内の他のサブネットと重複しない連続したIPアドレスの範囲で構成されます。 各サブネットに対して、それに適用されるルーティング・ルールとセキュリティ・リストを指定します。
サブネットの詳細については、「VCNとサブネット」「パブリックとプライベートのサブネット」を参照してください。
タグ

リソースにタグを適用して、ビジネス・ニーズに合わせてタグを整理するのに役立てることができます。 リソースを作成するときにタグを適用することも、後でそのタグを使用してリソースを更新することもできます。 タグの適用に関する一般的な情報は、「リソース・タグ」を参照してください。

仮想ホスト名
リクエスト・ルーティングを強化するためにリスナーに適用される仮想サーバー名。
詳細は、「リクエスト・ルーティングの管理」を参照してください。
仮想クラウド・ネットワーク(vcn)
ファイアウォール・ルールと、使用することを選択できる特定のタイプの通信ゲートウェイがある、Oracleデータセンターで設定したプライベート・ネットワーク。 VCNは、「許可されたIPアドレス範囲」での選択した1つの連続したIPv4 CIDRブロックをカバーします。
ロード・バランサを起動する前に、少なくとも1つの仮想クラウド・ネットワークが必要です。
仮想クラウド・ネットワークの設定については、「Networkingの概要」を参照してください。
可視性
ロード・バランサをパブリックまたはプライベートのどちらにするかを指定します。 パブリック・ロード・バランサには、クライアントがインターネットからアクセスできるパブリックIPアドレスがあります。 プライベート・ロード・バランサには、VCNローカル・サブネットのプライベートIPアドレスがあり、クライアントはVCN内からのみアクセスできます。
詳細は、「ロード・バランサの管理」を参照してください。
作業リクエスト
Load Balancingリクエストの現在の状態を報告するオブジェクト。
Load Balancingサービスはリクエストを非同期に処理します。 各リクエストは、レスポンスとして作業リクエストID (OCID)を返します。 作業リクエスト・アイテムを表示して、リクエストのステータスを表示できます。
詳細は、「作業リクエストの状態の表示」を参照してください。

リソース識別子

ほとんどのタイプのOracle Cloud Infrastructureリソースには、Oracle Cloud ID (OCID)という名前の一意のOracle割当て識別子があります。 OCID形式およびリソースを識別するその他の方法については、「リソース識別子」を参照してください。

Oracle Cloud Infrastructureにアクセスする方法

コンソール (ブラウザベースのインタフェース)またはREST APIを使用して、Oracle Cloud Infrastructureにアクセスできます。 コンソールおよびAPIの手順は、このガイドのトピックに含まれています。 使用可能なSDKのリストについては、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。

コンソールにアクセスするには、「サポートされているブラウザ」を使用する必要があります。 このページの上部にあるコンソールリンクを使用して、サインイン・ページにアクセスできます。 クラウド・テナント、ユーザー名、およびパスワードを入力するよう求められます。

APIの使用に関する一般的な情報は、REST APIを参照してください。

リソースのモニター

Oracle Cloud Infrastructureリソースのヘルス、容量、およびパフォーマンスをモニターするには、メトリック、アラーム、および通知を使用します。 詳細は、「Monitoring概要」および「Notifications概要」を参照してください。

ロード・バランサを介したトラフィックのモニターの詳細は、「Load Balancingメトリック」を参照してください。

認証と認可

Oracle Cloud Infrastructureの各サービスは、すべてのインタフェース(コンソール、SDKまたはCLI、およびREST API)の認証および認可のためにIAMと統合されています。

組織の管理者は、どのユーザーがどのサービス、どのリソースおよびアクセスのタイプにアクセスできるかを制御するグループ、コンパートメントおよびポリシーを設定する必要があります。 たとえば、ポリシーは、新しいユーザーの作成、クラウド・ネットワークの作成と管理、インスタンスの起動、バケットの作成、オブジェクトのダウンロードなどを実行できるユーザーを制御します。詳細は、「ポリシーの開始」を参照してください。 異なる各サービスに対するポリシーの記述の詳細は、「ポリシー・リファレンス」を参照してください。

会社が所有するOracle Cloud Infrastructureリソースを使用する必要がある通常のユーザー(管理者ではない)の場合は、管理者に連絡してユーザーIDを設定してください。 管理者は、使用する必要があるコンパートメントを確認できます。

Load Balancingリソースの制限

適用可能な制限の一覧と制限の増加をリクエストする手順については、「サービス制限」を参照してください。

その他の制限は次のとおりです:

  • より多くの着信トラフィックを処理するために、ロード・バランサのシェイプを動的に変更することはできません。 APIまたはコンソールを使用して、新しいシェイプ情報を持つロード・バランサを作成できます。
  • AD固有のロード・バランサは、リージョンのロード・バランサまたはその逆に変換できません。
  • Load BalancingサービスはIPv6アドレスをサポートしていません。
  • ロード・バランサ・サブネットにステートフルなセキュリティ・リスト・ルールを使用すると、同時接続の最大数が制限されます。 対照的に、ステートレスなセキュリティ・リスト・ルールを使用する場合、同時接続には理論上の制限はありません。 実際の制限は、様々なファクタに依存します。 ロード・バランサのシェイプが大きくなるほど、接続容量は大きくなります。 その他の考慮事項には、システム・メモリー、TCPタイムアウト時間、TCP接続状態などが含まれます。

    ヒント

    大量のトラフィックを処理するには、ロード・バランサ・サブネットに「ステートレス・セキュリティ・リストのルール」を使用することを強くお薦めします。

  • 各ロード・バランサには、次の構成制限があります:

    • 1つのIPアドレス
    • 16個のバックエンド・セット
    • バックエンド・セットごとに512個のバックエンド・サーバー
    • 1024個のバックエンド・サーバー合計
    • 16 listeners