ある企業がAPI GatewayのREST APIを本番運用しており、以下の2つの問題が発生している。 問題1: 一部のリクエストでLambda統合タイムアウト(29秒)に達してAPI Gatewayが504エラーを返している。 問題2: クライアントが再試行を行うため、タイムアウトした処理が実際には完了しているにもかかわらず二重実行される。 これらの問題に対処するためのアーキテクチャ変更として最も適切なものを2つ選択してください。
- A. 処理を非同期化し、API GatewayはリクエストをSQSキューに投入して即座に202(Accepted)を返し、別のLambda関数がキューを処理する
- B. Lambda関数のメモリを10,240 MBに増やしてタイムアウト前に処理が完了するよう高速化する
- C. API Gatewayの統合タイムアウトを30秒から60秒に延長してLambdaに十分な実行時間を与える
- D. API Gatewayの前段にSQSを配置する代わりに、API GatewayからStep Functionsのエクスプレスワークフローを同期実行する
- E. 処理開始時にDynamoDBに一意のリクエストIDを条件付き書き込みし、重複リクエストをスキップするべき等性ロジックをLambda内に実装する
解答と解説を見る
正解: A, E
問題1(504タイムアウト)の解決には選択肢A(非同期化)が最も適切である。API GatewayのREST APIには29秒の統合タイムアウト制限があり、これは変更できない。長時間処理をSQSキューに投入してクライアントには即座に202を返す非同期パターンに変更することで、API Gatewayのタイムアウト制限を回避できる。問題2(二重実行)の解決には選択肢E(べき等性ロジック)が必要である。クライアントの再試行による二重実行を防ぐには、処理側で「このリクエストは既に処理したか」を確認するロジックが必要であり、DynamoDBの条件付き書き込みによるリクエストIDの記録が確実な方法である。選択肢CについてはAPI Gatewayの統合タイムアウトは最大29秒に固定されており、30秒を超える値に変更できないため事実として誤りである。選択肢DのStep Expressワークフローの同期実行はAPI Gatewayから呼び出せるが、Expressワークフロー自体の最大実行時間は5分であり、タイムアウト問題には対処できるが依然として同期実行であるためAPIのブロッキングは続く。また、追加の問題(べき等性)の解決にはならない。選択肢Bのメモリ増量は処理によっては高速化できるが、I/O待機が主要因の長時間処理には効果がなく、根本解決にならない。
📚 関連サービスの解説: Amazon API Gateway ・ Amazon SQS