Amazon S3 にダウンロードまたはアップロードするときの遅いまたは安定しない速度をトラブルシューティングする方法を教えてください。

解決方法

Amazon S3 へのダウンロードまたはアップロード時に速度が遅くなったり安定しなくなったりする原因を特定して軽減するには、以下をチェックします。

• リクエストを行うクライアントのロケーション
• クライアントのインターネットサービスプロバイダー (ISP)
• クライアントのネットワーク
• クライアントのリソース
• Amazon S3 へのリクエストレート
• Amazon S3 サーバーアクセスログ (所要時間の算定に使用)

リクエストを行うクライアントのロケーション

クライアントにできるだけ地理的に近い Amazon S3 バケットを使用します。バケットはグローバルにアクセスできますが、特定の AWS リージョンにあります。リクエストとバケットの地理的な距離は、レスポンスが受信されるまでにかかる時間に影響します。

クライアントと S3 バケットの地理的な距離による影響はテストすることができます。例えば、バケットと同じ AWS リージョンで Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動することができます。次に、別のリージョンで別のインスタンスを起動します。両方のインスタンスを使用して同じファイルのアップロードとダウンロードをテストし、2 つのリージョンのスループットを比較します。

クライアントと S3 バケットの距離を縮めるには、データをクライアントに近い別のリージョンのバケットに移動します。ソースバケットのデータが新しいリージョンのレプリケート先バケットにレプリケートされるように、クロスリージョンレプリケーションを設定できます。別のオプションとして、クライアントを S3 バケットの近くに移動することもできます。

クライアントのインターネットサービスプロバイダー (ISP)

接続がインターネットを横断するうえで影響する問題がないか、ネットワークパスを確認します。このような問題としては、パケットロスやホップ数の増加など、ISP に関連する問題があります。

[mtr] や [traceroute] などのツールは、パケットロス発生原因の手がかりを得るのに役立ちます。また、リモートホストに送信されるパケットのレイテンシーも確認できます。さらに、ネットワークホップが原因でレイテンシーが高くなっているかどうかを特定するのにも役立ちます。

例えば、次の Linux [traceroute] コマンドは、TCP ポート 80 を使用して、us-west-2 (オレゴン) リージョンのエンドポイントへの接続をテストしています。

sudo traceroute -P TCP -p 80 s3.us-west-2.amazonaws.com

Windows オペレーティングシステムでは、[tracert] という類似のツールを使用できます。

注: ICMP に応答しないネットワークデバイスが多数あります。Amazon S3 へのリクエストをシミュレートしたテストを行うには、必ずバケットのリージョンエンドポイントへの TCP traceroute または MTR を実行します。

クライアントから Amazon S3 へのインターネットルートが最適でない場合は、Amazon CloudFront のエッジロケーションを活用する Amazon S3 Transfer Acceleration の使用を検討します。Amazon S3 Transfer Acceleration 速度比較 ツールを参照して、Transfer Acceleration によってユースケースのパフォーマンスが向上するかどうかを確認してください。

**注:**Transfer Acceleration をオンにすると、追加のデータ転送料金が適用されます。Amazon S3 のデータ転送料金 を必ず確認してください。

クライアントのネットワーク

クライアントのネットワークが正常であることを確認するため、内部パケット検査、ウイルス対策スキャン、またはネットワークアクセス管理を確認します。また、クライアントまたはアプリケーションが DNS の解決とキャッシングをどのように処理するかを確認します。

Amazon S3 の分散性と可用性を活用するには、長期間にわたって DNS の解決結果をキャッシュすることは避けてください。

クライアントのリソース

リクエストを行っているホストが、送信されたリクエストと受信したレスポンスを処理する方法や、アプリケーションに、レイテンシーが発生している可能性があります。ベストプラクティスとして、全体的なレイテンシーの原因となる可能性のあるリソース競合がホスト内で発生していないことを確認してください。例えば、ホスト内のリソース競合は、CPU、メモリ、またはネットワーク帯域幅について発生する可能性があります。

ほとんどのクライアントシステムでは、Resource Monitor や [top] コマンドなどのツールを使用して、データ転送中のリソース使用量を確認できます。使用できるツールはオペレーティングシステムによって異なります。

クライアントのストレージデバイスまたはシステムも、遅延の原因となる可能性があります。クライアントのストレージデバイスに対する、レイテンシーの高い読み取りまたは書き込み操作は、Amazon S3 へのダウンロードまたはアップロードのパフォーマンスに影響を与える可能性があります。ストレージデバイスの IOPS のトラブルは、クライアント側で解決する必要があります。Amazon S3 のパフォーマンスは、Amazon CloudWatch のメトリクス FirstByteLatency を使用して分析できます。

注: Amazon S3 CloudWatch リクエストメトリクスは、カスタムメトリクスと同じレートで請求されます。

FirstByteLatency は、Amazon S3 がクライアントからのリクエストを処理する時間と、その後でクライアントへの応答を送信し始めるまでにかかる時間の合計を示します。この CloudWatch メトリクスは、バケットレベルのパフォーマンスを示しています。このような調査は、Amazon S3 サーバーアクセスログを使用して掘り下げることができます。詳細については、[Amazon S3 サーバーアクセスログ (所要時間の算定に使用)] セクションを参照してください。

Amazon S3 へのリクエストレート

デフォルトでは、S3 バケットは、プレフィックスごとに 1 秒あたり数千のリクエスト をサポートできます。クライアントが Amazon S3 から HTTP 5xx のエラーレスポンスを受け取っている場合は、プレフィックスごとにサポートされているリクエストレートを超えている可能性があります。5xx エラーをトラブルシューティングするには、Amazon S3 の HTTP 500 または 503 エラーをトラブルシューティングするにはどうすればよいですか? を参照してください。

Amazon S3 サーバーアクセスログ (所要時間の算定に使用)

Amazon S3 サーバーアクセスログを有効にする と、所要時間 に関するメトリクスを確認できます。所要時間は、リクエストの最後のバイトが受信された時刻から、レスポンスの最初のバイトが送信された時刻までの間の時間です。これは、メトリクスとして「最初のバイトまでの時間 (TTFB)」と呼ばれます。所要時間を使用して、Amazon S3 の視点から操作にかかる時間を算定できます。次に、ダウンロードやアップロードを全体的に遅くしている可能性がある、Amazon S3 以外によるレイテンシーを評価できます。

レイテンシーが通常よりも高い場合は、リクエストが完了するのを待つのではなく、リクエストを再試行するのがベストプラクティスです。このガイダンスとその他のパフォーマンスに関する推奨事項の詳細については、Amazon S3 のパフォーマンスガイドライン を参照してください。