すべてのプロダクト
Search
ドキュメントセンター

Server Load Balancer:パスベースの転送ルールの設定

最終更新日:Aug 05, 2026

デフォルトでは、Classic Load Balancer (CLB) インスタンスは、リスナーに設定されたバックエンドサーバーグループにすべてのトラフィックを送信します。サービスの拡張に伴い、リソースの分散が不均等になったり、パフォーマンスが低下したり、運用が複雑化したりする可能性があります。CLB リスナーに転送ルールを設定することで、指定したバックエンドサーバーグループにトラフィックをルーティングできます。これにより、きめ細かいトラフィック管理とサービス分離が可能になり、リソース使用率を向上させ、サービス安定性を確保し、ユーザーエクスペリエンスを最適化できます。

機能概要

CLB リスナーの転送ルールは、ドメイン名と URL パスに基づいて、クライアントからの受信リクエストを異なるバックエンドサーバーに分散します。

主な機能

  • ドメイン名ベースの転送

    • 照合モード:完全一致とワイルドカード照合 (単一レベルおよび複数レベルのワイルドカードを含む) に対応しています。 たとえば、www.aliyun.com は完全一致、*.aliyun.com と *.market.aliyun.com はワイルドカード照合です。

    • 照合の優先順位:照合順序は、完全一致 > より狭い範囲のワイルドカード > より広い範囲のワイルドカードとなり、最も正確なルールが最初に実行されるようになります。

      次の表に、照合の優先順位の例を示します。✓ は一致を示し、× は不一致を示します。

      モード

      テストリクエスト URL

      ドメイン転送ルール

      www.aliyun.com

      *.aliyun.com

      *.market.aliyun.com

      [完全一致]

      www.aliyun.com

      ✓

      ×

      ×

      ワイルドカード一致

      market.aliyun.com

      ×

      ✓

      ×

      info.market.aliyun.com

      ×

      ×

      ✓

  • URL パスベースの転送

    照合ロジック: システムは URL パスに基づいて最長プレフィックス一致を使用します。 たとえば、/abc と /abcd の両方にルールを設定した場合、/abcde へのリクエストは /abcd のルールに一致します。

  • ポリシーの組み合わせ:同じリスナーに対して複数のポリシーを設定し、ドメイン名と URL パスの組み合わせを使用して、読み取りリクエストと書き込みリクエストを異なるサーバーグループに転送するなど、複雑なトラフィック分散シナリオを実装できます。

仕組み

1 つのリスナーに複数の転送ルールを追加でき、各ルールは異なる vServer グループに関連付けられます。照合ロジックは次の図のとおりです。転送ルールを設定していない場合、ロードバランサーはすべてのリクエストをリスナーに設定されたデフォルトサーバーグループに転送します。転送ルールが設定されている場合、ロードバランサーはルールとの照合を試みます。リクエストがルールに一致する場合、そのルールに関連付けられたサーバーグループに転送されます。それ以外の場合、リクエストはリスナーのデフォルトサーバーグループに送信されます。

image

ユースケース

  • マイクロサービスアーキテクチャ:マイクロサービスアーキテクチャでは、アプリケーションは、異なるインスタンスまたはコンテナにデプロイされた複数の独立したサービスで構成されます。パスベースルーティングは、対応するビジネスロジックを処理する特定のサービスインスタンスにクライアントリクエストを転送します。たとえば、e コマースプラットフォームでは、HTTP リクエストの URL パスに基づいて、ユーザー認証、注文処理、および決済リクエストを、それぞれの認証、注文、および決済サービスにルーティングできます。

  • 読み取り/書き込み分離: 注文処理など、高い同時実行性と厳密なデータ整合性が要求されるサービスの場合、読み取り/書き込み分離を実装することで、パフォーマンスとデータセキュリティを最適化できます。読み取り操作と書き込み操作は、異なるデータベースインスタンスまたはクラスターによって処理されます。読み取り操作は読み取りデータベースにルーティングされ、書き込み操作は書き込みデータベースに向けられます。

  • マルチテナントアプリケーション: マルチテナントアプリケーションでは、さまざまなテナントにサービスの分離とパーソナライゼーションを提供するために、独立した環境が必要です。 例えば、テナント固有のサブドメインを使用してさまざまなエントリーポイントを区別し、URL パスを使用してサービス機能をさらに洗練させることができます。 このアプローチは、各テナントのデータセキュリティとプライバシーを確保するだけでなく、カスタマイズされたユーザーエクスペリエンスとインターフェースも実現します。

制限事項

  • レイヤー 7 の HTTP および HTTPS リスナーのみが転送ルールをサポートします。

  • 転送ルールで指定されるバックエンドサーバーグループは、vServer グループである必要があります。

  • HTTP または HTTPS リスナーには、最大 40 個のドメイン名および URL 転送ルールを追加できます。詳細については、「制限事項」をご参照ください。

シナリオ例

ある教育プラットフォームが、ビデオコースやオンライン試験ライブラリなど、さまざまなオンライン学習サービスを単一のドメイン名で提供したいと考えています。ビデオサービスには高い帯域幅とストリーミング機能が必要ですが、試験ライブラリサービスには高い計算処理能力と高速な応答時間が必要です。当初、すべてのサービスは単一のサーバーグループにデプロイされていたため、リソースの割り当てが不均等になっていました。ビデオストリーミングのピーク時には、試験ライブラリのパフォーマンスが影響を受け、ユーザーエクスペリエンスが低下しました。また、トラフィックの急増時のサーバー負荷の高さも、サービスの安定性を損なっていました。

この問題に対処するため、プラットフォームは Alibaba Cloud の CLB の転送ルールを使用して、同じドメイン名で異なる URL パスに基づいてトラフィックをルーティングします。次の図に示すように、/video/ へのリクエストはビデオサービスの vServer グループ RS1 に転送され、ビデオサービスに十分な帯域幅と処理能力を確保します。/exam/ へのリクエストは試験サービスの vServer グループ RS2 に転送され、高速なクエリ応答と送信のために計算リソースを最適化します。このアプローチにより、正確なルーティングが実現し、各サブサービスが独立して動作することが保証されるようになります。

image

前提条件

  • Virtual Private Cloud (VPC) の作成で、中国 (上海) リージョンに VPC1 という名前の VPC を作成し、ゾーン E とゾーン G にそれぞれ vSwitch VSW1 と VSW2 が作成されていること。

  • VSW1 と VSW2 にそれぞれ Elastic Compute Service (ECS) インスタンス ECS01 と ECS02 を作成し、それぞれにアプリケーションサービスがデプロイされていること。注意:セキュリティグループのルールで、アプリケーションサービスが使用するポートでのトラフィックが許可されていることを確認してください。

    次のサンプルコマンドは、ECS01 と ECS02 にテストアプリケーションをデプロイする方法を示しています。

    ECS インスタンスにテストサービスをデプロイするためのサンプルコマンド

    ECS01 のコマンド

    yum install -y nginx
    systemctl start nginx.service
    mkdir /usr/share/nginx/html/video
    cd /usr/share/nginx/html/video
    echo "Hello World ! This is video service." > index.html

    ECS02 のコマンド

    yum install -y nginx
    systemctl start nginx.service
    mkdir /usr/share/nginx/html/exam
    cd /usr/share/nginx/html/exam
    echo "Hello World ! This is exam service." > index.html
  • CLB インスタンス用に 2 つの vServer グループ、RS1 と RS2 を作成し、ECS01 を RS1 に、ECS02 を RS2 に追加しました。 バックエンドサーバーポートは、アプリケーションサービスポートと一致させる必要があります。 この例では、NGINX のデフォルトポート 80 を使用します。

  • CLB インスタンスに HTTP リスナーまたは HTTPS リスナーが設定されていること。

  • Alibaba Cloud にドメイン名を登録し、ICP 登録を完了していること。

操作手順

ステップ 1:転送ルールの設定

  1. Classic Load Balancer (CLB) コンソールにログインします。

  2. トップナビゲーションバーで、CLB インスタンスがデプロイされているリージョンを選択します。

  3. インスタンス ページで、対象インスタンスの ID をクリックします。

  4. リスナー タブで、対象のリスナーを見つけ、操作 列の 転送ルールの設定 をクリックします。

  5. さらに追加 パネルで、転送ルールを設定し、さらに追加 をクリックします。

    この例では、2 つの転送ルールが設定されています。URL が /video のリクエストは vServer グループ RS1 に転送され、URL が /exam のリクエストは vServer グループ RS2 に転送されます。

    • [ドメイン]:登録済みのドメイン名を入力します。ICP 登録が完了している必要があります。

    • URL:リクエストパスを入力します。

      CLB 転送ルールのパスマッチングでは、大文字と小文字が区別されます。たとえば、/video と /viDeo は個別のパスと見なされるため、それぞれ異なる転送ルールが必要です。

    説明

    リクエストの URL パスに特殊文字が含まれている場合は、URL エンコーディングを使用する必要があります。たとえば、番号記号 (#) を含む URL パス (例:/#/) に転送ルールを設定した場合、リクエスト URL は URL エンコードされた値 "%23" (例:/%23/) を使用して、正しく照合および転送される必要があります。

ステップ 2:ヘルスチェックの設定

説明

デフォルトでは、HTTP ヘルスチェックは、サーバーに設定されているアプリケーションのデフォルトのホームページに HTTP リクエストを送信します。ヘルスチェックにデフォルトのホームページ以外のページを使用するには、そのページの正確なパスを指定する必要があります。

  1. インスタンス ページで、目的の CLB インスタンスを見つけ、その ID をクリックします。

  2. リスナー タブで、リスナーを見つけ、操作 列の 転送ルールの設定 をクリックします。

  3. ルール パネルの 転送ルール で、対象の転送ルールを見つけて 編集 をクリックします。設定が必要な他のルールについても、この手順を繰り返します。

  4. 転送ルールを編集する パネルで、高度な設定 を有効にし、ヘルスチェックへのパス を転送ルールの [URL] パスに設定します。たとえば、/video の URL を使用するルールの場合、ヘルスチェックパスを /video に設定します。

    [ヘルスチェック] スイッチを有効にし、[OK] をクリックします。

ステップ 3:DNS レコードの設定

説明
  • Alibaba Cloud に登録されていないドメインの場合、DNS レコードを設定する前に、まず Alibaba Cloud DNS コンソールにドメインを追加する必要があります。

  • お使いの CLB インスタンスが内部向けインスタンスの場合、まず Elastic IP アドレス (EIP) を関連付けてから、ドメイン名を EIP にマッピングする A レコードを作成して、インターネットからアクセスできるようにする必要があります。

  1. 左側メニューで、CLB > インスタンス を選択します。

  2. インスタンス ページで、対象のインスタンスを選択し、その IP をコピーします。

  3. A レコードを追加するには、次の手順を実行します。

    1. Alibaba Cloud DNS コンソールにログインします。

    2. インターネットの権威ある DNS 解決 ページで、対象のドメイン名を見つけ、Actions 列の 解決設定 をクリックします。

    3. 解決設定 ページで、Add Record をクリックします。

    4. Add Record パネルで、次のパラメーターを設定します。他のパラメーターはデフォルト値のままにするか、必要に応じて変更できます。次に、OK をクリックします。

      パラメーター

      説明

      [Record Type]

      ドロップダウンリストから [A] を選択します。

      [Hostname]

      ドメイン名のプレフィックスです。

      説明

      ルートドメインの場合、ホスト名を @ に設定します。

      [Record Value]

      コピーした CLB インスタンスの IP アドレスを入力します。

ステップ 4:設定のテスト

ブラウザを使用して http://<ご使用のドメイン名>/<URL>/ にアクセスし、リクエストが正しいサーバーグループにルーティングされることを確認します。

  1. http://www.example.com/video/ にあるビデオサービスにアクセスして、リクエストがビデオサービスの vServer グループ RS1 にルーティングされることを確認してください。

    アクセスが成功した場合、ページに次の内容が返されます:

    Hello World ! This is video service.
  2. http://www.example.com/exam/ にアクセスして、リクエストが exam サービス vServer グループ RS2 にルーティングされることを確認します。

    ページから次の応答が返された場合、リクエストは試験サービスに正常にルーティングされたことになります:

    Hello World ! This is exam service.

よくある質問

CLB の転送ルールは URL リダイレクトをサポートしていますか?

いいえ。CLB の転送ルールはトラフィックの転送のみを行います。URL リダイレクトを設定する必要がある場合は、Application Load Balancer (ALB) の使用を検討してください。詳細については、「リスナーの転送ルールの設定」をご参照ください。

パスベースの転送を設定した後、ヘルスチェックが失敗するのはなぜですか?

ヘルスチェックを実行する際、ロードバランサーは転送ルールを無視し、リスナーに設定されたヘルスチェックパス (デフォルトではルートパス) にリクエストを送信します。バックエンドサービスがリクエストパスに基づいて異なる応答をする場合、デフォルトまたは一致しないパスに送信されたヘルスチェックは失敗する可能性があります。必要に応じて、各転送ルールにカスタムのヘルスチェックパスを設定できます。

ドメインベースの転送ルールを使用すると追加料金は発生しますか?

ドメインベースの転送ルールを設定しても料金は発生しません。ただし、内部向けの CLB インスタンスに EIP を関連付けてインターネットからアクセスできるようにする場合、パブリックネットワークの使用量に対して課金されます。課金の詳細については、「CLB 課金概要」をご参照ください。

転送ルールはリスナーごとに設定されますか?

はい。各リスナーの転送ルールは独立しており、個別に設定する必要があります。

リスナーがデフォルトで転送するサーバーグループが空の場合でも、パブリック IP アドレス経由でバックエンドサービスに到達できるのはなぜですか?

リクエストの URL パスが転送ルールに一致する場合、ロードバランサーはそのルールに関連付けられた vServer グループにリクエストを直接ルーティングします。リスナーがデフォルトで転送するサーバーグループは使用されません。そのサーバーグループにバックエンドサーバーがない場合でも、転送ルールに一致するリクエストは対応する vServer グループに正常に転送されます。どの転送ルールにも一致しなかったリクエストのみが、そのサーバーグループに転送されます。そのサーバーグループが空の場合、一致しなかったリクエストには 503 エラーが返されます。

CLB の転送ルールは、リクエストがドメイン名を使用しているか、CLB のパブリック IP アドレスを使用しているかに関係なく、URL パスに基づいてリクエストを照合します。転送ルールに一致する URL パスで CLB のパブリック IP アドレスにアクセスすると、関連付けられた vServer グループに正常に到達します。

HTTP および HTTPS リスナーのみがパスベースの転送ルールをサポートします。TCP および UDP リスナーはサポートしておらず、すべてのリクエストをリスナーがデフォルトで転送するサーバーグループにルーティングするため、前述の動作にはなりません。

特定の URL へのアクセスのみを許可し、その他には 404 を返すように転送ルールを設定するにはどうすればよいですか?

許可する URL パスと 404 を返す必要がある URL パスに対して、個別の転送ルールを設定します。URL パスベースの転送では最長プレフィックス一致が使用されるため、/h5/ と /h5/entryPage/ のように 2 つのパスにプレフィックス関係がある場合は、より具体的なパスに個別のルールを設定します。たとえば、/h5/ のみを許可し、/h5/entryPage/ で 404 を返すには:

  • URL /h5/ → お客様のビジネスサービスの vServer グループ。

  • URL /h5/entryPage/ → 404 を返す専用の vServer グループ (軽量な Nginx サービスなど)。

/h5/entryPage/ へのリクエストはルール 2 に一致するため 404 が返され、/h5/ 配下のその他のリクエストはルール 1 に一致して正常に転送されます。

関連ドキュメント