# 設計パターンのベストプラクティス: Amazon S3 のパフォーマンスの最適化
Amazon S3 のストレージに対してアップロードおよび取得を行う際に、アプリケーションはリクエストのパフォーマンスとして 1 秒あたり数千のトランザクションを容易に達成できます。Amazon S3 は、高いリクエストレートに自動的にスケールされます。例えば、アプリケーションは、パーティショニングされた Amazon S3 プレフィックスごとに毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成できます。バケット内のプレフィックスの数に制限はありません。並列化を使用することによって、読み取りまたは書き込みのパフォーマンスを向上させることができます。例えば、Amazon S3 バケットに 10 個のプレフィックスを作成して読み取りを並列化すると、読み取りパフォーマンスを 1 秒あたり 55,000 回の読み取りリクエストにスケールできます。同様に、複数のプレフィックスに書き込むことで、書き込みオペレーションをスケールできます。読み取りオペレーションと書き込みオペレーションの両方の場合、スケーリングは徐々に行われ、瞬時には行われません。実際のパフォーマンスは、特定のワークロードの特性、使用パターン、システム設定によって異なります。Amazon S3 が新たに高くなったリクエストレートに合わせてスケーリングしている間に、503 (Slow Down) エラーが表示される場合があります。これらのエラーは、スケーリングが完了すると解消されます。プレフィックスの作成と使用の詳細については、「[プレフィックスを使用してオブジェクトを整理する](using-prefixes.md)」を参照してください。
Amazon S3 上のデータレイクアプリケーションによっては、ペタバイトを超えるデータに対して実行されるクエリで数百万から数十億のオブジェクトをスキャンします。これらのデータレイクアプリケーションは、[Amazon EC2](https://docs.aws.amazon.com/ec2/index.html) インスタンスのネットワークインターフェイスの使用を最大限に高めて、単一のインスタンスで最大 100 Gb/s の転送レートを実現しています。その後、これらのアプリケーションは、複数のインスタンスにわたってスループットを集約して 1 秒あたり複数テラバイトを確保します。
ソーシャルメディアメッセージングアプリケーションなどの他のアプリケーションは、レイテンシーの影響を受けやすいアプリケーションです。このようなアプリケーションでは、小さなオブジェクト (大きなオブジェクトの場合は最初のバイトを受け取るまで) のレイテンシーで約 100～200 ミリ秒の一定のレイテンシーを実現できます。
他の AWS のサービスもさまざまなアプリケーションアーキテクチャのパフォーマンスの高速化に役立ちます。例えば、HTTP 接続ごとの転送レートを高めたい場合やレイテンシーをミリ秒単位に抑えたい場合は、[Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) または [Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html) を Amazon S3 のキャッシュとして使用します。
また、長距離間のクライアントと S3 バケットのデータ転送を高速化する場合は、[Amazon S3 Transfer Acceleration を使用した高速かつ安全なファイル転送の設定](transfer-acceleration.md) を使用します。Transfer Acceleration は、CloudFront の世界中に点在するエッジロケーションを使用して、長距離間のデータ転送を高速化します。Amazon S3 ワークロードが AWS KMS によるサーバー側の暗号化を使用している場合、ユースケースでサポートされるリクエスト率については、『AWS Key Management Service デベロッパーガイド』の「[AWS KMS 制限](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html)」を参照してください。
以下のトピックでは、Amazon S3 を使用するアプリケーションのパフォーマンスを最適化するためのベストプラクティスガイドラインと設計パターンについて説明します。Amazon S3 のパフォーマンスの最適化に関する最新情報については、「[Amazon S3 のパフォーマンスのガイドライン](optimizing-performance-guidelines.md)」および「[Amazon S3 のパフォーマンスの設計パターン](optimizing-performance-design-patterns.md)」を参照してください。
**注記**
Amazon S3 Express One Zone ストレージクラスをディレクトリバケットで使用する方法の詳細については、「[S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone)」と「[ディレクトリバケットの使用](directory-buckets-overview.md)」を参照してください。
**Topics**
+ [Amazon S3 のパフォーマンスのガイドライン](optimizing-performance-guidelines.md)
+ [Amazon S3 のパフォーマンスの設計パターン](optimizing-performance-design-patterns.md)
# Amazon S3 のパフォーマンスのガイドライン
Amazon S3 に対してオブジェクトのアップロードや取得を行うアプリケーションを作成する場合は、ベストプラクティスガイドラインに従ってパフォーマンスを最適化してください。また、より詳細な「[Amazon S3 のパフォーマンスの設計パターン ](optimizing-performance-design-patterns.md)」も提供しています。
アプリケーションで Amazon S3 の最適なパフォーマンスを得るために、以下のガイドラインを推奨しています。
**Topics**
+ [
## パフォーマンスを測定する
](#optimizing-performance-guidelines-measure)
+ [
## ストレージ接続を水平にスケールする
](#optimizing-performance-guidelines-scale)
+ [
## バイト範囲のフェッチを使用する
](#optimizing-performance-guidelines-get-range)
+ [
## レイテンシーの影響を受けやすいアプリケーションのリクエストを再試行する
](#optimizing-performance-guidelines-retry)
+ [
## 同じ AWS リージョンで Amazon S3 (ストレージ) と Amazon EC2 (コンピューティング) を組み合わせる
](#optimizing-performance-guidelines-combine)
+ [
## Amazon S3 Transfer Acceleration を使用して距離によるレイテンシーを最小限に抑える
](#optimizing-performance-guidelines-acceleration)
+ [
## 最新バージョンの AWS SDK を使用する
](#optimizing-performance-guidelines-sdk)
## パフォーマンスを測定する
パフォーマンスを測定する際、ネットワークスループット、CPU、および DRAM の要件を確認してください。これらのさまざまなリソースの要件の組み合わせに応じて、さまざまな [Amazon EC2](https://docs.aws.amazon.com/ec2/index.html) インスタンスタイプを評価することをお勧めします。インスタンスタイプの詳細については、「**Amazon EC2 ユーザーガイド」の「[インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
これは、パフォーマンスの測定時に HTTP 分析ツールを使用して DNS ルックアップ時間、レイテンシー、およびデータ転送速度を確認する際にも役立ちます。
パフォーマンス要件を理解し、アプリケーションのパフォーマンスを最適化するために、受け取った 503 エラーレスポンスをモニタリングすることもできます。特定のパフォーマンスメトリクスのモニタリングには、追加費用が発生する場合があります。詳細については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。
### 503 (Slow Down) ステータスエラーレスポンスの数のモニタリング
503 のステータスエラーレスポンス数をモニタリングするには、次のいずれかのオプションを使用できます。
+ Amazon S3 に対する Amazon CloudWatch リクエストメトリクスの使用 CloudWatch リクエストメトリクスには、5xx ステータスレスポンスのメトリクスが含まれています。CloudWatch リクエストメトリクスの詳細については、「[Amazon CloudWatch によるメトリクスのモニタリング](cloudwatch-monitoring.md)」を参照してください。
+ Amazon S3 ストレージレンズの [高度なメトリクス] セクションにある 503 (Service Unavailable) エラー数を使用してください。詳細については、「[S3 ストレージレンズのメトリクスを使用してパフォーマンスを改善する](storage-lens-detailed-status-code.md)」を参照してください。
+ Amazon S3 サーバーアクセスロギングの使用 サーバーアクセスログを使用すると、503 (Internal Error) レスポンスを受け取ったすべてのリクエストをフィルタリングして確認できます。Amazon Athena を使用して、ログを解析することもできます。サーバーアクセスログ記録の詳細については、「[サーバーアクセスログによるリクエストのログ記録](ServerLogs.md)」を参照してください。
HTTP 503 ステータスエラーコードの数をモニタリングすることで、どのプレフィックス、キー、またはバケットが最もスロットリングリクエストを受け取っているかについて、貴重な分析情報を得られることがよくあります。
## ストレージ接続を水平にスケールする
多くの接続間にリクエストを分散することが、パフォーマンスを水平にスケールする一般的な設計パターンです。パフォーマンスの高いアプリケーションを作成するには、Amazon S3 を従来のストレージサーバーのような 1 つのネットワークエンドポイントではなく、非常に大きな分散システムと考えます。最適なパフォーマンスは、複数の同時リクエストを Amazon S3 に発行することで実現できます。これらのリクエストを別々の接続に分散して、Amazon S3 の利用可能な帯域幅を最大化します。Amazon S3 には、バケットへの接続数に制限はありません。
## バイト範囲のフェッチを使用する
[GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectGET.html) リクエストで HTTP ヘッダーの `Range` を使用すると、オブジェクトのバイト範囲をフェッチして指定した部分のみを転送できます。Amazon S3 への同時接続を使用して、同じオブジェクトのさまざまなバイト範囲をフェッチできます。これにより、単一のオブジェクト全体のリクエストに対して高い集約スループットを実現できます。大きなオブジェクトの小さい範囲をフェッチすると、リクエストの中断時にアプリケーションで再試行回数の向上が可能になります。詳細については、「[オブジェクトのダウンロード](download-objects.md)」を参照してください。
マルチパートアップロードを使用してオブジェクトを PUT する場合、最適なパフォーマンスのために同じパートサイズで (少なくともパート境界に沿って整列されている) それらのオブジェクトを GET することをお勧めします。GET リクエストは、個々のパートを直接アドレス指定できます (例えば、`GET ?partNumber=N.`)。
## レイテンシーの影響を受けやすいアプリケーションのリクエストを再試行する
積極的なタイムアウトと再試行は、一定のレイテンシーの促進に役立ちます。Amazon S3 を大規模に利用している場合、最初のリクエストが遅くても、再試行のリクエストでは別のパスを選択してすぐに成功することがあります。AWS SDK には、特定のアプリケーションの許容値に調整できる設定可能なタイムアウト値と再試行値があります。
## 同じ AWS リージョンで Amazon S3 (ストレージ) と Amazon EC2 (コンピューティング) を組み合わせる
S3 のバケット名はグローバルに一意ですが、各バケットはバケットの作成時に選択したリージョンに保存されます。バケットの命名ガイドラインの詳細については、「[バケットの概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucket.html)」および「[バケットの命名規則](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html)」を参照してください。パフォーマンスを最適化するには、可能であれば、同じ AWS リージョン の Amazon EC2 インスタンスからバケットにアクセスすることをお勧めします。これにより、ネットワークレイテンシーとデータ転送費用を低減できます。
データ転送費用の詳細については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。
## Amazon S3 Transfer Acceleration を使用して距離によるレイテンシーを最小限に抑える
[Amazon S3 Transfer Acceleration を使用した高速かつ安全なファイル転送の設定](transfer-acceleration.md) は、クライアントと S3 のバケットの長距離間の高速、簡単、安全なファイル転送を管理します。Transfer Acceleration は、[Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html) の世界中に点在するエッジロケーションを利用します。エッジロケーションに到着したデータは、最適化されたネットワークパスで Amazon S3 にルーティングされます。Transfer Acceleration は、大陸間で定期的にギガバイトからテラバイト単位のデータを転送するのに最適です。また、中央のバケットに対して世界中のお客様からアップロードが行われるクライアントにも役立ちます。
[Amazon S3 Transfer Acceleration の速度比較ツール](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html)を使用すると、高速化した場合と高速化していない場合の Amazon S3 リージョン間でのアップロード速度を比較できます。速度比較ツールでは、マルチパートアップロードを使用して、ブラウザからさまざまな Amazon S3 のリージョンへのファイル転送を行い、Amazon S3 Transfer Acceleration を使用した場合と使用していない場合の比較が行われます。
## 最新バージョンの AWS SDK を使用する
AWS SDK では、Amazon S3 のパフォーマンスの最適化のために推奨されている多くのガイドラインが組み込みでサポートされています。SDK では、アプリケーションから Amazon S3 を利用するためのシンプルな API が提供されており、最新のベストプラクティスに従うように定期的に更新されます。例えば、SDK には、HTTP 503 エラーでリクエストを自動的に再試行するロジックが含まれており、遅い接続に応答して適用するためにコードに投資しています。
また、SDK では [Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/examples-s3-transfermanager.html) も提供されています。これは、接続の水平スケーリングを自動化し、必要に応じてバイト範囲のリクエストを使用して 1 秒あたりに数千ものリクエストを実現します。最新バージョンの AWS SDK を使用して最新のパフォーマンス最適化機能を取得することが重要です。
また、HTTP REST API リクエストを使用している場合は、パフォーマンスを最適化することもできます。REST API を使用する際、SDK の一部である同じベストプラクティスに従う必要があります。オブジェクトデータを同時フェッチできるように、リクエストが遅い場合のタイムアウトと再試行、および複数の接続を可能にしてください。REST API の使用については、[Amazon Simple Storage Service API Reference](https://docs.aws.amazon.com/AmazonS3/latest/API/) を参照してください。
# Amazon S3 のパフォーマンスの設計パターン
Amazon S3 に対してオブジェクトのアップロードや取得を行うアプリケーションを設計する場合は、アプリケーションの最適なパフォーマンスを実現するためにベストプラクティスの設計パターンを使用してください。また、アプリケーションのアーキテクチャの計画時に考慮すべき[Amazon S3 のパフォーマンスのガイドライン ](optimizing-performance-guidelines.md)も提供しています。
パフォーマンスを最適化するには、以下の設計パターンを使用します。
**Topics**
+ [
## 頻繁にアクセスされるコンテンツにキャッシュを使用する
](#optimizing-performance-caching)
+ [
## レイテンシーの影響を受けやすいアプリケーションのタイムアウトと再試行
](#optimizing-performance-timeouts-retries)
+ [
## 高スループットのための水平スケーリングとリクエスト並列化
](#optimizing-performance-parallelization)
+ [
## Amazon S3 Transfer Acceleration を使用して長距離間のデータ転送を高速化する
](#optimizing-performance-acceleration)
+ [
## リクエストレートの高いワークロードの最適化
](#optimizing-performance-high-request-rate)
## 頻繁にアクセスされるコンテンツにキャッシュを使用する
Amazon S3 にデータを保存するアプリケーションの多くは、ユーザーから繰り返しリクエストされる「作業セット」のデータを提供します。ワークロードで一連のよく使用されるオブジェクトに対して繰り返し GET リクエストを送信する場合は、[Amazon CloudFront](https://docs.aws.amazon.com/cloudfront/index.html)、[Amazon ElastiCache](https://docs.aws.amazon.com/elasticache/index.html)、[AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/index.html) などのキャッシュを使用してパフォーマンスを最適化することができます。キャッシュ導入が成功すると、レイテンシーが低くなり、データ転送速度が速くなります。また、アプリケーションでキャッシュを使用すると Amazon S3 にリクエストを直接送信する回数も減るため、リクエストにかかる費用を削減できます。
Amazon CloudFront は、各地に点在する一連の大規模な POP (Point Of Presence) で Amazon S3 のデータを透過的にキャッシュする高速なコンテンツ配信ネットワーク (CDN) です。複数のリージョンまたはインターネットからオブジェクトにアクセスする場合に CloudFront を使用すると、オブジェクトにアクセスするユーザーの近くにデータをキャッシュできます。これにより、Amazon S3 のアクセス数の多いコンテンツの配信パフォーマンスを高めることができます。CloudFront の詳細については、[Amazon CloudFront 開発者ガイド](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/)を参照してください。
Amazon ElastiCache は、マネージド型のインメモリキャッシュです。ElastiCache を使用すると、オブジェクトをメモリにキャッシュする Amazon EC2 インスタンスをプロビジョニングできます。このキャッシュにより、GET レイテンシーが数桁減少し、ダウンロードスループットが大幅に向上します。ElastiCache を使用するには、アプリケーションのロジックを変更して、アクセス数の多いオブジェクトをキャッシュに保存し、Amazon S3 にそのオブジェクトをリクエストする前にキャッシュを確認するようにします。ElastiCache を使用して Amazon S3 の GET のパフォーマンスを向上させる例については、ブログ記事の「[Turbocharge Amazon S3 with Amazon ElastiCache for Redis](https://aws.amazon.com/blogs/storage/turbocharge-amazon-s3-with-amazon-elasticache-for-redis/)」を参照してください。
AWS Elemental MediaStore は、Amazon S3 の動画ワークフローとメディア配信のために特別に作成されたキャッシュおよびコンテンツ配信システムです。MediaStore には、動画専用のエンドツーエンドのストレージ API が用意されており、パフォーマンスが重視される動画ワークロードに最適です。MediaStore の詳細については、「[AWS Elemental MediaStore ユーザーガイド](https://docs.aws.amazon.com/mediastore/latest/ug/)」を参照してください。
## レイテンシーの影響を受けやすいアプリケーションのタイムアウトと再試行
アプリケーションが Amazon S3 から再試行が必要なことを示すレスポンスを受け取る場合があります。Amazon S3 は、バケット名とオブジェクト名を関連するオブジェクトデータにマッピングします。アプリケーションで発生するリクエスト率が高い場合 (通常、少数のオブジェクトに対して 1 秒あたり 5,000 リクエストを超える率が持続される)、アプリケーションは HTTP 503 *slowdown* レスポンスを受信することがあります。これらのエラーが発生した場合、各 AWS SDK はエクスポネンシャルバックオフを使用して自動再試行ロジックを実装します。AWS SDK を使用していない場合は、HTTP 503 エラーの受信時に再試行ロジックを実装する必要があります。バックオフテクニックの詳細については、「AWS SDK とツールのリファレンスガイド」の「[Retry behavior](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)」を参照してください。**
Amazon S3 は、処理を継続するための新しいリクエストレートに応じて自動的にスケールし、パフォーマンスを動的に最適化します。Amazon S3 が新しいリクエスト率のために内部的に最適化している間、最適化が完了するまで一時的に HTTP 503 リクエストレスポンスが送信されます。Amazon S3 が新しいリクエストレートに応じてパフォーマンスを内部的に最適化すると、リクエストはすべて再試行なしで通常どおり処理されます。
レイテンシーが重要なアプリケーションの場合、Amazon S3 では遅いオペレーションを追跡して積極的に再試行することをお勧めします。リクエストを再試行する際は、Amazon S3 に新しく接続して改めて DNS ルックアップを実行することをお勧めします。
可変サイズの大きいリクエスト (例えば、128 MB 超) を実行する際、達成されるスループットを追跡し、リクエストのうち、遅い方から 5 パーセントを再試行することをお勧めします。小さいリクエスト (例えば、512 KB 未満) を実行する際、レイテンシーの中央値が数十ミリ秒の範囲内であることが多い場合、2 秒後に GET または PUT オペレーションを再試行することをお勧めします。追加の再試行が必要な場合のべストプラクティスはバックオフすることです。例えば、2 秒後に 1 回目の再試行を発行し、さらに 4 秒後に 2 回目の再試行を発行することをお勧めします。
アプリケーションが Amazon S3 に固定サイズのリクエストを実行する場合は、それぞれのリクエストの応答時間はより一定になると考えられます。この場合、シンブルな戦略はリクエストのうち、遅い方から 1 パーセントを特定してそれらを再試行することです。1 回の再試行でもレイテンシーの低減において効果的でありことが多いです。
サーバー側の暗号化で AWS Key Management Service (AWS KMS) を使用している場合、ユースケースでサポートされるリクエスト率については、「*AWS Key Management Service デベロッパーガイド*」の「[Quotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html)」を参照してください。
## 高スループットのための水平スケーリングとリクエスト並列化
Amazon S3 は大規模な分散システムです。その規模を活用できるように、並列リクエストを Amazon S3 のサービスエンドポイントに水平にスケールすることをお勧めします。このようなスケーリングのアプローチは、Amazon S3 でのリクエストの分散だけでなく、ネットワークで複数のパスに負荷を分散するためにも役立ちます。
転送のスループットを高めるために、Amazon S3 では複数の接続によってデータの GET や PUT を並列で行うアプリケーションを使用することをお勧めします。このような並列化は、AWS Java SDK の [Amazon S3 Transfer Manager](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/transfer-manager.html) でサポートされています。また、その他のほとんどの AWS SDK でも同様の機能が提供されています。一部のアプリケーションでは、さまざまなアプリケーションスレッドで、またはさまざまなアプリケーションインスタンスで複数のリクエストを同時に起動することで、並列接続を実現できます。採用する最良のアプローチは、アプリケーション、およびアクセスするオブジェクトの構造によって異なります。
AWS SDK を使用して、AWS SDK で転送の管理を使用するのではなく GET リクエストまたは PUT リクエストを直接発行できます。このアプローチにより、ワークロードをより直接的に調整できると同時に、発生する可能性がある HTTP 503 レスポンスの再試行とその処理に引き続き SDK のサポートを活用できます。原則として、Amazon S3 から大きなオブジェクトをダウンロードするときは、ネットワークスループットを最大化し、ダウンロードパフォーマンスを最適化するために、同時リクエストを行うことをお勧めします。これを実現するには、オブジェクトの特定のバイト範囲をリクエストするか、マルチパートオブジェクトの個々のパートを同時にダウンロードします。この並列ダウンロードアプローチは、ネットワークインターフェイスカード (NIC) の容量を最大限に活用するのに役立ちます。マルチパートアップロードを使用してアップロードされたオブジェクトの場合は、同じパートサイズを使用してダウンロードするか、リクエストを元のパートの境界に合わせてパフォーマンスを最適化することをお勧めします。この同時ダウンロードの方法は、単一のオブジェクト全体のリクエストと比較して、より高い集約スループットを提供します。
パフォーマンスの測定は、同時に発行するリクエスト数を調整する場合に重要です。一度に 1 つのリクエストから始めることをお勧めします。達成されるネットワーク帯域幅とデータの処理でアプリケーションで使用されるその他のリソースの使用を測定します。その後、ボトルネックとなっているリソース (つまり、使用量が最も高いリソース) と有用である可能性が高いリクエスト数を特定できます。例えば、一度に 1 つのリクエストの処理で CPU 使用率が 25 パーセントの場合、これは最大 4 つの同時リクエストに対応できることを示しています。測定は不可欠であり、リクエスト率としてのリソース利用が向上していることを確認する価値があります。
アプリケーションで REST API を使用して Amazon S3 にリクエストを直接発行する場合は、HTTP 接続のプールを使用して、一連のリクエストで各接続を再利用することをお勧めします。リクエストごとの接続セットアップを回避すると、各リクエストで TCP スロースタートと Secure Sockets Layer (SSL) ハンドシェイクを実行する必要がなくなります。REST API の使用については、[Amazon Simple Storage Service API Reference](https://docs.aws.amazon.com/AmazonS3/latest/API/) を参照してください。
最後に、DNS に注意するとともに、リクエストが Amazon S3 の広範な IP アドレスのプールに分散されていることを確認することもお勧めします。Amazon S3 の DNS の問い合わせは、多数の IP エンドポイントのリストを確認します。ただし、キャッシュリゾルバ、または 1 つの IP アドレスを再利用するアプリケーションコードでは、アドレス多様性とそれによる負荷分散のメリットが得られません。コマンドラインツールの `netstat` などのネットワークユーティリティツールを使用すると、Amazon S3 との通信に使用されている IP アドレスを確認できます。また、使用する DNS 設定のガイドラインも提供しています。これらのガイドラインの詳細については、「Amazon S3 API リファレンス」の「[Making requests](https://docs.aws.amazon.com/AmazonS3/latest/API/MakingRequests.html)」を参照してください。**
## Amazon S3 Transfer Acceleration を使用して長距離間のデータ転送を高速化する
[Amazon S3 Transfer Acceleration を使用した高速かつ安全なファイル転送の設定](transfer-acceleration.md) は、世界中のクライアントと Amazon S3 を使用する特定のリージョンのアプリケーションの距離によるレイテンシーを最小限に抑える、またはなくすために有効です。Transfer Acceleration は、データの転送に CloudFront の世界中に点在するエッジロケーションを利用します。AWS エッジネットワークでは、50 を超えるロケーションに接続ポイントがあります。現在、このネットワークは、CloudFront でのコンテンツの配信や [Amazon Route 53](https://docs.aws.amazon.com/route53/index.html) に対する DNS の問い合わせへの迅速な応答のために使用されています。
このエッジネットワークは、Amazon S3 との間のデータ転送の高速化にも役立ちます。これは、大陸全域または大陸間でデータを転送する、高速なインターネット接続がある、大きなオブジェクトを使用する、またはアップロードするコンテンツが多数あるアプリケーションに最適です。エッジロケーションに到着したデータは、最適化されたネットワークパスで Amazon S3 にルーティングされます。一般的に、Amazon S3 のリージョンから遠いほど、Transfer Acceleration による速度の向上が期待できます。
新しいバケットまたは既存のバケットで Transfer Acceleration をセットアップできます。離れた Amazon S3 Transfer Acceleration エンドポイントを使用して、AWS のエッジロケーションを使用することができます。Transfer Acceleration がクライアントのリクエストのパフォーマンスに役立つかどうかをテストする最も良い方法は、[Amazon S3 Transfer Acceleration の速度比較ツール](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html)を使用することです。ネットワークの設定および条件は、随時、場所によって異なります。そのため、Amazon S3 Transfer Acceleration がアップロードのパフォーマンスを向上させることができると考えられる転送に対してのみ料金が発生します。さまざまな AWS SDK での Transfer Acceleration の使用については、「[S3 Transfer Acceleration の有効化と使用](transfer-acceleration-examples.md)」を参照してください。
## リクエストレートの高いワークロードの最適化
Amazon S3 へのリクエストレートが高いアプリケーションでは、最適なパフォーマンスを実現するために特定の設計パターンが必要です。アプリケーションがプレフィックスごとに 1 秒あたり 3,500 を超える PUT/COPY/POST/DELETE リクエストまたは 5,500 を超える GET/HEAD リクエストを一貫して生成する場合は、リクエストを分散し、スケーリング動作を処理する戦略を実装する必要があります。
Amazon S3 は、より高いリクエストレートに合わせて自動的にスケールしますが、このスケーリングは徐々に行われます。スケーリングプロセス中に、HTTP 503 (Slow Down) レスポンスを受け取る場合があります。これらのレスポンスは一時的なもので、Amazon S3 が新しいリクエストパターンに合わせて内部システムを最適化していることを示します。スケーリングが完了すると、リクエストはスロットリングなしで処理されます。
リクエストレートの高いワークロードのパフォーマンスを最適化するには、次の戦略を検討してください。
+ **複数のプレフィックスにリクエストを分散する** – ランダム化またはシーケンシャルプレフィックスパターンを使用して、複数のパーティションにリクエストを分散します。例えば、`log-2024-01-01.txt` のようなシーケンシャルオブジェクト名を使用する代わりに、`a1b2/log-2024-01-01.txt` のようなランダム化されたプレフィックスを使用します。これにより、Amazon S3 は負荷をより効果的に分散できます。
+ **503 エラーのエクスポネンシャルバックオフを実装する** – HTTP 503 レスポンスを受け取ったら、エクスポネンシャルバックオフを使用して再試行ロジックを実装します。短い遅延から開始し、再試行間の待機時間を徐々に長くします。AWS SDK には、これを自動的に処理する再試行ロジックが組み込まれています。
+ **リクエストパターンのモニタリング** – Amazon CloudWatch メトリクスを使用して、リクエスト率とエラー率をモニタリングします。アプリケーションが現在のスケーリング制限に近づいているか超えていることを示す 5xx エラーメトリクスに特に注意してください。
+ **リクエストレートを徐々に増やす** – 新しいアプリケーションを起動したり、リクエストレートを大幅に増やしたりする場合は、ピークレートにすぐにジャンプするのではなく、時間の経過とともにトラフィックを徐々に増やします。これにより、Amazon S3 はプロアクティブにスケールでき、スロットリングの可能性が低くなります。
+ **複数の接続を使用する** – 複数の HTTP 接続にリクエストを分散してスループットを最大化し、単一の接続問題の影響を軽減します。
一貫した高パフォーマンスを必要とするアプリケーションの場合は、Amazon S3 Express One Zone の使用を検討してください。Amazon S3 Express One Zone は、1 桁ミリ秒のレイテンシーを必要とするアプリケーション向けに設計されており、1 秒あたり数十万件のリクエストをサポートできます。詳細については、「[S3 Express One Zone](directory-bucket-high-performance.md#s3-express-one-zone)」を参照してください。