バックエンド サーバー間の負荷分散

Apigee Edge は、複数のバックエンド サーバー インスタンスにわたる負荷分散とフェイルオーバーの組み込みサポートを提供することで API の可用性を高めます。

TargetServer 構成により、実際のエンドポイント URL が TargetEndpoint 構成から分離されます。各 TargetServer は、TargetEndpoint HTTPConnection では名前で参照されます。構成で実際の URL を定義する代わりに、TargetEndpoint セクションで説明しているように、名前付き TargetServer を 1 つまたは複数構成できます。

TargetServer 定義は、名前、ホスト、ポート、TargetServer が有効か無効かを表す追加要素で構成されています。

動画

ターゲット サーバーを使用した API ルーティングと負荷分散に関する詳細は、次の動画をご覧ください。

動画 説明
ターゲット サーバーを使用した負荷分散 複数のターゲット サーバーにわたる負荷分散 API
ターゲット サーバーを使用した、環境に基づく API ルーティング 環境に基づいて API を異なるターゲット サーバーにルーティングする
ターゲット サーバーを使用した API ルーティングと負荷分散（Classic Edge） Classic Edge UI で、環境に基づいて API を異なるターゲット サーバーにルーティングし、ターゲット サーバー間で API を負荷分散する

TargetServer 構成の例

次のコードは、ターゲット サーバーを定義します。

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

TargetServer 構成要素

次の表に、TargetServer の作成と構成に使用される要素を示します。

名前 説明 デフォルト 必須
name TargetServer 構成の名前。環境内で一意である必要があります。TargetServer 名には英数字のみ使用できます。 なし ○
Host バックエンド サービスのホスト URL（プロトコルなし）。 なし ○
Port バックエンド サービスがリッスンしているポート。 なし ○
IsEnabled TargetServer 構成が有効か無効かを表すブール値。この値により、API プロキシ構成を変更せずに TargetServer をローテーションから除外できます。想定される容量要件やメンテナンス スケジュールなどに基づいて、TargetServer を自動的に有効または無効にするアプリやスクリプトを記述するためによく使用されます。 true ○

UI を使用したターゲット サーバーの管理

次に説明する手順で、ターゲット サーバーを管理します。

Edge

Edge UI を使用してターゲット サーバーを管理するには、次のようにします。

  1. apigee.com/edge にログインします。
  2. 左側のナビゲーション メニューで [Admin] > [Environments] > [Target Servers] を選択します。
  3. 対象とする環境（[test] や [prod] など）を選択します。
  4. ターゲット サーバーを作成するには、次のようにします。
    1. [+ Target server] をクリックします。
    2. ターゲット サーバーの名前、ホスト、ポートを入力します。

      例:

      • Name: target1
      • Host: 1.mybackendservice.com
      • Port: 80
    3. 必要に応じて [SSL] を選択します。
    4. [Enabled] を選択してターゲット サーバーを有効にします。
    5. [Add] をクリックします。
  5. ターゲット サーバーを編集するには、次のようにします。
    1. 編集するターゲット サーバーにカーソルを合わせて、操作メニューを表示します。
    2. をクリックします。
    3. ターゲット サーバーの値を編集します。
    4. [Update] をクリックします。
  6. ターゲット サーバーを削除するには、次のようにします。
    1. 削除するターゲット サーバーにカーソルを合わせて、操作メニューを表示します。
    2. をクリックします。
    3. [Delete] をクリックして、操作を確定します。

Classic Edge（Private Cloud）

Classic Edge UI を使用して Create Proxy ウィザードにアクセスするには、次のようにします。

  1. http://ms-ip:9000 にログインします。ここで、ms-ip は、Management Server ノードの IP アドレスまたは DNS 名です。
  2. 左側のナビゲーション バーで [APIs] > [Environment Configuration] > [Target Servers] を選択します。
  3. 対象とする環境（[test] や [prod] など）を選択します。
  4. ターゲット サーバーを作成するには、次のようにします。
    1. [Edit] をクリックします。
    2. [+ Target server] をクリックします。
    3. ターゲット サーバーの名前、ホスト、ポートを入力します。

      例:

      • Name: target1
      • Host: 1.mybackendservice.com
      • Port: 80
    4. [Enabled] を選択してターゲット サーバーを有効にします。
    5. [Save] をクリックします。
  5. ターゲット サーバーを編集するには、次のようにします。
    1. [Edit] をクリックします。
    2. ターゲット サーバーの値を編集します。
    3. [Save] をクリックします。
  6. ターゲット サーバーを削除するには、次のようにします。
    1. [Edit] をクリックします。
    2. [Delete] をクリックします。

API を使用したターゲット サーバーの管理

Edge API を使用して、ターゲット サーバーを作成、削除、更新、取得、リスト取得できます。詳しくは、TargetServers をご覧ください。

次の API 呼び出しを使用して、ターゲット サーバーを作成します。

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

レスポンスの例:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

最初の TargetServer を作成したら、次の API 呼び出しを使用して 2 つ目の TargetServer を作成します。2 つの TargetServer を定義することで、TargetEndpoint が負荷分散に利用できる URL が 2 つ用意されます。

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

レスポンスの例:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

次の API 呼び出しを使用して、環境内の TargetServers のリストを取得します。

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

レスポンスの例:

[ "target2", "target1" ]

以上で、テスト環境にデプロイされている API プロキシから 2 つの TargetServer を利用できるようになりました。これらの TargetServer 間でトラフィックを負荷分散するには、その TargetServer を使用するように API プロキシのターゲット エンドポイントで HTTP 接続を構成します。

上限トピックに記載されているとおり、1 環境あたりの TargetServer 数は 500 までに制限されています。

名前付きの 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 の間で 1 回ずつ切り替わります。

<Path> 要素は、すべてのターゲット サーバーの TargetEndpoint URI のベースパスを構成します。これは <LoadBalancer> の利用時に限り使用されます。それ以外では、無視されます。上記の例では、「target1」に到達するリクエストは http://target1/test となり、他のターゲット サーバーに対する場合も同様の形になります。

ロードバランサのオプションの設定

ロードバランサと 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 つのリクエストがルーティングされるごとに、target2 に 2 つのリクエストがルーティングされます。

最小接続

最小接続数アルゴリズムを使用するように構成されている 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 がターゲット サーバーからレスポンスを受信していないことを意味します。この場合、エラーカウンタが 1 つ増えます。

ただし、Apigee がターゲットからレスポンスを受信すると、レスポンスが HTTP エラー（500 など）であっても、ターゲット サーバーからのレスポンスとしてカウントされ、エラーカウンタがリセットされます。できる限り早く異常なサーバーへの負荷分散を除外するため、不正な HTTP レスポンス（500 など）もエラーとしてカウントさせたい場合は、<ResponseCode> 子要素を含む <ServerUnhealthyResponse> 要素をロードバランサの構成に加えます。Edge は、こうしたコードを含むレスポンスもエラーとしてカウントするようになります。

次の例では、リクエスト（ターゲット サーバーからの 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 です。これは、リクエストが送られるたびに Edge はターゲットへの接続を試み、ターゲット サーバーをローテーションから除外することはないという意味です。

再試行

再試行を有効にすると、レスポンス エラー（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 にルーティングされます。

Path

Path では、TargetServer がバックエンド サーバーに対して発行するすべてのリクエストの末尾に追加される URI フラグメントを定義します。

この要素には、リテラル文字列パスまたはメッセージ テンプレートを記述できます。メッセージ テンプレートを使用すると、変数文字列を実行時に置き換えることができます。たとえば、次のターゲット エンドポイントの定義では、{mypath} の値がパスに使用されています。

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

TLS/SSL 用のターゲット サーバーの構成

TargetServer を使用してバックエンド サービスを定義していて、そのバックエンド サービスで HTTPS プロトコルを使用する接続が必要な場合は、TargetServer 定義で TLS/SSL を有効にする必要があります。<Host> タグでは接続プロトコルを指定できないため、この記述が必要になります。次の例は、Edge がバックエンド サービスへの HTTPS リクエストを作成する一方向 TLS/SSL 用の TargetServer 定義を示しています。

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

バックエンド サービスで双方向つまり相互の TLS/SSL が必要な場合は、TargetEndpoints と同じ TLS/SSL 構成設定を使用して TargetServer を構成します。

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

<SSLInfo> プロパティ（<Ciphers> や <ClientAuthEnabled> など）については、Private Cloud 用 API への TLS アクセスの構成で仮想ホストのこうしたプロパティ設定に関する情報をご覧ください。

送信 TLS/SSL を構成する詳細手順については、Edge からバックエンドへの TLS の構成（Cloud、Private Cloud）をご覧ください。

TargetServer スキーマ

GitHub で TargetServer と他のエンティティに対するスキーマをご覧ください。

ヘルス モニタリング

ヘルス モニタリングを使用すると、TargetServer 構成で定義されているバックエンド サービス URL を能動的にポーリングすることによって負荷分散構成を強化できます。ヘルス モニタリングが有効な場合、正常に動作しなかった TargetServer は、その TargetServer が正常であると HealthMonitor により判定されたとき自動的にローテーションに戻されます。

ヘルス モニタリングは <MaxFailures> と連動します。ヘルス モニタリングが有効化されていない場合、<MaxFailures> で指定された API プロキシから TargetServer に対するリクエストのエラー数により、リクエストが別の TargetServer にリダイレクトされるようになります。正常に動作しない TargetServer は、プロキシをユーザーが再デプロイするまでローテーションから除外されます。

ヘルス モニタリングを有効にすると、正常に動作しなかった TargetServer は自動的にローテーションに戻され、プロキシの再デプロイは必要ありません。

HealthMonitor は、TCP または HTTP を介してバックエンド サービスを呼び出す単純なクライアントとして次のように動作します。

  • TCP クライアントはソケットが確実に開くようにします。
  • 有効な HTTP リクエストをバックエンド サービスに送信するように HTTP クライアントを構成します。HTTP の GET、PUT、POST、DELETE オペレーションを定義できます。HTTP モニタリング呼び出しのレスポンスは、<SuccessResponse> ブロックに構成された設定と一致する必要があります。

成功と失敗

ヘルス モニタリングを有効にすると、Edge はターゲット サーバーにヘルスチェックの送信を開始します。ヘルスチェックとは、ターゲット サーバーに送信されるリクエストのことで、ターゲット サーバーが正常かどうかを判断します。

ヘルスチェックでは、次のいずれかの結果が得られます。

  • 成功: ヘルスチェックが成功すると、ターゲット サーバーは正常とみなされます。一般には、次の 1 つ以上の結果がこの判断に使用されます。
    • ターゲット サーバーが、指定されたポートへの新しい接続を受け入れ、そのポートを使用してリクエストに応答して、指定された時間内にポートを閉じる。ターゲット サーバーからのレスポンスに「Connection: close」が含まれている。
    • ターゲット サーバーが、ヘルスチェック リクエストに対して 200（OK）など、受理を意味するものと決めた HTTP ステータス コードで応答する。
    • ターゲット サーバーが、期待されるメッセージ本文を付けてヘルスチェック リクエストに応答する。

    Edge がサーバーを正常と判断すると、Edge によりサーバーへのリクエスト送信が続行または再開されます。

  • 失敗: ターゲット サーバーがヘルスチェックに失敗する形は、チェックの種類によりさまざまです。ターゲット サーバーが次のように動作した場合、異常として記録されます。
    • ヘルスチェック ポートへの Edge からの接続を拒否する。
    • 指定した期間内にヘルスチェック リクエストに応答しない。
    • 想定外の HTTP ステータス コードを返す。
    • 期待するメッセージ本文と一致しない本文で応答する。

    ターゲット サーバーがヘルスチェックに失敗すると、Edge はそのサーバーの失敗カウントを増やします。サーバーの失敗数が事前に定義したしきい値（<MaxFailures>）を超えた場合、Edge はそのサーバーへのリクエスト送信を停止します。

HealthMonitor の有効化

HealthMonitor を作成するには、<HealthMonitor> 要素をプロキシの TargetEndpoint の HTTPConnection 構成に追加します。これは UI では行えません。代わりに、プロキシ構成を作成し、ZIP ファイルの形で Edge にアップロードします。プロキシ構成とは、API プロキシのすべての側面が構造化して記述されたものです。プロキシ構成は、事前定義されたディレクトリ構造に XML ファイルで構成されています。詳細については、API プロキシ構成リファレンスをご覧ください。

単純な HealthMonitor では、TCPMonitor または HTTPMonitor と連携した IntervalInSec を定義します。<MaxFailures> 要素は API プロキシから TargetServer へのリクエストの最大失敗回数で、この数値を上回ると、リクエストは別の TargetServer にリダイレクトされます。デフォルトでは、<MaxFailures> は 0 で、その場合、Edge は修正動作を行いません。ヘルスモニターを構成するときは、<TargetEndpoint> タグの <HTTPTargetConnection> タグ中の <MaxFailures> をゼロ以外の値に設定してください。

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>
. . .

TCPMonitor 構成要素による HealthMonitor

次の表に、TCPMonitor の構成要素を示します。

名前 説明 デフォルト 必須
IsEnabled HealthMonitor を有効または無効にするブール値。 無効 ×
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 の設定は、呼び出す必要があるバックエンド サービスに固有のものです。

<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>
    </Request>
    <SuccessResponse>
      <ResponseCode>200</ResponseCode>
      <Header name=”ImOK”>YourOK</Header>
    </SuccessResponse>
  </HTTPMonitor>
</HealthMonitor>

HTTPMonitor 構成要素による HealthMonitor

次の表に、HTTPMonitor 構成要素を示します。

名前 説明 デフォルト 必須
IsEnabled HealthMonitor を有効または無効にするブール値。 無効 ×
IntervalInSec リクエストをポーリングする時間間隔（秒単位）。 0 ○
Request

ローテーションしている TargetServer に対して HealthMonitor が送信する送信リクエスト メッセージの構成オプション。

Path では変数はサポートされていません。

 なし ○
ConnectTimeoutInSec 成功と判定されるためには、この時間（秒単位）内に HTTP サービスへの TCP 接続 handshake を完了する必要があります。この指定時間間隔内に接続できなかった場合、失敗とカウントされ、LoadBalancer でのその TargetServer の失敗カウントが 1 つ増加します。 0 ×
SocketReadTimeoutInSec 成功と判定されるためには、この時間（秒単位）内に HTTP サービスからのデータを読み取る必要があります。指定時間内に読み取りできなかった場合、失敗とカウントされ、LoadBalancer でのその TargetServer の失敗カウントが 1 つ増加します。 0 ×
Port バックエンド サービスへの HTTP 接続が確立されるポート。 なし ×
Verb バックエンド サービスへの各ポーリング HTTP リクエストに使用される HTTP 動詞。 なし ×
Path TargetServer 構成で定義されている URL の末尾に追加されるパス。このパス要素を使用して、HTTP サービスでの「ポーリング エンドポイント」を構成します。 なし ×
Payload 各ポーリング HTTP リクエストのために生成される HTTP 本文。この要素は GET リクエストには不要です。 なし ×
SuccessResponse ポーリングされたバックエンド サービスによって生成された受信 HTTP レスポンス メッセージに対するマッチング オプション。レスポンスが一致しない場合、失敗カウントが 1 つ増加します。 なし ×
ResponseCode ポーリングされた TargetServer から受信すると予想される HTTP レスポンス コード。実際のコードが指定コードと異なっている場合、失敗となり、ポーリングされたバックエンド サービスのカウントが 1 つ増加します。複数の ResponseCode 要素を定義できます。 なし ×
Headers ポーリングされたバックエンド サービスから受信すると想定されている 1 つまたは複数の HTTP ヘッダーと値のリスト。レスポンスの HTTP ヘッダーまたは値がこの指定と異なる場合、失敗となり、ポーリングされた TargetServer のカウントが 1 つ増加します。複数の Header 要素を定義できます。 なし ×