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

このページの内容は ApigeeApigee ハイブリッドに該当します。

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 を使用してターゲット サーバーを作成するには:

  1. Cloud コンソールの Apigee UI にログインします。
  2. [管理] > [環境] を選択します。
  3. 新しいターゲット サーバーを定義する環境を選択します。
  4. ペインの上部にある [Target Servers] をクリックします。
  5. [+ Create Target Server] をクリックします。
  6. 表示されたフィールドに、名前、ホスト、プロトコル、ポートを入力します。[Protocol] のオプションは、[HTTP](REST ベースのターゲット サーバー用)、[gRPC - Target](gRPC ベースのターゲット サーバー用)、または [gRPC - External callout] です。gRPC プロキシのサポートについては、gRPC API プロキシを作成するをご覧ください。

    必要に応じて、[SSL を有効にする] を選択できます。SSL 証明書の概要をご覧ください。

  7. [作成] をクリックします。

従来の Apigee

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

  1. Apigee UI にログインします。
  2. [Admin] > [Environments] > [TargetServers] を選択します。
  3. [Environment] プルダウン リストから、新しいターゲット サーバーを定義する環境を選択します。

    Apigee UI に、選択した環境の現在のターゲット サーバーのリストが表示されます。

    ターゲット サーバーのリスト

  4. [+Target server] をクリックして、選択した環境に新しいターゲット サーバーを追加します。

    [Add target server] ダイアログ ボックスが表示されます。

    ターゲット サーバーの追加ダイアログ

  5. [Enabled] をオンにすると、新しいターゲット サーバーの定義の作成後に、すぐに定義が有効になります。
  6. 表示されたフィールドに、名前、ホスト、プロトコル、ポートを入力します。[Protocol] のオプションは、HTTP または GRPC です。

    必要に応じて、[SSL] チェックボックスをオンできます。これらのフィールドの詳細については、TargetServers(4MV4D 動画)をご覧ください。

  7. [Add] をクリックします。

    Apigee によって新しいターゲット サーバーの定義が作成されます。

  8. 新しいターゲット サーバーを作成した後、API プロキシを編集して、新しい定義を参照するように <HTTPTargetConnection> 要素を変更できます。

Apigee API

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

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

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

ポート 801.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 プロキシからバックエンド サーバーへのアウトバウンド リクエストは target1target2 に対し交互に送信されます。

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

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

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

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

アルゴリズム

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

ラウンドロビン

デフォルトのアルゴリズムであるラウンドロビンでは、ターゲット エンドポイントの 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 エラー(404500 など)であってもターゲット サーバーからのレスポンスとしてカウントされ、エラーカウンタはリセットされます。できる限り早く異常なサーバーをロード バランシングのローテーションから除外するため、不正な 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>

上記の構成では、target1target2 の両方が使用不可になるまでは、target1target2 の間でラウンドロビンでロードバランスされます。target1target2 が使用不可になった場合、すべてのトラフィックは 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 タグでは接続プロトコルを指定できないためです。

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

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

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

厳格な SSL 適用を構成する

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

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

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

  • TCP クライアントはソケットが確実に開くようにします。
  • 有効な HTTP リクエストをバックエンド サービスに送信するように HTTP クライアントを構成します。HTTP GETPUTPOSTDELETE オペレーションを定義できます。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 ×
SocketReadTimeoutInSec 成功と判定されるためには、この時間(秒単位)内に HTTP サービスからのデータを読み取る必要があります。指定時間内に読み取りできなかった場合、失敗とカウントされ、そのターゲット サーバーに対する LoadBalancer の失敗カウントが 1 つ増加します。

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 要素を定義できます。 なし ×