APIゲートウェイのタイムアウト：原因と解決策

API（アプリケーションプログラミングインターフェース）は、現代のWebアプリケーションやマイクロサービスにおいて、クライアントと様々なサービスを接続する最も一般的な方法です。APIゲートウェイは、データフローを管理、保護、最適化する重要な架け橋となります。しかし、最適なAPIパフォーマンスを実現する上で大きな課題となるのが、APIゲートウェイのタイムアウトエラーです。

この記事では、APIゲートウェイのタイムアウトについて、その発生原因と回避方法を例と実装例を交えて解説します。

API ゲートウェイとは何ですか?

APIゲートウェイとは、バックエンドサービスからリソースを要求するクライアントからのAPIリクエストを処理するサーバーまたはマネージドサービスです。事前定義されたポリシーを使用して主要な機能を提供し、クライアントアプリケーションとバックエンドサービス間のやり取りを簡素化および管理します。ほとんどの場合、APIゲートウェイはリクエストを複数のマイクロサービスに渡して結果を集約し、エンドユーザーに簡素化されたユーザーエクスペリエンスを提供します。

APIゲートウェイの仕組み

APIゲートウェイは、クライアントとサービスの間に位置することで機能します。クライアントからのリクエストを受け取ると、関連するバックエンドサービスにリクエストを送信し、すべてのレスポンスを集約します。リバースプロキシとして機能することで、クライアントのリクエストをさまざまなサービスにルーティングします。

APIゲートウェイは主に、アクセス制御を伴うルーティングポリシーを実装します。また、認証、セキュリティ、ログ記録、監視ポリシーをAPIゲートウェイに実装することも一般的です。さらに、SSL、DDoS攻撃対策、WAFなどのセキュリティ対策を追加することで、セキュリティを強化することも可能です。

APIゲートウェイのタイムアウトとは何ですか？

マイクロサービス環境において、APIゲートウェイのタイムアウトとは、APIゲートウェイがクライアントからのリクエストを関連サービスにルーティングし、レスポンスをクライアントに返すまでに要する合計時間のことです。APIゲートウェイは、リクエストの処理に必要なアップストリームサービスからタイムリーなレスポンスが得られない場合、エラー（通常はステータスコード504）をスローします。APIゲートウェイのタイムアウトは、ゲートウェイがクライアントからバックエンドサービスへのリクエストとレスポンスのサイクルを待機する最大時間です。

APIゲートウェイのタイムアウトの種類 

特定のフェーズやコンポーネントで発生する可能性のある、一般的なAPIゲートウェイタイムアウトの種類を以下に示します。

APIゲートウェイのタイムアウトの一般的な原因

APIゲートウェイのタイムアウトは、さまざまな理由で発生します。一般的な原因を以下に示します。

サーバー過負荷

APIゲートウェイのバックエンドサービスが大量のリクエストで過負荷状態になると、処理速度が低下し、応答しなくなり、APIゲートウェイのタイムアウトが発生します。サーバーリソースの不足や非効率なコードも、サーバーの過負荷の原因となることがあります。バックエンドサービスの容量を超えるトラフィックの急増も、バックエンドサービスの過負荷につながる可能性があります。 

LogicMonitor Tracingのようなツールを使えば、サーバーのリクエストとレスポンスのメトリクスをレポートできるため、問題を迅速に特定して修正できます。チームは、重要なビジネスKPIやデジタルエクスペリエンスに基づくシグナルをオブザーバビリティフレームワークに組み込むことで、一貫したユーザーパフォーマンスを実現できます。 

ネットワークの問題

APIゲートウェイとバックエンドサービス間の接続が、高遅延、パケット損失、DNS/BGPの問題、またはネットワークリンクの混雑などにより不安定になると、リクエストとレスポンスのサイクルが遅くなります。この遅延は伝播し、APIゲートウェイのタイムアウトを引き起こします。
ネットワークの問題を検出して軽減するには、アクティブな監視とリアルタイムのアラートが必要です。たとえば、LogicMonitor の トレース また、BGP監視ツールには、さまざまなテスト場所を順番にテストできる機能があり、これは非常に稀ではあるものの、地域ネットワークの問題やボトルネックを発見する上で非常に効果的です。

最適化されていないデータベースクエリ

非効率的で最適化が不十分なデータベースクエリは、APIゲートウェイのタイムアウトを引き起こす可能性があります。データ量が増加するにつれて、データベースクエリが遅いバックエンドサービスはますます遅くなります。最終的に、これらのサービスが最適化されないまま放置されると、使用できなくなります。また、N+1クエリもAPIゲートウェイのタイムアウトの一般的な原因であり、ループを削除することで容易に軽減できます。
LogicMonitorトレース アプリケーションのパフォーマンス向上のため、最適化されていないデータベースクエリを検出する機能が組み込まれています。

長時間実行されるタスク

複雑なアルゴリズム計算やデータ処理など、時間のかかる計算を実行するバックエンドサービスは、APIゲートウェイのタイムアウト問題が発生しやすい。タスクに時間がかかりすぎると、APIゲートウェイは一定時間待機した後、タイムアウトエラーを返す。 

資源枯渇

バックエンドサービスがCPUやストレージなどのリソースを使い果たすと、応答しなくなり、APIゲートウェイのタイムアウトにつながる可能性があります。リソース枯渇を避けるためには、十分なリソースを割り当てる必要があります。

APIゲートウェイのタイムアウトを回避するためのベストプラクティス

APIゲートウェイのタイムアウトを回避し、APIの信頼性を確保するためには、一連のベストプラクティスを実装することが不可欠です。これらのベストプラクティスは、サーバーサイドとクライアントサイドの2つのサブカテゴリに分類できます。

サーバーサイドのプラクティス

バックエンドサービスが適切に最適化されていない場合、APIゲートウェイのパフォーマンスが低下します。そのため、APIゲートウェイのタイムアウトを回避するには、バックエンドコードとデータベースクエリを適切に最適化する必要があります。APIゲートウェイのタイムアウトエラーを減らすには、バックエンドサービスに以下の変更を加えると良いでしょう。

適切なキャッシュ戦略

頻繁にリクエストされるデータをキャッシュすることで、APIゲートウェイへの負荷を軽減できます。データを保存して迅速に配信するキャッシュメカニズムを実装することで、APIゲートウェイのタイムアウト問題を大幅に削減できます。ただし、古いデータの問題が発生しないよう、細心の注意を払う必要があります。静的アセットはコンテンツ配信ネットワーク（CDN）を使用して配信でき、キャッシュ戦略を実装する際には、キャッシュヘッダーによって古いデータの問題を防ぐことができます。

リクエストのスロットルとレート制限を設定する

APIゲートウェイのタイムアウトの主な原因の一つは、サーバーの過負荷です。サーバーの過負荷を防ぐには、リクエストのスロットリングとレート制限を設定してください。これにより、受信リクエストを制御し、バックエンドサービスの過負荷を防ぐことができます。制限値は、サーバーの容量と使用状況に基づいて設定する必要があります。

非同期処理を使用する

長時間実行されるタスクの代わりに、非同期処理を使用してください。長時間実行されるタスクを並列実行可能なサブタスクのチャンクに分割することで、リソースと実行時間を節約でき、API ゲートウェイのパフォーマンスが向上します。分割が不可能な場合は、リソースを大量に消費する処理をキューやバックグラウンドワーカーにオフロードすることを検討してください。 

エラー処理と再試行管理

エラーや例外をスムーズに処理する、堅牢なエラー処理機能を実装してください。失敗したリクエストに対して自動的に再試行するように設定することで、クライアントエクスペリエンスを向上させ、バックエンドサービスが障害から復旧する機会を増やすことができます。

回路遮断器パターンを実装する

バックエンドサービスの障害や遅延は、他のサービスのパフォーマンスを阻害します。特に、APIゲートウェイが失敗したリクエストを複数回再試行するように設計されている場合、問題は急速に悪化する可能性があります。この悪化を防ぐには、サーキットブレーカーパターンを実装し、サーキットブレーカーが失敗したリクエストを一時的にブロックするようにします。これにより、サービスのさらなる劣化を防ぐことができます。

合成監視および警報

合成監視とアラートメカニズムを組み合わせることで、APIゲートウェイのタイムアウトを回避するための積極的な戦略となります。ユーザー操作をシミュレートし、スケジュールされたテストを実行することでパフォーマンスのベースラインを確立し、問題や逸脱を早期に検出できます。 総合モニタリングこれにより、テスト結果の継続的な分析、APIゲートウェイ構成の反復的な最適化のための貴重な洞察の提供、潜在的な問題が影響を及ぼされる前に特定されることを保証しながらの容量計画が可能になります。

クライアント側の業務

クライアント側のプラクティスとは、クライアントからのリクエスト処理を最適化するAPIゲートウェイ構成を指します。

同時リクエストの管理

同時リクエストを適切に管理することで、スムーズなユーザーエクスペリエンスを実現できます。クライアントサイドのコードを最適化し、同時リクエストによってタスクを効率的に分散させ、水平方向にスケーリングすることで、過負荷やタイムアウトを防ぎながら、ユーザーインターフェースの応答性を維持できます。最新のブラウザではドメインごとの接続数に上限が設けられているため、同時リクエスト数には特に注意が必要です。例えば、Google Chromeではドメインごとに6つの接続が許可されており、他のブラウザでも同様のデフォルト値が設定されています。

キャッシュ応答

クライアント側のキャッシュは、サーバー側のキャッシュと同様に重要です。頻繁に発生するリクエストをクライアント側でキャッシュすることで、リクエスト数とAPI呼び出し数を大幅に削減できます。また、応答時間も最適化されます。

API利用の最適化

レスポンス時のデータ転送量を最小限に抑え、不要な呼び出しを回避し、バッチ処理を活用することで、APIのパフォーマンスを向上させることができます。クライアントとAPI間のやり取りを効率化することで、タイムアウトのリスクを大幅に軽減し、リソースを節約できます。

指数バックオフ

指数バックオフ方式は、一時的なサービス障害が発生した場合に、APIへの再試行間隔を徐々に長くしていく方式です。再試行間隔を動的に調整することで、成功率を高めることができます。これは、APIゲートウェイのタイムアウトを未然に防ぎ、信頼性を維持するための予防策です。

アクティブモニタリング

アクティブモニタリングは、リアルタイムデータを継続的に監視・分析します。これにより、パフォーマンスの異常を積極的に検知し、問題発生時に迅速な対応が可能になります。アクティブモニタリングデータと合成モニタリングデータを関連付けることで、システム動作をより包括的に理解することもできます。アクティブモニタリングは、合成モニタリングによって設定された事前定義済みのベースラインに現実世界の動的な要素を加えることで、動的な環境におけるAPIゲートウェイのタイムアウトリスクをさらに低減します。

AWSにおけるAPIゲートウェイのタイムアウト実装

次のサーバーレスプロジェクトを考えてみましょう。下の図は元のプロジェクトを簡略化したもので、AWS API Gateway の下にあるマイクロサービスの一部のみを示しています。Web アプリケーションやモバイル アプリのすべてのクライアントは、ゲートウェイ経由で接続します。AWS API Gateway は、認証、ログ記録、WAF およびログ記録を処理します。

トラフィックが多いときに API Gateway タイムアウトが発生している、ハイライト表示されている長時間実行タスクに注目してください。この実装の問題点は、Lambda 関数を使用してオンデマンドで Crawler サービスをトリガーし、ターゲットの Web サイトからリアルタイムでデータを抽出し、結果を別の Lambda 関数に返して、結果とアセットをストレージに保存していることです。トラフィックが少ない小規模な環境では問題なく動作します。しかし、トラフィックが増加するにつれて、バックエンド サービスが受信リクエストを処理するのに非常に時間がかかるため、このエンドポイントの処理速度が低下し、タイムアウト エラーが発生し始めます。

考えられる解決策の一つは、クローラーサービスをバックグラウンドタスクキューに移動し、定期的にデータをクロールしてストレージに保存することです。これにより、影響を受けるエンドポイントの負荷が軽減され、処理速度が向上します。実装例は以下のようになります。

ご覧のとおり、エンドポイントのLambda関数はRDSからデータをほぼ瞬時に計算し、リクエスト処理にクローラーを直接依存しません。S3バケットからクロールされたアセットのバックアップもRDSから別のプロセスに移行され、データベースのパフォーマンスがさらに向上しています。

注意すべき点の1つは、AWS API Gatewayのタイムアウトのデフォルトの設定は29秒ですが、APIのリソースを設定することで、より短い時間に設定することが可能です。

AWS API Gateway タイムアウト設定

API Gateway のタイムアウト設定は非常に簡単です。Amazon API Gateway で REST API リソースのエンドポイントを作成する際にタイムアウトを設定できます。`API Gateway > APIs` から目的の `API` に移動し、以下のようにメソッドを定義します。

デフォルトでは、Amazon API Gateway のタイムアウトは 29 秒に設定されています。上記の「デフォルトタイムアウト」設定を切り替えて、「カスタムタイムアウト」設定を表示する必要があります。上記の例では、タイムアウトを 15 秒に設定しています。AWS API Gateway のデフォルトタイムアウトの最大制限は 29 秒です。Lambda 関数の実行時間がこれより長い場合、タイムアウトエラーが発生します。

AWS LambdaにおけるAPIゲートウェイのタイムアウトへの一般的な対処法

AWS Lambda における API ゲートウェイのタイムアウトへの対処には、戦略的なアプローチが必要です。主な目標は、Lambda 関数の実行時間をタイムアウト設定値以下に抑えることです。Lambda が複数のタスクを実行する場合は、それらをより小さな関数に分割し、複数の Lambda に分散して並列実行することで、全体の計算時間を短縮するのが望ましいです。並列計算が不可能な場合は、SQS、SNS などの非同期サービスを使用して計算と処理をオフロードします。また、頻繁に発生する計算リクエストの結果をキャッシュすることで Lambda の負荷を軽減するために、キャッシュ統合と指数バックオフ戦略を適切に実装してください。

他のパブリッククラウドプロバイダーにおけるAPIゲートウェイのタイムアウト

Google Cloud PlatformとMicrosoft Azureはどちらも、APIゲートウェイのタイムアウト設定を簡単にカスタマイズできる便利な方法を提供しています。以下のセクションでは、GCPとAzureにおけるAPIゲートウェイのタイムアウト設定方法について説明します。他のクラウドプロバイダーでも同様のタイムアウト設定方法が用意されていますので、該当するドキュメントをご確認ください。

GCP

バックエンドサービスの API ゲートウェイタイムアウトを設定するには、 締め切り `x-google-backend` OpenAPI拡張機能のパラメータです。エンドポイントごとにタイムアウト設定をカスタマイズできます。例えば、以下のサンプル`openapi2-functions.yaml`ファイルをご覧ください。

swagger: '2.0'
info:
  title: sample-api
  description: Sample API on API Gateway
  version: 1.0.0
schemes:
  - https
produces:
  - application/json
paths:
  /microservice_1:
    get:
      summary: Microservice 1 endpoint
      operationId: microservice_1
      x-google-backend:
        address: https://microservice_1
        deadline: 75
      responses:
        '200':
          description: Success
          schema:
            type: string
  /microservice_2:
    get:
      summary: Microservice 2 endpoint
      operationId: microservice_2
      x-google-backend:
        address: https://microservice_2
        deadline: 30
      responses:
        '200':
          description: Success
          schema:
            type: string

`microservice_1`と`microservice_2`は、`x-google-backend` OpenAPI拡張機能の`deadline`パラメータを利用して、それぞれタイムアウト設定が`75秒`と`30秒`に設定されています。

Azure

同様に、Microsoft Azure では、受信ポリシーと送信ポリシーを定義する際に、XML 構成の `forward-request` オプションを使用して API ゲートウェイのタイムアウト設定を構成する方法も提供しています。以下の構成例を参照してください。

<!-- api gateway timeout -->
<policies>
    <inbound>
        <!-- other inbound policies here -->
        <base/>
    </inbound>
    <backend>
        <!-- other backend configs here -->
        
        <!-- set timeout to 180s -->
        <forward-request timeout="180"/>
    </backend>
    <outbound>
        <!-- outbound policies here -->
        <base/>
    </outbound>
</policies>

ご覧のとおり、バックエンドで `forward-request` を使用すると、タイムアウトは `180` 秒に設定されます。これを ` 内に配置する必要があります。 `タグ。

オンプレミス

オンプレミス環境への導入には、多くの選択肢があります。例えば、NGINX、HAProxy、Apacheサーバーなどを使用して、タイムアウト機能を備えたAPIゲートウェイを実装できます。ここでは、NGINX APIゲートウェイをカスタマイズしてタイムアウトを設定する方法を見ていきましょう。

location /api/v1/ {
    # Policy configurations here such as authentication, rate limiting, logging, etc.

    access_log /var/log/nginx/api/v1/.log main;

    location /api/v1/microservice_1 {
        proxy_pass https://microservice_1;
        proxy_connect_timeout 60s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
        # Other relevant configs here
    }

    location /api/v1/microservice_2 {
        proxy_pass https://microservice_2;
        proxy_connect_timeout 30s;
        proxy_read_timeout 30s;
        proxy_send_timeout 30s;
    }
    keepalive_timeout 180s;
    send_timeout 60s;
    client_body_timeout 180s;
    client_header_timeout 180s;
    # show errors on other
    return 404; 
}

サービスごとに異なるタイムアウトを設定できることに注意してください。タイムアウトを設定するための3つの主要な要素は、`proxy_connect_timeout`、`proxy_read_timeout`、および`proxy_send_timeout`です。 

`keepalive_timeout` などのパラメータやその他のタイムアウトも、この文脈では非常に重要です。これらのタイムアウトは、さまざまな API ゲートウェイのタイムアウト設定を制御します。詳細については、以下を参照してください。 ドキュメント.

結論

この記事では、APIゲートウェイのタイムアウトとは何か、タイムアウトの種類、そして一般的な原因について解説しました。また、クライアント側とサーバー側の両方における戦略を用いて、APIゲートウェイのタイムアウトを回避するためのベストプラクティスについても学びました。さらに、様々なクラウドプロバイダーやオンプレミス環境におけるAPIゲートウェイの実装と構成プロセスについても見てきました。

適切な対策を講じることで、APIゲートウェイのタイムアウトエラーを回避し、APIゲートウェイが正しく安全に実装されることを保証できます。可能な限り、業界標準の方法を用いてバックエンドサービスとリソースを最適化および監視し、APIがトラフィックを容易に処理できるほど堅牢で回復力のあるシステムとなるようにすることが重要です。

よくあるご質問