NVMe・SATA と管理 UI の配置方針

はじめに

データ基盤のストレージを、クエリ用の NVMe とログ用の SATA に分けました。管理 UI は Linux から Mac に移し、計算・保存と画面表示の役割も分けています。

データ基盤構築で、ログの連続書き込みと解析の一時 I/O を分けるための配置方針です。

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

当初はすべて NVMe に置いていました。運用では、次の負荷が重なることが問題でした。

1. 連続書き込み: systemd、Loki、Prometheus が継続して I/O を使います。高頻度の fsync や同期書き込みは、内部バッファや耐久性、クエリの待ち時間に影響し得ます。
2. 解析との競合: Trino や dbt の spill がログ書き込みと重なると、応答が遅くなります。
3. UI の負荷: Dagit や Grafana もログを出します。同じ Linux ノードで動かすと、データ処理とリソースを取り合います。

そこで、デバイスの種類とホストの役割を分けました。

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

データを I/O の特性で 2 つに分けます。

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

ランダムアクセスと低レイテンシが必要なものは NVMe に置きます。

• Postgres: WAL を含む DB の主要ファイル。クエリ応答を優先します。
• 解析の spill/cache: Trino のディスク退避や Iceberg の staging など、一時的な大量 I/O。
• LLM モデル: Ollama・vLLM の数 GB〜数十 GB のファイル。ロード時間を短くするため NVMe に置きます。
• 検索と中間データ: Qdrant のインデックス、Dagster の中間キャッシュ。

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

ログの連続書き込みと、アクセスの少ないファイルは SATA SSD に置きます。この構成では、steady write の安定性を重視して選びました。

• ログ・時系列データ: /var/log、Prometheus TSDB、Loki chunks/index。
• コンテナの管理情報: Podman のレイヤー、compose 定義。
• バックアップ: データ本体と別の物理デバイスに置きます。

UIデモンの集約戦略

Linux はデータエンジン、Mac は管理 UI の役割にしました。

Dagit、Grafana、Lightdash、Trino Web UI を、Mac の Podman/Docker に移しました。

この構成のメリット

• UI のログや設定ファイルの I/O を、Mac の SSD に分散できます。
• Linux の rootless podman はデータエンジンに絞り、管理するコンテナと I/O の競合を減らします。
• UI は gRPC や SQL で Linux に接続するため、操作方法は変わりません。

結論と今後の展望

Linux 側を計算と保存に集中させました。デバイスとホストを分けることで、限られたリソースの競合を抑える方針です。

UI の実行環境として、Podman on Mac と Docker Desktop の負荷と安定性は今後比較する予定です。

配置ポリシーまとめ