このページは Apigee と Apigee ハイブリッドに適用されます。
Apigee Edge ドキュメントを表示する
Apigee は、複数のバックエンド サーバー インスタンスにわたる負荷分散とフェイルオーバーの組み込みサポートを提供することで API の可用性を高めています。
TargetServer により、具体的なエンドポイント URL が TargetEndpoint 構成から切り離されています。その構成で具体的な URL を定義する代わりに、1 つ以上の名前付き TargetServer を構成できます。つまり、各 TargetServer は、TargetEndpoint HTTPConnection では名前によって参照されます。
動画
ターゲット サーバーを使用した API ルーティングと負荷分散に関する詳細は、次の動画をご覧ください。
動画 | 説明 |
---|---|
ターゲット サーバーを使用した負荷分散 | 複数のターゲット サーバーにわたる負荷分散 API。 |
ターゲット サーバーを使用した環境に基づく API ルーティング | 環境に基づいて API を異なるターゲット サーバーにルーティングする。 |
TargetServer 構成について
TargetServer 構成は、名前、ホスト、プロトコル、ポートで構成され、TargetServer が有効か無効かを示す追加要素を含みます。
次のコードは、TargetServer 構成の例を示しています。
{ "name": "target1", "host": "1.mybackendservice.com", "protocol": "http", "port": "80", "isEnabled": "true" }
TargetServers API の詳細については、organizations.environments.targetservers をご覧ください。
GitHub で TargetServer と他のエンティティに対するスキーマをご覧ください。
TargetServer の作成
以下のセクションで説明するように、Apigee UI または API を使用して TargetServer を作成します。
Cloud コンソールの Apigee
Cloud コンソールの Apigee を使用して TargetServer を作成するには:
- Cloud コンソールの Apigee UI にログインします。
- [管理] > [環境] > [TargetServers] を選択します。
- 新しい TargetServer を定義する環境を選択します。
- ペインの上部にある [Target Servers] をクリックします。
- [+ Create Target Server] をクリックします。
表示されたフィールドに、名前、ホスト、プロトコル、ポートを入力します。[Protocol] のオプションは、[HTTP](REST ベースのターゲット サーバー用)、[gRPC - Target](gRPC ベースのターゲット サーバー用)、または [gRPC - External callout] です。gRPC プロキシのサポートについては、gRPC API プロキシを作成するをご覧ください。
必要に応じて、[SSL を有効にする] を選択できます。SSL 証明書の概要をご覧ください。
- [作成] をクリックします。
従来の Apigee
従来の Apigee UI を使用して TargetServer を作成するには:
- Apigee UI にログインします。
- [Admin] > [Environments] > [TargetServers] を選択します。
- [Environment] プルダウン リストから、新しい TargetServer を定義する環境を選択します。
Apigee UI に、選択した環境の現在の TargetServer のリストが表示されます。
- [+Target server] をクリックして、選択した環境に新しい TargetServer を追加します。
[Add target server] ダイアログ ボックスが表示されます。
- [Enabled] をオンにすると、新しい TargetServer の定義の作成後に、すぐに定義が有効になります。
表示されたフィールドに、名前、ホスト、プロトコル、ポートを入力します。[Protocol] のオプションは、HTTP または GRPC です。
必要に応じて、[SSL] チェックボックスをオンできます。これらのフィールドの詳細については、TargetServers(4MV4D 動画)をご覧ください。
- [Add] をクリックします。
Apigee によって新しい TargetServer 定義が作成されます。
- 新しい TargetServer を作成した後、API プロキシを編集して、新しい定義を参照するように
<HTTPTargetConnection>
要素を変更できます。
Apigee API
以下のセクションでは、Apigee API を使用して TargetServer を作成し、一覧表示する例を示します。
詳細については、TargetServers API をご覧ください。
API を使用して環境に TargetServer を作成する
ポート 80
の 1.mybackendservice.com
に接続する target1
という名前の TargetServer を作成するには、次の API 呼び出しを使用します。
curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \ -X POST \ -H "Content-Type:application/json" \ -H "Authorization: Bearer $TOKEN" \ -d ' { "name": "target1", "host": "1.mybackendservice.com", "protocol": "http", "port": "80", "isEnabled": "true", }'
ここで、OAuth 2.0 アクセス トークンの取得で説明されているように、$TOKEN
は OAuth 2.0 アクセス トークンに設定されます。この例で使用されている curl
オプションの詳細については、curl の使用をご覧ください。使用される環境変数の説明については、Apigee API リクエストの環境変数の設定をご覧ください。
レスポンスの例を次に示します。
{ "host" : "1.mybackendservice.com", "protocol": "http", "isEnabled" : true, "name" : "target1", "port" : 80 }
次の API 呼び出しを使用して、2 つ目の TargetServer を作成します。2 つの TargetServer を定義して、TargetEndpoint が負荷分散用に使用できる URL を 2 つ指定します。
curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \ -X POST \ -H "Content-Type:application/json" \ -H "Authorization: Bearer $TOKEN" \ -d ' { "name": "target2", "host": "2.mybackendservice.com", "protocol": "http", "port": "80", "isEnabled": "true", }'
レスポンスの例を次に示します。
{ "host" : "2.mybackendservice.com", "protocol": "http", "isEnabled" : true, "name" : "target2", "port" : 80 }
API を使用して環境の TargetServer を一覧表示する
環境の TargetServer を一覧表示するには、次の API 呼び出しを使用します。
curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \ -H "Authorization: Bearer $TOKEN"
レスポンスの例を次に示します。
[ "target2", "target1" ]
これで、test
環境にデプロイされた API プロキシで 2 つの TargetServer を利用できるようになりました。これらの TargetServer 間でトラフィックを負荷分散するには、その TargetServer を使用するように API プロキシのターゲット エンドポイントで HTTP 接続を構成します。
名前付き TargetServer 間で負荷分散するように TargetEndpoint を構成する
ここまでで、2 つの TargetServer を利用できるようになりました。その 2 つの TargetServer を名前で参照するように、TargetEndpoint HTTP 接続設定を次のように変更できます。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
上の構成は、最も基本的な負荷分散構成です。ロードバランサは、ラウンドロビン、重み付け、最小接続の 3 つの負荷分散アルゴリズムをサポートしています。デフォルトのアルゴリズムはラウンドロビンです。上の構成ではアルゴリズムが指定されていないため、API プロキシからバックエンド サーバーへの送信リクエストは target1
と target2
に対し交互に送信されます。
<Path>
要素は、すべての TargetServer の TargetEndpoint URI のベースパスを形成します。<LoadBalancer>
が使用されるときのみ使用されます。それ以外では、無視されます。上の例では、target1
に到達するリクエストは http://target1/test
となり、他の TargetServer に対する場合も同様の形になります。
ロードバランサのオプションの構成
以下のセクションで説明するように、ロードバランサと TargetServer のレベルで負荷分散とフェイルオーバーのオプションを構成することで、可用性を調整できます。
アルゴリズム
<LoadBalancer>
で使用されるアルゴリズムを設定します。使用可能なアルゴリズムには RoundRobin
、Weighted
、LeastConnections
があります。それぞれについて以下で説明します。
ラウンドロビン
デフォルトのアルゴリズムであるラウンドロビンでは、ターゲット エンドポイントの HTTP 接続に記載されているサーバーの順にリクエストが各 TargetServer に転送されます。次に例を示します。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
重み付け
重み付け負荷分散アルゴリズムを使用すると、TargetServer に対してトラフィック負荷の比率を構成できます。重み付け LoadBalancer は、各 TargetServer の重み付けに正比例にしてリクエストを TargetServer に分配します。したがって、重み付けアルゴリズムでは、各 TargetServer に weight
属性を設定する必要があります。次に例を示します。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>Weighted</Algorithm> <Server name="target1"> <Weight>1</Weight> </Server> <Server name="target2"> <Weight>2</Weight> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
この例では、target1
に 1 つのリクエストが転送されるたびに、2 つのリクエストが target2
に転送されます。
最小接続
最小接続数アルゴリズムを使用するように構成されている LoadBalancer は、開いている HTTP 接続数が最も少ない TargetServer に送信リクエストを転送します。次に例を示します。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>LeastConnections</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> </HTTPTargetConnection> <Path>/test</Path> </TargetEndpoint>
最大失敗数
API プロキシから TargetServer へのリクエストの最大エラー数で、この数値により、リクエストは別の TargetServer にリダイレクトされることになります。
レスポンスのエラーとは、Apigee が TargetServer からのレスポンスを 1 つも受信していないことを意味します。この状況が発生した場合、エラーカウンタが 1 つ増えます。
ただし、Apigee がターゲットからレスポンスを受信すると、そのレスポンスが HTTP エラー(500
など)であっても TargetServer からのレスポンスとしてカウントされ、エラーカウンタはリセットされます。できる限り早く異常なサーバーをロード バランシングのローテーションから除外するため、不正な HTTP レスポンス(500
など)もエラーとしてカウントさせたい場合は、<ResponseCode>
子要素を含む <ServerUnhealthyResponse>
要素をロードバランサの構成に加えます。Apigee は、これらのコードを含むレスポンスも失敗としてカウントするようになります。
次の例では、リクエスト(TargetServer からの 5XX
レスポンスを含む)が 5 回エラーになると、target1
がローテーションから除外されます。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> <ServerUnhealthyResponse> <ResponseCode>500</ResponseCode> <ResponseCode>502</ResponseCode> <ResponseCode>503</ResponseCode> </ServerUnhealthyResponse> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
MaxFailures のデフォルト値は 0 です。これは、Apigee は各リクエストのためにターゲットへの接続を常に試み、TargetServer をローテーションから除外しないことを意味します。
HealthMonitor では MaxFailures が 0 より大きいものを使用することをおすすめします。MaxFailures に 0 より大きい値を構成した場合、ターゲットが指定された回数エラーになると、TargetServer はローテーションから除外されます。HealthMonitor を設定すると、その HealthMonitor の構成に従い、ターゲットが再起動した後、Apigee が自動的に TargetServer をローテーションに戻します。詳細については、ヘルス モニタリングをご覧ください。
また、MaxFailures に 0 より大きい値を構成して、HealthMonitor を構成しない場合、Apigee がエラーを検出したあと、Apigee よって TargetServer は自動的にはローテーションに組み込まれません。この場合、Apigee によって TargetServer がローテーションに戻される前に、API プロキシを再デプロイする必要があります。API プロキシのデプロイをご覧ください。
再試行
再試行が有効になっている場合、レスポンスのエラー(I/O エラーまたは HTTP タイムアウト)が発生したとき、またはレスポンスが <ServerUnhealthyResponse>
で設定された値と一致するたびにリクエストが再試行されます。<ServerUnhealthyResponse>
の設定に関する詳細は、前述の最大エラー数をご覧ください。
デフォルトでは <RetryEnabled>
は true
に設定されています。再試行を無効にするには、false
に設定します。次に例を示します。
<RetryEnabled>false</RetryEnabled>
IsFallback
TargetServer の 1 つ(だけ)は「フォールバック」サーバーとして設定できます。フォールバック TargetServer は、ロードバランサが他のすべての TargetServer を使用不可と判定するまでは、負荷分散のルーティンに組み込まれません。ロードバランサがすべての TargetServer を使用不可であると判定すると、すべてのトラフィックはフォールバック サーバーに転送されます。次に例を示します。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <Server name="target3"> <IsFallback>true</IsFallback> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
上記の構成では、target1
と target2
の両方が使用不可になるまでは、target1
と target2
の間でラウンドロビンでロードバランスされます。target1
と target2
が使用不可になった場合、すべてのトラフィックは target3
にルーティングされます。
パス
パスは、TargetServer がバックエンド サーバーに発行するすべてのリクエストに付加される URI フラグメントを定義します。
この要素は、リテラル文字列のパスまたはメッセージ テンプレートを受け付けます。メッセージ テンプレートを使用すると、変数文字列をランタイム時に置き換えることができます。たとえば、次のターゲット エンドポイントの定義では、{mypath}
の値がパスに使用されています。
<HTTPTargetConnection> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <LoadBalancer> <Server name="testserver"/> </LoadBalancer> <Path>{mypath}</Path> </HTTPTargetConnection>
TLS / SSL 用の TargetServer の構成
TargetServer を使用してバックエンド サービスを定義していて、そのバックエンド サービスで HTTPS プロトコルを使用する接続が必要な場合は、TargetServer 定義で TLS / SSL を有効にする必要があります。これが必要になるのは、host
タグでは接続プロトコルを指定できないためです。次の例は、Apigee がバックエンド サービスへの HTTPS リクエストを行う一方向 TLS / SSL の TargetServer 定義を示しています。
{ "name": "target1", "host": "mocktarget.apigee.net", "protocol": "http", "port": "443", "isEnabled": "true", "sSLInfo": { "enabled": "true" } }
バックエンド サービスで双方向つまり相互の TLS / SSL が必要な場合は、TargetEndpoints と同じ TLS / SSL 構成設定を使用して TargetServer を構成します。
{ "name": "TargetServer 1", "host": "www.example.com", "protocol": "http", "port": "443", "isEnabled": "true", "sSLInfo": { "enabled": "true", "clientAuthEnabled": "true", "keyStore": "keystore-name", "keyAlias": "keystore-alias", "trustStore": "truststore-name", "ignoreValidationErrors": "false", "ciphers": [] } }
API 呼び出しを使用して SSL で TargetServer を作成するには:
curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \ -X POST \ -H "Content-Type:application/json" \ -H "Authorization: Bearer $TOKEN" \ -d ' { "name": "TargetServer 1", "host": "www.example.com", "protocol": "http", "port": 443, "isEnabled": true, "sSLInfo": { "enabled":true, "clientAuthEnabled":true, "keyStore":"keystore-name", "keyAlias":"keystore-alias", "ciphers":[], "protocols":[], "clientAuthEnabled":true, "ignoreValidationErrors":false, "trustStore":"truststore-name" } }'
稼働状況のモニタリング
稼働状況のモニタリングを使用すると、TargetServer 構成で定義されているバックエンド サービス URL を能動的にポーリングすることによってロード バランシング構成を強化できます。ヘルス モニタリングが有効な場合、到達不能な TargetServer またはエラー レスポンスを返す TargetServer は異常としてマークされます。正常に動作しなかった TargetServer は、その TargetServer が正常であると HealthMonitor により判定されたとき自動的にローテーションに戻されます。プロキシを再デプロイする必要はありません。
HealthMonitor は、TCP または HTTP 経由でバックエンド サービスを呼び出す単純なクライアントとして動作します。
- TCP クライアントはソケットが確実に開くようにします。
- 有効な HTTP リクエストをバックエンド サービスに送信するように HTTP クライアントを構成します。HTTP
GET
、PUT
、POST
、DELETE
オペレーションを定義できます。HTTP モニタリング呼び出しのレスポンスは、<SuccessResponse>
ブロックに構成された設定と一致する必要があります。
成功と失敗
稼働状況のモニタリングを有効にすると、Apigee によってターゲット サーバーにヘルスチェックの送信が開始されます。ヘルスチェックは、TargetServer に送信されたリクエストで、TargetServer が正常であるかどうかを判別します。
ヘルスチェックでは、次の 2 つの結果いずれかが得られます。
- 成功: ヘルスチェックが成功した場合、TargetServer は正常と見なされます。これは通常、次の中のいずれか 1 つ以上の結果になります。
- TargetServer は、指定されたポートへの新しい接続を受け入れ、そのポートのリクエストに応答し、指定された期間内にポートを閉じる。TargetServer からのレスポンスには
Connection: close
が含まれる。 - TargetServer は、ヘルスチェック リクエストに対して、
200 (OK)
やその他の HTTP ステータス コード(受け入れ可能と判断する)で応答している。 - TargetServer は、ヘルスチェック リクエストに対して、期待されるメッセージ本文と一致するメッセージ本文で応答している。
サーバーが正常であると Apigee が判断した場合は、そのサーバーへのリクエスト送信を続行または再開します。
- TargetServer は、指定されたポートへの新しい接続を受け入れ、そのポートのリクエストに応答し、指定された期間内にポートを閉じる。TargetServer からのレスポンスには
- 失敗: TargetServer がヘルスチェックに失敗する状況は、チェックの種類に応じて異なります。TargetServer が次のように動作した場合、失敗としてログに記録されます。
- Apigee からヘルスチェック ポートへの接続が拒否される。
- 指定された期間内にヘルスチェック リクエストに応答しない。
- 想定外の HTTP ステータス コードを返す。
- 期待されるメッセージ本文と一致しないメッセージ本文で応答する。
TargetServer がヘルスチェックに失敗すると、Apigee はそのサーバーのエラー数のカウントを増やします。そのサーバーのエラー数が、事前に定義したしきい値(
<MaxFailures>
)と一致または超えた場合、Apigee によってそのサーバーへのリクエスト送信は停止されます。
HealthMonitor の有効化
HealthMonitor を作成するには、プロキシの TargetEndpoint の HTTPConnection 構成に <HealthMonitor>
要素を追加します。UI ではこれを行うことはできません。代わりに、プロキシ構成を作成し、ZIP ファイルとして Apigee にアップロードします。プロキシ構成とは、API プロキシのあらゆる側面の構造化記述です。プロキシ構成は、事前定義されたディレクトリ構造の XML ファイルで構成されています。詳細については、API プロキシ構成リファレンスをご覧ください。
単純な HealthMonitor では、TCPMonitor または HTTPMonitor と組み合わされた IntervalInSec
を定義します。<MaxFailures>
要素では、API プロキシから TargetServer へのリクエストの最大失敗回数を指定し、この数値を上回ると、リクエストは別の TargetServer にリダイレクトされます。デフォルトでは、<MaxFailures>
は 0 です。これは、Apigee は修正アクションを実施しないことを意味します。HealthMonitor を構成するときは、<TargetEndpoint>
タグの <HTTPTargetConnection>
タグで <MaxFailures>
を 0 以外の値に設定します。
TCPMonitor
以下の構成例では、5 秒ごとにポート 80 で接続を開いて各 TargetServer をポーリングする HealthMonitor を定義しています(Port は省略可能です。指定されていない場合は、TCPMonitor のポートが TargetServer のポートになります)。
- 接続が失敗したか、接続に 10 秒以上かかった場合、その TargetServer の失敗カウントが 1 つ増えます。
- 接続に成功すると、その TargetServer の失敗カウントは 0 にリセットされます。
HealthMonitor は、次のように TargetEndpoint の HTTPTargetConnection 要素の子要素として追加できます。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <Port>80</Port> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> </TargetEndpoint>
TCPMonitor 構成要素による HealthMonitor
次の表に、TCPMonitor の構成要素を示します。
名前 | 説明 | デフォルト | 要否 |
---|---|---|---|
IsEnabled |
HealthMonitor を有効または無効にするブール値。 | false | × |
IntervalInSec |
TCP リクエストをポーリングする時間間隔(秒単位)。 | 0 | ○ |
ConnectTimeoutInSec |
成功と判定されるためには、この時間(秒単位)内に TCP ポートへの接続が確立される必要があります。この指定時間間隔内に接続できなかった場合、失敗とカウントされ、その TargetServer に対するロードバランサの失敗カウントが 1 つ増加します。 | 0 | ○ |
Port |
省略可。TCP 接続が確立されるポート。指定されていない場合は、TCPMonitor のポートが TargetServer のポートになります。 | 0 | × |
HTTPMonitor
HTTPMonitor を使用するサンプル HealthMonitor では、5 秒に 1 回 GET
リクエストをバックエンド サービスに送信します。以下のサンプルでは、リクエスト メッセージに HTTP Basic Authorization ヘッダーを追加しています。Response 構成では、バックエンド サービスからの実際のレスポンスと比較される設定を定義します。下の例では、想定されるレスポンスは HTTP レスポンス コードの 200
と、値が YourOK
のカスタム HTTP ヘッダー ImOK
です。レスポンスが一致しない場合、ロードバランサの構成により、リクエストは失敗として処理されます。
HTTPMonitor では、HTTP と一方向 HTTPS プロトコルを使用するように構成されているバックエンド サービスがサポートされています。ただし、双方向 HTTPS(双方向 TLS / SSL、自己署名証明書とも呼ばれる)はサポートされていません。
HTTPMonitor 内のすべての Request および Response の設定は、呼び出す必要があるバックエンド サービスに固有のものです。
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Port>80</Port> <Verb>GET</Verb> <Path>/healthcheck</Path> <Header name="Authorization">Basic 12e98yfw87etf</Header> <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> <Header name="ImOK">YourOK</Header> </SuccessResponse> </HTTPMonitor> </HealthMonitor> </HTTPTargetConnection> </TargetEndpoint>
HTTPMonitor 構成要素による HealthMonitor
次の表に、HTTPMonitor 構成要素を示します。
名前 | 説明 | デフォルト | 要否 |
---|---|---|---|
IsEnabled |
HealthMonitor を有効または無効にするブール値。 | false | × |
IntervalInSec |
リクエストをポーリングする時間間隔(秒単位)。 | 0 | ○ |
Request |
ローテーションしている TargetServer に対して HealthMonitor が送信する送信リクエスト メッセージの構成オプション。 Path では変数はサポートされていません。 |
なし | ○ |
ConnectTimeoutInSec |
成功と判定されるためには、この時間(秒単位)内に HTTP サービスへの TCP 接続 handshake を完了する必要があります。この指定時間内に接続できなかった場合、失敗とカウントされ、その TargetServer に対する LoadBalancer の失敗カウントが 1 つ増加します。 | 0 | × |
SocketReadTimeoutInSec |
成功と判定されるためには、この時間(秒単位)内に HTTP サービスからのデータを読み取る必要があります。指定時間内に読み取りできなかった場合、失敗とカウントされ、その TargetServer に対する LoadBalancer の失敗カウントが 1 つ増加します。 | 0 | × |
Port |
バックエンド サービスへの HTTP 接続が確立されるポート。 | なし | × |
Verb |
バックエンド サービスへの各ポーリング HTTP リクエストに使用される HTTP 動詞。 | なし | × |
Path |
TargetServer 構成で定義されている URL の末尾に追加されるパス。このパス要素を使用して、HTTP サービスでの「ポーリング エンドポイント」を構成します。 | なし | × |
| アップストリーム システムでのヘルスチェック リクエストを追跡できます。IncludeHealthCheckIdHeader はブール値を受け取ります。デフォルトは false です。true に設定すると、X-Apigee-Healthcheck-Id という名前の Header があり、ヘルスチェック リクエストに挿入されます。ヘッダーの値は動的に割り当てられ、ORG/ENV/SERVER_UUID/N の形式になります。ここで、ORG は組織名、ENV は環境名、SERVER_UUID は MP を識別する一意の ID で、N は 1970 年 1 月 1 日からの経過時間(ミリ秒数)です。
生成されるリクエスト ヘッダーの例: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123
|
false | × |
Payload |
各ポーリング HTTP リクエストのために生成される HTTP 本文。この要素は GET リクエストには不要です。 |
なし | × |
SuccessResponse |
ポーリングされたバックエンド サービスによって生成された受信 HTTP レスポンス メッセージに対するマッチング オプション。レスポンスが一致しない場合、失敗カウントが 1 つ増加します。 | なし | × |
ResponseCode |
ポーリングされた TargetServer から受信すると予想される HTTP レスポンス コード。実際のコードが指定されたコードと異なっている場合、失敗となり、ポーリングされたバックエンド サービスのカウントが 1 つ増加します。複数の ResponseCode 要素を定義できます。 | なし | × |
Headers |
ポーリングされたバックエンド サービスから受信すると想定されている 1 つまたは複数の HTTP ヘッダーと値のリスト。レスポンスの HTTP ヘッダーまたは値が、この指定されたヘッダーまたは値と異なる場合、失敗となり、ポーリングされた TargetServer のカウントが 1 つ増加します。複数の Header 要素を定義できます。 | なし | × |