こんにちは！「LINUX工房」管理人の「リナックス先生」です。
今日から全8回にわたる新連載「Linuxエンジニアになるための基礎」がスタートします。本連載では、CentOSの後継としてエンタープライズ領域でデファクトスタンダードとなっている「AlmaLinux 9」および次世代の「AlmaLinux 10」をベースに、インフラエンジニアとして現場で通用する実践的なシステム管理スキルを体系的に学んでいきます。
第1回となる今回は、Linuxシステム管理の全体像を俯瞰し、サーバーを安全かつ安定的に稼働させるためのコア技術（リソース監視、ストレージ管理、ログ運用、タスク自動化など）の基礎概念と、プロが現場で実践している深い知見を徹底的に解説します。
先生！いよいよLinuxエンジニアへの第一歩ですね。でも、覚えるコマンドがたくさんあって、どこから手を付ければいいのか迷ってしまいます。まずはWebサーバー（ApacheとかNginx）やデータベースのインストールから始めるのが普通ですか？
コウ君、やる気に満ちているわね！でも、ミドルウェアの構築を急ぐ前に、絶対に押さえておくべきなのが「システム管理の基礎（OSそのものの管理）」なの。
どんなに優れたWebアプリケーションや高速なデータベースを構築しても、土台となるOSのCPUが枯渇したり、メモリがスワップを起こしたり、ディスク容量が100%になってログが書き込めなくなれば、システムは一瞬でダウンしてしまうわ。今日はその「土台を守るための全体像」を、プロの監視目線でしっかり学んでいくわよ！
📚 本連載のカリキュラム（全8回）
目次
1. Linuxシステム管理とは？（インフラエンジニアの真の役割）
「システム管理（System Administration）」とは、一言で言えば「サーバーを24時間365日、安全かつ安定して稼働させ続けるための全活動」を指します。開発者が作成したアプリケーションがユーザーに価値を届けるためには、その実行環境であるOSが極めて健全な状態で維持されていなければなりません。
プロのインフラエンジニアが担うシステム管理の領域は非常に広範ですが、主に以下の5つの柱に分類されます。
- リソース管理： CPU、メモリ、ネットワーク帯域が不足していないかを監視し、ボトルネックを特定・解消する。
- ストレージ管理： データの保存先となる物理ディスク（HDD/SSD/NVMe）を論理的に分割・統合し、無停止での拡張性を持たせる。
- ログ管理： カーネル、デーモン、アプリケーションの挙動を記録し、異常発生時の原因究明（トラブルシューティング）や監査証跡として保存する。
- タスク自動化： 定期的なメンテナンス、証明書更新、バックアップなどを自動化し、トイル（手作業による運用負荷）を排除する。
- セキュリティ管理： 最小権限の原則に基づくパーミッション管理、SELinuxの運用、Firewalldによるアクセス制御を行う。
AlmaLinux 9や今後登場するAlmaLinux 10といったRed Hat Enterprise Linux（RHEL）クローンのモダンなOSでは、これらの管理タスクの多くが「systemd」という巨大な初期化・統合管理システムによって一元的に制御されています。SysVinit時代の古い知識（/etc/init.d/等）から脱却し、systemdネイティブな管理手法を身につけることが、現代のLinuxエンジニアにとって必須の要件となります。
2. システムリソース監視の深淵（CPU負荷とメモリ管理）
システム障害の多くは「突然」起きるわけではありません。数日、数週間前からリソースの枯渇という「予兆」が現れます。インフラエンジニアにとって最も重要なスキルは、「サーバーが重い」というユーザーからの抽象的な申告を、メトリクス（数値）に基づいた客観的な事実へと変換し、真のボトルネックを特定することです。
CPU負荷の確認（Load Averageとtop/vmstatコマンド）
サーバーにログインして最初に叩くべきコマンドは uptime または w コマンドです。ここでシステム全体の過負荷状態を示す「ロードアベレージ（Load Average）」を確認します。
$ uptime 10:00:01 up 10 days, 2:30, 1 user, load average: 4.50, 2.40, 1.35
出力の右端にある3つの数値は、それぞれ「直近1分間」「5分間」「15分間」のロードアベレージを示しています。これは「CPUの実行権を待っている（または実行中の）プロセスと、割り込み不可能なI/O待ち状態にあるプロセスの平均数」を表します。
目安として、「ロードアベレージが論理CPUコア数を恒常的に上回っている場合、システムは処理しきれないタスクを抱え込んでいる（遅延が発生している）」と判断します。例えば4コアのサーバーでロードアベレージが4.50であれば、常に0.5個のタスクが順番待ちをしている状態です。
詳細な内訳を見るには top コマンドを実行します。
$ top -b -n 1 top - 10:05:22 up 10 days, 2:35, 1 user, load average: 4.60, 2.80, 1.55 Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie %Cpu(s): 15.0 us, 5.0 sy, 0.0 ni, 40.0 id, 35.0 wa, 0.0 hi, 0.0 si, 5.0 st
⚠️ topコマンドのCPUステータスのプロ的見方（超重要）
・us (User): ユーザー空間（Nginx、PHP-FPM、MySQLなど）での処理割合。これが高い場合はアプリケーションの処理が重い証拠です。
・sy (System): カーネル空間での処理割合。異常に高い場合は、大量のコンテキストスイッチやシステムコールが発生している可能性があります。
・id (Idle): アイドル（何もしていない）割合。
・wa (I/O Wait): ディスクやネットワークのI/O待ちが発生している割合。プロはここを最も警戒します。waが高い場合、CPUの性能を上げるのではなく、ディスクをNVMeに変更するなどのストレージ改善が必要です。
・st (Steal): クラウド（AWSやVPS）特有の指標。物理ホスト上の他の仮想マシン（ノイジーネイバー）にCPUリソースを奪われている割合を示します。これが高い場合は基盤側の問題であり、サーバーの再起動（別ホストへの移動）を検討します。
メモリ管理の真実（freeコマンドとページキャッシュ）
Linuxのメモリ管理は、Windowsとは根本的に異なる哲学を持っています。free -h や cat /proc/meminfo で確認します。
$ free -h
total used free shared buff/cache available
Mem: 7.6Gi 2.2Gi 500Mi 50Mi 4.9Gi 5.1Gi
Swap: 2.0Gi 0B 2.0Gi
初心者が陥りやすい最大の罠が、「free（空きメモリ）が 500Mi しかない！メモリ不足でサーバーが落ちる！」と勘違いしてしまうことです。
Linuxカーネルは「空いているメモリは無駄である」という思想のもと、一度ディスクから読み込んだファイルデータを可能な限りメモリ上にキャッシュ（buff/cache）として保持し、次回の読み込み速度を劇的に向上させます。そのため、サーバーを長期間稼働させると free の値はゼロに近づいていくのが「正常な挙動」です。
真に見るべき指標は、右端の available（利用可能メモリ） です。これは「アプリケーションが新たにメモリを要求した際、カーネルがページキャッシュを破棄して即座に明け渡すことができるメモリの総量」を示しています。上記の場合、5.1GiBの余裕があるため全く問題ありません。
OOM Killerの恐怖
もし available も枯渇し、Swap（仮想メモリ）も使い果たした場合、Linuxカーネルはシステム全体のクラッシュを防ぐために最終手段に出ます。それが OOM Killer（Out Of Memory Killer） です。カーネルは独自のスコアリング（oom_score）に基づき、「最もメモリを消費しているプロセス（往々にしてMySQLなどの重要デーモン）」を強制的にKill（SIGKILL）してメモリを確保します。
インフラエンジニアは、監視ツール（ZabbixやPrometheus）を用いて available メモリを常時監視し、OOM Killerが発動する前にスケールアップやパラメータチューニングを実施しなければなりません。
3. ストレージ管理の基礎（ディスク・LVM・マウントのアーキテクチャ）
システム管理において、ストレージ容量の枯渇（ディスクフル）は「即システムダウン」に直結する致命的なインシデントです。ログファイルが追記できなくなり、データベースのトランザクションは停止し、最悪の場合はOSの起動すら不可能になります。
ディスク使用率とiノードの監視
まずは df コマンドでファイルシステムごとの容量を確認します。
$ df -hT Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev /dev/mapper/almalinux-root xfs 50G 45G 5.0G 90% / /dev/sda1 xfs 1014M 250M 765M 25% /boot
AlmaLinux 9/10のデフォルトファイルシステムは、エンタープライズ向けの堅牢性とスケーラビリティに優れた XFS が採用されています。XFSはオンラインでのファイルシステム拡張（xfs_growfs）をサポートしており、ダウンタイムなしでの容量追加に優れています。
また、ディスクの「容量（バイト数）」だけでなく、「ファイル数（iノード）」の枯渇にも注意が必要です。大量の小さなセッションファイルや一時ファイルが生成されると、容量が余っていても「No space left on device」エラーが発生します。これは df -i コマンドで監視します。
LVM（Logical Volume Manager）の概念と優位性
Linuxのストレージ管理でプロが必ず用いる技術が LVM（論理ボリュームマネージャー） です。物理的なハードディスクをそのままパーティション（/dev/sdb1 など）としてマウントする旧来の手法は、容量拡張の際に「OSの停止とデータの移行」を伴うため、現代の24時間稼働システムには適しません。
直接ディスクをフォーマットして使うのと何が違うんですか？LVMって構造が複雑で難しそうです……。
LVMの最大のメリットは「物理ディスクの制約からの解放」と「無停止での容量拡張」よ。
例えば、データベース用のディレクトリ（/var/lib/mysql）の容量が足りなくなったとき、通常のパーティションだと手詰まりになるわ。でもLVMなら、新しい物理ディスクをサーバーに挿入して「ストレージプール」に追加し、そこから必要な分だけ論理ボリュームを広げるコマンドを叩くだけで、システムを動かしたまま瞬時に容量を増やせるの！
LVMは以下の3層アーキテクチャで構成されています。
 | ＜7/19 ~26限定 全品15倍 要エントリー＞試して理解Linuxのしくみ 実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識／武内覚 価格:3520円 |
- PV（Physical Volume / 物理ボリューム）: 物理的なディスクやパーティション（/dev/sdb など）をLVM用に初期化したもの。
- VG（Volume Group / ボリュームグループ）: 複数のPVを束ねて構築した「巨大な仮想ストレージプール」。
- LV（Logical Volume / 論理ボリューム）: VGのプールから、必要なサイズだけを切り出した仮想的なパーティション。このLVに対してXFSやext4などのファイルシステムを作成し、マウントします。
LVMはスナップショット機能も備えており、バックアップ取得時にファイルシステムの一貫性を保つ（静止点を設ける）ためにも極めて有用です。
マウントと /etc/fstab のベストプラクティス
作成したファイルシステムを利用するには、ディレクトリのツリー構造（ルート / 以下の任意の場所）に接ぎ木する「マウント（Mount）」作業が必要です。
# 手動マウントの例 $ sudo mount /dev/mapper/vg01-lv_data /mnt/data
しかし、手動マウントはOSを再起動すると解除されてしまいます。永続化するには /etc/fstab ファイルに設定を記述します。
# /etc/fstab の記述例 (UUIDでの指定を推奨) UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890 /mnt/data xfs defaults,nofail,noatime 0 0
現場でのベストプラクティスとして、デバイス名（/dev/sdb1等）ではなく UUID を使用することが鉄則です。デバイス名はディスクの認識順序によって変わるリスクがあるためです。
また、外付けディスクやネットワークストレージ（iSCSI/NFS）をマウントする際は、必ず nofail オプションを付与します。これがないと、該当ディスクが故障した際にOSのブートシーケンスが停止し、SSH接続すらできなくなる（リカバリーモード行き）という大惨事になります。noatime はファイルのアクセス日時更新をスキップし、ディスクI/O負荷を軽減するプロのチューニングテクニックです。
4. ログ管理とトラブルシューティングの初動（systemd/journald）
システムに障害が発生した際、エンジニアにとって唯一の真実となるのが「ログ」です。かつてLinuxのログは /var/log/messages や /var/log/secure などのプレーンテキストファイルに分散して出力されていましたが、systemdを採用するAlmaLinux 9/10では、systemd-journald によるバイナリ形式の中央集権的なログ管理が主流となっています。
journalctlをプロレベルで使いこなす
journalctl コマンドを制する者は、トラブルシューティングを制します。膨大なログの中から、必要な情報だけを瞬時にフィルタリングする技術が求められます。
# 1. 全体のログを末尾からリアルタイムで監視する（tail -f 相当） $ sudo journalctl -f # 2. 特定のサービス（例: Nginx）のログのみを抽出する $ sudo journalctl -u nginx.service # 3. 「今日の午前9時から10時」の間に発生したログを見る $ sudo journalctl --since "09:00" --until "10:00" # 4. カーネルメッセージ（dmesg相当）のみを表示 $ sudo journalctl -k # 5. エラーレベル（優先度 err = 3 以上）の深刻なログのみを抽出する $ sudo journalctl -p 3 -xb
journaldのログはデフォルトではメモリ上（/run/log/journal）に保存され、再起動すると消えてしまう設定になっている場合があります。永続化させるためには、/etc/systemd/journald.conf で Storage=persistent に設定し、/var/log/journal/ ディレクトリを作成する必要があります。
⚠️ logrotate（ログローテーション）の重要性
ログは放置すると無限に肥大化し、ディスク容量を食いつぶします。これを防ぐのが logrotate デーモンです。定期的に古いログを圧縮し（例: access.log.1.gz）、一定期間を過ぎたものを自動で削除する仕組みがOSには標準で備わっています。自作のWebアプリケーションやバッチ処理を稼働させる際も、必ず /etc/logrotate.d/ に固有のローテーション設定を配置するクセをつけましょう。ログ起因のディスクフルは、初心者が最も起こしやすい障害第1位です。
5. タスクの自動化（cronからsystemd timerへのパラダイムシフト）
インフラエンジニアの仕事の半分は「トイル（手作業）の撲滅」、すなわち自動化です。夜間のデータベースダンプ、古いファイルのクリーンアップ、Let’s Encrypt証明書の自動更新など、定期的なタスクはすべてOSのスケジューラに委ねます。
伝統的な cron とその限界
長年親しまれてきた自動化ツールが cron です。分・時・日・月・曜日の5つのフィールドで直感的に実行タイミングを指定できます。
# crontab -e の記述例: 毎日午前3時30分にバックアップスクリプトを実行 30 3 * * * /usr/local/bin/backup_mysql.sh > /dev/null 2>&1
しかし、cronにはエンタープライズ運用においていくつかの弱点があります。
・スクリプトが失敗した際の検知やログの追跡が難しい。
・サーバーがダウンしていた時間帯に設定されていたジョブは、起動後にスキップされてしまう。
・タスクごとのCPUやメモリのリソース制限（Cgroups）がかけられない。
次世代の標準「systemd timer」
AlmaLinux 9/10などの最新環境では、これらの課題を解決する systemd timer を利用することがベストプラクティスとされています。タスクの定義（.service）とスケジュールの定義（.timer）を分離して管理します。
# /etc/systemd/system/backup.timer の例 [Unit] Description=Daily Backup Timer [Timer] # 毎日午前3時30分に実行 OnCalendar=*-*-* 03:30:00 # サーバーダウン等で実行できなかった場合、次回起動時に即座に実行する Persistent=true [Install] WantedBy=timers.target
systemd timerを使用することで、実行ログはすべて journalctl -u backup.service で一元管理でき、Persistent=true により実行漏れを防ぐことができます。さらに、バックアップ処理が重すぎてWebサービスに影響を与えないよう、serviceユニット側で CPUQuota=50% のような厳密なリソース制限をかけることも可能です。
6. 確実なデータ保護のためのバックアップ戦略（3-2-1ルールとWORM）
最後に、システム管理において最も重要であり、エンジニアの最後の砦となる「バックアップ」について触れます。どんなに完璧にリソースを監視し、LVMでRAIDを組み、クラスタリングで冗長化を行っていても、ランサムウェア攻撃や、ヒューマンエラー（rm -rf / などの誤操作や、間違ったSQLのUPDATE文）からデータを守ることはできません。冗長化は可用性のためのものであり、バックアップの代わりにはならないのです。
tarとrsyncによる基本バックアップ
Linuxにおけるファイルベースのバックアップの基本は、ファイルをまとめて圧縮する tar コマンドと、差分のみをネットワーク越しに高速転送する rsync コマンドの組み合わせです。
# リモートのバックアップサーバーへ差分同期を行う（プロのオプション例） $ rsync -avz --delete --bwlimit=10000 /var/www/html/ backup-user@192.168.1.100:/remote_backup/
プロは本番環境のネットワーク帯域を食いつぶさないよう --bwlimit（帯域制限）をかけたり、無駄なキャッシュファイルを除外する --exclude を駆使して転送を最適化します。
エンタープライズで必須の「3-2-1ルール」
バックアップを設計する際、世界中のエンジニアが遵守している鉄則が「3-2-1ルール」です。
1. データを 3つ 持つ（本番データ1 ＋ バックアップデータ2）
2. 2種類 の異なるメディアに保存する（ローカルディスク ＋ オブジェクトストレージ等）
3. そのうち 1つ は遠隔地（オフサイト）に保管する（地震などの物理的災害対策）
さらに近年では、ランサムウェアによってバックアップデータ自体が暗号化される被害を防ぐため、一度書き込んだら一定期間削除・変更が不可能な WORM（Write Once Read Many） アーキテクチャをクラウドストレージ（Amazon S3のオブジェクトロック機能など）と組み合わせて実装することが、モダンなインフラ設計のスタンダードとなっています。
総まとめ：システム管理は「プロアクティブな予防」がすべて
第1回の解説、お疲れ様でした。
今回は、AlmaLinux 9/10をベースにしたLinuxシステム管理の全体像と、各コンポーネントの深いアーキテクチャについて解説しました。
インフラエンジニアの真価は、障害が起きてから慌てて対処する「火消し（リアクティブ）」の速さではありません。メトリクスの変化から未来のリソース枯渇を予測し、自動化によって人為的ミスを排除し、強固なバックアップによって最悪の事態を想定する「予防（プロアクティブ）」の仕組みを構築できるかどうかにかかっています。
次回、【第2回】ストレージ管理の極意：パーティション、LVM、ファイルシステム構築 では、本日概要を触れた「LVM（論理ボリュームマネージャー）」について、実際にサーバーに仮想ディスクを追加し、PV/VG/LVを作成し、ダウンタイムなしでファイルシステムを拡張する一連のコマンドオペレーションを実践的に掘り下げていきます。
お楽しみに！LINUX工房の「リナックス先生」でした。
▼ 【Linux環境を実際に構築して学ぼう】 ▼
AlmaLinux 9/10がすぐに使える
「高コスパおすすめVPS」
インフラエンジニアへの道
「ITエンジニア専門転職」
コメント