ec2 Elastic Block Storeボリュームからs3に400Gのファイルをコピーする最も速い方法はどれですか?


21

エラスティックブロックストアボリュームから400Gのファイルをs3バケットにコピーする必要があります...これらは約1MBの約30万ファイルです

私はs3cmds3fuseを試してみましたが、両方とも本当に、本当に遅いです。s3cmdは丸一日実行し、コピーが終了したと言って、バケツをチェックしても何も起こらなかった(何かがうまくいかなかったと思いますが、 s3cmdは何も文句を言いませんでした)

S3Fuseは別の1日間機能しており、コピーしたファイルは10%未満です...

これのためのより良い解決策はありますか?

もちろんLinux(ubuntu 12.04)を実行しています


2
多くのベンチマーク(例:これ)は、S3に対するスループットの3つの決定要因を示しています。1)ファイルサイズ2)並列スレッドの数、3)インスタンスサイズ。1MBオブジェクトの64〜128の並列(同時)アップロードにより、m1.xlargeが持つ1Gbpsアップリンクが飽和し、クラスターコンピューティング(cc1.4xlarge)インスタンスの10Gbpsアップリンクも飽和するはずです。これを念頭において多くのスクリプトがあるはずです(例えば、この1かs3cmd-修正)
cyberx86

1
s3-parallel-putがうまくいきました!
アセバ

回答:


20

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を直接使用して同様のことを実現します。キーは並列リクエストであることに留意して、次のようないくつかの潜在的なスクリプトを見つけることは難しくありません。
    • s3cmd-modification - s3cmdの初期バージョンのフォークで、この機能を追加しましたが、数年間更新されていません。
    • s3-parallel-put-うまく機能する比較的最近のpythonスクリプト

8

そのため、多くのテストを行った後、s3-parallel-putがすばらしくトリックを実行しました。大量のファイルをS3にアップロードする必要がある場合は、明らかにソリューションです。コメントしてくれたcyberx86に感謝します。


3
好奇心から、a)400GBのアップロードにかかった時間b)使用したスレッドの数c)使用したインスタンスサイズ
cyberx86

1
@ Cyber​​x86最近、大規模なEc2インスタンスでs3-parallel-putを使用しました。5つのスレッドを使用し、10.49時間で288.73 GBをコピーしました。
ゴートロン


2

これを行うために、C#(CopyFasterToS3)で最適化されたコンソールアプリケーションを作成しました。私はEBS volで使用しました。私の場合は、20ギガバイトの200万以上のファイルを含む5つのフォルダーがありました。スクリプトは30分以内に実行されました。

、この記事で私がどのように並列に再帰関数を使用して示しました。別の言語に転写することができます。

がんばろう!


1

s3funnelもあります。これは非常に古い(2008)ようで、いくつかの未解決のバグがありますが、Amazon自体からはまだリストされています:amzn-lnk



1

使用してみてください s3cmdの代わりにs3-cli。s3cmdの代わりにs3バケットにファイルをアップロードするためにそれを使用し、17分近く(21から4分)で展開を高速化しました!

リンクはこちらです:https : //github.com/andrewrk/node-s3-cli

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.