内部アプリケーションロードバランサのトラフィック管理を設定する

このドキュメントで説明するトラフィック管理の使用例は、特定のユースケースのものです。他にもさまざまなユースケースが考えられます。

このドキュメントでは、次のロードバランサの例を示します。

リージョン外部アプリケーションロードバランサ
リージョン内部アプリケーションロードバランサ
クロスリージョン内部アプリケーションロードバランサ

リージョン外部アプリケーションロードバランサとリージョン内部アプリケーションロードバランサリージョンロードバランサのトラフィック管理構成については、リージョン URL マップ API とリージョンバックエンドサービス API のドキュメントをご覧ください。フィールドの完全なリストや、関係、制限、カーディナリティに関するセマンティクスを確認できます。

2 つのロードバランサの違いはロードバランシングのスキームだけです。

リージョン外部アプリケーションロードバランサは EXTERNAL_MANAGED を使用します。
リージョン内部のアプリケーションロードバランサでは、INTERNAL_MANAGED を使用します。

リージョン内部アプリケーションロードバランサとクロスリージョン内部アプリケーションロードバランサトラフィック管理の構成:

リージョン内部アプリケーションロードバランサは、リージョン URL マップ API を使用します。リージョンバックエンドサービス API のドキュメントには、フィールドの完全なリストと、関係、制限、カーディナリティに関するセマンティクスなどが記載されています。
クロスリージョン内部アプリケーションロードバランサはグローバル URL マップ API を使用します。グローバルバックエンドサービス API のドキュメントにはフィールドの完全なリストと、関係、制限、カーディナリティに関するセマンティクスが記載されています。

注: クロスリージョン内部アプリケーションロードバランサについては、regions/REGION/backendServices を global/backendServices に置き換えることで、このドキュメントで説明している例を使用できます。

このページで説明する高度なルーティング機能に加えて、サポートされているアプリケーションロードバランサは Service Extensions と統合されているため、ロードバランシングデータパスにカスタムロジックを挿入できます。

始める前に

トラフィック管理の仕組みについて理解する必要があります。詳細については、トラフィック管理のコンセプトをご覧ください。
内部アプリケーションロードバランサの設定の手順に沿って、必要な VM ホストまたは GKE クラスタを構成します。
ロードバランサの構成の説明に従って、必要なヘルスチェックを作成するか、既存のヘルスチェックを再使用します。

トラフィック管理の構成

選択した構成環境で、YAML 構成を使用してトラフィック管理を設定します。URL マップとバックエンドサービスにはそれぞれ独自の YAML ファイルがあります。必要な機能に応じて、URL マップの YAML、バックエンドサービスの YAML、またはその両方を記述する必要があります。

これらの YAML ファイルの作成方法については、このページの例と Cloud Load Balancing API ドキュメントをご覧ください。

リージョン内部アプリケーションロードバランサの場合は、Google Cloud コンソールを使用してトラフィック管理を構成することもできます。

リージョン内部アプリケーションロードバランサとリージョン外部アプリケーションロードバランサの場合は、リージョン URL マップ API とリージョンバックエンドサービス API のドキュメントをご覧ください。関係、制限、カーディナリティに関するセマンティクスなどが記載されています。

Google Cloud コンソールで YAML のサンプルにアクセスする

Google Cloud コンソールで YAML のサンプルにアクセスするには:

Google Cloud コンソールで、[ロードバランシング] ページに移動します。

[ロードバランシング] に移動
[ロードバランサを作成] をクリックします。
ウィザードの指示に従って、リージョン内部アプリケーションロードバランサを作成します。
ルーティングルールの構成で、[詳細なホスト、パス、ルートのルール] を選択します。
[Add hosts and path matcher] をクリックします。
[コードガイダンス] のリンクをクリックします。

[パスマッチャーの YAML の例] ページが表示されます。

1 つのサービスへのトラフィックのマッピング

すべてのトラフィックを 1 つのサービスに送信します。プレースホルダを置き換えてください。

    defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
    hostRules:
    - hosts:
      - '*'
      pathMatcher: matcher1
    name: URL_MAP_NAME
    pathMatchers:
    - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: matcher1
      routeRules:
        - matchRules:
            - prefixMatch: /PREFIX
          priority: 1
          routeAction:
            weightedBackendServices:
              - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
                weight: 100

2 つのサービス間でのトラフィックの分割

2 つ以上のサービス間でトラフィックを分割します。プレースホルダを置き換えてください。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   name: URL_MAP_NAME
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
     - matchRules:
       - prefixMatch: /PREFIX
       priority: 2
       routeAction:
         weightedBackendServices:
         - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
           weight: 95
         - backendService: regions/REGION/backendServices/BACKEND_SERVICE_2
           weight: 5

URL のリダイレクトの構成

次のサンプルでは、構成可能な 3xx レスポンスコードが返されます。また、このサンプルでは、Location レスポンスヘッダーに適切な URI を設定し、リダイレクトアクションで指定されたホストとパスを置き換えます。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         urlRedirect:
           hostRedirect: "new-host-name.com" # Omit to keep the requested host
           pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
           prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
           redirectResponseCode: FOUND
           stripQuery: True

トラフィックのミラーリング

選択されたバックエンドサービスにリクエストを転送するだけでなく、構成されたミラーバックエンドサービスに「ファイアアンドフォーゲット」方式で同じリクエストを送信します。ロードバランサは、ミラーリングされたリクエストを送信するバックエンドからのレスポンスを待ちません。ミラーリングは、バックエンドサービスの新しいバージョンをテストする際に利用できます。また、本番環境バージョンではなく、バックエンドサービスのデバッグ環境バージョンで、本番環境のエラーのデバッグに使用することもできます。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: 1
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           requestMirrorPolicy:
             backendService: regions/REGION/backendServices/BACKEND_SERVICE_2

トラフィックミラーリングを使用する場合は、次の制限事項に注意してください。

トラフィックミラーリングは、両方のバックエンドサービスにマネージドインスタンスグループ、ゾーン NEG、またはハイブリッド NEG のバックエンドがある場合にサポートされます。インターネット NEG、サーバーレス NEG、Private Service Connect のバックエンドではサポートされていません。
ミラーリングされたバックエンドサービスへのリクエストでは、Cloud Logging と Cloud Monitoring のログや指標は生成されません。

リクエストされた URL の書き換え

選択したバックエンドサービスにリクエストを送信する前に、URL のホスト名部分、URL のパス部分、またはその両方を書き換えます。プレースホルダを置き換えてください。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           urlRewrite:
             hostRewrite: "new-host-name.com" # Omit to keep the requested host
             pathPrefixRewrite: "/new-path/" # Omit to keep the requested path

リクエストの再試行

ロードバランサが失敗したリクエストを再試行する条件、再試行までのロードバランサの待機時間、再試行の最大回数を構成します。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           retryPolicy:
             retryConditions: 502, 504
             numRetries: 3
             perTryTimeout:
               seconds: 1
               nanos: 500000000

ルートタイムアウトの指定

選択したルートのタイムアウトを指定します。リクエストが完全に処理されてからレスポンスが完全に処理されるまでのタイムアウトが計算されます。タイムアウトにはすべての再試行が含まれます。プレースホルダを置き換えてください。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           timeout:
             seconds: 30
             nanos: 500000000

フォールトインジェクションの構成

高レイテンシ、サービス過負荷、サービス障害、ネットワークパーティショニングなどの障害をシミュレートするリクエストを処理する際にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           faultInjectionPolicy:
             delay:
               fixedDelay:
                 seconds: 10
                 nanos: 500000000
               percentage: 25
             abort:
               httpStatus: 503
               percentage: 50

CORS の構成

クロスオリジンリソースシェアリング（CORS）ポリシーを構成して、CORS リクエストを適用するための設定を処理します。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
           corsPolicy:
               allowOrigins: my-domain.com
               allowMethods: GET, POST
               allowHeaders: Authorization, Content-Type
               maxAge: 1200
               allowCredentials: True

リクエストヘッダーとレスポンスヘッダーの追加と削除

バックエンドサービスにリクエストを送信する前にリクエストヘッダーを追加および削除します。また、バックエンドサービスからレスポンスを受信した後に、レスポンスヘッダーを追加および削除することもできます。

リージョン外部アプリケーションロードバランサと内部アプリケーションロードバランサは、カスタムヘッダーでの変数の使用もサポートしています。カスタムヘッダー値（headerValue）フィールドに 1 つ以上の変数を指定すると、変数が対応するリクエストごとの値に変換されます。サポートされているヘッダー値の一覧については、URL マップでカスタムヘッダーを作成するをご覧ください。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
   name: regional-lb-map
   region: region/REGION
   hostRules:
   - hosts:
     - '*'
     pathMatcher: matcher1
   pathMatchers:
   - defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
     name: matcher1
     routeRules:
       - matchRules:
           - prefixMatch: /PREFIX
         priority: PRIORITY # 0 is highest
         routeAction:
           weightedBackendServices:
             - backendService: regions/REGION/backendServices/BACKEND_SERVICE_1
               weight: 100
               headerAction:
                 requestHeadersToAdd:
                 - headerName: header-1-name
                   headerValue: header-1-value
                   replace: True
                 requestHeadersToRemove:
                 - header-2-name
                 - header-3-name
                 responseHeadersToAdd:
                 - headerName: header-4-name
                   headerValue: header-4-value
                   replace: True
                responseHeadersToRemove:
                - header-5-name
                - header-6-name

外れ値検出を構成する

NEG の正常でないバックエンド VM またはエンドポイントのエビクションの基準、およびバックエンドまたはエンドポイントがトラフィックを再度受信するのに十分に正常だと考えられるのはどのようになったときかを定義する基準を指定します。プレースホルダを置き換えてください。

    loadBalancingScheme: LOAD_BALANCING_SCHEME
    localityLbPolicy: RANDOM
    name: regions/REGION/backendServices/BACKEND_SERVICE_1
    outlierDetection:
      baseEjectionTime:
        nanos: 0
        seconds: '30'
      consecutiveErrors: 5
      consecutiveGatewayFailure: 3
      enforcingConsecutiveErrors: 2
      enforcingConsecutiveGatewayFailure: 100
      enforcingSuccessRate: 100
      interval:
        nanos: 0
        seconds: '1'
      maxEjectionPercent: 50
      successRateMinimumHosts: 5
      successRateRequestVolume: 100
      successRateStdevFactor: 1900
    region: region/REGION

サーキットブレーカーの構成

クライアントリクエストでバックエンドが過負荷にならないように、回路遮断で障害しきい値を設定できます。リクエストが設定したしきい値に達すると、ロードバランサは新しい接続や追加のリクエストの送信の許可を停止し、バックエンドの復旧のための時間を確保します。そのため、バックエンドで過負荷を発生させずにエラーをクライアントに返すことで、カスケード障害を回避できます。これにより、自動スケーリングによって容量を増やしてトラフィックの急増に対応するなど、過負荷状態を管理する時間を確保しつつ、一部のトラフィックを処理できます。

接続あたりのリクエスト数と、バックエンドサービスへの接続量に上限を設定します。また、保留中のリクエストと再試行の数も制限します。

    loadBalancingScheme: LOAD_BALANCING_SCHEME # EXTERNAL_MANAGED or INTERNAL_MANAGED
    localityLbPolicy: RANDOM
    affinityCookieTtlSec: 0
    backends:
    - balancingMode: UTILIZATION
      capacityScaler: 1.0
      group: region/REGION/instanceGroups/INSTANCE_GROUP
      maxUtilization: 0.8
    circuitBreakers:
      maxConnections: 1000
      maxPendingRequests: 200
      maxRequests: 1000
      maxRequestsPerConnection: 100
      maxRetries: 3
    connectionDraining:
      drainingTimeoutSec: 0
    healthChecks:
    - region/REGION/healthChecks/HEALTH_CHECK

トラフィック分割の設定: 詳細な手順

この例では次の手順を説明します。

サービスごとに異なるテンプレートを作成します。
テンプレートのインスタンスグループを作成します。
95% / 5% のトラフィック分割を設定するルーティングルールを作成します。
curl コマンドを送信すると、構成とほぼ一致するトラフィック分割率が表示されます。

ここでは、次のことを想定しています。

リージョンは us-west1 である。
regional-lb-map という URL マップとともに、ターゲットプロキシと転送ルールが作成される。
URL マップによって、すべてのトラフィックがデフォルトのバックエンドサービスである red-service というバックエンドサービスに送信される。
トラフィックの 5% を blue-service、95% を green-service に送信する代替パスを設定している。
パスマッチャーが使用されている。
Cloud Shell（または bash がインストールされているその他の環境）を使用している。

サービスを定義する

次の bash 関数によって、インスタンステンプレートとマネージドインスタンスグループを含むバックエンドサービスが作成されます。

ここでは、HTTP ヘルスチェック（regional-lb-basic-check）が作成されていることが前提です。手順については、内部アプリケーションロードバランサを設定するをご覧ください。

function make_service() {
  local name="$1"
  local region="$2"
  local zone="$3"
  local network="$4"
  local subnet="$5"
  local subdir="$6"

  www_dir="/var/www/html/$subdir"

  (set -x; \
  gcloud compute instance-templates create "${name}-template" \
    --region="$region" \
    --network="$network" \
    --subnet="$subnet" \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --metadata=startup-script="#! /bin/bash
  apt-get update
  apt-get install apache2 -y
  a2ensite default-ssl
  a2enmod ssl
  sudo mkdir -p $www_dir
  /bin/hostname | sudo tee ${www_dir}index.html
  systemctl restart apache2"; \
  gcloud compute instance-groups managed create \
    "${name}-instance-group" \
    --zone="$zone" \
    --size=2 \
    --template="${name}-template"; \
  gcloud compute backend-services create "${name}-service" \
    --load-balancing-scheme=LOAD_BALANCING_SCHEME\
    --protocol=HTTP \
    --health-checks=regional-lb-basic-check \
    --health-checks-region="$region" \
    --region="$region"; \
  gcloud compute backend-services add-backend "${name}-service" \
    --balancing-mode='UTILIZATION' \
    --instance-group="${name}-instance-group" \
    --instance-group-zone="$zone" \
    --region="$region")
}

サービスを作成する

この関数を呼び出して、red、green、blue という 3 つのサービスを作成します。red サービスは、/ へのリクエストのデフォルトサービスとして動作します。green および blue サービスは、それぞれトラフィックの 95% と 5% を処理するように、いずれも /PREFIX で設定されます。

make_service red us-west1 us-west1-a lb-network backend-subnet ""
make_service green us-west1 us-west1-a lb-network backend-subnet /PREFIX
make_service blue us-west1 us-west1-a lb-network backend-subnet /PREFIX

URL マップの作成

gcloud

gcloud compute url-maps export コマンドを使用して、既存の URL マップをエクスポートします。

gcloud compute url-maps export regional-lb-map \
  --destination=regional-lb-map-config.yaml \
  --region=us-west1

これをファイルの末尾に追加して、URL マップファイル regional-lb-map-config.yaml を更新します。

hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /PREFIX
    routeAction:
      weightedBackendServices:
        - backendService: regions/us-west1/backendServices/green-service
          weight: 95
        - backendService: regions/us-west1/backendServices/blue-service
          weight: 5

gcloud compute url-maps import コマンドを使用して、URL マップを更新します。

gcloud compute url-maps import regional-lb-map \
   --region=us-west1 \
   --source=regional-lb-map-config.yaml

構成のテスト

構成をテストするには、まず、以前に設定したロードバランサの IP アドレスへのリクエストがデフォルトの red 構成で処理されることを確認します。

次に、FORWARDING_RULE_IP_ADDRESS/PREFIX に送信されたリクエストが想定どおりに分割されることを確認します。

クライアント VM を作成する

手順については、ゾーンで VM インスタンスを作成して接続をテストするをご覧ください。

`FORWARDING_RULE_IP_ADDRESS` にリクエストを送信する

ssh を使用してクライアントに接続します。

gcloud compute ssh global-lb-client-us-west1-a \
   --zone=us-west1-a

次のコマンドを実行します。

for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
   RESULTS=
   for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}`"; done >/dev/null 2>&1
   IFS=':'
   echo "***"
   echo "*** Results of load balancing to $LB_IP: "
   echo "***"
   for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
   echo
done

結果を確認する

***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

`FORWARDING_RULE_IP_ADDRESS/PREFIX` にリクエストを送信する

FORWARDING_RULE_IP_ADDRESS/PREFIX にリクエストを送信して、トラフィック分割を確認します。

for LB_IP in FORWARDING_RULE_IP_ADDRESS; do
    RESULTS=
    for i in {1..1000}; do RESULTS="$RESULTS:`curl ${LB_IP}/PREFIX/index.html`"; done >/dev/null 2>&1
    IFS=':'
    echo "***"
    echo "*** Results of load balancing to $LB_IP/PREFIX: "
    echo "***"
    for line in $RESULTS; do echo $line; done | grep -Ev "^$" | sort | uniq -c
    echo
done

結果を確認する

***
***Results of load balancing to FORWARDING_RULE_IP_ADDRESS/PREFIX:
***
21 blue-instance-group-8n49
27 blue-instance-group-vlqc
476 green-instance-group-c0wv
476 green-instance-group-rmf4

このカナリアの設定では、/PREFIX リクエストの 95% が green のサービスに、5% が blue のサービスにそれぞれ正しく送信されています。

`HTTP_COOKIE` に基づいてセッションアフィニティを設定する

トラフィック制御では、提供された Cookie に基づいてセッションアフィニティを構成できます。red-service というバックエンドサービスのために HTTP_COOKIE ベースのセッションアフィニティを構成するには、次に示す手順を行ってください。

gcloud compute backend-services export コマンドを使用してバックエンドサービスの構成を取得します。
```
gcloud compute backend-services export red-service \
    --destination=red-service-config.yaml \
    --region=us-west1
```

次のように red-service-config.yaml ファイルを更新します。

sessionAffinity: 'HTTP_COOKIE'
localityLbPolicy: 'RING_HASH'
consistentHash:
 httpCookie:
  name: 'http_cookie'
  path: '/cookie_path'
  ttl:
    seconds: 100
    nanos: 500000000
 minimumRingSize: 10000

red-service-config.yaml ファイルで次の行を削除します。
```
sessionAffinity: NONE
```

このバックエンドサービス構成ファイルを更新します。

gcloud compute backend-services import red-service \
    --source=red-service-config.yaml \
    --region=us-west1

トラブルシューティング

構成したルートルールとトラフィックポリシーに従ってトラフィックがルーティングされない場合は、次に示す情報を使用してトラブルシューティングを行ってください。

ロギングとモニタリングについては、内部 HTTP(S) のロギングとモニタリングをご覧ください。

症状:

ルールの上位にあるサービスへのトラフィックが増加した。
指定されたルートルールに対する 4xx および 5xx HTTP レスポンスが予期しない増加を示した。

解決策: ルートルールの順序を確認する。ルートルールは、指定された順序で解釈される。

URL マップ内のルートルールは、指定された順序で解釈されます。これは、パスルールが解釈される方法（最長一致法）とは異なります。パスルールの場合は、内部アプリケーションロードバランサで単一パスルールのみが選択されます。しかし、ルートルールを使用する場合は、複数のルートルールが適用される可能性があります。

ルートルールを定義するときは、リストの先頭のルールによって、後続のルートルールがルーティングするトラフィックが誤ってルーティングされないように注意します。誤って転送されたトラフィックをサービスが受信するとリクエストが拒否されるため、ルートルールのトラフィックが受信するトラフィックが減少するかまったく受信しなくなります。

次のステップ

ロードバランサの設定をクリーンアップする。

内部アプリケーション ロードバランサのトラフィック管理を設定する

始める前に

トラフィック管理の構成

Google Cloud コンソールで YAML のサンプルにアクセスする

1 つのサービスへのトラフィックのマッピング

2 つのサービス間でのトラフィックの分割

URL のリダイレクトの構成

トラフィックのミラーリング

リクエストされた URL の書き換え

リクエストの再試行

ルート タイムアウトの指定

フォールト インジェクションの構成

CORS の構成

リクエスト ヘッダーとレスポンス ヘッダーの追加と削除

外れ値検出を構成する

サーキット ブレーカーの構成

トラフィック分割の設定: 詳細な手順

サービスを定義する

サービスを作成する

URL マップの作成

gcloud

構成のテスト

クライアント VM を作成する

FORWARDING_RULE_IP_ADDRESS にリクエストを送信する

結果を確認する

FORWARDING_RULE_IP_ADDRESS/PREFIX にリクエストを送信する

結果を確認する

HTTP_COOKIE に基づいてセッション アフィニティを設定する

トラブルシューティング

次のステップ

内部アプリケーションロードバランサのトラフィック管理を設定する

ルートタイムアウトの指定

フォールトインジェクションの構成

リクエストヘッダーとレスポンスヘッダーの追加と削除

サーキットブレーカーの構成

`FORWARDING_RULE_IP_ADDRESS` にリクエストを送信する

`FORWARDING_RULE_IP_ADDRESS/PREFIX` にリクエストを送信する

`HTTP_COOKIE` に基づいてセッションアフィニティを設定する