このドキュメントで説明するトラフィック管理の使用例は、特定のユースケースのものです。他にもさまざまなユースケースが考えられます。
このドキュメントでは、次のロードバランサの例を示します。
- リージョン外部アプリケーション ロードバランサ
- リージョン内部アプリケーション ロードバランサ
- クロスリージョン内部アプリケーション ロードバランサ
リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサリージョン ロードバランサのトラフィック管理構成については、リージョン URL マップ API とリージョン バックエンド サービス API のドキュメントをご覧ください。フィールドの完全なリストや、関係、制限、カーディナリティに関するセマンティクスを確認できます。
2 つのロードバランサの違いはロード バランシングのスキームだけです。
- リージョン外部アプリケーション ロードバランサは
EXTERNAL_MANAGEDを使用します。 - リージョン内部のアプリケーション ロードバランサでは、
INTERNAL_MANAGEDを使用します。
リージョン内部アプリケーション ロードバランサとクロスリージョン内部アプリケーション ロードバランサトラフィック管理の構成:
リージョン内部アプリケーション ロードバランサは、リージョン URL マップ API を使用します。リージョン バックエンド サービス API のドキュメントには、フィールドの完全なリストと、関係、制限、カーディナリティに関するセマンティクスなどが記載されています。
クロスリージョン内部アプリケーション ロードバランサはグローバル URL マップ API を使用します。グローバル バックエンド サービス API のドキュメントにはフィールドの完全なリストと、関係、制限、カーディナリティに関するセマンティクスが記載されています。
このページで説明する高度なルーティング機能に加えて、サポートされているアプリケーション ロードバランサは Service Extensions と統合されているため、ロード バランシング データパスにカスタム ロジックを挿入できます。
始める前に
トラフィック管理の仕組みについて理解する必要があります。詳細については、リージョン外部アプリケーション ロードバランサのトラフィック管理の概要をご覧ください。
トラフィック管理の構成
選択した構成環境で、YAML 構成を使用してトラフィック管理を設定します。URL マップとバックエンド サービスにはそれぞれ独自の YAML ファイルがあります。必要な機能に応じて、URL マップの YAML、バックエンド サービスの YAML、またはその両方を記述する必要があります。
これらの YAML ファイルの作成方法については、このページの例と Cloud Load Balancing API ドキュメントをご覧ください。
Google Cloud コンソールはサポートされていません。リージョン内部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサの場合は、リージョン URL マップ API とリージョン バックエンド サービス API のドキュメントをご覧ください。関係、制限、カーディナリティに関するセマンティクスなどが記載されています。
1 つのサービスへのトラフィックのマッピング
すべてのトラフィックを 1 つのサービスに送信します。プレースホルダを置き換えてください。
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
2 つのサービス間でのトラフィックの分割
2 つ以上のサービス間でトラフィックを分割します。プレースホルダを置き換えてください。
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
name: URL_MAP_NAME
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 2
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 95
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
weight: 5
URL のリダイレクトの構成
次のサンプルでは、構成可能な 3xx レスポンス コードが返されます。また、このサンプルでは、Location レスポンス ヘッダーに適切な URI を設定し、リダイレクト アクションで指定されたホストとパスを置き換えます。
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: URL_MAP_NAME
hostRules:
- hosts:
- "HOST TO REDIRECT FROM" # Use * for all hosts
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
defaultUrlRedirect:
hostRedirect: "HOST TO REDIRECT TO" # Omit to keep the requested host
pathRedirect: "PATH TO REDIRECT TO" # Omit to keep the requested path
redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
stripQuery: True
トラフィックのミラーリング
選択されたバックエンド サービスにリクエストを転送するだけでなく、構成されたミラー バックエンド サービスに「ファイア アンド フォーゲット」方式で同じリクエストを送信します。つまり、ロードバランサは、ミラーリングされたリクエストを送信するバックエンドからのレスポンスを待ちません。リクエスト ミラーリングは、バックエンド サービスの新しいバージョンをテストする際に利用できます。また、本番環境バージョンではなくバックエンド サービスのデバッグ環境バージョンで本番環境のエラーをデバッグすることもできます。
デフォルトでは、元のトラフィックが複数の重み付けされたバックエンド サービス間で分割されている場合でも、ミラーリングされたバックエンド サービスはすべてのリクエストを受信します。オプションの mirrorPercent フラグを使用して、ミラーリングされるリクエストの割合を 0 ～ 100.0 の値で指定することで、リクエストの割合のみを受信するようにミラーリングされたバックエンド サービスを構成できます。割合ベースのリクエスト ミラーリングはプレビュー版です。
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: 1
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
requestMirrorPolicy:
backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_2
mirrorPercent: 50.0
トラフィック ミラーリングを使用する場合は、次の制限事項に注意してください。
- トラフィック ミラーリングは、両方のバックエンド サービスにマネージド インスタンス グループ、ゾーン NEG、またはハイブリッド NEG のバックエンドがある場合にサポートされます。インターネット NEG、サーバーレス NEG、Private Service Connect のバックエンドではサポートされていません。
- ミラーリングされたバックエンド サービスへのリクエストでは、Cloud Logging と Cloud Monitoring のログや指標は生成されません。
リクエストされた URL の書き換え
選択したバックエンド サービスにリクエストを送信する前に、URL のホスト名部分、URL のパス部分、またはその両方を書き換えます。プレースホルダを置き換えてください。
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
retryPolicy:
retryConditions: 502, 504
numRetries: 3
perTryTimeout:
seconds: 1
nanos: 500000000
ルート タイムアウトの指定
選択したルートのタイムアウトを指定します。リクエストが完全に処理されてからレスポンスが完全に処理されるまでのタイムアウトが計算されます。タイムアウトにはすべての再試行が含まれます。プレースホルダを置き換えてください。
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
weight: 100
timeout:
seconds: 30
nanos: 500000000
フォールト インジェクションの構成
高レイテンシ、サービス過負荷、サービス障害、ネットワーク パーティショニングなどの障害をシミュレートするリクエストを処理する際にエラーを発生させます。この機能は、サービスの復元力を疑似的にテストするために利用できます。
defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: regional-lb-map
region: region/REGION
hostRules:
- hosts:
- '*'
pathMatcher: matcher1
pathMatchers:
- defaultService: projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE_1
name: matcher1
routeRules:
- matchRules:
- prefixMatch: /PREFIX
priority: PRIORITY # 0 is highest
routeAction:
weightedBackendServices:
- backendService: projects/PROJECT_ID/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: projects/PROJECT_ID/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: projects/PROJECT_ID/regions/us-west1/backendServices/red-service name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: /PREFIX routeAction: weightedBackendServices: - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/green-service weight: 95 - backendService: projects/PROJECT_ID/regions/us-west1/backendServices/blue-service weight: 5gcloud 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 に送信されたリクエストが想定どおりに分割されることを確認します。
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: 10000red-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 マップ内のルートルールは、指定された順序で解釈されます。これは、パスルールが解釈される方法（最長一致法）とは異なります。パスルールの場合は、内部アプリケーション ロードバランサで単一パスルールのみが選択されます。しかし、ルートルールを使用する場合は、複数のルートルールが適用される可能性があります。
ルートルールを定義するときは、リストの先頭のルールによって、後続のルートルールがルーティングするトラフィックが誤ってルーティングされないように注意します。誤って転送されたトラフィックをサービスが受信するとリクエストが拒否されるため、ルートルールのトラフィックが受信するトラフィックが減少するかまったく受信しなくなります。