高スループットのための水平スケーリングとリクエスト並列化

Amazon S3 は大規模な分散システムです。その規模を活用できるように、並列リクエストを Amazon S3 のサービスエンドポイントに水平にスケールすることをお勧めします。このようなスケーリングのアプローチは、Amazon S3 でのリクエストの分散だけでなく、ネットワークで複数のパスに負荷を分散するためにも役立ちます。

転送のスループットを高めるために、Amazon S3 では複数の接続によってデータの GET や PUT を並列で行うアプリケーションを使用することをお勧めします。このような並列化は、AWS Java SDK の Amazon S3 Transfer Manager でサポートされています。また、その他のほとんどの AWS SDK でも同様の機能が提供されています。一部のアプリケーションでは、さまざまなアプリケーションスレッドで、またはさまざまなアプリケーションインスタンスで複数のリクエストを同時に起動することで、並列接続を実現できます。採用する最良のアプローチは、アプリケーション、およびアクセスするオブジェクトの構造によって異なります。

AWS SDK を使用して、AWS SDK で転送の管理を使用するのではなく GET リクエストまたは PUT リクエストを直接発行できます。このアプローチにより、ワークロードをより直接的に調整できると同時に、発生する可能性がある HTTP 503 レスポンスの再試行とその処理に引き続き SDK のサポートを活用できます。一般的なルールとして、リージョン内の大きなオブジェクトを Amazon S3 から Amazon EC2 にダウンロードする場合は、8～16 MB の粒度でオブジェクトのバイト範囲の同時リクエストを実行することをお勧めします。同時リクエストは、必要なネットワークスループットの 85～90 MB/秒ごとに 1 つ実行します。10 Gb/s のネットワークインターフェイスカード (NIC) を使用するには、個別の接続で約 15 の同時リクエストを使用します。より多くの接続で同時リクエストをスケールアップして、25 Gb/s や 100 Gb/s の NIC などのより高速な NIC を使用できます。

パフォーマンスの測定は、同時に発行するリクエスト数を調整する場合に重要です。一度に 1 つのリクエストから始めることをお勧めします。達成されるネットワーク帯域幅とデータの処理でアプリケーションで使用されるその他のリソースの使用を測定します。その後、ボトルネックとなっているリソース (つまり、使用量が最も高いリソース) と有用である可能性が高いリクエスト数を特定できます。たとえば、一度に 1 つのリクエストの処理で CPU 使用率が 25 パーセントの場合、これは最大 4 つの同時リクエストに対応できることを示しています。

測定は不可欠であり、リクエスト率としてのリソース利用が向上していることを確認する価値があります。

アプリケーションで REST API を使用して Amazon S3 にリクエストを直接発行する場合は、HTTP 接続のプールを使用して、一連のリクエストで各接続を再利用することをお勧めします。リクエストごとの接続セットアップを回避すると、各リクエストで TCP スロースタートと Secure Sockets Layer (SSL) ハンドシェイクを実行する必要がなくなります。REST API の使用方法については、「Amazon S3 REST API の概要」を参照してください。

最後に、DNS に注意するとともに、リクエストが Amazon S3 の広範な IP アドレスのプールに分散されていることを確認することもお勧めします。Amazon S3 の DNS の問い合わせは、多数の IP エンドポイントのリストを確認します。ただし、キャッシュリゾルバ、または 1 つの IP アドレスを再利用するアプリケーションコードでは、アドレス多様性とそれによる負荷分散のメリットが得られません。コマンドラインツールの netstat などのネットワークユーティリティツールを使用すると、Amazon S3 との通信に使用されている IP アドレスを確認できます。また、使用する DNS 設定のガイドラインも提供しています。このガイドラインの詳細については、「リクエストルーティング」を参照してください。