Amazon S3 からのHTTP500または503エラーのトラブルシューティングを行うにはどうすればよいですか?
最終更新日:2021-12-17
オブジェクトのコピーまたはアップロードをAmazonSimple Storage Service(Amazon S3にリクエストすると、Amazon S3 は次のいずれかのメッセージを返します:
AmazonS3Exception: 内部エラー (サービス:Amazon S3、ステータスコード:500、エラーコード:500 内部エラー、リクエスト ID: A4DBBEXAMPLE2C4D)
「AmazonS3Exception: Slow Down (サービス: Amazon S3、ステータスコード: 503、エラーコード: 503 Slow Down、リクエスト ID: A4DBBEXAMPLE2C4D)
これらのエラーをトラブルシューティングするにはどうすればよいですか?
簡単な説明
エラーコード 500 内部エラーは、Amazon S3 がその時点ではリクエストを処理できないことを示しています。通常、エラーコード 503 Slow Down は、S3 バケットに対するリクエスト数が非常に多く、リクエストレートを超えていることを示しています。(たとえばS3バケットのプレフィックスごとに1秒あたり3,500のPUT / COPY / POST / DELETEまたは5,500のGET / HEADリクエストを送信できます。) ただし、リクエストがクロスリージョンコピーに使用できる帯域幅の量を超えた場合には、Amazon S3は503Slow Down応答を返すことがあります。
Amazon S3 は分散しているサービスであるため、非常に低い割合の 5xx エラーはこのサービスの正常な使用中に発生する場合があります。Amazon S3 から 5xx エラーを返すリクエストはすべて再試行できます。したがって、Amazon S3 にリクエストを行うアプリケーションには、耐障害性のメカニズムを使用するか、再試行ロジックを実装することがベストプラクティスです。そうすれば、S3 はこれらのエラーから回復できます。
5xx エラーを解決または回避するには、次の方法を検討してください:
- リクエストするアプリケーションの再試行メカニズムを有効にする。
- リクエスト率を徐々に増やすようにアプリケーションを設定します。
- 複数のプレフィックスにオブジェクトを分散します。
- 500 件の内部エラー応答数を監視します。
- 別の方法を使用してデータをコピーします。
解決方法
リクエストするアプリケーションの再試行メカニズムを有効にする
Amazon S3 は分散性があるため、500 エラーまたは 503 エラーを返すリクエストは再試行することができます。Amazon S3 にリクエストするアプリケーションに再試行ロジックを構築することをお勧めします。アプリケーションの再試行ロジックを更新するには、アプリケーションの再試行回数を「10」に設定します。
すべての AWS SDK には、エクスポネンシャルバックオフを使用するアルゴリズムを持つ再試行メカニズムが組み込まれています。このアルゴリズムは、連続的なエラー応答に対する再試行の間の待機時間をますます長くします。ほとんどのエクスポネンシャルバックオフアルゴリズムは、衝突の連続を防ぐためにジッター (ランダム化された遅延) を使用します。詳細については、「AWS でのエラー再試行とエクスポネンシャルバックオフ」を参照してください。
リクエスト率を徐々に増やすようにアプリケーションを設定する
503 Slow Down エラーを回避するために、アプリケーションがより低いリクエスト率 (1 秒あたりのトランザクション) で開始するように設定します。次に、アプリケーションのリクエスト率を指数関数的に増やします。Amazon S3 はより高いリクエスト率を処理するために自動的にスケールされます。
複数のプレフィックスにオブジェクトを分散する
「リクエスト率およびリクエストパフォーマンスに関する留意事項」で説明されているリクエスト率は S3 バケットのプレフィックスごとに適用されます。全般的に高いリクエスト率を処理し、503 Slow Down エラーを回避するようにバケットを設定するために、オブジェクトを複数のプレフィックスに分散することができます。たとえば、S3 バケットを使用して画像と動画を保存している場合は、次のような 2 つのプレフィックスにファイルを分散します。
- mybucket/images
- mybucket/videos
プレフィックスのリクエストレートが徐々に増加すると、Amazon S3 は 2 つのプレフィックスそれぞれのリクエストを処理するようにスケールアップします。(S3 は、1 秒あたり 3,500 個の PUT/POST/DELETE または 5,500 個の GET リクエストを処理するようにスケールアップします。) その結果、バケットが処理する全体のリクエスト率は 2 倍になります。
500件の内部エラー応答数を監視する
取得している500 内部エラー応答の数をモニタリングするには、次のいずれかのオプションを使用できます:
- Amazon CloudWatchメトリクスを有効にします。Amazon S3 CloudWatch リクエストメトリクスには、5xx サーバーエラーのメトリクスが含まれます。
- Amazon S3 サーバーアクセスログを有効にします。サーバーアクセスログはすべての要求をキャプチャするため、 500 Internal Error 応答を受信したすべての要求をフィルタリングして確認することができます。Amazon Athena を使用してログを解析することもできます。
別の方法でデータをコピーします
リージョン間でデータをコピーするその他の方法については、次のオプションを検討してください:
- Amazon EMR で S3DistCp オペレーションを使用します。S3DistCp の使用に関する詳細なガイダンスについては、「Seven Tips for Using S3DistCp on Amazon EMR to Move Data Efficiently Between HDFS and Amazon S3」をご参照ください。
注: このアプローチでは Amazon EMR を使用する必要があるので、Amazon EMR の料金をご確認ください。 - コピー元バケットから GET 操作を実行してから、コピー先バケットへの PUT 操作を試します。
- ソースバケットで、クロスリージョンレプリケーション (CRR) を有効にします。CRR は、オブジェクトをコピー先バケットに自動的かつ非同期的にコピーします。
注: CRR を有効にすると、新しいオブジェクトは自動的に宛先バケットにコピーされます。CRR を有効にする前にコピー元バケットにあったオブジェクトは、自動的にコピーされません。