ディスクレイアウトの設計 — パーティションとLVMをどこまで分けるか

ディスクレイアウトは「後から直せる」という油断が最も危険な設計領域のひとつです。本番稼働後に構成を変えるコストは初期設計時の数十倍に跳ね上がり、特に/varの容量不足はシステム全体を停止させる直接原因になります。どの領域を独立させ、どこにLVMの柔軟性を持ち込み、何を省略してよいか — この三つの判断を初期設計で確定させることが、安定運用の土台となります。

全部1パーティションで作って/varが溢れて止まる構造

/varに巻き込まれてシステム全体が停止する仕組み

単一パーティション構成の罠は、ディスク容量を使い切る主体が「システム」ではなく「特定の用途」であることにあります。Linuxシステムでは/var以下にログ、スプール、パッケージキャッシュ、データベースのジャーナル、コンテナイメージなど、運用に伴って増え続けるデータが集中します。これらが同じパーティションに同居していると、/varの肥大化が/tmpや/etcへの書き込みも封じ、最終的にsyslogdやsshdさえも起動できない状態に陥ります。

現場ではこの障害パターンが繰り返されています。100台規模のウェブサーバー群を管理していたある担当者は、デプロイ後3ヶ月でほぼ全台が/varの逼迫を起こし、ログローテーションを手動で回すために数日間の対応工数を要したと話しています。単一パーティションが持つ「手軽さ」は初期構築の速度には貢献しますが、その代償は運用フェーズに先送りされるだけです。

ログ肥大化だけではない/varの罠

/varの逼迫をログ管理の問題として捉えると、対策が「logrotateの設定を強化する」という方向に限定されます。しかし実態は複数の要因が重なっています。systemd-journaldのバイナリログは設定なしで際限なく積み上がります。パッケージマネージャーのキャッシュは更新のたびに古いパッケージを蓄積します。コンテナを使う環境では/var/lib/dockerが数十GBに達することも珍しくありません。これらはいずれも「ログ」ではなく、それぞれ独立した性質を持つデータです。

設計段階でこれらの増加傾向を把握せずにディスクレイアウトを決めると、後から個別に対応しなければならない穴が複数残ります。「/varを独立させておけばよかった」という後悔は、単に容量の話ではなく、障害の影響範囲を限定できなかったという構造上の失敗を意味します。

単一パーティション構成が招く連鎖障害のパターン

ディスクフルが引き起こす障害は段階的に拡大します。まずログの書き込みが失敗し始め、次にプロセスがディスク待ちで応答しなくなります。SSHのセッション確立にも影響が出ると、リモートからの回復操作自体が困難になります。最終的にシングルユーザーモードで起動し直す必要が生じ、サービス停止時間が予期せず長引くケースも発生します。単一パーティション構成では、この連鎖が/varの溢れという一点から始まり、システム全体に波及する速度が速いのが特徴です。設計時に領域を分離しておけば、影響をその領域内に留めることができます。

分けるべき領域と分けなくてよい領域の判断

独立させるべき領域の判断基準

領域を独立させる主な理由は三つあります。第一は「溢れたとき他の領域に波及させたくない」という隔離の要件です。/varと/tmpがその典型で、どちらも運用中に予測外の速度で肥大化します。第二は「マウントオプションを変えたい」という性能・セキュリティ要件です。/tmpにnoexecを付けたい、/homeをnosuidにしたいといった要件は、独立したパーティションがなければ実現できません。第三は「スナップショットやバックアップの境界を揃えたい」という管理の都合です。これら三つの理由のうち一つでも当てはまる領域は、独立させる候補として扱うべきです。

分けなくてよい領域の判断

/usr、/lib、/binは変化頻度が低く、溢れるリスクも小さいため、多くの構成では/（ルート）と同居させても問題が出ません。/optや/srvについても、用途が決まっているアプリケーションを専用のデータパーティションに格納する設計であれば、独立させる必要はほぼありません。むやみに分割を増やすと、後述する「空き容量の偏り」問題を引き起こします。判断基準のない分割は、管理コストを増やすだけで安全性には寄与しません。

ワークロード別の分割方針

ウェブサーバーとして動かすLinuxサーバーなら、最低限「/（ルート）」「/var」「/tmp」の3領域を独立させれば大半の障害連鎖を防げます。データベースサーバーであれば、さらにデータディレクトリ（/var/lib/mysqlや専用の/dataなど）を切り出し、WALやバイナリログを別の物理ディスクに置く構成が基本になります。CI/CDサーバーのように/var/lib/dockerや一時ビルドファイルが急増する環境では、増加量の見積もりが先決であり、設計前にワークロードの特性を把握しておくことが前提条件です。

比較表: 単一パーティション・固定分割・LVMの向き不向き

三つのアプローチとその特性

ディスクレイアウトには大きく三つのアプローチがあります。単一パーティション構成はすべての領域を一つのファイルシステムにまとめる最もシンプルな方式です。固定分割はパーティションを用途ごとに切り出し、それぞれに固定サイズを割り当てる方式です。LVM（論理ボリュームマネージャー）は物理ディスクを抽象化し、後から容量を変更できる柔軟性を持ちます。それぞれに適した状況が異なるため、サーバーの役割と運用フェーズに応じた選択が求められます。

比較項目	単一パーティション	固定分割	LVM
初期構築の速度	速い	中程度	やや遅い
障害の影響範囲	全域に波及	領域内に限定	領域内に限定
容量変更の柔軟性	なし（再構築が必要）	低い（停止を伴うことが多い）	高い（オンライン拡張が可能）
スナップショット対応	困難	困難	LVスナップショットで対応可能
マウントオプション制御	不可	領域ごとに設定可能	LVごとに設定可能
適したシナリオ	使い捨て・検証環境	容量が安定した固定ワークロード	成長するデータ量・長期運用サーバー
管理コスト	低い	中程度	高い（VG/LV概念の理解が必要）

選択基準の整理

上記の比較をもとにすると、検証環境や短期運用のサーバーには単一パーティション、容量が安定していて変更頻度が低いワークロードには固定分割、本番の長期運用サーバーや将来的な拡張が見込まれる環境にはLVMという選び分けが基本軸になります。ただし、LVMを採用したとしても「すべてをLVで管理する」のではなく、/bootは物理パーティションのままにする設計が一般的です。LVMにトラブルが発生した際でもブートが通ることを保証するためであり、この点は見落としやすい設計上の落とし穴のひとつです。

XFSとext4をワークロードでどう選び分けるか

ext4が適するワークロード

ext4は小さいファイルの読み書きが多い環境で安定した性能を発揮します。メールスプール、Webアプリのセッションファイル、ソースコードリポジトリのように、多数の小さなファイルが混在するワークロードではext4の方が管理しやすい特性を持ちます。また、fsckによるファイルシステムチェックの挙動が長年にわたって枯れており、問題発生時の回復手段も整っています。システム領域（/や/boot）にext4を使う構成は、扱いやすさと実績の両面で依然として有力な選択です。

XFSが適するワークロード

XFSは大きなファイルの連続書き込みと高スループットが求められるワークロードに強みを持ちます。動画ファイルのストレージ、データベースのデータ領域、バックアップリポジトリ、ログ集約サーバーなどがその典型です。並列書き込みの性能も高く、マルチスレッドで大量データを書き出すアプリケーションでは顕著な差が現れます。RHELやAlmaLinuxのデフォルトがXFSになっていることからもわかるとおり、現在の本番Linux環境ではXFSが主流になりつつあります。

選択の基準と設計上の注意点

ファイルシステムの選択で押さえておくべき判断基準は「ファイルサイズの分布」と「I/Oの方向性」の二点です。多数の小さなファイルを高頻度で読み書きするならext4、大きなファイルを連続して書き込む用途ならXFSを選ぶのが基本方針になります。ただし注意が必要な点として、XFSはオンラインでの縮小をサポートしていないため、初期サイズの見積もりを誤ると後始末が困難になります。LVMと組み合わせてXFSを使う場合は、拡張方向に余裕を持たせた設計を前提に据えておくことが重要です。

後から広げられる容量設計 — 拡張前提の切り方

LVM設計の基本: PEサイズとVGの分け方

LVMを使う前提で設計するとき、Physical Extent（PE）のサイズはデフォルト（4MB）のままで多くのケースは問題ありません。数TBを超えるような大容量ディスクを管理する場合はPEサイズを大きく設定しておくと管理の手間を削減できます。VG（ボリュームグループ）の設計では、システム用とデータ用を別々に作ることが推奨されます。データ用のディスクを追加する際にシステムVGへの影響を排除でき、用途別の独立した拡張が可能になります。

LVのサイズ配分と未割り当て領域の確保

LVを作成するとき、VG全体の容量をすべてLVに割り当てきるのは避けたほうが賢明です。VG容量の20〜30%を未割り当て（Unallocated）のまま残しておくと、急な容量増加にその場でLVを拡張して対応できます。本番サーバーで100GBのVGを用意した場合、最初から80GBをLVに割り当て、残り20GBを予備として温存しておく設計がひとつの目安です。この未割り当て領域が後々の自由度を大きく左右します。

拡張時に行き詰まらないための設計判断

容量拡張を後から行う場合に頻繁に問題となるのは、「物理ディスクの追加スロットがない」「ホットプラグに対応していない」というハードウェア制約です。オンプレミス環境では初期時点で物理スロットの空きを確認しておく必要があります。クラウド環境であれば追加ブロックストレージをアタッチする手順になり、仮想環境全般でも「まず小さく作って必要に応じて拡張する」設計がLVMと組み合わせると特に有効に機能します。初期構築の段階でこの拡張シナリオを具体的にイメージしておくことが、後から詰まらないための前提条件です。

細かく分けすぎて空き容量が偏る境界

分割数が増えると起きる管理コストの増大

領域を細かく分けすぎると、「ある領域は空き容量が90%あるのに、別の領域は残り5%」という偏りが生まれます。固定パーティションで10以上の領域を作ったサーバーでは、この偏りの調整が定期的な管理タスクになります。LVMであれば領域をまたぐ再配分がある程度容易ですが、それでも20台程度のサーバーを管理する環境では調整作業が月に数回発生するという話も珍しくありません。分割数が増えるほど、個々の領域サイズの見積もり精度が求められ、外れた場合の修正コストも上がります。

空き容量の偏りが引き起こす問題

偏りの問題は管理コストにとどまりません。ある領域がフルに近い状態で、他の領域に大量の空きがある構成は、障害対応時の選択肢を狭めます。緊急でログを退避させたい、一時的に大きなファイルを置きたいという場面で、「容量はあるはずなのに書けない」という状況が発生します。これは分割が細かすぎることによる設計上の制約であり、運用で補える性質のものではありません。設計段階で気づかずに通り過ぎると、後から気づいたときには構成変更の工数が膨らんでいます。

適切な分割数の目安と判断基準

設計の目安として、汎用のLinuxサーバーであれば「/」「/boot」「/var」「/tmp」「データ領域」「/home（ユーザーアクセスがある場合）」の5〜6領域が現実的な上限です。これ以上細かくする場合は、追加する理由を一つひとつ言語化できることが条件になります。「なんとなく分けておいた方が良さそう」という根拠のない分割は、後の偏りと管理コストを招くだけです。LVMを使うと後から分割や統合が比較的容易になるため、迷ったら「少なく分けてLVMで柔軟に」が安全な出発点です。手を動かす段階での詳細な操作は、実機演習や専門の技術書で補うことを前提に、設計判断だけを先に確定させる進め方が現場では合理的です。

ディスクレイアウト設計チェックリスト

設計の抜け漏れを防ぐために、以下のチェックリストを活用してください。初期設計時だけでなく、構築レビューの段階でも同じ項目で確認することを推奨します。

初期設計で確定させる判断項目

• 障害隔離の確認: /varと/tmpは独立したパーティションまたはLVになっているか
• ワークロードの把握: 急増する可能性があるディレクトリ（/var/log、/var/lib/docker、DBデータ等）を特定し、独立した領域または拡張可能なLVに割り当てているか
• LVMのVG設計: システムVGとデータVGを分けているか。VGの20〜30%を未割り当てで残す設計になっているか
• /bootの配置: /bootは物理パーティションで独立させ、LVMに依存しない構成になっているか
• ファイルシステムの選定: データ領域にXFSを使う場合、縮小できないことを前提にサイズを見積もっているか
• 分割数の妥当性: 各パーティション・LVを独立させる理由を言語化できるか。根拠のない分割がないか

構築レビューと運用準備で確認する項目

• マウントオプションの確認: /tmpにnoexec・nosuidを設定する要件がある場合、独立した領域として設計されているか
• 拡張余地の確認: オンプレミス環境では物理スロットの空きを確認しているか。クラウドであれば追加ストレージのアタッチ手順を事前に把握しているか
• 容量見積もりの根拠: ワークロードの成長率をもとに、初年度・3年後の使用量を試算しているか
• スナップショット・バックアップの境界: バックアップ対象とスナップショットの範囲が、パーティション設計の境界と一致しているか