EC2からS3へのスループットを決定するいくつかの重要な要素があります。
- ファイルサイズ-小さいファイルには、より多くのリクエストとより多くのオーバーヘッドと転送が必要です。ファイルサイズの増加(EC2から発生する場合)は、256kBを超えるファイルでは無視できます。(一方、待ち時間が長い遠隔地からの転送は、1MiBと2MiBの間までかなりの改善が見られる傾向があります)。
- 並列スレッドの数-通常、単一のアップロードスレッドは全体的にかなり低く、多くの場合5MiB / s未満です。スループットは、同時スレッドの数とともに増加し、64〜128スレッドの間にピークを迎える傾向があります。より大きなインスタンスは、より多くの同時スレッドを処理できることに注意してください。
- インスタンスのサイズ- インスタンスの仕様に従って、より大きなインスタンスにはより多くの専用リソースがあり、ネットワーク帯域幅(および一般的なI / O-エフェメラル/ EBSディスクからの読み取りを含む)の割り当てが大きくなります。各カテゴリの数値は次のとおりです。
- 非常に高い:理論的:10Gbps = 1250MB / s; 現実的:8.8Gbps = 1100MB / s
- 高:理論:1Gbps = 125MB / s; 現実的:750Mbps = 95MB / s
- 中程度:理論的:250Mbps; 現実的:80Mbps = 10MB / s
- 低:理論的:100Mbps; 現実的:10-15Mbps = 1-2MB / s
大量のデータを転送する場合、クラスターコンピューティングインスタンスを使用するのが経済的に実用的です。スループットの効果的な増加(> 10x)はコストの差(2-3x)よりも大きいためです。
上記のアイデアはかなり論理的ですが(スレッドごとの上限はそうではないかもしれませんが)、それらをバックアップするベンチマークを見つけるのは非常に簡単です。特に詳細なものはここにあります。
1MBオブジェクトの64〜128の並列(同時)アップロードを使用すると、m1.xlargeが持つ1Gbpsアップリンクが飽和し、クラスターコンピューティング(cc1.4xlarge)インスタンスの10Gbpsアップリンクも飽和するはずです。
インスタンスのサイズを変更するのはかなり簡単ですが、他の2つの要因は管理が難しい場合があります。
- 通常、ファイルサイズは固定されています。EC2でファイルを結合し、S3でファイルを分割することはできません(したがって、小さなファイルに対してできることはあまりありません)。ただし、大きなファイルの場合、EC2側で分割し、S3側で再構築できます(S3のマルチパートアップロードを使用)。通常、これは100MBを超えるファイルに有利です。
- 並列スレッドは、対応が少し難しくなります。最も簡単なアプローチは、複数のコピーを一度に実行する既存のアップロードスクリプトのラッパーを作成することです。より良いアプローチでは、APIを直接使用して同様のことを実現します。キーは並列リクエストであることに留意して、次のようないくつかの潜在的なスクリプトを見つけることは難しくありません。