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

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

始める前に

トラフィック管理の構成

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

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

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

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

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

[パスマッチャーの 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]

トラフィック分割の設定

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

  1. サービスごとに異なるテンプレートを作成します。

  2. テンプレートのインスタンス グループを作成します。

  3. 95% / 5% のトラフィック分割を設定するルーティング ルールを作成します。

  4. 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")
}

サービスの作成

この関数を呼び出して、redgreenblue という 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

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

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

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

  8. [更新] をクリックします。

gcloud

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

    gcloud compute url-maps export l7-ilb-map \
      --destination=l7-ilb-map-config.yaml \
      --region=us-west1
    
  2. これをファイルの末尾に追加して、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
    
  3. 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 のサービスにそれぞれ正しく送信されています。

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

HTTP_COOKIE を使用してセッション アフィニティを構成するには、次の手順を行います。

  1. gcloud compute backend_services export コマンドを使用してバックエンド サービスの構成を取得します。

    gcloud compute backend-services export red-service \
        --destination=red-service-config.yaml \
        --region=us-west1
    
  2. 次のように 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
    
  3. red-service-config.yaml ファイルの次の行を削除します。

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

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

トラブルシューティング

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

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

症状:

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

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

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

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