Amazon S3 が HTTP 500 または 503 エラーを返す場合のトラブルシューティング方法を教えてください。

所要時間2分

Amazon Simple Storage Service (Amazon S3) にリクエストを行うと、Amazon S3 は 5xx ステータスエラーを返します。

簡単な説明

Amazon S3 にリクエストを行う際、次の例に類似したエラーメッセージが表示される場合があります。

"AmazonS3Exception: Internal Error (Service: Amazon S3; Status Code: 500; Error Code: 500 Internal Error; Request ID: A4DBBEXAMPLE2C4D)"
"AmazonS3Exception: Slow Down (Service: Amazon S3; Status Code: 503; Error Code: 503 Slow Down; Request ID: A4DBBEXAMPLE2C4D)"

エラーメッセージ "500 Internal Error" は、Amazon S3 はその時点でリクエストを処理できない場合に表示されます。エラーメッセージ "503 Slow Down" は通常、S3 バケットが受信するリクエスト数が多い場合に表示されます。パーティション化された Amazon S3 のプレフィックスごとに、1 秒あたり 3,500 件の PUT/COPY/POST/DELETE リクエストまたは 5,500 件の GET/HEAD リクエストを送信できます。ただし、リクエストが AWS リージョン間のコピーに利用できる帯域幅を超過した場合、Amazon S3 は応答 "503 Slow Down" を返す可能性があります。

5xx ステータスエラーを解決または回避するには、次の手順を実行します。

リクエストを行うアプリケーションにおいて、再試行メカニズムを実装します。
リクエストレートを徐々に上げるようにアプリケーションを設定します。
オブジェクトを複数のプレフィックスに分散します。
5xx エラー応答の数を監視します。

注: プレフィックスの作成時、Amazon S3 は、サポートされるリクエストレートに追加リソースを自動では割り当てません。Amazon S3 はリクエストパターンに基づいてスケーリングします。リクエストレートが上がると、Amazon S3 は新しいリクエストレートに対して動的に最適化します。

解決策

再試行メカニズムを使用する

Amazon S3 は分散型であるため、500 または 503 のエラーを返すリクエストを再試行できます。Amazon S3 にリクエストを行うアプリケーションには、再試行ロジックを組み込むことをおすすめします。AWS SDK には再試行メカニズムが組み込まれています。

注: 一部のシナリオでは、同一キーに対する高頻度の同時リクエストにより、503 応答が引き起こされる可能性があります。このシナリオでは、失敗したリクエストを再試行することをおすすめします。

アプリケーションがリクエストレートを徐々に増やすよう設定する

オブジェクトに対する高頻度のリクエストや、リクエストレートの急増は、エラーメッセージ "503 Slow Down" を引き起こす可能性があります。アプリケーションがリクエストレートを維持するよう設定し、エクスポネンシャルバックオフによる再試行を実装するエクスポネンシャルバックオフの実装では、連続したエラー応答を再試行するまでの待機時間が漸増します。この構成では、Amazon S3 がリクエストレートを管理するために、リクエストパターンを監視し、バックエンドをスケールインする時間が確保されます。

まず、アプリケーションが 1 秒あたりのリクエストレートにおいて、少ないトランザクション数で開始するよう設定します。次に、アプリケーションのリクエストレートを指数関数的に増やします。Amazon S3 は、自動スケーリングを行うことで、リクエストレートの増加に対処します。

複数のプレフィックスにオブジェクトを分散する

リクエストレートは Amazon S3 バケット内のプレフィックスごとに適用されます。バケットがリクエストレートの増加に対処できるよう設定するには、オブジェクトを複数のプレフィックスに分散します。たとえば、バケットを画像とビデオの保存に使用する場合は、ファイルを次の 2 つのプレフィックスに分散します。

mybucket/images
mybucket/videos

プレフィックスに対するリクエストが漸増すると、Amazon S3 はスケールアップすることで、各プレフィックスに対するリクエストを別個に処理します。結果的に、バケットがは 2 倍のリクエストレートを処理できます。

5xx ステータスのエラー応答数を監視する

5xx ステータスのエラー応答が返された回数を監視するには、次のいずれかの手順を実行します。

5xx ステータス応答に関するメトリクスを確認するために、Amazon CloudWatch メトリクスを有効化します。
Amazon S3 サーバーのアクセスログを有効化してすべてのリクエストをキャプチャした後、5xx エラー応答が返されたリクエストをフィルターし、確認します。Amazon Athena でログを解析します。

問題のトラブルシューティングを進める

Expedited オプションでアーカイブされたオブジェクトを取得する際、次のいずれかのエラーメッセージが表示される場合があります。

"GlacierExpeditedRetrievalNotAvailable"
"Glacier expedited retrievals are currently not available, please try again later"

この問題は、Expedited RestoreObject リクエストを処理するための容量が十分でない場合に発生します。需要が継続的に高い期間中、Amazon S3 は、Expedited Retrieval リクエストを拒否し、503 エラーメッセージを返す可能性があります。プロビジョンドキャパシティユニットを使用すると、オンデマンドでの Expedited Retrieval 用に容量を確保できます。各ユニットあたり、5 分ごとに 3 回以上の Expedited Retrieval を実行できます。各ユニットは、最大 150 MBps の取得スループットを提供します。取得オプションには、Standard または Bulk も使用できます。

取得は、再試行可能です。ただし、問題が解決されない場合もあります。需要が極端に高い場合を除き、プロビジョンドキャパシティを持たない場合も Expedited Retrieval の実行は可能です。プロビジョニングされていないキャパシティからの Expedited Retrieval の可用性は、継続的に変化し、需要が高いため、Expedited Retrieval には SLA が定められていません。

5xx ステータスエラーの発生率が依然として高い場合は、AWS サポートにお問い合わせください。5xx ステータスエラーコードで失敗したリクエストには、複数の Amazon S3 リクエスト ID ペアを含めてください。