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

このページは Apigee と Apigee ハイブリッドに適用されます。

Apigee Edge のドキュメントを表示する。

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

ターゲットサーバーにより、具体的なエンドポイント URL がターゲットエンドポイント構成から切り離されています。その構成で具体的な URL を定義する代わりに、1 つ以上の名前付きターゲットサーバーを構成できます。つまり、各ターゲットサーバーは、ターゲットエンドポイントの HTTPConnection では名前によって参照されます。

動画

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

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

ターゲットサーバーの構成について

ターゲットサーバーの構成は、名前、ホスト、プロトコル、ポートで構成され、ターゲットサーバーが有効か無効かを示す追加要素を含みます。ターゲットサーバーには、オプションの <sSLInfo> オブジェクトを指定することもできます。

次のコードは、ターゲットサーバーの構成例を示しています。

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

TargetServers API の詳細については、organizations.environments.targetservers をご覧ください。

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

ターゲットサーバーの作成

以下のセクションで説明するように、Apigee UI または API を使用してターゲットサーバーを作成します。

Cloud コンソールの Apigee

Cloud コンソールの Apigee を使用してターゲットサーバーを作成するには:

Cloud コンソールの Apigee UI にログインします。
[管理] > [環境] を選択します。
新しいターゲットサーバーを定義する環境を選択します。
ペインの上部にある [Target Servers] をクリックします。
[+ Create Target Server] をクリックします。
表示されたフィールドに、名前、ホスト、プロトコル、ポートを入力します。[Protocol] のオプションは、[HTTP]（REST ベースのターゲットサーバー用）、[gRPC - Target]（gRPC ベースのターゲットサーバー用）、または [gRPC - External callout] です。gRPC プロキシのサポートについては、gRPC API プロキシを作成するをご覧ください。
必要に応じて、[SSL を有効にする] を選択できます。SSL 証明書の概要をご覧ください。
[作成] をクリックします。

従来の Apigee

従来の Apigee UI を使用してターゲットサーバーを作成するには:

Apigee UI にログインします。
[Admin] > [Environments] > [TargetServers] を選択します。
[Environment] プルダウンリストから、新しいターゲットサーバーを定義する環境を選択します。
Apigee UI に、選択した環境の現在のターゲットサーバーのリストが表示されます。
[+Target server] をクリックして、選択した環境に新しいターゲットサーバーを追加します。
[Add target server] ダイアログボックスが表示されます。
[Enabled] をオンにすると、新しいターゲットサーバーの定義の作成後に、すぐに定義が有効になります。
表示されたフィールドに、名前、ホスト、プロトコル、ポートを入力します。[Protocol] のオプションは、HTTP または GRPC です。

必要に応じて、[SSL] チェックボックスをオンできます。これらのフィールドの詳細については、TargetServers（4MV4D 動画）をご覧ください。
[Add] をクリックします。
Apigee によって新しいターゲットサーバーの定義が作成されます。
新しいターゲットサーバーを作成した後、API プロキシを編集して、新しい定義を参照するように <HTTPTargetConnection> 要素を変更できます。

Apigee API

以下のセクションでは、Apigee API を使用してターゲットサーバーを作成し、一覧表示する例を示します。

API を使用して環境にターゲットサーバーを作成する
API を使用して環境のターゲットサーバーを一覧表示する

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

API を使用して環境にターゲットサーバーを作成する

ポート 80 の 1.mybackendservice.com に接続する target1 という名前のターゲットサーバーを作成するには、次の 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 つ目のターゲットサーバーを作成します。2 つのターゲットサーバーを定義して、ターゲットエンドポイントがロードバランシング用に使用できる 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 を使用して環境のターゲットサーバーを一覧表示する

環境のターゲットサーバーを一覧表示するには、次の API 呼び出しを使用します。

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

レスポンスの例を次に示します。

[ "target2", "target1" ]

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

名前付きターゲットサーバー間でロードバランスするようにターゲットエンドポイントを構成する

これで 2 つのターゲットサーバーが利用可能になりました。ターゲットエンドポイントの <HTTPTargetConnection> 要素を変更して、2 つのターゲットサーバーを名前で参照できます。

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

上の構成は、最も基本的な負荷分散構成です。ロードバランサは、ラウンドロビン、重み付け、最小接続の 3 つの負荷分散アルゴリズムをサポートしています。デフォルトのアルゴリズムはラウンドロビンです。上の構成ではアルゴリズムが指定されていないため、API プロキシからバックエンドサーバーへのアウトバウンドリクエストは target1 と target2 に対し交互に送信されます。

<Path> 要素は、すべてのターゲットサーバーのターゲットエンドポイント URI のベースパスを形成します。<LoadBalancer> が使用されるときのみ使用されます。それ以外では、無視されます。上の例では、target1 に到達するリクエストは http://target1/test となり、他のターゲットサーバーに対する場合も同様の形になります。

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

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

以下のセクションで説明するように、ロードバランサとターゲットサーバーのレベルでロードバランシングとフェイルオーバーのオプションを構成することで、可用性を調整できます。

アルゴリズム

<LoadBalancer> で使用されるアルゴリズムを設定します。使用可能なアルゴリズムには RoundRobin、Weighted、LeastConnections があります。それぞれについて以下で説明します。

ラウンドロビン

デフォルトのアルゴリズムであるラウンドロビンでは、ターゲットエンドポイントの HTTP 接続に記載されているサーバーの順にリクエストが各ターゲットサーバーに転送されます。例:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

重み付け

重み付けロードバランシングアルゴリズムを使用すると、ターゲットサーバーに対してトラフィック負荷の比率を構成できます。重み付け LoadBalancer は、各ターゲットサーバーの重み付けに正比例にしてリクエストをターゲットサーバーに分配します。したがって、重み付けアルゴリズムでは、各ターゲットサーバーに 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 接続数が最も少ないターゲットサーバーにアウトバウンドリクエストを転送します。例:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

最大失敗数

API プロキシからターゲットサーバーへのリクエストの最大エラー数で、この数値により、リクエストは別のターゲットサーバーにリダイレクトされることになります。

レスポンスのエラーとは、Apigee がターゲットサーバーからのレスポンスを 1 つも受信していないことを意味します。この状況が発生した場合、エラーカウンタが 1 つ増えます。

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

次の例では、リクエスト（ターゲットサーバーからの 404 と一部の 5XX レスポンスを含む）が 5 回エラーになると、target1 がローテーションから除外されます。

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>404</ResponseCode>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

MaxFailures のデフォルト値は 0 です。これは、Apigee は各リクエストのためにターゲットへの接続を常に試み、ターゲットサーバーをローテーションから除外しないことを意味します。

ヘルスモニターでは MaxFailures が 0 より大きいものを使用することをおすすめします。MaxFailures に 0 より大きい値を構成した場合、ターゲットが指定された回数エラーになると、ターゲットサーバーはローテーションから除外されます。ヘルスモニターを設定すると、そのヘルスモニターの構成に従い、ターゲットが再起動した後、Apigee が自動的にターゲットサーバーをローテーションに戻します。詳細については、稼働状況のモニタリングをご覧ください。

また、MaxFailures に 0 より大きい値を構成して、ヘルスモニターを構成しない場合、最初のエラーが検出された後、Apigee はターゲットサーバーを自動的にローテーションから除外します。Apigee は 5 分ごとにターゲットサーバーの状態を確認し、ターゲットサーバーが正常に応答したときにローテーションに戻します。

再試行

再試行が有効になっている場合、レスポンスのエラー（I/O エラーまたは HTTP タイムアウト）が発生したとき、またはレスポンスが <ServerUnhealthyResponse> で設定された値と一致するたびにリクエストが再試行されます。<ServerUnhealthyResponse> の設定に関する詳細は、前述の最大エラー数をご覧ください。

デフォルトでは <RetryEnabled> は true に設定されています。再試行を無効にするには、false に設定します。例:

<RetryEnabled>false</RetryEnabled>

IsFallback

ターゲットサーバーの 1 つ（だけ）は「フォールバック」サーバーとして設定できます。フォールバックターゲットサーバーは、ロードバランサが他のすべてのターゲットサーバーを使用不可と判定するまでは、ロードバランシングのルーティンに組み込まれません。ロードバランサがすべてのフォールバック以外のターゲットサーバーが使用不可であると判定すると、すべてのトラフィックはフォールバックサーバーに転送されます。例:

<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 にルーティングされます。

フォールバックサーバーが正常でない場合、Apigee はフォールバックサーバーにトラフィックを転送しません。代わりに、API 呼び出しで 503（サービスが一時的に利用不能）エラーが返されます。

パス

パスは、ターゲットサーバーがバックエンドサーバーに発行するすべてのリクエストに付加される URI フラグメントを定義します。

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

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

TLS / SSL 用にターゲットサーバーを構成する

ターゲットサーバーを使用してバックエンドサービスを定義していて、そのバックエンドサービスで HTTPS プロトコルを使用する接続が必要な場合は、ターゲットサーバーの定義で TLS / SSL を有効にする必要があります。これが必要になるのは、host タグでは接続プロトコルを指定できないためです。

注: ターゲットエンドポイントとターゲットサーバーの両方の定義に sSLInfo ブロックを定義すると、ターゲットサーバーの定義が優先されます。

一方向の TLS / SSL を構成する

次の構成を使用して、一方向の TLS / SSL でターゲットサーバーを定義します。この例では、Apigee がバックエンドサービスに HTTPS リクエストを送信します。

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

厳格な SSL 適用を構成する

ターゲットサーバーの定義で厳密な SSL 適用を指定するには、次の例に示すように、sSLInfo ブロックで enforce を true に設定します。

  {
    "name": "target1",
    "host": "mocktarget.apigee.net",
    "protocol": "http",
    "port": "443",
    "isEnabled": "true",
    "sSLInfo": {
      "enabled": "true",
      "enforce": "true"
    }
  }

双方向の TLS / SSL を構成する

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

{
  "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 を構成する

API 呼び出しを使用して厳格な SSL 適用でターゲットサーバーを作成するには:

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,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

稼働状況のモニタリング

稼働状況のモニタリングを使用すると、ターゲットサーバーの構成で定義されているバックエンドサービス URL を能動的にポーリングすることによってロードバランシング構成を強化できます。ヘルスモニタリングが有効な場合、到達不能なターゲットサーバーまたはエラーレスポンスを返すターゲットサーバーは異常としてマークされます。正常に動作しなかったターゲットサーバーは、そのターゲットサーバーが正常であるとヘルスモニターにより判定されたときに自動的にローテーションに戻されます。プロキシを再デプロイする必要はありません。

ヘルスモニターを使用する場合、<MaxFailures> を 0 より大きい値に設定する必要があります。<MaxFailures> の値を 0 に設定すると、Apigee はリクエストごとにターゲットに接続しようとし、ターゲットサーバーをローテーションから除外しません。

ヘルスモニターは、TCP または HTTP 経由でバックエンドサービスを呼び出すシンプルなクライアントとして動作します。

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

成功と失敗

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

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

成功: ヘルスチェックが成功した場合、ターゲットサーバーは正常と見なされます。これは通常、次の中のいずれか 1 つ以上の結果になります。
- ターゲットサーバーは、指定されたポートへの新しい接続を受け入れ、そのポートのリクエストに応答し、指定された期間内にポートを閉じる。ターゲットサーバーからのレスポンスには Connection: close が含まれる。
- ターゲットサーバーが、ヘルスチェックリクエストに対して、200 (OK) やその他の HTTP ステータスコード（受け入れ可能と判断）で応答している。
- ターゲットサーバーは、ヘルスチェックリクエストに対して、期待されるメッセージ本文と一致するメッセージ本文で応答している。
サーバーが正常であると Apigee が判断した場合は、そのサーバーへのリクエスト送信を続行または再開します。
失敗: ターゲットサーバーがヘルスチェックに失敗する状況は、チェックの種類に応じて異なります。ターゲットサーバーが次のように動作した場合、失敗としてログに記録されます。
- Apigee からヘルスチェックポートへの接続が拒否される。
- 指定された期間内にヘルスチェックリクエストに応答しない。
- 想定外の HTTP ステータスコードを返す。
- 期待されるメッセージ本文と一致しないメッセージ本文で応答する。
ターゲットサーバーがヘルスチェックに失敗すると、Apigee はそのサーバーのエラー数のカウントを増やします。そのサーバーのエラー数が、事前に定義したしきい値（<MaxFailures>）と一致または超えた場合、Apigee によってそのサーバーへのリクエスト送信は停止されます。

ヘルスモニターの有効化

API プロキシのヘルスモニターを作成するには、プロキシのターゲットエンドポイントの <HTTPTargetConnection 要素構成に <HealthMonitor> 要素を追加します。

ヘルスモニターを UI で作成することはできません。代わりに、プロキシ構成を作成し、ZIP ファイルとして Apigee にアップロードします。プロキシ構成とは、API プロキシのあらゆる側面の構造化記述です。プロキシ構成は、事前定義されたディレクトリ構造の XML ファイルで構成されています。詳細については、API プロキシ構成リファレンスをご覧ください。

`<HealthMonitor>` 構成要素

次の表に、<HealthMonitor> 構成要素を示します。

名前	説明	デフォルト	必須かどうか
`IsEnabled`	ヘルスモニターを有効または無効にするブール値。	false	×
`IntervalInSec`	TCP または HTTP リクエストのポーリング間隔（秒単位）。	0	○
`HTTPMonitor` または `TCPMonitor`	ターゲットサーバーのポーリングに使用する TCP または HTTP クライアントの定義。	なし	○

これらの要素に加えて、ヘルスモニターを有効にするには、<TargetEndpoint> 要素の <HTTPTargetConnection> ブロックで <MaxFailures> 要素を 0 より大きい値に設定する必要があります。<MaxFailures> には、API プロキシからターゲットサーバーへのリクエストの最大失敗回数を指定します。この数値に達すると、リクエストは別のターゲットサーバーにリダイレクトされます。

デフォルトでは、<MaxFailures> は 0 です。これは、Apigee が修正アクションを実施しないことを意味します。ヘルスモニターを構成する場合は、<MaxFailures> を 0 以外の値に設定します。

TCP モニターを使用するヘルスモニター

次の構成で説明するサンプルのヘルスモニターは、TCP モニターを使用して、5 秒ごとにポート 80 で接続を開き、各ターゲットサーバーをポーリングします（Port は省略可能です。指定されていない場合は、TCP モニターのポートがターゲットサーバーのポートになります）。

このヘルスモニターの構成例では、次のようになっています。

接続が失敗したか、接続に 10 秒以上かかった場合、そのターゲットサーバーの失敗カウントが 1 つ増えます。
接続に成功すると、そのターゲットサーバーの失敗カウントは 0 にリセットされます。

次に示すように、ヘルスモニターをターゲットエンドポイントの <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>` 構成要素

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

名前	説明	デフォルト	必須かどうか
`ConnectTimeoutInSec`	成功と判定されるためには、この時間（秒単位）内に TCP ポートへの接続が確立される必要があります。この指定時間間隔内に接続できなかった場合、失敗とカウントされ、そのターゲットサーバーに対するロードバランサの失敗カウントが 1 つ増加します。	0	○
`Port`	省略可。TCP 接続が確立されるポート。指定されていない場合は、TCP モニターのポートがターゲットサーバーのポートになります。	0	×

HTTP モニターを使用するヘルスモニター

次の構成で説明するサンプルのヘルスモニターでは、5 秒ごとにバックエンドサービスに GET リクエストを送信し、リクエストメッセージに HTTP Basic Authorization ヘッダーを追加する HTTP モニターを使用します。

このヘルスモニターの構成例では、次のようになっています。

バックエンドサービスからの想定されるレスポンスは、HTTP レスポンスコード 200 です。
カスタム HTTP 基本認証ヘッダー ImOK の想定値は YourOK です。
<UseTargetServerSSLInfo> 要素が true に設定され、ターゲットサーバーの <SSLInfo> ブロックの SSL パラメータが使用されます。

この構成では、想定されるレスポンスコードとヘッダー値が、バックエンドサービスからの実際のレスポンスと比較されます。レスポンスが一致しない場合、ロードバランサの構成により、リクエストは失敗として処理されます。

デフォルトでは、ヘルスモニターはターゲットサーバーからキーストア、トラストストア、その他の SSL パラメータにアクセスできません。相互 TLS をサポートするためにヘルスモニターのこれらのパラメータへのアクセスを有効にするには、<Request> ブロックに <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> を追加します。

    <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>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <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>` 構成要素

次の表に、最上位の <HTTPMonitor> 構成要素を示します。

名前	説明	デフォルト	必須かどうか
`Request`	ローテーション中のターゲットサーバーにヘルスモニターから送信されるアウトバウンドリクエストメッセージ。	なし	○
`SuccessResponse`	（省略可）ポーリングされたバックエンドサービスによって生成されたインバウンド HTTP レスポンスメッセージに対するマッチングオプション。	なし	×

<HTTPMonitor> / <Request> 構成要素

ローテーションしているターゲットサーバーにヘルスモニターが送信するアウトバウンドリクエストメッセージの構成オプション。<Request> は必須の要素です。

名前	説明	デフォルト	要否
`ConnectTimeoutInSec`	成功と判定されるためには、この時間（秒単位）内に HTTP サービスへの TCP 接続 handshake を完了する必要があります。この指定時間内に接続できなかった場合、失敗とカウントされ、そのターゲットサーバーに対する LoadBalancer の失敗カウントが 1 つ増加します。注: 指定した値が 0 の場合、Apigee はデフォルトのタイムアウト（30 秒）を使用します。	0	×
`SocketReadTimeoutInSec`	成功と判定されるためには、この時間（秒単位）内に HTTP サービスからのデータを読み取る必要があります。指定時間内に読み取りできなかった場合、失敗とカウントされ、そのターゲットサーバーに対する LoadBalancer の失敗カウントが 1 つ増加します。注: 指定した値が 0 の場合、Apigee はデフォルトのタイムアウト（30 秒）を使用します。	0	×
`Port`	バックエンドサービスへの HTTP 接続が確立されるポート。	ターゲットサーバーのポート	×
`Verb`	バックエンドサービスへの各ポーリング HTTP リクエストに使用される HTTP 動詞。	なし	×
`Path`	ターゲットサーバー構成で定義されている URL の末尾に追加されるパス。`Path` 要素を使用して、HTTP サービスで「ポーリングエンドポイント」を構成します。`Path` 要素は変数をサポートしていないことに注意してください。	なし	×
`UseTargetServerSSLInfo`	`UseTargetServerSSLInfo` が true の場合、ターゲットサーバーに対するヘルスモニターリクエストは、ターゲットサーバーの SSLInfo（sSLInfo）ブロックの SSL パラメータを使用します。そうでない場合、プロトコル、キーストア、トラストストアなどの SSL パラメータは、ヘルスモニターで使用できません。	false	×
`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` リクエストには不要です。	なし	×
`Header`	ポーリングされたバックエンドサービスから受信すると想定されている 1 つ以上の HTTP ヘッダーと値。レスポンスの HTTP ヘッダーまたは値が、この指定されたヘッダーまたは値と異なる場合、失敗となり、ポーリングされたターゲットサーバーのカウントが 1 つ増加します。複数の Header 要素を定義できます。	なし	×
`IsSSL`	true の場合、ヘルスモニターリクエストを HTTPS を使用して送信することを指定します。	False	×
`TrustAllSSL`	HTTP モニターチェックですべての SSL 証明書を自動的に信頼するかどうかを指定します。	False	×

<HTTPMonitor> / <SuccessResponse> 構成要素

（省略可）ポーリングされたバックエンドサービスによって生成された受信 HTTP レスポンスメッセージに対するマッチングオプション。レスポンスが一致しない場合、失敗カウントが 1 つ増加します。

名前	説明	デフォルト	必須かどうか
`ResponseCode`	ポーリングされたターゲットサーバーから受信すると予想される HTTP レスポンスコード。実際のコードが指定されたコードと異なっている場合、失敗となり、ポーリングされたバックエンドサービスのカウントが 1 つ増加します。複数の ResponseCode 要素を定義できます。	なし	×
`Header`	ポーリングされたバックエンドサービスから受信すると想定されている 1 つ以上の HTTP ヘッダーと値。レスポンスの HTTP ヘッダーまたは値が、この指定されたヘッダーまたは値と異なる場合、失敗となり、ポーリングされたターゲットサーバーのカウントが 1 つ増加します。複数の Header 要素を定義できます。	なし	×

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

動画

ターゲット サーバーの構成について

ターゲット サーバーの作成

Cloud コンソールの Apigee

従来の Apigee

Apigee API

API を使用して環境にターゲット サーバーを作成する

API を使用して環境のターゲット サーバーを一覧表示する

名前付きターゲット サーバー間でロードバランスするようにターゲット エンドポイントを構成する

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

アルゴリズム

ラウンドロビン

重み付け

最小接続

最大失敗数

再試行

IsFallback

パス

TLS / SSL 用にターゲット サーバーを構成する

一方向の TLS / SSL を構成する

厳格な SSL 適用を構成する

双方向の TLS / SSL を構成する

API を使用して厳密な SSL を構成する

稼働状況のモニタリング

成功と失敗

ヘルスモニターの有効化

<HealthMonitor> 構成要素

TCP モニターを使用するヘルスモニター

<TCPMonitor> 構成要素

HTTP モニターを使用するヘルスモニター

<HTTPMonitor> 構成要素

<HTTPMonitor> / <Request> 構成要素

<HTTPMonitor> / <SuccessResponse> 構成要素

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

ターゲットサーバーの構成について

ターゲットサーバーの作成

API を使用して環境にターゲットサーバーを作成する

API を使用して環境のターゲットサーバーを一覧表示する

名前付きターゲットサーバー間でロードバランスするようにターゲットエンドポイントを構成する

TLS / SSL 用にターゲットサーバーを構成する

`<HealthMonitor>` 構成要素

`<TCPMonitor>` 構成要素

`<HTTPMonitor>` 構成要素