Send Docs Feedback

Note: Most user interface tasks can be performed in Edge Classic or the New Edge experience. For an overview, getting started topics, and release notes specific to the New Edge experience, see the docs.

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

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

TargetServer 設定は、実際のエンドポイント URL と TargetEndpoint 設定を分離しています。各 TargetServer は、TargetEndpoint HTTPConnection 内の名前で参照されます。 設定で実際の URL を定義する代わりに、1 つ以上の名前付き TargetServer を設定できます。 

TargetServer 定義は、名前、ホスト、ポートに加えて、TargetServer が有効であるか無効であるかを示す補足的なエレメントで構成します。

TargetServer 設定の例:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

TargetServer 設定の要素

Name 説明 デフォルト 必須であるかどうか
name TargetServer 設定の名前。name は、環境内で一意にする必要があります。 該当なし
Host バックエンドサービスのホスト URL (プロトコルなし)。 該当なし
Port バックエンドサービスが待ち受けを行うポート。 該当なし
IsEnabled TargetServer 設定が有効であるか無効であるかを示すブール演算子。この指定により、API プロキシ設定を変更しなくても、TargetServer をローテーションから外すことができます。一般的な使い方としては、予想される容量要件、保守スケジュールに基づいて、TargetServer を自動的に有効または無効にするアプリ/スクリプトを記述する操作が挙げられます。 true

 

UI でターゲットサーバーを管理する

Edge UI を使用して、ターゲットサーバーの作成と管理を実行できます。 

  1. 管理 UI で「API」>「Environment Configuration」を選択します。 
  2. テスト実稼動など、目的の環境を選択します。
  3. 「Target Servers」タブに移動します。
  4. 「Edit」をクリックします。
  5. 「+ Target Server」をクリックします。 
  6. 名前、ホスト、ポートを入力します。
  7. 「Enabled」が選択されていることを確認します。 
  8. 「Save」をクリックします。  

例:

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

さらにターゲットサーバーの追加と有効化を行う場合は、これらの手順を繰り返します。 

API でターゲットサーバーを管理する

Edge 管理 API を使用して、ターゲットサーバーの作成、削除、更新、取得、およびリストを実行できます。詳細については、「TargetServers」を参照してください。 

$ 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
}

After you create the first TargetServer, then create a second TargetServer. By defining two TargetServers, you provide two URLs that a TargetEndpoint can use for load balancing:

$ 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
}

環境にある TargetServer のリストを取得します。

$ 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 接続を設定します。

環境で設定できる、または TargetEndpoint の HTTPConnection から参照できる TargetServer の台数には制限がありません。

名前付きの TargetServer 間で負荷分散を行うように TargetEndpoint を設定する

この時点で利用可能な TargetServer が 2 台あるため、これらの 2 台の TargetServer を名前で参照するように TargetEndpoint HTTP 接続設定を変更できます。

You can also call target servers and use load balancing in a ServiceCallout policy. For details, see Service Callout policy.

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

上記の設定は、最も基本的な負荷分散設定です。ロードバランサは、ラウンドロビン、加重、最小接続の 3 つの負荷分散アルゴリズムをサポートします。ラウンドロビンは、デフォルトのアルゴリズムです。上記の設定ではアルゴリズムが指定されていないため、API プロキシからバックエンドサーバーへの送信リクエストは、target1 と target 2 の間で 1 対 1 で切り替わります。 

<Path>  要素は、すべてのターゲットサーバーへの TargetEndpoint URI のベースパスを構成します。これは、<LoadBalancer> が使用されているときに限って使用されます。それ以外の場合、無視されます。上記の例で、「target1」に到達するリクエストは http://target1/test になり、他のターゲットサーバーについても同様になります。

再試行は I/O 例外と HTTP タイムアウトによってトリガされます。HTTP エラーコード (4xx、5xx) では、再試行はトリガされません。

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

ロードバランサと TargetServer のレベルで負荷分散とフェイルオーバーのオプションを使用することで、可用性を調整することができます。

<LoadBalancer> に使用可能なオプション:

アルゴリズム

Sets the algorithm used by <LoadBalancer>. The available algorithms are RoundRobin, Weighted, and LeastConnections, each of which is documented below.

ラウンドロビン

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

以下の構成では、リクエストが 5 回失敗すると target1 はローテーションから外されます。  

<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 はリクエストごとにターゲットに常に接続しようとします。ローテーションからターゲットサーバーを外すことはありません。

If you configure MaxFailures > 0 without also configuring a HealthMonitor, the TargetServer will be removed from rotation when the target fails the number of times you indicate. Edge does not automatically put the TargetServer back in rotation even after the target is up and running again. To have Edge put the TargetServer back in rotation, redeploy the API proxy.

再試行

I/O エラー (HTTP ステータスコード 500 以外) の後、異なるサーバーにもう一度リクエストを再試行します。

<RetryEnabled>true</RetryEnabled>

IsFallback

1 台の 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>

上記の構成では、ターゲット 1 と 2 の両方が使用できなくなるまで、ターゲット 1 と 2 の間でラウンドロビンの負荷分散が行われます。ターゲット 1 と 2 が使用できない場合、すべてのトラフィックはターゲット 3 に転送されます。

Path

Path では、バックエンドサーバー向けに TargetServer が発行するすべてのリクエストに追加される URI フラグメントを定義します。

Configuring a target server for TLS/SSL 

If you are using a TargetServer to define the backend service, and the backend service requires the connection to use the HTTPS protocol, then you must enable TLS/SSL in the TargetServer definition. This is necessary because the <Host> tag does not let you specify the connection protocol. Shown below is the TargetServer definition for one-way TLS/SSL where Edge makes HTTPS requests to the backend service:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo> 
      <Enabled>true</Enabled> 
  </SSLInfo> 
</TargetServer> 

If the backend service requires two-way, or mutual, TLS/SSL, then you configure the TargetServer by using the same TLS/SSL configuration settings as TargetEndpoints:

<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 > 

For information on the <SSLInfo> properties, such as <Ciphers>, <ClientAuthEnabled>, etc., see the information on setting those properties for a Virtual Host at  Configuring TLS access to an API for the Private Cloud.

For complete instructions on configuring outbound TLS/SSL, see Client-SSL to backend servers.

スキーマ

TargetServer のスキーマと Github のその他のエンティティを参照してください。

正常性の監視

正常性の監視では、TargetServer 構成に定義されたバックエンドサービス URL を高い頻度でポーリングすることで負荷分散の構成を強化できます。HealthMonitor は、TCP または HTTP 経由でバックエンドサービスを呼び出す簡易なクライアントとして動作します。TCP クライアントは、単にソケットを確実に開けるようにします。有効な HTTP リクエストをバックエンドサービスに送信するように HTTP クライアントを構成します。HTTP GET、PUT、POST、または DELETE 操作を定義できます。通常、バックエンドサービスが使用可能であることを示すだけの単純な GET リクエストを定義します。 

You create a HealthMonitor by setting one up in a TargetEndpoint's HTTPConnection configuration for a proxy.

Health monitors must be configured on a per-proxy basis. If you have multiple proxies that call the same target server, you must configure a Health Monitor for each proxy.

A simple HealthMonitor defines an IntervalInSec combined with either a TCPMonitor or an HTTPMonitor. The <MaxFailures> tag specifies maximum number of failed requests from the API proxy to the TargetServer that results in the request being redirected to another TargetServer. By default MaxFailures is 0, which means Edge performs no corrective action. When configuring a health monitor, ensure that you set <MaxFailures> in the <HTTPTargetConnection> tag of the <TargetEndpoint> tag. 

TCPMonitor

以下の構成では、5 秒おきにポート 80 で接続を開くことで各 TargetServer をポーリングする HealthMonitor を定義します。Port はオプションです。指定されていない場合、TCPMonitor ポートは TargetServer ポートです。

  • 接続が失敗する場合、または接続に 10 秒を超える時間がかかる場合、当該 TargetServer に対して障害カウントが 1 ずつ加算されます。
  • 接続が成功した場合、この TargetServer の障害カウントは 0 にリセットされます。

以下に示すように、TargetEndpoint では HTTPTargetConnetion 要素の子要素として HealthMonitor を追加できます。

<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>
. . .

HealthMonitor に指定できる TCPMonitor 構成要素

Name 説明 デフォルト 必須であるかどうか
IsEnabled HealthMonitor を有効または無効にするブール演算子。 false
IntervalInSec ポーリング TCP リクエスト間の秒を単位とする時間間隔。 0
ConnectTimeoutInSec 成功と判定するために TCP ポート接続を確立しておく必要がある時間。指定された時間、接続を維持できなかった場合、その接続は失敗とカウントされ、当該 TargetServer に対してロードバランサの失敗カウントが加算されます。 0
Port オプション。TCP 接続が確立されるポート。指定されていない場合、TCPMonitor ポートは TargetServer ポートです。 0

HTTPMonitor

A sample HealthMonitor that uses an HTTPMonitor will submit a GET request to the backend service once every five seconds. The sample below adds an HTTP Basic Authorization header to the request message. The Response configuration defines settings that will be compared against actual response from the backend service. In the example below, the expected response is an HTTP response code 200 and a custom HTTP header ImOK whose value is YourOK. If the response does not match, then the request will treated as a failure by the load balancer configuration.

The HTTPMonitor supports backend services configured to use HTTP and one-way HTTPS protocols. However, it does not support two-way HTTPS, also called two-way TLS/SSL. 

HTTP の監視では、呼び出す必要があるバックエンドサービスに対して、すべての 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>

HealthMonitor に指定できる HTTPMonitor 構成要素

Name 説明 デフォルト 必須であるかどうか
IsEnabled HealthMonitor を有効または無効にするブール演算子。 false
IntervalInSec ポーリングリクエスト間の秒を単位とする時間間隔。 0
Request ローテーションで HealthMonitor が TargetServer に送信する送信リクエストメッセージの構成オプション。 該当なし
ConnectTimeoutInSec 成功と判定するために TCP 接続が HTTP サービスへのハンドシェイクを完了しておく必要がある時間 (単位は秒)。指定された時間、接続を維持できなかった場合、その接続は失敗とカウントされ、当該 TargetServer に対して LoadBalancer の失敗カウントが加算されます。 0
SocketReadTimeoutInSec 成功と判定するために HTTP サービスからデータを読み込んでおく必要がある秒数。指定された時間までに読み込みを完了できなかった場合、その読み込みは失敗とカウントされ、当該 TargetServer に対して LoadBalancer の失敗カウントが加算されます。 0
Port バックエンドサービスへの HTTP 接続が確立されるポート。 該当なし
Verb バックエンドサービスへの各ポーリング HTTP リクエストに使用される HTTP 動詞。 該当なし
Path TargetServer に定義された URL に追加されるパス。このパス要素を使用して、HTTP サービスで「ポーリングエンドポイント」を構成します。 該当なし
Payload 各ポーリング HTTP リクエストのために生成される HTTP 本文。この要素は GET リクエストには不要です。ご注意ください。 該当なし
SuccessResponse SuccessResponse 受信 HTTP レスポンスメッセージの一致オプション (ポーリングされたバックエンドサービスによって生成される)。レスポンスが一致しない場合、失敗カウントが 1 ずつ加算されます。 該当なし
ResponseCode ポーリングされた TargetServer から受信すると予想される HTTP レスポンスコード。コードが指定されたコードと異なっている場合、失敗と見なされ、ポーリングされたバックエンドサービスに対してカウントが加算されます。複数の ResponseCode 要素を定義できます。 該当なし
Headers ポーリングされたバックエンドサービスから受信すると予想される 1 つ以上の HTTP ヘッダーと値のリスト。レスポンスの HTTP ヘッダーまたは値が一部でも指定された値と異なる場合、失敗と見なされ、ポーリングされた TargetServer のカウントが 1 ずつ加算されます。複数の Header 要素を定義できます。 該当なし

 

Help or comments?