Oracle Cloud Infrastructureドキュメント

リクエスト・ルーティングの管理

このトピックでは、ロード・バランサのリクエスト・ルーティングを管理する方法について説明します。 ロード・バランサの管理については、「ロード・バランサの管理」を参照してください。

警告

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用してクラウド・リソースに説明、タグまたはわかりやすい名前を割り当てるときは、機密情報を入力しないでください。

必要なIAMポリシー

Oracle Cloud Infrastructureを使用するには、管理者が作成するポリシーで、コンソールまたはSDK、CLIまたはその他のツールを使用したREST APIのどちらを使用しているかにかかわらず、必要なタイプのアクセスを付与する必要があります。 アクションを実行しようとしたときに、権限のないメッセージや権限のないメッセージを取得する場合は、管理者に付与されているアクセスのタイプと作業するコンパートメントを確認してください。

管理者向け: ロード・バランサとそのコンポーネントにアクセスできる典型的なポリシーについては、「ネットワーク管理者がロード・バランサを管理できるようにします」を参照してください。

また、inspect load-balancersを含むポリシー・ステートメントは、指定されたグループに、ロード・バランサに関するall情報を表示する機能を提供することに注意してください。 詳細は、「Load Balancingの詳細」を参照してください。

新しいポリシーの場合は、「ポリシーの開始」「共通ポリシー」を参照してください。

着信リクエストのルーティング

Load Balancingサービスを使用すると、着信リクエストをさまざまなバックエンド・セットにルーティングできます。 次のことが可能です。

仮想ホスト名

ロード・バランサの任意の「作成するリスナー」に仮想ホスト名を割り当てることができます。 各ホスト名は、バックエンドから提供されるアプリケーションに対応できます。 仮想ホスト名には次のような利点があります:

  • 単一の関連IPアドレス。 DNSエントリによってバックアップされた複数のホスト名は、同じロード・バランサIPアドレスを指すことができます。
  • 単一のロード・バランサ。 アプリケーションごとに個別のロード・バランサは必要ありません。
  • 単一のロード・バランサ・シェイプ。 単一のロード・バランサの背後にある複数のアプリケーションを実行することで、総帯域幅の需要を管理し、利用率を最適化することができます。
  • より単純なバックエンド・セット管理。 1つのリソースで一連のバックエンド・サーバーを管理することで、ネットワークの構成と管理が簡単になります。

app.example.comなどの正確な仮想ホスト名を定義することも、ワイルドカード名を使用することもできます。 ワイルドカード名には、名前の最初または最後の部分の代わりにアスタリスク(*)が含まれています。 仮想ホスト名を検索する場合、サービスは最初に一致するバリアントを次の優先順位で選択します:

  1. app.example.comなどの完全な名前の一致(アスタリスクなし)。
  2. アスタリスクで始まる最長のワイルドカード名(*.example.comなど)。

    ヒント

    プレフィクス・ワイルドカード名には、HTTPSサイト用のワイルドカード証明書が必要な場合があります。

  3. アスタリスクで終わる最長のワイルドカード名(app.example.*など)。

    ヒント

    ワイルドカード名には、HTTPSサイト用の複数ドメインのSubject Alternative Name (SAN)証明書が必要な場合があります。

適用するパターンを指定する必要はありません。 パターンは、アスタリスクの位置、すなわち開始、終了、またはなしに固有のものです。

仮想ホスト名には、次の考慮事項が適用されます:

  • 正規表現は使用できません。
  • リスナーに仮想ホスト名を適用するには、最初にロード・バラン・サーに関連付けられた「1つ以上の仮想ホスト名を作成」を使用します。
  • 仮想ホスト名の選択優先度は、リスナーの構成順序とは関係ありません。
  • リスナーには最大16の仮想ホスト名を適用できます。
  • 最大16の仮想ホスト名をロード・バランサに関連付けることができます。

ヒント

仮想ホスト名機能は、HTTPリスナーのみをサポートしますが、TCPリスナーはサポートしません。

ノート

デフォルト・リスナー

リスナーに仮想ホスト名が指定されていない場合、そのリスナーは割り当てられたポートのデフォルトです。

ポート上のすべてのリスナーに仮想ホスト名がある場合、そのポート用に構成された最初の仮想ホスト名がデフォルトのリスナーとして機能します。

パス・ルート・ルール

いくつかのアプリケーションには、複数のエンドポイントまたはコンテンツ・タイプがあり、それぞれ固有のURIパスで識別されます。 たとえば、/admin//data//video/、または/cgi/です。 複数のリスナーまたはロード・バランサを使用せずに、パス・ルート・ルールを使用してトラフィックを正しいバックエンド・セットにルーティングできます。

「パス・ルート」は、Load Balancingサービスが着信URIと照合して適切な宛先バックエンド・セットを決定する文字列です。

  • パス・ルート文字列にアスタリスクを使用することはできません。
  • 正規表現は使用できません。
  • パスのルート文字列のマッチングは大文字と小文字を区別しません。

重要

ブラウザでは、リクエスト内のパスに終了スラッシュを追加することがよくあります。
/adminのようなパスを指定する場合は、パスの末尾にスラッシュを付けたり、スラッシュを付けたりしないでパスを構成することができます。 たとえば、/adminおよび/admin/です。

「パス・ルート・ルール」は、パスのルート文字列とパターン・マッチ・タイプで構成されています。

  • パターン・マッチ・タイプは次のとおりです:

    • EXACT_MATCH

      着信URIパスと正確に一致するパス文字列を探します。

      大文字と小文字を区別しない正規表現を適用する:

      ^<path_string>$
    • FORCE_LONGEST_PREFIX_MATCH

      着信URIパスの先頭部分が最も長く一致するパス文字列を探します。

      大文字と小文字を区別しない正規表現を適用する:

      <path_string>.*
    • PREFIX_MATCH

      着信URIパスの先頭部分に一致するパス文字列を探します。

      大文字と小文字を区別しない正規表現を適用する:

      ^<path_string>.*
    • SUFFIX_MATCH

      着信URIパスの末尾部分に一致するパス文字列を探します。

      大文字と小文字を区別しない正規表現を適用する:

      .*<path_string>$
  • パスのルート・ルールは、HTTPおよびHTTPSリクエストにのみ適用され、TCPリクエストには影響しません。

「パス・ルート・セット」には、特定のリスナーのデータ・ルーティングを定義するすべてのパスのルート・ルールが含まれています。

  • パス・ルート・セットごとに最大20のパス・ルート・ルールを指定できます。
  • リスナーごとに1つのパス・ルートを設定できます。 「リスナーの最大数」は、ロード・バランサに指定できるパス・ルート・セット数を制限します。

ルールの優先度

マッチ・タイプに基づいて、セット内のパス・ルート・ルールに以下の優先順位が適用されます:

  • EXACT_MATCHタイプを指定する1つのパス・ルート・ルールの場合、優先順位のカスケードはありません。 リスナーは正確な一致のみを探します。
  • EXACT_MATCHタイプと他のマッチ・タイプを指定する2つのパス・ルート・ルールの場合、完全一致ルールが最初に評価されます。 一致するものが見つからない場合、システムは2番目の一致タイプを探します。
  • さまざまなマッチ・タイプを指定する複数パスのルート・ルールの場合、システムは次の優先順位のカスケードを適用します:

    1. EXACT_MATCH
    2. FORCE_LONGEST_PREFIX_MATCH
    3. PREFIX_MATCHまたはSUFFIX_MATCH
  • パス・ルート・セット内のルールの順序は、EXACT_MATCHとFORCE_LONGEST_PREFIX_MATCHでは関係ありません。 これらのマッチ・タイプがパス・ルート・セット内のどこに表示されても、システムは優先順位カスケードを適用します。
  • 一致するサフィクスがプレフィクスまたはサフィクスに一致する場合、パス・ルート・セット内のルールの順序は重要です。 システムは、着信URIパスと一致する最初のプレフィクスまたはサフィクスのルールを選択します。

仮想ホスト名とパス・ルート・ルールの組み合わせ

仮想ホスト名とパス・ルート・ルールは、リクエストをバックエンド・セットにルーティングします。 仮想ホスト名を持つリスナーは、デフォルト(ホスト名なし)のリスナーよりも優先順位が高くなります。 次の例は、単純なルーティングの相互作用の結果を示しています。

この例のシステムには、3つのリスナーと1つのパス・ルート・セットが含まれています:

Listener 1

  • 仮想ホスト名: none
  • デフォルトのバックエンド・セット: A
  • パス・ルート・セット: PathRouteSet1

Listener 2

  • 仮想ホスト名: captive.com
  • デフォルトのバックエンド・セット: B
  • パス・ルート・セット: PathRouteSet1

Listener 3

  • 仮想ホスト名: wild.com
  • デフォルトのバックエンド・セット: C
  • パス・ルート・セット: PathRouteSet1

パス・ルート・セット

  • パス・ルート・セット名: PathRouteSet1

    • パス文字列/tame/のバックエンド・セットBへの完全一致。
    • パス文字列/feral/のバックエンド・セットCへの完全一致。

構成例では、着信URLを次のようにルーティングします:

http://animals.com/はバックエンド・セットaにルーティングされます。
http://animals.com/tame/はバックエンド・セットbにルーティングされます。
http://animals.com/feral/はバックエンド・セットcにルーティングされます。
http://captive.com/はバックエンド・セットbにルーティングされます。
http://captive.com/tame/はバックエンド・セットbにルーティングされます。
http://captive.com/feral/はバックエンド・セットcにルーティングされます。
http://wild.com/はバックエンド・セットcにルーティングされます。
http://wild.com/tame/はバックエンド・セットbにルーティングされます。
http://wild.com/tame/はバックエンド・セットcにルーティングされます。

コンソールの使用

「リスナーを作成または更新」を実行すると、仮想ホスト名とパスのルート・セットを指定できます。

仮想ホスト名の作成

仮想ホスト名をリスナーに適用するには、最初に1つ以上の仮想ホスト名を作成します。 仮想ホスト名は、ロード・バランサ構成の一部になります。 ロード・バランサのリスナーを作成または更新するときに使用する1つ以上の仮想ホスト名を指定します。

仮想ホスト名を作成するには
仮想ホスト名を更新するには
仮想ホスト名を削除するには

パス・ルート・セットの作成

パス・ルート・ルールをリスナーに適用するには、最初にルールを含むパス・ルート・セットを作成します。 パス・ルート・セットは、ロード・バランサ構成の一部になります。 ロード・バランサのリスナーを作成または更新するときに使用するパス・ルート・セットを指定します。 リスナー「リスナーを編集」からパス・ルート・セットを削除し、「なし」「パス・ルート・セット」オプションとして選択します。

パス・ルート・セットを作成するには
パス・ルート・セットを更新するには
単一パス・ルート・ルールを更新するには

APIの使用

APIおよび署名リクエストの使用については、REST APIおよび「セキュリティ資格証明」を参照してください。 SDKの詳細は、「ソフトウェア開発キットとコマンドライン・インタフェース」を参照してください。

リクエスト・ルーティングを管理するには、次のAPI操作を使用します: