このガイドでは、内部 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) 負荷分散で単一パスルールのみが選択されます。しかし、ルートルールを使用する場合は、複数のルートルールが適用される可能性があります。
ルートルールを定義するときは、リストの先頭のルールによって、後続のルートルールがルーティングするトラフィックが誤ってルーティングされないように注意します。誤って転送されたトラフィックをサービスが受信するとリクエストが拒否されるため、ルートルールのトラフィックが受信するトラフィックが減少するかまったく受信しなくなります。