はじめに
この記事はAWSに自作アプリをデプロイするための学習記録です。
筆者の自己紹介
- 異業種、実務未経験からフルスタックエンジニアを目指して転職活動中
- 2024年10月から学習を開始、オンラインスクール卒業を経て、現在も学習を継続中
ポートフォリオアプリ：https://github.com/geek-3340/Fameal_app/tree/main
前回の記事：Linuxコマンド基礎〜インフラ知識０からAWSデプロイ学習記録〜
今回の内容
前回はLinuxコマンドの基礎をまとめましたが、今回はその応用編として
本番運用のサーバーで「動いてるアプリの状態を見る」「サービスを起動・停止する」「ログを追ってエラーを調査する」ために必須となる以下３点を学習します
- プロセスの監視・操作
- systemdによるサービス管理
- ログ・エラー管理
学習記録
プロセスについて
プロセスとは、今まさに実行中のプログラムを指す言葉
例えばLinuxシステム全体のプロセスを確認するコマンドps auxを走らせると、バッグラウンドで動き続けているプロセスに加えて、たった今実行したps aux も出力される
Nginxを起動すると、Nginxを動かすプロセスがメモリ上に複数作られ、停止するとそのプロセスは消える
サーバー上では複数のプロセスが同時に動いており、それぞれにPID（プロセスID） という一意の番号が振られている
プロセスの確認
# 自分が起動したプロセスだけを表示
ps
# システム全体のプロセス一覧（よく使う形）
ps aux
# 上位20件だけ表示
ps aux | head -20
# 特定のプロセスを名前で検索
ps aux | grep nginx
ps auxの出力例
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 167456 11532 ? Ss 09:00 0:01 /sbin/init
www-data 842 0.0 0.5 62120 5432 ? S 09:01 0:00 nginx: worker process
user 1024 0.1 1.2 723456 25600 ? Sl 09:05 0:12 php-fpm: pool www
| 列 | 意味 |
|---|---|
| USER | プロセスを起動したユーザー |
| PID | プロセスID（一意の番号） |
| %CPU | CPU使用率 |
| %MEM | メモリ使用率 |
| STAT | プロセスの状態（S=スリープ、R=実行中など） |
| COMMAND | 実行されているコマンド |
STAT列は雑にいうと「プロセスが今何してるか」で、S（待機中）が多ければ正常、R（実行中）ばかりだと何かに張り付いて重い可能性あり、というような見方もできる
リアルタイム監視
# CPU・メモリ使用率の高いプロセスをリアルタイムで監視（qで終了）
top
# topの強化版（事前に sudo apt install -y htop でhtopのインストールが必要）
htop
topは今動いてるプロセスのうち、リソースを食ってるやつを上から順に表示してくれる
サーバーが重い時などに叩くと有効
htopはtopでの一覧をさらに見やすく表示できるパッケージで、カラー表示、マウス操作・矢印キー操作も可能で、視認性が高い
プロセスを止める
# PIDを指定して終了させる
kill 1234
# それでも終わらない時の強制終了（最終手段）
kill -9 1234
# プロセス名で一括終了
pkill nginx
killは名前的に物騒だが、実態は「プロセスにシグナルを送る」コマンド
デフォルトではSIGTERM（終了して、と丁寧にお願い）を送る
-9をつけるとSIGKILL（問答無用で強制終了）になり、これは終了処理を踏まずに殺すのでファイル破損のリスクあり、最終手段として使う
通常は
kill PIDで終わらない時のみ-9を使うのが鉄則
systemdについて
systemdはLinuxのサービス管理システム
Nginxやデータベース、SSHなど、１つまたは複数のプログラムで構成されたサービス をサービスごとに起動・停止・自動起動設定するための仕組み
ちなみにLinuxのサービスのことをデーモンと呼ぶこともある。厳密に言えばデモーンとはバックグラウンドで常に動き続けてるプロセスのこと
systemd自体も複数のプロセスで動いている
systemctlコマンド
systemdを操作するのがsystemctlコマンド
# サービスの状態確認（よく使う）
sudo systemctl status nginx
# 起動
sudo systemctl start nginx
# 停止
sudo systemctl stop nginx
# 再起動（設定変更後によく使う）
sudo systemctl restart nginx
# 設定だけリロード（プロセスは止めない、可能なサービスのみ）
sudo systemctl reload nginx
# OS起動時に自動で立ち上げる設定
sudo systemctl enable nginx
# 自動起動を無効化
sudo systemctl disable nginx
systemctl status nginxの出力例
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2026-05-19 09:00:12 JST; 2h 15min ago
Docs: man:nginx(8)
Main PID: 842 (nginx)
Tasks: 3 (limit: 4915)
Memory: 5.2M
CPU: 124ms
CGroup: /system.slice/nginx.service
├─842 nginx: master process /usr/sbin/nginx
└─843 nginx: worker process
注目すべきは以下の２行
-
Loaded:enabledなら自動起動ON、disabledならOFF -
Active:active (running)なら起動中、inactive (dead)なら停止中
ちなみに restartとreloadの使い分けは
- restart: 一度プロセスを止めて再起動。ダウンタイムが発生する
- reload: プロセスは生かしたまま設定だけ読み直す。ダウンタイムなし
本番運用ではできるだけreloadを使うのが基本（ただし対応していないサービスもある）
サービス一覧の確認
# 動いているサービスの一覧
systemctl list-units --type=service
# 自動起動設定の一覧
systemctl list-unit-files --type=service
WSL2でsystemctlが効かないとき
WSL2は最近のバージョンでsystemdに対応したが、デフォルトでは無効な場合がある
その場合は/etc/wsl.confに以下を追記し、PowerShellでwsl --shutdownしてから再起動する[boot] systemd=true
ログ・エラー管理
サーバーで問題が起きた時、原因を特定するために最初に見るのがログ
ログを読めないと、エラーが起きても「なんか動かない」で詰むので、ここはサーバー運用の基礎中の基礎
ログの保存場所
Linuxのログは/var/log/配下にまとまっている
ls /var/log/
出力例
auth.log # 認証関連（SSHログイン等）
syslog # システム全体のログ
nginx/ # Nginxのログ（access.log, error.log）
dpkg.log # パッケージインストール履歴
サービスごとにディレクトリやファイルが分かれていることが多い
ログを読む基本コマンド
# 全体を表示（短いログ向け）
cat /var/log/nginx/error.log
# 末尾だけ表示（デフォルト10行）
tail /var/log/nginx/error.log
# 末尾50行
tail -n 50 /var/log/nginx/error.log
# リアルタイムで追従（ログが追記されるのを見続ける、Ctrl+Cで終了）
tail -f /var/log/nginx/access.log
# 先頭だけ表示
head /var/log/nginx/error.log
特にtail -fは神コマンドで、別のターミナルでアプリを動かしながらこちらでログを流し続け、リアルタイムで何が起きてるかを観察することが可能
ログから特定の文字列を探す
# ファイル内から"error"を含む行を抽出
grep "error" /var/log/nginx/error.log
# 大文字小文字を区別しない
grep -i "error" /var/log/nginx/error.log
# マッチした行の前後3行も表示（文脈を見たい時）
grep -C 3 "500" /var/log/nginx/access.log
# 複数ファイルから検索
grep -r "Exception" /var/log/
# tail -fの結果からgrepでフィルタ（合わせ技）
tail -f /var/log/nginx/access.log | grep "500"
grepはパイプと組み合わせると本領発揮するコマンドで、「膨大なログから必要な行だけ抜き出す」のに必須
journalctl：systemd管理のログを見る
systemdで管理されているサービスのログは、/var/log/にファイルとして残らず、ジャーナルという専用の仕組みで管理されている
それを参照するコマンドがjournalctl
# 全ログを表示（古い順、qで終了）
journalctl
# 末尾から逆順で表示
journalctl -r
# 特定のサービスのログだけ
journalctl -u nginx
# 直近の起動以降のログ
journalctl -b
# リアルタイム追従
journalctl -f
# 期間で絞る
journalctl --since "2026-05-19 09:00" --until "2026-05-19 10:00"
journalctl --since "1 hour ago"
# サービス + リアルタイム追従（最強の組み合わせ）
journalctl -u nginx -f
| オプション | 意味 |
|---|---|
-u <サービス名> |
特定のサービスに絞る |
-f |
リアルタイム追従（follow） |
-r |
逆順（reverse、新しい順） |
-b |
現在の起動以降のログ |
--since / --until
|
期間指定 |
tail -f /var/log/...のsystemd版がjournalctl -fという認識でOK
ログのローテーション
ログは放っておくとどんどん溜まってディスクを食い潰すので、Linuxではlogrotateという仕組みで、古いログを自動で圧縮・削除している
# nginxディレクトリを見ると、過去のログが圧縮されている
ls /var/log/nginx/
access.log # 現在のログ
access.log.1 # 1日前のログ
access.log.2.gz # 2日前のログ（gzip圧縮済み）
access.log.3.gz
圧縮済み（.gz）のログを見たい時はzcatやzlessを使う
zcat /var/log/nginx/access.log.2.gz
zless /var/log/nginx/access.log.2.gz
ディスク容量の確認
ログが溜まりすぎてディスクが圧迫された際に使用する、容量確認コマンドも合わせて覚えておく
# ファイルシステム全体の使用量
df -h
# 現在のディレクトリ配下のサイズ
du -sh ./*
# /var/logの中で大きいファイルTOP10を出す
du -ah /var/log | sort -rh | head -10
-hはhuman-readable（GB、MB等の単位で読みやすく表示）の意味で、dfやduでは基本これを付ける
エラー調査のフロー
実際にエラーが起きた時、どういう順序で調査手順の例
例：「Nginxが動かない」
-
サービスの状態確認
wslsudo systemctl status nginxActive: failed等の表示があれば、その下にエラー概要が出る
-
詳細なログ確認
wslsudo journalctl -u nginx -n 50失敗時のスタックトレースを見る
-
Nginx固有のエラーログ確認
wslsudo tail -n 50 /var/log/nginx/error.log設定ファイルのsyntax errorなどはここに出る
-
設定ファイルの構文チェック
wslsudo nginx -tミスがあれば行数付きで教えてくれる
この 「状態 → ログ → 詳細ログ → 構文確認 → 直近の変更」 という流れは他のサービスでも応用が利くエラー調査フロー
おわりに
今回はプロセス・systemd・ログ管理についての解説でした！
Linuxのシステムやサーバー上で何が起こっているのか、少し顕在化できた気がします。
次回はネットワーク基礎について書いていきたいと思います！
ご覧いただきありがとうございました🔥