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

所要時間2分

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

簡単な説明

Amazon S3 は、次の例のような 5xx ステータスエラーを返します：

"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 内部エラーは、Amazon S3 がその時点でリクエストを処理できないことを示しています。エラーコード 503 Slow Down は通常、S3 バケットへのリクエスト数が多いことを示しています。たとえば、S3 バケットのプレフィックスごとに 1 秒あたり 3,500 件の PUT/COPY/POST/DELETE リクエストまたは 5,500 件の GET/HEAD リクエストを送信できます。ただし、リクエストがクロスリージョンコピーに使用できる帯域幅を超える場合、Amazon S3 は 503 Slow Down レスポンスを返すことがあります。
5xx ステータスエラーを解決または回避するには、次の方法を試してください。

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

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

解決方法

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

Amazon S3 は分散型であるため、500 または 503 のエラーを返すリクエストを再試行できます。Amazon S3 にリクエストを行うアプリケーションに再試行ロジックを組み込むのがベストプラクティスです。

すべての AWS SDK には、指数関数的バックオフを使用するアルゴリズムを備えた再試行メカニズムが組み込まれています。このアルゴリズムでは、連続したエラー応答を再試行するまでの待ち時間がますます長くなります。指数関数的バックオフアルゴリズムの多くは、ジッター (ランダム化された遅延) を使用して連続的な衝突を防ぎます。詳細については、リトライ動作を参照してください。

**注:**Amazon S3 は、1 つのプレフィックスに対して 1 秒あたり最大 3500 件の PUT リクエストのリクエストレートをサポートしています。シナリオによっては、同じキーへの迅速な同時 Put リクエストにより、503 レスポンスが返されることがあります。このような場合は、失敗したリクエストを再試行するのがベストプラクティスです。

リクエストレートを徐々に上げるようにアプリケーションを設定

レート制限に近い高いリクエストレートでリクエストを実行する場合、Amazon S3 は「503 Slow Down」(503 速度低下) エラーを返します。プレフィックス内のオブジェクトのリクエストレートが急激に増加すると、503 Slow Down エラーが表示されます。リクエストレートを維持し、指数関数的バックオフによるリトライを実装するようにアプリケーションを設定します。そうすることで、Amazon S3 がリクエストパターンを監視し、バックエンドでスケールインしてリクエストレートを処理する時間ができます。

503 Slow Down エラーを回避するには、より低いリクエストレート (1 秒あたりのトランザクション数) で開始するようにアプリケーションを設定します。次に、アプリケーションのリクエストレートを指数関数的に増やします。Amazon S3 は、より高いリクエストレートを処理するように自動的にスケールします。

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

リクエストレートは Amazon S3 バケットのプレフィックスごとに適用されます。全体的に高いリクエストレートを処理し、503 件のスローダウンエラーを回避するようにバケットを設定するには、オブジェクトを複数のプレフィックスに分散します。たとえば、Amazon S3 バケットを使用して画像と動画を保存する場合、ファイルを 2 つのプレフィックスに分けて配布します。

マイバケット/画像
マイバケット/ビデオ

プレフィックスのリクエストレートが徐々に上がると、Amazon S3 はスケールアップして 2 つのプレフィックスそれぞれのリクエストを個別に処理します。Amazon S3 は、プレフィックスごとに 1 秒あたり 3,500 件の PUT/POST/DELETE リクエストまたは 5,500 件の GET リクエストを処理するようにスケールアップします。その結果、バケットが処理する全体的なリクエストレートは 2 倍になります。

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

受け取った 5xx ステータスエラー応答の数を監視するには、次のいずれかのオプションを使用してください。

Amazon CloudWatch メトリクスをオンにします。Amazon S3 CloudWatch リクエストメトリクスには、5xx ステータスレスポンスのメトリックスが含まれています。
Amazon S3 サーバーアクセスログを有効にします。サーバーアクセスログはすべてのリクエストをキャプチャするため、500/503 エラーレスポンスを受け取るすべてのリクエストをフィルタリングして確認します。Amazon Athena を使用してログを解析してください。

5xx エラーのその他の理由

Expedited Restore Tier を使用してアーカイブされたオブジェクトを取得すると、次の例のようなエラーが表示されることがあります。

"GlacierExpeditedRetrievalNotAvailable"
「Glacier の優先検索は現在ご利用いただけません。後でもう一度お試しください」

これらのエラーは、優先リクエストを処理するのに十分な容量がない場合に発生します。

需要が引き続き高い期間中、Amazon S3 は優先取り出しリクエストを拒否し、503 エラーを返す場合があります。プロビジョニングされたキャパシティユニット (PCU) を使用して、優先取り出し用の取り出し容量がオンデマンドで使用可能であることを確認します。各ユニットでは、5 分ごとに少なくとも 3 回の優先取り出しを実行できます。各ユニットは、最大 150 メガバイト/秒 (MBps) の検索スループットを提供します。「標準」または「一括取得」の検索オプションを使用することもできます。

取得を再試行することはできますが、これを行っても成功するとは限りません。非常に需要が高い場合を除き、キャパシティをプロビジョニングしなくても優先取り出しが可能です。絶え間なく変化し、プロビジョニングされていない容量からの迅速な取り出しに対する需要が高まっているため、AWS サポートでは保証された SLA を提供していません。

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