1 か月の経験があれば、考えていることはうまくいくかもしれませんが、その道のりには落とし穴があります。
それらを説明するには、少し哲学的になる必要があります。
最適化する必要のあるリソース集約型のジョブに直面した場合、一般に、いくつかの限られたリソースのうちどれを限界までプッシュするのに最適かを判断し、他のすべてのリソースで十分であることを確認するのが最善の方法です。それが起こるように。場合によっては、実際には 1 つのリソースを人為的で不必要な制限までプッシュすることになります。
1 ミリ秒で、10 Gbit/s リンクは 10 Mbit を転送できます。データを転送せずに無駄にする 1 ミリ秒ごとに、ジョブの実行時間がさらに長くなります。したがって、データの流れを維持する必要があります...そしてあなたのソリューションはそれを達成しません.
S3 は1 秒あたり 100 のアップロードを簡単に処理できます。これは、連続してアップロードされる場合、10 ミリ秒ごとに 1 アップロードです...そして s3fs はそれに追いつくことができず、10 ミリ秒ごとにリンクを介して 100 メガビットを転送していた可能性があります。 ..しかし、あなたはしませんでした。1 つまたはそれ以下の 50k オブジェクトのみを管理しました。s3fs が非常にクールであることは疑いの余地がありませんが (私は実稼働バックエンド システムの 1 つのアプリケーションで使用しています)、S3 をファイルシステムのように扱おうとするため、実際に機能する S3 の使用方法としては、理論的に最も不適切な方法でもあります...ファイルシステムのセマンティクスを使用してオペレーティングシステムに公開します... S3はファイルシステムではなくオブジェクトストアであり、2つの間に「インピーダンスギャップ」があります。
ここでの人為的なチョーク ポイントは s3fs であり、tar が任意の時点で 1 つのファイルのみを抽出できるようにします。tar の出力は、各オブジェクトで s3fs を待機するマイクロ秒またはミリ秒の間繰り返しブロックされます。これにより、ネットワークからの tar の入力がブロックされ、TCP 接続がブロックされ、ソース tar がブロックされます...つまり、不必要な制限に達しているため、実際のリソースを最大限に活用することはできません。
s3fs でエラーが発生した場合にどうなるかは気にしないでください。エラーの性質に応じて...
tar: broken pipe
ああ。
本当に必要なのは並行性です。それらのファイルを、S3 が受け取るのと同じ速さで並行して S3 にプッシュします。
これに対する最善の策は、プライベート データ センターでコードを実行することです。ファイルのリストをいくつかのチャンクに分割します。複数の独立したプロセス (またはスレッド) を生成して、ファイルの 1 つのチャンクを処理し、ディスクから読み取り、S3 にアップロードします。
私がこれを行っていた場合 (実際に行ったことがあるため)、独自のコードを作成します。
aws s3 cpただし、 aws CLI のコマンドを gnu と組み合わせて使用すると、かなり簡単にこれを実現できます。これは、ビルドするファイルのリストをコピーするように指示された"n" 個の並列呼び出しのそれぞれが、次parallelのように動作するように構成できます。stdin からコマンド ラインで渡します。xargsaws s3 cpparallel
テストされていませんが、正しい軌道に乗っています... cdファイルのディレクトリに移動してから：
$ ls -1 -f | parallel --eta -m aws s3 cp {} s3://bucket-name
ls -1 -fディレクトリ内のファイルを 1 行に 1 つずつ、名前のみ、並べ替えなし、出力パイプで に一覧表示しますparallel。
--etaこれまでの進行状況に基づいて、残りのランタイムを推定します。
-m{}コマンドラインの長さに対するシェルの制限を超えないようにしながら、できるだけ多くの入力引数で置き換えることを意味します
parallelログファイル、エラー処理、生成する並列プロセスの数の制御などの他のオプションについては、gnu のドキュメントを参照してください(これは、これが実行されているマシンにあるコアの数にデフォルト設定する必要があります)。空きプロセッサ容量とメモリがある限り、プロセッサがネットワーク I/O の待機に多くの時間を浪費するため、コアがあるため、2 倍、3 倍、4 倍の数の並列ジョブを実行することをお勧めします。