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

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

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

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

動画

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

動画 説明
ターゲット サーバーを使用した負荷分散 ターゲット サーバー間の負荷分散 API
ターゲット サーバーを使用した、環境に基づく API ルーティング 環境に基づいて API を異なるターゲット サーバーにルーティングする
ターゲット サーバーを使用した API ルーティングと負荷分散(従来の Edge) 従来の 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 UI を使用してターゲット サーバーを作成および管理できます。

UI で、ターゲット サーバーの名前、ホスト、ポート、有効なプロパティを指定します。

  1. 管理 UI で [APIs] > [Environment Configuration] を選択します。
  2. 対象とする環境([test] や [prod] など)を選択します。
  3. [Target Servers] タブをクリックします。
  4. [Edit] をクリックします。
  5. [+ Target Server] をクリックします。
  6. 名前、ホスト、ポートを入力します。
  7. [Enabled] チェックボックスが選択されていることを確認します。
  8. [Save] をクリックします。

次に例を示します。

  • Name: target1
  • Host: 1.mybackendservice.com
  • Port: 80
  • Enabled: オン

さらにターゲット サーバーを追加して有効にする場合は、上記の手順を繰り返します。

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 の数や、TargetEndpoint の HTTPConnection から参照できる TargetServer の数に制限はありません。

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

<Path> 要素は、すべてのターゲット サーバーに対する TargetEndpoint URI のベースパスを形成します。この要素は <LoadBalancer> が使用されている場合にのみ使用されます。そうでない場合は無視されます。上記の例では、target1 に届くリクエストは http://target1/test であり、他のターゲット サーバーでも同様です。

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

ロードバランサと TargetServer のレベルで負荷分散とフェイルオーバーのオプションを使用して可用性を調整できます。以下では、これらのオプションについて説明します。

アルゴリズム

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

ラウンドロビン

デフォルトのアルゴリズムであるラウンドロビンでは、ターゲット エンドポイントの 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 にリダイレクトされます。

下記の構成では、target1 は 5 回失敗するとローテーションから除外されます。次に例を示します。

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

MaxFailures のデフォルト値は 0 です。 この値の場合、Edge は常に各リクエストをターゲットに接続しようとし、ターゲット サーバーをローテーションから除外することはありません。

再試行

I/O エラーまたは HTTP タイムアウト(HTTP エラーコード 4xx、5xx ではない)が発生した場合に、別のサーバーに対してそのリクエストを 1 回再試行します。次に例を示します。

    <RetryEnabled>true</RetryEnabled>
    

IsFallback

1 つの TargetServer を「フォールバック」サーバーとして設定できます。フォールバック 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 >
    

<Ciphers><ClientAuthEnabled> などの <SSLInfo> プロパティの詳細については、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> ブロックで構成されている設定と一致する必要があります。

HealthMonitor の有効化

プロキシに対する TargetEndpoint の HTTPConnection 構成でセットアップすることによって HealthMonitor を作成します。

単純な HealthMonitor では、TCPMonitor または HTTPMonitor のいずれかと組み合わせた IntervalInSec を定義します。<MaxFailures> タグでは、API プロキシから TargetServer へのリクエストの最大失敗数を指定します。この回数を超えて失敗すると、リクエストは別の TargetServer にリダイレクトされます。デフォルトでは <MaxFailures> は 0 であり、その場合 Edge は修正措置を行いません。ヘルス モニタリングを構成する場合は、<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>
    . . .
    

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