同じワークロードを二つのストレージに入れて比べる

目標

同じコーパスを、ファイルシステム、S3互換ストレージ(SeaweedFSのS3ゲートウェイ)、SeaweedFSのファイラーの3か所に入れ、個数・時間・レイテンシを自分で測って、ストレージの選択を、好みではなく数字で行う方法を身につけます。

なぜ重要なのか

ストレージの選択は、ベンチマークの表を書き写すことでは決まりません。同じ製品が、ワークロードによって最良にも最悪にもなるからです。4KiBのファイル2,000個で分かれる差は、200MiBのファイル1つでは消え、その逆もあります。このラボは、その事実を、自分で測って確かめさせてくれます。特に、ステップ4で、ファイル2,000個がボリュームファイルいくつに入っているかを自分で数えてみると、「小さなファイルに強い」という文が、具体的な構造の話に変わります。最後の判断表は、あとで実際に選択をするときに、そのまま取り出して使える形に作ります。

比較の相手について、1つ書いておきます。このラボのS3側は、もともとMinIOでした。MinIOは、オブジェクト1つを、ディスク上のディレクトリ1つとメタデータファイル(xl.meta)として置くので、ステップ2で測ったファイルシステムのコストを、オブジェクトごとにそのまま負います。小さなファイルの問題の、典型的な反対側でした。2025年にコミュニティエディションがバイナリの配布を終えて、このイメージから外れ、今のステップ3のS3サーバーは、SeaweedFSのS3ゲートウェイです。そのため、このラボが測るのは、2つのストレージエンジンの対決ではなく、小さなファイルのコストの2層です。ファイルシステム(ステップ2)は「ディスク上のファイルの個数」のコストを、S3(ステップ3)とファイラー(ステップ4)は、同じSeaweedFSを2つの入口から叩いて、「リクエストの個数」のコストを見せてくれます。S3から入れても、ボリュームファイルは増えないことまで、ステップ3で一緒に確認します。

ステップ

/root/cmp/corpus/の下に、4096バイトのファイルを2,000個作成してください。名前は、f0000.binからf1999.binまでです。
/root/cmp/fs.txtに、files=2000、data_bytes=8192000、disk_kb=<du -sk 결과>の3行を書いてください。山括弧の部分には、duコマンドの結果の数値を入れます。disk_kbは、データのサイズより大きい必要があります。
S3サーバー(http://127.0.0.1:9000)にバケットlab-cmpを作成して、コーパスをまるごとアップロードし、/root/cmp/s3.txtにobjects=2000 seconds=<소수>を書いてください。山括弧の部分には、小数で表した秒数を入れます。
同じコーパスを、SeaweedFSのファイラーの/cmp/の下に入れ、/root/cmp/sw.txtにfiles=2000 dat_files=<n> seconds=<소수>を書いてください。dat_filesは、20以下である必要があります。
ランダムな100個を、それぞれのストレージから読み、/root/cmp/latency.csvに、store,avg_msのヘッダーと、fs、s3、filerの3行を書いてください。
200MiBのファイル1つを、3つのストレージに入れて読み、/root/cmp/bigfile.csvに、store,put_ms,get_msのヘッダーと3行を書いてください。
/root/cmp/decision.mdに、Markdownの表を書いてください。行の見出しは、소파일 대량、대용량 소수、S3 API 필요、운영 인력の4つ(順に、小さなファイルが大量、大容量で少数、S3 APIが必要、運用人員)で、おすすめの列がある必要があります。

参考

ファイルの作成: dd if=/dev/urandom of=f0000.bin bs=4096 count=1、またはPythonのループ
ディスク使用量: du -sk /root/cmp/corpus
時間の測定: date +%s.%Nの前後の差、またはtime
S3側: 認証情報は/opt/fixtures/s3/creds.envで、プロファイルは、s3-basicsのステップ1と同じ方法でlocalを作ります。アップロードはaws s3 cp --recursive、読み取りは、boto3が楽です。
2つのSeaweedFSは、別々のプロセスです。S3サーバーは、ラボ環境が立ち上げたもの(データは/var/lib/lab-s3/data)で、ステップ4のマスター・ボリューム・ファイラー(9333・8180・8888)は、自分で立ち上げるものです。
よくあるミス1: 3つのストレージに、異なるデータを入れて比較してしまうこと。
よくあるミス2: キャッシュが温まった状態と、冷えた状態を混ぜて測ること。順序を一定にしてください。

比較用のコーパスを作る

/root/cmp/corpus/の下に、4096バイトのファイルを2,000個作成してください。名前は、f0000.binからf1999.binまでです。

同じデータを3か所に入れて、はじめて比較になります。サイズと個数を、正確に合わせてください。

ファイルシステムに入れて、メタデータのコストを測る

/root/cmp/fs.txtに、files=2000、data_bytes=8192000、disk_kb=<du -sk 결과>の3行を書いてください。山括弧の部分には、duコマンドの結果の数値を入れます。disk_kbは、データのサイズより大きい必要があります。

データのサイズと、実際に使われるブロックは違います。ファイルの数も、一緒に数えておいてください。

S3に入れて、所要時間を測る

S3サーバー(http://127.0.0.1:9000)にバケットlab-cmpを作成して、コーパスをまるごとアップロードし、/root/cmp/s3.txtにobjects=2000 seconds=<소수>を書いてください。山括弧の部分には、小数で表した秒数を入れます。

オブジェクト1つ1つがリクエストです。個数がそのまま時間になるのか、そして、S3サーバーのボリュームファイルは増えるのかを、確認してください。

SeaweedFSに入れて、ボリュームファイルの数を測る

同じコーパスを、SeaweedFSのファイラーの/cmp/の下に入れ、/root/cmp/sw.txtにfiles=2000 dat_files=<n> seconds=<소수>を書いてください。dat_filesは、20以下である必要があります。

前のラボで立ち上げたデーモンを、そのまま使います。ボリュームファイルの個数が、核心となる観察ポイントです。

ランダム読み取りのレイテンシを比較する

ランダムな100個を、それぞれのストレージから読み、/root/cmp/latency.csvに、store,avg_msのヘッダーと、fs、s3、filerの3行を書いてください。

同じ100個を、ランダムな順序で読みます。3つの値を、1つのファイルにまとめてください。

大きなファイル1つでも、同じ比較をする

200MiBのファイル1つを、3つのストレージに入れて読み、/root/cmp/bigfile.csvに、store,put_ms,get_msのヘッダーと3行を書いてください。

小さなファイルで分かれていた差が、大きなファイルではどうなるかが、結論の半分です。

選択基準の表を書く

/root/cmp/decision.mdに、Markdownの表を書いてください。行の見出しは、소파일 대량、대용량 소수、S3 API 필요、운영 인력の4つ(順に、小さなファイルが大量、大容量で少数、S3 APIが必要、運用人員)で、おすすめの列がある必要があります。

ワークロードの特性ごとに、どちらを選ぶかを、表に整理します。行の見出しが、採点の基準です。