API ゲートウェイに問題があります。いくつかの API メソッドを作成しましたが、10 秒以上動作することがあり、Amazon が 504 エラーを返します。以下にスクリーンショットを示します。
助けてください!タイムアウトを増やすにはどうすればよいですか?
ありがとう!
API ゲートウェイに問題があります。いくつかの API メソッドを作成しましたが、10 秒以上動作することがあり、Amazon が 504 エラーを返します。以下にスクリーンショットを示します。
助けてください!タイムアウトを増やすにはどうすればよいですか?
ありがとう!
現在、 http://docs.aws.amazon.com/apigateway/latest/developerguide/limits.htmlによると、Lambda 呼び出しまたは HTTP 統合のデフォルトの制限は30 秒であり、この制限は構成できません。
少なくとも今は、タイムアウトを増やすことはできません。エンドポイントは 10 秒以内に完了する必要があります。エンドポイントの速度の改善に取り組む必要があります。
http://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html
「joarleymoraes」の投稿にコメントしたかったのですが、十分な評判がありません。それに追加する唯一のことは、非同期を使用するためにリファクタリングする必要がないことです。それは、バックエンドと、それを分割する方法とクライアント側の再試行に依存するだけです。
504 の割合が高くなく、非同期処理の準備ができていない場合は、指数バックオフを使用してクライアント側の再試行を実装して、永続的な失敗にならないようにすることができます。
AWS SDK はバックオフを使用して再試行を自動的に実装するため、特にLambda レイヤーを使用すると、デプロイ パッケージを常に更新しなくても関数の SDK を維持できるため、再試行が容易になります。
これを行うと、永続的な障害ではなくなるため、タイムアウトに対する可視性が低下します。これにより、最初に 504 が発生しているというコアの問題に対処するための時間を稼ぐことができます。これは確かに、コードをリファクタリングして応答性を高め、大規模な機能をより「マイクロ サービス」タイプの概念に分割し、外部ネットワーク呼び出しを減らすことを意味します。
再試行のもう 1 つの利点は、アプリケーションからのすべての 5xx 応答を再試行すると、通常の実行中に発生する可能性のあるさまざまな問題をカバーできることです。一般に、すべてのアプリケーションで、これらの問題を 100% 回避することはできないと考えられているため、先に進んで最悪の事態に備えて計画することをお勧めします。
そうは言っても、ラムダの実行時間を短縮するか、非同期にすることに引き続き取り組む必要があります。これにより、タイムアウト値をはるかに小さい数値に設定できるようになり、より速く失敗することができます。これは、失敗したリクエストを再試行するために 29 秒待つ必要がないため、フロントエンドへの影響を軽減するのに非常に役立ちます。