データ基盤のI/Oを最適化する：NVMe/SATAの使い分けとUIデモンの集約戦略

はじめに

モダンなデータ解析基盤を個人や小規模チームで運用する際、最も頭を悩ませるのがストレージのI/O設計だ。NVMe SSDの普及によりバースト的な読み込み性能は飛躍的に向上したが、一方でログやメトリクスの連続的な書き込みによる負荷が、本来優先すべきデータクエリのレイテンシに悪影響を及ぼすケースも少なくない。

今回は、システム全体の安定性を高めるために採用した「ストレージ配置ポリシー」と、管理UIを別ホストに分離する「UI集約戦略」についてまとめる。

背景と動機：なぜストレージを分けるのか

当初はすべてのデータを高速なNVMe SSDに集約していたが、運用を続けるうちにいくつかの課題が見えてきた。

1. 連続書き込みによる揺らぎ: ログ（systemd, Loki）やメトリクス（Prometheus）は常にI/Oを消費し続ける。NVMeはピーク性能は高いものの、高頻度な fsync や連続同期書き込みが続くと、内部バッファの枯渇や耐久性の懸念が生じ、クエリのレイテンシに揺らぎが出ることがある。
2. I/O衝突のリスク: 解析系（Trino, dbt）が一時的に大量のデータをスワップ（spill）させる際、ログ書き込みと衝突すると、システム全体のレスポンスが悪化する。
3. UIデモンのリソース消費: DagitやGrafanaなどのUIコンテナは、それ自体が管理用のログを吐き出す。これらをLinux側のデータエンジンと同じノードで動かし続けるのは、リソース管理の観点からも非効率だった。

これらを解決するため、ストレージのデバイス特性（NVMe vs SATA）とホストの役割（Linux vs Mac）を再定義した。

ストレージ配置ポリシーの再定義

I/Oの特性に応じて、データを以下の2つに分離した。

NVMe：高スループット・バースト読込向き

高速なランダムアクセスと低レイテンシが必要なものはすべてNVMeに配置する。

• Postgresデータ本体: WALを含め、データベースの主要ファイルはNVMeに置くことで、クエリ応答速度を最大化する。
• 解析エンジンのspill/cache: Trinoのspill（メモリ溢れ時のディスク退避）や、Icebergのstaging領域など、一時的な大量I/Oが発生する場所。
• LLMモデル: OllamaやvLLMで使用する数GB - 数十GBのモデルファイルは、ロード速度がUXに直結するためNVMeが必須。
• ベクトル検索と中間生成物: Qdrantのインデックスや、Dagsterの中間データキャッシュなどが含まれる。

SATA：安定シーケンシャル書き込み向き

連続的な書き込みが発生するログや、読み書きの頻度が低いものはSATA SSDに逃がす。SATA SSDは内部バッファが安定しており、steady writeにおいて信頼感がある。

• システムログと時系列データ: /var/log のほか、書き込みレートが高いPrometheus TSDB、Lokiのchunks/indexをこちらへ移動した。
• コンテナ管理メタデータ: Podmanのコンテナレイヤーやcompose定義。
• バックアップ: 冗長性の観点からも、データ本体とは別の物理デバイス（SATA）に置くのが定石。

UIデモンの集約戦略

もう一つの大きな変更が、「Linuxはデータエンジン、MacはUIハブ」という役割分担だ。

管理用のUI（Dagit, Grafana, Lightdash, Trino Web UI）をLinuxノードから取り除き、メインの作業端末であるMac側のPodman/Docker上で動かすようにした。

この構成のメリット

• Linux側のI/O負荷軽減: UI系コンテナが吐き出す細かいログや設定ファイルの読み書きが、Mac側のSSDに分散される。
• rootless podmanの安定化: Linux側で管理するコンテナ数を「データエンジン専任」に絞り込むことで、管理レイヤーの複雑さを排除し、I/O衝突のリスクを最小化できる。
• ネットワーク経由の透過的アクセス: Mac上のUIからは gRPCやSQLを介してLinux側のバックエンドに繋ぐだけなので、操作感は変わらない。

結論と今後の展望

今回の戦略により、Linuxノードを「純粋な計算・データ蓄積エンジン」として研ぎ澄ませることができた。I/O特性に応じた物理的な棲み分けは、リソースが限られた環境ほど効果を発揮する。

今後は、Mac側で稼働させるUIコンテナのランタイムとして、Podman on MacとDocker Desktopのどちらがよりオーバーヘッドが少なく安定するかを検証していく予定だ。

配置ポリシーまとめ