「とりあえず動かすことはできるが、本番運用に耐える構成になっているか自信がない」
Webアプリ向けにLinuxサーバーを組むとき、最初の構成設計を間違えると、半年後・1年後の運用で必ず痛い目を見ます。
この記事では、Webアプリ向けLinuxサーバーの「標準構成」をディレクトリ・サービス・パーティションの3軸で解説します。
RHEL 9.4 / AlmaLinux 9.3 / Ubuntu 24.04 LTS で検証しています。
20年以上のサーバー運用経験から「これだけは押さえておけば事故らない」という最低限の設計指針をまとめました。
この記事のポイント
・Webサーバーの標準は /var /tmp /home を分離した4～6パーティション構成
・サービスは Web/DB/監視 を最小限に絞り SELinux と firewalld を必ず有効化
・ログ設計と日次バックアップ設計をサーバー構築の同じタイミングで決める
・移行時のチェックリストで設計漏れと運用事故を防げる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Linuxサーバー標準構成の考え方
Webアプリ向けのLinuxサーバーを構築するとき、まず押さえておきたいのは「単一目的・最小構成・分離設計」の3原則です。・単一目的：1サーバーに役割を詰め込みすぎない（Web+DB+メール同居は障害切り分けが地獄）
・最小構成：使わないサービスはインストールしない・有効化しない
・分離設計：パーティション・ユーザー・ネットワーク・ログを役割ごとに切り分ける
この3原則を念頭に、Webアプリ向けの標準構成を組み立てていきます。
クラウドでもオンプレでも考え方は同じです。EC2のEBS、オンプレの物理ディスクのどちらでも応用できます。
推奨パーティション設計（Webアプリ向け）
1. 4～6パーティションが標準
Webアプリ向けの本番サーバーでは、最低でも以下の4パーティションを分けます。物理メモリが32GB未満であればスワップも追加します。・/（ルート）：30～50GB。OSとパッケージ用
・/var：50～100GB以上。ログ・DB・キャッシュ・コンテナイメージ用
・/tmp：10～20GB。一時ファイル用（noexec推奨）
・/home：20～50GB。運用ユーザーのホーム用
・swap：RAM 8GB以下なら2倍、RAM 16～32GBなら同量、RAM 32GB超なら4～8GB固定
・/boot：1GB（UEFIなら /boot/efi 512MBも）
LVMを使う場合は VG=system / VG=data の2VG構成にすると、データ用ディスクの拡張・移行が楽になります。mount コマンドの使い方と組み合わせて、各パーティションが正しいマウントポイントに割り当てられているか必ず確認してください。
2. 実サーバーでの dfコマンド出力例
本番運用中のWebサーバー（RHEL 9.4）での実際のdf -h 出力です。$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/system-root 40G 12G 28G 31% / /dev/mapper/system-var 100G 48G 52G 48% /var /dev/mapper/system-tmp 15G 2.1G 13G 15% /tmp /dev/mapper/system-home 30G 5.2G 25G 18% /home /dev/mapper/data-app 200G 88G 112G 44% /opt/app /dev/sda1 976M 248M 662M 28% /boot /dev/sda2 599M 6.8M 592M 2% /boot/efi tmpfs 7.8G 0 7.8G 0% /dev/shm
・/var が一番大きく確保されている（ログとDBの増加に耐える）
・/opt/app がアプリ用に独立確保されている
3. パーティション切り分けの優先順位
リソースに制約がある場合の優先順位は以下です。・最優先：/var を分離（ログ・DBの肥大化でOSが止まるのを防ぐ）
・次点：/tmp を分離（noexec・nosuid を付けてセキュリティ強化）
・余裕があれば：/home を分離（運用ユーザーのデータ保護）
スワップ容量の詳細な決め方は、別記事の「Linuxサーバーのスワップ領域を設計・拡張する方法」も参照してください。
/var /tmp /home を分離する必要性
1. /var を分離しないと何が起きるか
/var を分離しない場合、ログやDBが肥大化して /（ルート）が100% になると、OSの基本動作（ログイン・systemctl・dnf）が全て失敗します。私が現場でよく見るのは、深夜のログ肥大化で朝出社したら sshd が動かない、というパターンです。具体的に
/var 配下で容量を食うのは以下です。・/var/log：journal・httpd・nginx・syslog
・/var/lib/mysql ・ /var/lib/postgresql：DB本体
・/var/cache：yum/dnfキャッシュ
・/var/lib/docker：コンテナイメージ
これらが膨らんでもルートには影響しないように、必ず /var を別パーティション化します。
2. /tmp に noexec を付ける理由
/tmp は誰でも書き込めるディレクトリのため、攻撃者がマルウェアを置いて実行する典型的な攻撃経路です。/etc/fstab に
noexec,nosuid,nodev を付けると、/tmp 配下のバイナリを実行できなくなります。# /etc/fstab の /tmp 行の例 /dev/mapper/system-tmp /tmp xfs defaults,noexec,nosuid,nodev 0 0
・nosuid：SUIDビットを無効化
・nodev：デバイスファイルの作成を禁止
ただし、一部のパッケージインストールが /tmp で実行を試みるため、dnf 更新時に noexec を一時的に外す必要が出る場合があります。
3. /home を分離するメリット
/home を分離しておくと、OS再インストール時に /home パーティションをそのまま残せます。運用ユーザーのSSH鍵・dotfilesが消えないため、復旧時間を大幅に短縮できます。共有開発機やジャンプサーバーでは、/home パーティションをNFSやCIFS経由で共有することもあります。
サービス選定（Web・DB・監視）
1. Webサーバー：Nginx と Apache の選び分け
2026年現在、Webアプリ向けには Nginx が第一選択肢です。リバースプロキシ・静的配信・SSL終端のいずれも高速で、設定もシンプルです。・Nginx：高負荷・リバースプロキシ・静的配信に強い。設定はディレクティブ型
・Apache：.htaccess を使う既存アプリ・PHPモジュール直接連携に強い。設定は柔軟だが冗長
新規構築なら Nginx + アプリサーバー（uWSGI/Gunicorn/PHP-FPM）の組み合わせを推奨します。
2. データベース：MySQL/MariaDB と PostgreSQL の選び分け
Webアプリ向けの定番は以下の2択です。・MySQL / MariaDB：WordPress・CMS系・既存案件が多い。レプリケーションが枯れている
・PostgreSQL：複雑なクエリ・地理情報・JSON操作が必要なら有利。型に厳密
本番ではDBサーバーをWebサーバーと別ホストに分けるのが原則です。同居させると、メモリ競合とバックアップ時のディスクI/O競合で必ず問題になります。
3. 監視：軽量導入なら node_exporter + Prometheus + Grafana
構築直後から監視を入れておくと、後で「いつから遅くなったのか」を追えます。最低限の監視構成は以下です。# 最小監視構成（各ノード） node_exporter : OSメトリクス（CPU/メモリ/ディスク/ネット）を9100番ポートで公開 systemd で常駐させる # 集約サーバー Prometheus : node_exporter からメトリクスをスクレイプ Grafana : Prometheus を参照してダッシュボード表示 Alertmanager : 閾値超過時にメール・Slack通知
起動時間や各サービスの起動所要時間を確認するなら、systemd-analyze で起動時間計測を活用すると、構築直後のチューニングが進めやすくなります。
最小化原則と SELinux / firewalld
1. 不要サービスは止める・消す
RHEL系・Ubuntuどちらも、デフォルトで起動しているサービスは結構あります。Webサーバー専用機であれば、以下は止めて問題ないことが多いです。# 起動中サービス一覧を確認 $ systemctl list-units --type=service --state=running # 不要サービスを止めて無効化（例: cups・avahi-daemon） # systemctl stop cups # systemctl disable cups # systemctl stop avahi-daemon # systemctl disable avahi-daemon
2. SELinux は Enforcing のまま運用する
RHEL系では SELinux を Disabled にする運用例をいまだに見ますが、本番では Enforcing のまま運用するのが正解です。# 現在のSELinuxモードを確認 $ getenforce Enforcing # 詳細を確認 $ sestatus SELinux status: enabled Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33
audit2allow でポリシーを生成し、必要最小限の許可を追加します。Disabled にして全部素通しにするのは、防御層を1枚はがすのと同じです。3. firewalld でポート最小公開
firewalld のゾーン設計はシンプルにします。# 現在の設定確認 $ firewall-cmd --list-all public (active) target: default interfaces: eth0 services: ssh ports: protocols: # HTTPSとHTTPを許可 # firewall-cmd --permanent --add-service=https # firewall-cmd --permanent --add-service=http # firewall-cmd --reload
ログ設計
1. ログのローテーションと保管期間
ログ設計で押さえておくべきは「ローテーション」「保管期間」「外部送付」の3点です。・ローテーション：logrotate で日次または容量基準でローテート
・保管期間：法令要件があれば最低7年（医療・金融）、なくても1年は残す
・外部送付：syslog-ng / rsyslog で集約サーバーに転送、または S3 / GCS にアップロード
本番Webサーバーでよく使う logrotate 設定の例です。
# /etc/logrotate.d/nginx の例 /var/log/nginx/*.log { daily missingok rotate 60 compress delaycompress notifempty create 640 nginx adm sharedscripts postrotate /bin/kill -USR1 `cat /var/run/nginx.pid 2>/dev/null` 2>/dev/null || true endscript }
2. journalctl の永続化
RHEL系・Ubuntuどちらも、systemd journal はデフォルトでメモリ保存（再起動で消える）の設定になっている場合があります。永続化しておくと、再起動前のエラーが追えます。# /etc/systemd/journald.conf を編集 # Storage=auto → Storage=persistent に変更 # SystemMaxUse=2G などで容量上限も指定 # 反映 # systemctl restart systemd-journald
バックアップ設計
1. バックアップの3-2-1ルール
バックアップ設計の鉄則は「3-2-1ルール」です。・3：データのコピーを3つ持つ（オリジナル + バックアップ2つ）
・2：2種類の媒体に保存（ローカルディスク + クラウド or テープ）
・1：1つは遠隔地（オフサイト）に保管
最低でも「ローカルバックアップ + クラウドバックアップ」の2系統を作ります。片方が破損しても、もう片方から復旧できる体制です。
2. 何を・どの頻度でバックアップするか
Webサーバーで最低限バックアップ対象にすべき項目です。# 日次（毎日） /etc : 設定ファイル一式 /var/log : ログ（圧縮） DBのダンプ : mysqldump / pg_dump # 週次 /var/www : Webコンテンツ /opt/app : アプリ本体（gitで管理していなければ） /home : ユーザーデータ # 月次 フルバックアップ : システム全体（dd / Clonezilla / Veeam）
3. 復元手順を必ずリハーサルする
「バックアップは取っているが、戻したことがない」というサーバーが現場には驚くほど多いです。実際に戻せないバックアップは、無いのと同じです。構築直後に「DBを別環境に戻す」「設定ファイルを別ホストに展開する」というリハーサルを1度はやってください。所要時間と手順書を整備しておくと、本番障害時の復旧時間が短縮できます。
移行時のチェックリスト
旧サーバーから新サーバーへの移行時、見落としやすい項目をチェックリストにまとめました。| 項目 | 確認内容 |
|---|---|
| OS | RHEL / AlmaLinux / Ubuntu のメジャーバージョンとサポート期限 |
| パーティション | /var /tmp /home が分離されているか、各容量は妥当か |
| SELinux | Enforcing で起動するか、必要なポリシーは生成済みか |
| firewalld | 必要ポートのみ開放されているか、SSHのIP制限はあるか |
| NTP | chrony または ntpd で時刻同期されているか |
| DNS | resolv.conf または NetworkManager で正引き・逆引きが通るか |
| ログ | logrotate と journal の永続化設定がされているか |
| バックアップ | 日次・週次・月次の対象と保管先が定義されているか |
| 監視 | node_exporter または相当のメトリクス収集が動いているか |
| ユーザー | 運用ユーザーのSSH鍵と sudo 権限が引き継がれているか |
| cron / timer | 定期処理がすべて新サーバーにコピーされているか |
| 切替手順 | DNSのTTLを短くしてから切替、ロールバック手順を準備 |
トラブルシュート・エラー対処
「No space left on device」が出た場合
ディスクが満杯になったときの典型エラーです。/var ・ /tmp のどちらかが100%になっていることが多いです。# 各パーティションの使用率を確認 $ df -h # /var で容量を食っているディレクトリを特定 # du -sh /var/* | sort -h | tail
「SELinux is preventing ～」が出た場合
SELinux Enforcing で動作中にアプリがブロックされるケースです。audit.log を見て、必要最小限の許可を追加します。# audit.logから直近のブロックを確認 # ausearch -m AVC -ts recent # audit2allow でポリシーを生成 # ausearch -m AVC -ts recent | audit2allow -M myapp # semodule -i myapp.pp
サービスが起動しない・systemctl statusで failed になる場合
まず journalctl で詳細ログを確認します。# 直近のサービスログを確認 # journalctl -u サービス名 -xe --since "10 minutes ago" # ブート以降の全ログを確認 # journalctl -u サービス名 -b
firewalldで開けたはずのポートに繋がらない場合
permanent オプションで追加した後、reload を忘れている場合があります。# 現在のルール（永続化済）を確認 # firewall-cmd --permanent --list-all # ランタイムに反映 # firewall-cmd --reload # 反映後を確認 # firewall-cmd --list-all
本記事のまとめ
| やりたいこと | コマンド・設計指針 |
|---|---|
| パーティション構成を確認する | df -h |
| マウント状況を確認する | mount | column -t |
| 起動中サービスを一覧する | systemctl list-units --type=service --state=running |
| 不要サービスを停止する | systemctl stop サービス名 && systemctl disable サービス名 |
| SELinuxモードを確認する | sestatus |
| firewallの公開ポートを確認する | firewall-cmd --list-all |
| サービスごとの起動時間を確認する | systemd-analyze blame |
| journalログを永続化する | vi /etc/systemd/journald.conf |
| logrotate設定を確認する | logrotate -d /etc/logrotate.d/nginx |
| 時刻同期を確認する | chronyc sources |
構築時にこの3点を妥協すると、運用に入ってから数倍のコストを払って手当てすることになります。最初の30分の設計検討で、半年後の数十時間の障害対応が消えます。
「Linuxサーバーを自信を持って構築・運用できる」エンジニアになりたいなら
パーティション設計・サービス選定・SELinux・バックアップ・監視を一気通貫で押さえられると、本番運用で事故らないサーバーが組めるようになります。
ネットの断片情報を寄せ集めるだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linux初心者向けインストール基礎知識｜ディストロ選定からデュアルブート・仮想環境まで
- 前のページへ：ps2pdfコマンドでPostScriptをPDFに変換する方法｜LinuxでのPDF変換の実践例
- この記事の属するカテゴリ：Linuxtips・Linuxサーバー構築（Rocky Linux/RHEL9）へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます