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

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

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

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

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

動画

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

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

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

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

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

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

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

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

以下のセクションで説明するように、Apigee UI または 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",
  }'
 

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

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
}

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

[ "target2", "target1" ]

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

これで 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 となり、他のターゲット サーバーに対する場合も同様の形になります。

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

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

アルゴリズム

<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 にルーティングされるリクエストごとに、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 が自動的にターゲット サーバーをローテーションに戻します。詳細については、稼働状況のモニタリングをご覧ください。

通常の API 呼び出しとヘルスモニターによって開始された呼び出しの両方が、MaxFailures のカウントにカウントされます。

また、各ターゲット サーバーの実行中の障害数は、ロードバランサごとに維持されます。たとえば、プロキシに 2 つのターゲット エンドポイントがあり、それぞれにロードバランサがあり、両方のロードバランサが同じターゲット サーバー セットを使用するように構成されているとします。この場合、1 つのターゲット エンドポイントの障害は、対応するロードバランサに対してのみカウントされます。他のターゲット エンドポイントのローテーションには影響しません。

また、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 タグでは接続プロトコルを指定できないためです。

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

ヘルスモニターは、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> 構成要素を示します。

これらの要素に加えて、ヘルスモニターを有効にするには、<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> 構成要素を示します。

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> 構成要素を示します。

<HTTPMonitor> / <Request> 構成要素

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

<HTTPMonitor> / <SuccessResponse> 構成要素

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