バックエンドサーバー間のロードバランシング

このページは 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 を作成し、一覧表示する例を示します。

API を使用して環境に TargetServer を作成する
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 に対する場合も同様の形になります。

詳細については、TargetEndpoint をご覧ください。

ロードバランサのオプションの構成

以下のセクションで説明するように、ロードバランサと 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"
  }
}

注: TargetEndpoint と TargetServer の両方の定義に sSLInfo ブロックを定義すると、TargetServer の定義が優先されます。

バックエンドサービスで双方向つまり相互の 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 を使用する場合<MaxFailures>は、を 0 より大きい値に設定する必要があります。<MaxFailures> の値を 0 に構成すると、Apigee は各リクエストのためにターゲットへの接続を常に試みるように構成され、ローテーションから TargetServer は除外されません。

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 が次のように動作した場合、失敗としてログに記録されます。
- 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`	アップストリームシステムでのヘルスチェックリクエストを追跡できます。`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 要素を定義できます。	なし	×

バックエンド サーバー間のロード バランシング

動画

TargetServer 構成について

TargetServer の作成

Cloud コンソールの Apigee

従来の Apigee

Apigee API

API を使用して環境に TargetServer を作成する

API を使用して環境の TargetServer を一覧表示する

名前付き TargetServer 間で負荷分散するように TargetEndpoint を構成する

ロードバランサのオプションの構成

アルゴリズム

ラウンドロビン

重み付け

最小接続

最大失敗数

再試行

IsFallback

パス

TLS / SSL 用の TargetServer の構成

稼働状況のモニタリング

成功と失敗

HealthMonitor の有効化

TCPMonitor

TCPMonitor 構成要素による HealthMonitor

HTTPMonitor

HTTPMonitor 構成要素による HealthMonitor

バックエンドサーバー間のロードバランシング