I/O タイムアウトを構成するためのベスト プラクティス

Apigee Edge のドキュメントを表示しています。
Apigee X のドキュメントに移動します。
情報

クライアント アプリケーションから送信された API リクエストは、バックエンド サービスに到達する前に Apigee Edge のさまざまなコンポーネントを通過します。ほとんどのクライアント アプリケーションは、これらのリクエストに対するレスポンスがタイムリーに受信されることを想定しています。

タイムリーなレスポンスを実現するため、API リクエストが流れる各コンポーネントで I/O タイムアウト値が設定されています。フロー内のコンポーネントのいずれかが前のコンポーネントよりも時間がかかると、前のコンポーネントがタイムアウトし、504 Gateway Timeout エラーで応答します。

タイムアウトを構成する際は、各コンポーネントで値を慎重に構成する必要があります。そうしないと、 504 Gateway Timeout エラーが発生する可能性があります。

このドキュメントでは、Apigee Edge で API リクエストが流れるさまざまなコンポーネントで I/O タイムアウトを構成するためのベスト プラクティスについて説明します。

I/O タイムアウトの構成に関するベスト プラクティス

I/O タイムアウトを構成する際は、次のベスト プラクティスを考慮してください。

  • 最初のコンポーネント: API リクエスト フローの最初のコンポーネント(Apigee Edge のクライアント アプリケーション)では、常に最も長いタイムアウトを使用します。
  • 最後のコンポーネント: API リクエスト フローの最後のコンポーネント(Apigee Edge のバックエンド サービス)では、常に最も短いタイムアウトを使用します。
  • コンポーネント間: フローの最初のコンポーネントと最後のコンポーネントの間で、各コンポーネントに構成されたタイムアウト値に 2 ~ 3 秒以上の差があることを確認します。
  • Router: Router で構成するのではなく、特定の仮想ホストの I/O タイムアウト値を構成(変更)することをおすすめします。これにより、新しいタイムアウト値は、特定の仮想ホストを使用している API プロキシにのみ影響し、ルーターによって処理されるすべての API プロキシには影響しません。

    Router で実行されているすべての API プロキシに新しい I/O タイムアウト値が必要であるか、適用可能であることが確実な場合にのみ、Router の I/O タイムアウトを構成(変更)します。

  • Message Processor: Message Processor で構成するのではなく、特定の API プロキシの I/O タイムアウト値を構成(変更)することをおすすめします。これにより、新しいタイムアウト値は特定の API プロキシにのみ影響し、Message Processor によって処理されるすべての API プロキシには影響しません。

    Message Processor の I/O タイムアウトを構成(変更)するのは、新しい I/O タイムアウト値が Message Processor で実行されているすべての API プロキシで必要または適用可能であることが確実な場合に限ります。

サンプル事例

このセクションのシナリオは、I/O タイムアウト値を正しく設定する方法を理解するのに役立ちます。

シナリオ 1: クライアント アプリケーションから Apigee Edge へのリクエスト

このセクションでは、クライアント アプリケーションと Apigee Edge の間、および Apigee Edge とバックエンド サーバーの間に中間コンポーネントがない Apigee Edge の設定で、タイムアウト値を設定する際のベスト プラクティスについて説明します。

中間コンポーネントのない Apigee の設定例

クライアントから Router、Message Processor、バックエンド サーバーに移動するフロー

上の図に示すように、中間コンポーネントなしで Apigee Edge を設定する場合は、次のベスト プラクティスを使用します。

  1. クライアント アプリケーションはフローの最初のコンポーネントです。最大タイムアウト値はクライアントで設定する必要があります。
  2. バックエンド サーバーはフローの最後のコンポーネントです。最小タイムアウト値は、バックエンド サーバーで設定する必要があります。
  3. 次の順序で、各コンポーネントのタイムアウト値を構成します。

    クライアント、Router、Message Processor、バックエンド サーバーの順にタイムアウトを構成する

    次の例は、上記で説明したガイドラインに沿って、さまざまなコンポーネントに設定されたタイムアウト値を示しています。

    クライアントのタイムアウトを 60 秒、Router のタイムアウトを 57 秒、Message Processor のタイムアウトを 55 秒、バックエンド サーバーのタイムアウトを 52 秒に構成します。

シナリオ 2: 中間コンポーネントを介したクライアント アプリケーションから Apigee Edge へのリクエスト

このセクションでは、クライアント アプリケーションと Apigee Edge の間、および Apigee Edge とバックエンド サーバーの間に 1 つ以上の中間コンポーネントがある Apigee Edge の設定で、タイムアウト値を設定する際のベスト プラクティスについて説明します。

中間コンポーネントは、ロードバランサ、コンテンツ配信ネットワーク(CDN)、NGINX などです。

クライアントと Apigee Edge の間、および Apigee Edge とバックエンド サーバーの間に 1 つの中間コンポーネントがある Apigee の設定例

クライアントから始まり、中間コンポーネント 1、ルーター、Message Processor、中間コンポーネント 2、バックエンド サーバーへと続くフロー

Apigee Edge が上記の図のように、1 つ以上の中間コンポーネントを使用して設定されている場合は、次のベスト プラクティスを使用します。

  1. クライアント アプリケーションはフローの最初のコンポーネントです。最大 タイムアウト値はクライアントで設定する必要があります。
  2. バックエンド サーバーはフローの最後のコンポーネントです。最小 タイムアウト値は、バックエンド サーバーで設定する必要があります。
  3. 中間コンポーネントを含む各コンポーネントのタイムアウト値を次の順序で構成します。

    クライアント、中間コンポーネント 1、ルーター、Message Processor、中間コンポーネント 2、バックエンド サーバーの順にタイムアウトを構成する

    次の例は、上記で説明したガイドラインに沿って、さまざまなコンポーネントに設定されたタイムアウト値を示しています。

    クライアントのタイムアウトを 63 秒、中間コンポーネント 1 を 60 秒、ルーターを 57 秒、Message Processor を 55 秒、中間コンポーネント 2 を 52 秒、バックエンド サーバーを 59 秒に構成します。