MinIO on Ubuntu — S3互換オブジェクトストレージでデータレイク構築

「AWS S3 は便利だけど、データ量が増えると料金が怖い」「自分のサーバーに S3 互換のストレージを置いて、データレイクを自前で作りたい」——そんなときに使えるのがMinIOです。結論から言うと、Ubuntu なら docker run 1行で S3 互換のオブジェクトストレージが立ち上がり、AWS S3 と同じ API・同じ aws s3 / mc コマンドでそのまま使えます。

本記事では Ubuntu ホスト上の Docker に MinIO を構築し、raw / processed / curated の3層からなるデータレイクを実際に作りました。さらに MinIO 公式のベンチマークツール warp で S3 スループットを実測し、ブラウザの管理画面（Console）も実際に撮影しています。

「オブジェクトストレージって、結局ディスクのどこに何が保存されるの？」という疑問にも、データディレクトリの中身を直接覗いて答えます。コマンドの結果も画面も、すべて実際に動かして確かめた実データ中心の記事です。

MinIOとは：自分のサーバーに置けるS3互換オブジェクトストレージ

MinIO は、AWS S3 と互換性のある API を持つオープンソースのオブジェクトストレージです。オブジェクトストレージとは、ファイルを「バケット」という入れ物に「オブジェクト」として放り込んで、HTTP の API（GET / PUT など）で読み書きするストレージのこと。写真・ログ・バックアップ・機械学習の学習データなど、大量の非構造データを置くのに向いています。

MinIO の最大の利点は、AWS S3 とほぼ同じ API で動くことです。つまり aws s3 コマンドや、Python の boto3 / s3fs、PySpark、DuckDB といった「S3 を読めるツール」が、エンドポイントを自分の MinIO に向けるだけでそのまま使えます。S3 にかかるストレージ料金・転送料金を払わずに、同じ使い勝手のデータ基盤を自宅サーバーや VPS に作れるわけです。

本記事では、バケットを「層」として分けてデータを段階的に整える、データレイクの典型構成を作っていきます。

生データをそのまま入れる raw、整形済みデータを置く processed、分析・配信用に仕上げた curated の3つのバケットを用意します。MinIO は S3 互換なので、この各層を Spark や pandas で読み書きしてパイプラインを組めます。

動作確認済み環境

手順1：DockerでMinIOを起動する

MinIO の起動は docker run 1行です。MINIO_ROOT_USER と MINIO_ROOT_PASSWORD で管理者の認証情報を指定し、server /data でデータの保存先を、--console-address ":9001" で管理画面のポートを指定します。

-v minio_data:/data で named volume を割り当てているのがポイントです。これをやらないと、コンテナを消したときにオブジェクトも一緒に消えてしまいます。本番運用では /data を必ず永続ボリュームに置いてください。

手順2：mcクライアントでデータレイクを作る

MinIO の操作には専用クライアント mc（MinIO Client）を使います。aws s3 でも操作できますが、mc は MinIO に最適化されていて管理コマンドも豊富です。まず mc alias set でサーバーを登録し、バケットを3つ作って、ローカルのディレクトリを mc mirror で同期します。

実際に動かすと、3つのバケット（raw / processed / curated）が作成され、5.00 MiB のデータが 104.33 MiB/s で同期されました。mc ls --recursive で中身を見ると、46バイトの CSV から 5.0 MiB のバイナリまで、S3 のオブジェクトとして並んでいます。最後の mc anonymous set download lab/curated は、curated 層だけを匿名で読み取り可能（公開）にする設定です。層ごとに公開範囲を変えられるのがバケット分割の利点です。

mc admin info の出力には 1 drive online, EC:0 と表示されました。MinIO は本来、複数ドライブにデータを分散して冗長化（Erasure Coding）しますが、ドライブが1台のときは EC:0（冗長なし）の単一ドライブ Erasure バックエンドとして動きます。学習や個人用途ならこれで十分です。

手順3：ブラウザの管理画面（Console）で確認する

MinIO は http://localhost:9001 でブラウザの管理画面が開きます。コマンドだけでなく GUI でもバケットやオブジェクトを操作できるのが、自前 S3 の嬉しいところです。アクセスすると、まずログイン画面が表示されます。

手順1で指定した MINIO_ROOT_USER / MINIO_ROOT_PASSWORD を入力してログインします。初回ログイン時に AGPLv3 ライセンスの確認モーダルが出るので、Acknowledge で閉じてください。ログインすると、左サイドバーに作成した3つのバケットが並ぶオブジェクトブラウザが表示されます。

サイドバーの raw をクリックすると、mc mirror で同期したディレクトリ構造が events/ と users/ というフォルダ（プレフィックス）として見えます。バケットの Access が PRIVATE になっている点にも注目してください。

さらに events/ を開くと、CSV ファイル5つと 2.0 MiB のバイナリが、サイズ・更新日時つきで一覧表示されます。ここから直接アップロード・ダウンロード・削除もできます。

正直、最初は「コマンドで全部できるのに GUI いる？」と思っていました。でも、データレイクに何が入っているかをチームで確認したり、間違って入れたファイルをサッと消したりするとき、画面があるとやっぱり安心です。S3 のマネジメントコンソールが手元にある感覚ですね。

データはディスク上にどう保存されるのか

ここが個人的に一番おもしろかった部分です。「S3 にアップロードしたファイルは、実際にはサーバーのディスクのどこに、どんな形で置かれているのか？」を確かめてみました。named volume の中身を別のコンテナから直接覗いてみます。

結果は予想外でした。event_1.csv はファイルではなくディレクトリで、その中に xl.meta という459バイトのファイルが入っていたのです。MinIO は「1オブジェクト = 1ディレクトリ + その中の xl.meta」という構造でデータを保存します。xl.meta にはオブジェクトのメタデータが入り、小さいオブジェクトの場合はデータ本体もこの xl.meta にインライン格納されます。だから46バイトの CSV を探してもファイルとしては見当たらないわけです。

find /data/raw -name xl.meta | wc -l の結果は 7。投入した7オブジェクトに対して、ちょうど7個の xl.meta がありました。この構造を知っておくと、「ディスク使用量が想定より多い」「小さいファイルを大量に置くと inode を食う」といった運用上の挙動も腑に落ちます。

S3スループットを公式ベンチ warp で実測する

「自前の MinIO は実際どれくらい速いのか？」を、MinIO 公式のベンチマークツール warp で測りました。warp は実際に S3 の PUT / GET / mixed（混在）ワークロードを並列で流して、スループットを計測してくれます。1MiB のオブジェクトを並列8で20秒間流した結果がこちらです。

はっきり差が出たのは GET（読み出し）と PUT（書き込み）の非対称性です。GET が 1,975.7 MiB/s なのに対し、PUT は 281.2 MiB/s。読み出しは書き込みの約7倍速いという結果でした。オブジェクトストレージは書き込み時にメタデータの整合性を取る処理が入るため、読み出しのほうが速くなります。実運用に近い mixed ワークロード（GET 45%・STAT 30%・PUT 15%・DELETE 10%）では合計 878.4 MiB/s（1,464 obj/s）でした。

もうひとつ重要なのが、オブジェクトのサイズで「効く指標」が変わるという点です。1秒あたりのオブジェクト処理数（obj/s）で見てみます。

4KiB の小オブジェクトを PUT すると、帯域はわずか 4.5 MiB/s ですが、1秒あたり 1,157個も処理できています。小さいファイルの世界では「何 MB/s 出るか」ではなく「1秒に何件さばけるか（メタデータ操作の速さ）」がボトルネックになるのです。逆に大きいファイルはディスク帯域が効きます。データレイクに小さいファイルを大量にばらまくと管理コストが増える、という設計上の教訓がここから読み取れます。

MinIOを動かすホストの基礎性能

ベンチ結果の背景として、MinIO を動かしたホストの基礎性能も sysbench と dd で測っておきました。オブジェクトストレージの実体はファイルシステムなので、ディスクの速さがそのまま PUT/GET に効いてきます。

CPU は sysbench で 14,561 events/sec（3回平均）、メモリ帯域は 46,064 MiB/sec、ディスクは direct I/O で書込 1.9 GB/s・読込 2.0 GB/s でした。注目したいのは、ディスク読込の 2.0 GB/s が、先ほどの warp の GET スループット（約1,976 MiB/s ≒ 2.0 GB/s）とほぼ一致している点です。MinIO の読み出し速度は、結局そのサーバーのディスク読込速度で頭打ちになることが実測で裏づけられました。本番 VPS を選ぶときは、NVMe ストレージかどうかを必ず確認しましょう。

「自宅PCで試して、本番はVPSに置きたい」という場合、NVMe を使える VPS なら、自前 MinIO でも十分実用的なデータ基盤になります。

用途別の選び方

MinIO の使いどころと、向いている環境を整理します。

いずれの用途でも、データが増えるほど「ディスクの速さ・容量」と「停電やディスク故障への備え」が効いてきます。自宅サーバーで始めて、データが大事になってきたら NVMe の VPS に移すのが現実的なステップです。

よくあるエラーと解決策

① パスワードが短くてサーバーが起動しない

MINIO_ROOT_PASSWORD が8文字未満だとこのエラーで起動しません。8文字以上の文字列を指定してください。

② ブラウザで9001を開いても繋がらない（VPSの場合）

Vultr や DigitalOcean などの VPS はデフォルトでポートが閉じています。sudo ufw allow 9001 で開放してください。ただし管理画面を全世界に公開するのは危険なので、SSHポートフォワード（ssh -L 9001:localhost:9001 user@サーバーIP）でローカルからだけ繋ぐのが安全です。

③ mc alias set で「invalid hostname」と言われる

コンテナ名にアンダースコア（_）が入っていると、DNS のホスト名として不正と判定されて mc がエンドポイントを解決できません。コンテナ名やネットワークエイリアスはハイフン（-）で構成してください。

④ コンテナを消したらデータが消えた

-v でボリュームを割り当てずに server /data を使うと、データはコンテナ内に閉じ込められ、docker rm で消えます。必ず -v minio_data:/data のように named volume かホストディレクトリをマウントしてください。

まとめ

MinIO を Ubuntu に構築して実測した結果をまとめます。

• MinIO は docker run -d -p 9000:9000 -p 9001:9001 -v minio_data:/data minio/minio server /data --console-address ":9001" の1行で起動できる
• 操作は mc（MinIO Client）が便利。mc mb でバケット作成、mc mirror でディレクトリをS3同期、mc anonymous で公開設定
• 管理画面は http://localhost:9001。バケット・オブジェクトをブラウザで操作できる
• 実測: warp で GET 1,976 MiB/s・PUT 281 MiB/s。読み出しは書き込みの約7倍速い
• 実測: 小オブジェクト(4KiB)は 1,157 obj/s。小ファイルは帯域でなく件数(obj/s)が効く
• MinIOは1オブジェクト=1ディレクトリ+xl.metaで保存する。読込速度はディスク帯域で頭打ち
• 本番VPSは2〜4GBメモリ・NVMeストレージが目安。読込速度がそのまま性能になる

まずは自宅PCやWSLの Docker で raw / processed / curated の3層を作って、S3 互換のデータレイクを触ってみてください。データが本物になってきたら、NVMe の VPS に載せ替えるのが次のステップです。サーバー選びは下記の比較記事も参考にどうぞ。

[LINK_X_ARTICLE]