systemd 実践リファレンス（AWS/EC2）｜サービスを常駐・自動復旧させるユースケース

未経験〜駆け出しのエンジニア向けに、EC2 上でサービスを「常駐させる・OS再起動後も動かす・落ちても復活させる」を systemd で実現する方法をユースケース中心にまとめました。unitファイルの断片をそのまま使えます。

01なぜ systemd を学ぶのか

EC2 で Linux サーバーを運用すると、必ず「このプロセスを常駐させたい」「落ちたら自動で立ち上げ直したい」「OS再起動後も勝手に動いていてほしい」という場面に出会います。それを担うのが systemd です。

systemd は現在の主要ディストリビューションで標準の init システム（PID 1、最初に立ち上がる管理プロセス）兼サービス管理の仕組みです。Amazon Linux 2023 も systemd を採用しています（Amazon Linux では AL2 から upstart に代わって systemd が使われ、AL2023 でも継続しています）。RHEL系・Ubuntu など他の主要ディストロも同様なので、一度覚えれば環境をまたいで通用します。

• サービス管理：起動・停止・自動起動の設定を systemctl で統一的に扱える
• 自動復旧：プロセスが落ちたら設定に従って再起動できる（Restart=）
• ログ集約：各サービスの出力を journal に集めて journalctl で横断的に読める
• 依存関係と順序：ネットワーク起動後に動かす、といった前後関係を宣言できる

02基本操作 — まずこの7つ

systemd の操作は systemctl に集約されています。サービス名（unit名）は末尾の .service を省略できます。設定変更を伴うコマンドは sudo が必要です。

# 起動・停止・再起動
sudo systemctl start  app.service     # 今すぐ起動
sudo systemctl stop   app.service     # 停止
sudo systemctl restart app.service    # 停止して起動（設定反映）
sudo systemctl reload app.service     # 無停止で設定再読込（対応サービスのみ）

# 自動起動（OS起動時に立ち上がるか）
sudo systemctl enable  app.service    # 自動起動をオン
sudo systemctl disable app.service    # 自動起動をオフ
sudo systemctl enable --now app.service   # 自動起動オン＋今すぐ起動

# 状態確認
systemctl status app.service          # 稼働状態・直近ログ・PIDなど
systemctl is-active  app.service      # active / inactive をスクリプト向けに1語で
systemctl is-enabled app.service      # enabled / disabled

# unitファイルを編集したら忘れずに
sudo systemctl daemon-reload

status は人が読む用、is-active / is-enabled はシェルスクリプトやヘルスチェックで判定に使う用、と覚えると迷いません。

03ログを読む — journalctl

systemd 管理のサービスは、標準出力・標準エラーがすべて journal（journald が管理するログ基盤）に集約されます。journalctl で横断的に読めるのが強みです。

journalctl -u app.service                 # このサービスのログ
journalctl -u app.service -f              # 追尾（tail -f 相当）
journalctl -u app.service --since "10 min ago"   # 直近10分
journalctl -u app.service --since today   # 今日ぶん
journalctl -u app.service -p err          # エラー以上（優先度でフィルタ）
journalctl -u app.service -b              # 今回の起動以降（前回は -b -1）
journalctl -u app.service -n 100 --no-pager   # 末尾100行だけ

トラブル時は「-u で対象を絞り、--since で時間を絞り、-p err で深刻なものだけ拾う」の3点セットが速いです。起動に失敗したときは -b（今回の起動）でブート直後のログを見ると原因が掴めます。

ログをファイルに残したい・CloudWatch Logs に集約して監視やアラートに使いたい場合は、journal だけに頼らず CloudWatch Agent のログ収集設定 を併用します。

04ユースケース：自作アプリをサービス化する

一番よく使う場面です。Python / Node / Go などで書いた常駐プロセスを、unitファイル1枚で systemd 管理下に置きます。ここでは Gunicorn で動く Web アプリを例にします。

# /etc/systemd/system/app.service
[Unit]
Description=My App (Gunicorn)
After=network-online.target
Wants=network-online.target

[Service]
User=appuser
Group=appuser
WorkingDirectory=/opt/app
EnvironmentFile=/etc/app/app.env
ExecStart=/opt/app/venv/bin/gunicorn -b 127.0.0.1:8000 app:app
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

各セクションの意味を押さえておきましょう。

• [Unit]：Description で説明、After / Wants で「ネットワークが上がってから起動」を宣言
• [Service]：ExecStart に起動コマンド（絶対パス）、User で実行ユーザー、WorkingDirectory で作業ディレクトリ、EnvironmentFile で環境変数ファイルを指定
• [Install]：WantedBy=multi-user.target が「通常のサーバー起動時に立ち上げる」の定番

配置したら反映して有効化します。

sudo systemctl daemon-reload
sudo systemctl enable --now app.service
systemctl status app.service

環境変数は unitファイルに直書きせず、EnvironmentFile で別ファイル（例 /etc/app/app.env）に切り出すのがおすすめです。KEY=VALUE を1行ずつ書きます。

# /etc/app/app.env （このファイルのパーミッションは絞る）
APP_ENV=production
DB_HOST=db.internal.example
API_TOKEN=YOUR_TOKEN_HERE

05ユースケース：EC2 起動時に自動で動かす

サービスを enable しておけば OS再起動後も自動起動します。加えて、EC2 インスタンスを新規に立ち上げる段階で unit を仕込みたい場合は、user-data（cloud-init）を使います。Auto Scaling で増えるインスタンスにも同じ設定が行き渡ります。

#!/bin/bash
# EC2 の user-data 例（初回起動時に一度だけ実行される）
dnf install -y python3-pip
# ... アプリの配置・依存インストールなど ...

# unitファイルを書き出して有効化
cat >/etc/systemd/system/app.service <<'UNIT'
[Unit]
Description=My App
After=network-online.target
Wants=network-online.target
[Service]
User=appuser
WorkingDirectory=/opt/app
ExecStart=/opt/app/venv/bin/gunicorn -b 127.0.0.1:8000 app:app
Restart=always
[Install]
WantedBy=multi-user.target
UNIT

systemctl daemon-reload
systemctl enable --now app.service

cloud-init のログ（user-data がうまく動いたか）は /var/log/cloud-init-output.log に出ます。うまく起動しないときはまずここを確認します。

06ユースケース：落ちても自動で復活させる

常駐プロセスは、バグやメモリ不足、外部依存の一時障害などで落ちることがあります。systemd の Restart= で自動復旧を宣言できます。

[Service]
ExecStart=/opt/app/venv/bin/gunicorn -b 127.0.0.1:8000 app:app
Restart=on-failure     # 異常終了（0以外）のときだけ再起動
# Restart=always       # 正常終了でも常に再起動（常駐サービス向け）
RestartSec=5           # 再起動まで5秒待つ（連続クラッシュ時の暴走を防ぐ）
StartLimitIntervalSec=60
StartLimitBurst=5      # 60秒に5回を超えて再起動したら諦めて failed にする

• Restart=on-failure：異常終了のときだけ立ち上げ直す。バッチ的な処理に向く
• Restart=always：正常終了でも必ず立ち上げ直す。落ちてはいけない常駐サービス向け
• RestartSec：即時再起動の連打を避けるためのクールダウン
• StartLimitBurst / StartLimitIntervalSec：短時間に再起動を繰り返す（＝直らない障害）ときに無限ループを止める安全弁

起動の順序・依存関係も宣言できます。DB や別サービスが立ち上がってから起動したいときに使います。

[Unit]
After=network-online.target postgresql.service   # これらの後に起動を試みる
Wants=network-online.target                        # 弱い依存（無くても自分は起動する）
Requires=postgresql.service                        # 強い依存（相手が失敗すると自分も止まる）

07ユースケース：定期実行（systemd timer と cron）

日次バックアップやログローテーションなど「定期的に1回だけ走らせたい」処理は、systemd timer か cron で行います。timer は「実行する処理（.service）」と「いつ実行するか（.timer）」の2ファイルに分けて書きます。

# /etc/systemd/system/app-backup.service
[Unit]
Description=Nightly backup to S3

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/app-backup.timer
[Unit]
Description=Run backup every night at 02:30

[Timer]
OnCalendar=*-*-* 02:30:00     # 毎日 02:30。曜日や月も指定可
Persistent=true              # 停止中に来た分を次回起動時に取り返す

[Install]
WantedBy=timers.target

有効化と確認は次の通りです。timer は .timer の方を enable します。

sudo systemctl daemon-reload
sudo systemctl enable --now app-backup.timer
systemctl list-timers          # 次回実行時刻の一覧
journalctl -u app-backup.service   # 実行結果のログ

cron との使い分けの目安です。

08つまづきポイント

• daemon-reload 忘れ：unitを編集したら sudo systemctl daemon-reload → restart の2手。忘れると古い定義のまま動く
• ExecStart は絶対パス：PATH は期待通りに通っていません。gunicorn ではなく /opt/app/venv/bin/gunicorn と書く
• 環境変数が渡らない：ログイン時の .bashrc は読まれません。EnvironmentFile か Environment= で明示的に渡す
• User の権限不足：指定ユーザーがログや作業ディレクトリに書けず起動失敗しがち。ディレクトリの所有者・パーミッションを合わせる
• 相対パスの罠：WorkingDirectory を指定しないとカレントが想定と違う。ファイル参照は絶対パスか WorkingDirectory 前提で書く
• ログ肥大：journald の上限（SystemMaxUse）を決めておく。ディスク full はサービス全体を巻き込む

09早見表 — 逆引きチートシート

「やりたいこと」から引ける systemctl / journalctl の逆引きです。1画面で確認できるよう主要なものだけ載せます。

unitファイルの主要ディレクティブも早見でまとめます。

関連記事：Linux 実践コマンドリファレンス ／ CloudWatch Agent ログ設定ガイド ／ Python × Lambda 実践ユースケース。基礎は クラウドエンジニアの教科書 で。

EMW は札幌を拠点に、EC2 を含む AWS 運用の自動化・監視を伴走しています。基礎を積みたい方の学びも歓迎です。採用情報・カジュアル面談はこちら。

10よくある質問（FAQ）