Elastic Beanstalk で API スロットリングまたは「レート超過」エラーを解決するにはどうすればよいですか?

所要時間1分
0

AWS Elastic Beanstalk を使用している際に発生する API スロットリングまたは「レートを超過しました」エラーを解決する方法を教えてください。

簡単な説明

AWS サービスへの API 呼び出しは、1 秒あたりに許可される最大 API リクエストレートを超えることはできません。この制限は、アカウントごと、および AWS リージョンごとにすべてのリソースで共有されます。

呼び出しがアプリケーション、AWS コマンドラインインターフェイス (AWS CLI)、AWS マネジメントコンソールのいずれから来たかは関係ありません。API リクエストが 1 秒あたりの最大レートを超えると、「Rate Exceeded」エラーが表示され、API 呼び出しが抑制されます。API 呼び出しの中には、1 秒間に数十回実行できるものもあれば、1 秒間に数回の呼び出しに制限されるものもあります。

注意: AWS CLI コマンドの実行中にエラーが発生した場合は、最新バージョンの AWS CLI を使用していることを確認してください

Elastic Beanstalk に直接行われる API 呼び出しや、AWS CloudFormation、Amazon Elastic Compute Cloud (Amazon EC2)、Auto Scaling、ロードバランシングなど、Elastic Beanstalk によって管理されている他の AWS のサービスからエラーを受け取ることができます。スロットルのリスクは、アカウントの使用量が増えたり、同じアカウントにリソースを追加したりするにつれて大きくなります。

**注意:**当社のサービスは負荷に応じて調整されるため、呼び出しの制限は時間帯によって異なる場合があります。動的制限の動作に合わせて調整するには、API を使用するレートを動的に調整することがベストプラクティスです。

解決方法

「レートを超過しました」エラーとスロットリングを防止または解決するには、以下の解決策を試してください。

高い API 呼び出しのソースを見つける

1.    Elastic Beanstalk イベントストリームで、スロットリングエラーを特定します。エラーが発生した時間枠を書き留めます。または、API 呼び出しがアプリケーションまたはスクリプトから来ている場合は、アプリケーションログで時間枠を探します。

2.    RequestLimitExceeded エラーのある時間枠で見つかったリクエストについては、AWS CloudTrail を使用してイベントを表示し、eventNameeventSource (サービス)、userAgent を検証します。Elastic Beanstalk イベントまたはログのエラーのタイムスタンプを、CloudTrail で見つかったエラーと照合します。これにより、アカウント内のどのソースが API 呼び出しを最も多く消費しているかを知るのに役立ちます。

注意: CloudTrail レコードを手動でカウントするのは難しい場合があります。CloudTrail 経由で Athena クエリを使用することもできます。

Amazon CloudWatch の使用状況メトリクスは、API の使用状況を経時的にモニタリングするのに役立ちます。現時点では、すべてのサービスと API 呼び出しが使用状況メトリクスでサポートされているわけではないことに注意してください。

サードパーティーアプリケーションは、Elastic Beanstalk または Elastic Beanstalk が管理する他の AWS のサービスを継続的に呼び出すことができます。アカウントで API 呼び出しを行う権限をサードパーティアプリケーションに付与する場合は、これらも監視するようにしてください。

ベストプラクティスを使用して API の使用量を減らす

エラーの再試行、エクスポネンシャルバックオフを使用して、API 呼び出しのレートを制限します。それぞれの AWS SDK には自動再試行ロジックとエクスポネンシャルバックオフアルゴリズムが実装されていますが、デフォルトの再試行ロジックでは不十分な場合は、ニーズに合わせて SDK の設定を調整する必要があります。

注意: SDK の設定は、考慮すべき部分の 1 つにすぎません。また、独自のコードでは、SDK を呼び出すときにバックオフ、再試行、およびジッターロジックを使用する必要があります。

毎秒 API 呼び出しを行うカスタムスクリプトがある場合は、これが必要かどうかを検討してください。高度なユースケースでは、API の消費を減らすためにキャッシングレイヤーを作成することを検討してください。マルチアカウント戦略を検討することもできます。1 つの AWS アカウントが大きくなりすぎないようにするのがベストプラクティスです。開発リソースまたはテストリソースを本番リソースから分離すると、開発リソースが本番リソースから API の使用を奪うのを防ぐことができます。

API コールレート制限の上限引き上げをリクエストする

必要に応じて、API コールレート制限の上限引き上げをリクエストできます。これらの制限は、通常のリソースベースの制限よりも増やすのが難しく、ユースケースを正当化する必要があります。当社のチームがお客様の API をレビューし、ベストプラクティスが守られていることを確認します。リクエストは、必要になる前に十分に行う必要があります。

引き上げをリクエストする場合は、次の情報を含めてください。

  • お客様の AWS リージョンとスロットリングの問題に関連する期間
  • 使用する API 呼び出しと必要なコールレート
  • ビジネスニーズや増加に対する技術的ニーズなど、詳細なユースケースの正当化

リクエストを送信する前に、必ずエラーの再試行、エクスポネンシャルバックオフ、およびジッターを使用してみてください。これらの試行の結果をリクエストに含め、試行に関連する情報を含めます。


関連情報

AWS でのエラーの再試行とエクスポネンシャルバックオフ

エクスポネンシャルバックオフとジッター

AWS CloudTrail を使用した Elastic Beanstalk API 呼び出しのログ記録

CloudWatch 使用量メトリクス

複数の AWS アカウントを使用する利点

AWS公式
AWS公式更新しました 2年前
コメントはありません

関連するコンテンツ