内部 HTTP(S) ロードバランサのトラフィック管理の設定

このガイドでは、内部 HTTP(S) 負荷分散のトラフィック管理の設定例を示します。このドキュメントで紹介するトラフィック管理の使用例は、特定のユースケースのものです。他にもさまざまなユースケースが考えられます。

始める前に

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

トラフィック管理の構成

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

これらの YAML ファイルの作成方法については、次のリソースをご覧ください。

リージョン URL マップ API ドキュメントとリージョンバックエンドサービス API ドキュメント

フィールドの完全なリストを提供します。関係、制限、カーディナリティに関するセマンティクスなども確認できます。
このページの例
Cloud Console の例

Cloud Console での YAML サンプルへのアクセス

Cloud Console で YAML のサンプルにアクセスするには:

Google Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動
[HTTP(S) 負荷分散] で [設定を開始] をクリックします。
[VM 間のみ] を選択します。この設定は、ロードバランサが内部であることを意味します。
[続行] をクリックします。
ルーティングルールの構成で、[詳細なホスト、パス、ルートのルール] を選択します。
[Add hosts and path matcher] をクリックします。
[コードガイダンス] のリンクをクリックします。

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

URL マップの YAML の例

URL マップで許可されている 1 つの URL

1 つのサービス

すべてのトラフィックを 1 つのサービスに送信します。[] でマークされた変数を置き換えます。

defaultService: regions/[region]/backendServices/[backend-service1]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: [url-map-name]
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100

トラフィックの分割

複数のサービスへトラフィックを分割します。[] でマークされた変数を置き換えます。

defaultService: regions/[region]/backendServices/[backend-service1]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
name: [url-map-name]
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /prefix
    priority: 2
    routeAction:
      weightedBackendServices:
      - backendService: regions/[region]/backendServices/[backend-service1]
        weight: 95
      - backendService: regions/[region]/backendServices/[backend-service2]
        weight: 5

URL のリダイレクト

構成可能な 3xx レスポンスコードが返されます。Location レスポンスヘッダーに適切な URI を設定すると、リダイレクトアクションで指定されたホストとパスが置き換わります。[] でマークされた変数を置き換えます。

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      urlRedirect:
        hostRedirect: [REDIRECT_HOST]
        pathRedirect: [REDIRECT_PATH]
        redirectResponseCode: FOUND
        stripQuery: True

URL マップで許可されている複数の URL

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

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        requestMirrorPolicy:
          backendService: regions/[region]/backendServices/[backend-service2]

URL の書き換え

選択したバックエンドサービスにリクエストを送信する前に、URL のホスト名部分、URL のパス部分、またはその両方を書き換えます。[] でマークされた変数を置き換えます。

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        urlRewrite:
          hostRewrite: [REWRITE_HOST]
          pathPrefixRewrite: [REWRITE_PATH]

リクエストの再試行

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        retryPolicy:
          retryConditions: 502, 504
          numRetries: 3
          perTryTimeout:
            seconds: 1
            nanos: 50

タイムアウト

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        timeout:
          seconds: 30
          nanos: 100

フォールト

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        faultInjectionPolicy:
          delay:
            fixedDelay:
              seconds: 10
              nanos: 20
            percentage: 25
          abort:
            httpStatus: 503
            percentage: 50

CORS

Cross-Origin Resource Sharing（CORS）ポリシーを構成して、CORS リクエストを適用するための内部 HTTP(S) 負荷分散設定を処理します。[] でマークされた変数を置き換えます。

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      routeAction:
        weightedBackendServices:
          - backendService: regions/[region]/backendServices/[backend-service1]
            weight: 100
        corsPolicy:
            allowOrigins: my-domain.com
            allowMethods: GET, POST
            allowHeaders: Authorization, Content-Type
            maxAge: 1200
            allowCredentials: True

ヘッダー

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

defaultService: regions/[region]/backendServices/[backend-service1]
kind: compute#urlMap
name: l7-ilb-map
region: region/[region]
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: regions/[region]/backendServices/[backend-service1]
  name: matcher1
  routeRules:
    - matchRules:
        - prefixMatch: /
      priority: [priority]
      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

バックエンドサービスの YAML の例

外れ値検出

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

kind: compute#backendService
loadBalancingScheme: INTERNAL_MANAGED
localityLbPolicy: RANDOM
name: regions/[region]/backendServices/[backend-service1]
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]

回路遮断

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

接続あたりのリクエスト数と、バックエンドサービスへの接続量に上限を設定します。また、保留中のリクエストと再試行の数も制限します。[] でマークされた変数を置き換えます。

kind: compute#backendService
loadBalancingScheme: 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 である。
l7-ilb-map という URL マップとともに、ターゲットプロキシと転送ルールが作成される。
転送ルールのアドレスは 10.1.2.99 である。

Compute Engine VM の内部 HTTP(S) 負荷分散の設定の手順をご覧ください。
URL マップによって、すべてのトラフィックがデフォルトのバックエンドサービスである red-service というバックエンドサービスに送信される。
トラフィックの 5% を blue-service、95% を green-service に送信する代替パスを設定している。
パスマッチャーが使用されている。
Cloud Shell（または bash がインストールされているその他の環境）を使用している。

サービスの定義

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

ここでは、HTTP ヘルスチェック（l7-ilb-basic-check）が作成されていることが前提です。Compute Engine VM に対する内部 HTTP(S) 負荷分散の設定の手順をご覧ください。

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-9 \
    --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=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-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 マップの作成

Console

Google Cloud Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動
l7-ilb-map のリンクをクリックします。
[編集] をクリックします。

新しいルーティングルールの構成

[ルーティングルール] で [詳細なホスト、パス、ルートのルール] を選択します。
[新しいホストとパスのマッチャー] で [サービス] を red-service に設定してデフォルトのアクションを作成します。
[完了] をクリックします。
[Add hosts and path matcher] をクリックします。
[ホスト] フィールドに 10.1.2.99 と入力します。これは、ロードバランサの転送ルールの IP アドレスです。

次の YAML コンテンツを [パスマッチャー] ボックスに貼り付け、[PROJECT_ID] をプロジェクト ID に置き換えます。

defaultService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/red-service
name: matcher1
routeRules:
- priority: 2
  matchRules:
    - prefixMatch: /prefix
  routeAction:
    weightedBackendServices:
      - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/green-service
        weight: 95
      - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/blue-service
        weight: 5

[完了] をクリックします。
[更新] をクリックします。

gcloud

gcloud compute url-maps export コマンドを使用して、既存の URL マップをエクスポートします。
```
gcloud compute url-maps export l7-ilb-map \
  --destination=l7-ilb-map-config.yaml \
  --region=us-west1
```

これをファイルの末尾に追加して、URL マップファイル l7-ilb-map-config.yaml を更新します。[PROJECT_ID] はプロジェクト ID に置き換えてください。

hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/red-service
  name: matcher1
  routeRules:
  - priority: 2
    matchRules:
      - prefixMatch: /prefix
    routeAction:
      weightedBackendServices:
        - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/green-service
          weight: 95
        - backendService: https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/blue-service
          weight: 5

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

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

構成のテスト

構成をテストするには、最初に 10.1.2.99/（前に設定されたロードバランサの IP アドレス）へのリクエストがデフォルトの red 構成によって処理されることを確認します。

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

クライアント VM の作成

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

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

クライアントに SSH 接続します。

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

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

for LB_IP in 10.1.2.99; 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 10.1.2.99:
***
502 red-instance-group-9jvq
498 red-instance-group-sww8

`10.1.2.99/prefix` にリクエストを送信する

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

for LB_IP in 10.1.2.99; 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 10.1.2.99/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 ベースのセッションアフィニティを構成するには、次に示す手順を行ってください。

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: 30
 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 マップ内のルートルールは、指定された順序で解釈されます。これは、パスルールが解釈される方法（最長一致法）とは異なります。パスルールの場合は、内部 HTTP(S) 負荷分散で単一パスルールのみが選択されます。しかし、ルートルールを使用する場合は、複数のルートルールが適用される可能性があります。

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

次のステップ

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

内部 HTTP(S) ロードバランサのトラフィック管理の設定

始める前に

トラフィック管理の構成

Cloud Console での YAML サンプルへのアクセス

URL マップの YAML の例

URL マップで許可されている 1 つの URL

1 つのサービス

トラフィックの分割

URL のリダイレクト

URL マップで許可されている複数の URL

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

URL の書き換え

リクエストの再試行

タイムアウト

フォールト

CORS

ヘッダー

バックエンド サービスの YAML の例

外れ値検出

回路遮断

トラフィック分割の設定

サービスの定義

サービスの作成

URL マップの作成

Console

新しいルーティング ルールの構成

gcloud

構成のテスト

クライアント VM の作成

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

結果の確認

10.1.2.99/prefix にリクエストを送信する

結果の確認

HTTP_COOKIE に基づいたセッション アフィニティの設定

トラブルシューティング

次のステップ

バックエンドサービスの YAML の例

新しいルーティングルールの構成

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

`10.1.2.99/prefix` にリクエストを送信する

`HTTP_COOKIE` に基づいたセッションアフィニティの設定