自動再起動で解決できない障害がある――usacloud と cron によるサービス自動復旧の設定と、その限界

こんにちは、ネットアシスト運用チームのhaokiです。

さくらのクラウドのCLIツール「usacloud」と cron を組み合わせると、夜間や休日など担当者が不在の時間帯でも、サービスの死活監視と自動復旧を無人で動かすことができます。

ただし、自動復旧が有効に機能するのは障害の原因が「プロセスの一時的な異常」に限られます。外形監視からは見えない問題――継続的な攻撃や設定の誤り――に対しては、サービスを再起動しても根本的な解決にはなりません。本記事では実際の構築手順と動作確認をもとに、自動化の有効範囲とその限界を整理します。

構成の概要

今回は以下の2台構成で検証します。

• 管理サーバ（haoki）：usacloud と cron を動かす起点。監視スクリプトをここで実行する
• 監視対象サーバ（targetserver）：Apache（httpd）を動かすサーバ。死活監視の対象

監視対象サーバの準備

SSHキーの作成とサーバの起動

まず管理サーバ側でSSHキーペアを生成し、usacloud に公開鍵を登録します。

[root@haoki ~]# ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub

[root@haoki ~]# usacloud ssh-key create \
  --name "mykey" \
  --public-key "~/.ssh/id_ed25519.pub" \
  --assumeyes
+--------------+-------+-------------+-------------------------------------------------+
|      ID      | Name  | Description |                   Fingerprint                   |
+--------------+-------+-------------+-------------------------------------------------+
| 1xx000xx0000 | mykey | -           | xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx |
+--------------+-------+-------------+-------------------------------------------------+

登録した SSH キー ID を指定してサーバを作成します。OS は AlmaLinux 10、スペックは 1CPU／1GB メモリです。

[root@haoki ~]# usacloud server create \
  --name "targetserver" \
  --cpu 1 --memory 1 \
  --disk-os-type "almalinux" \
  --disk-size 20 \
  --disk-edit-password "xxxxxxxxxxxxxxxx" \
  --disk-edit-ssh-key-ids 1xx000xx0000 \
  --network-interface-upstream shared \
  --zone "is1a" \
  --assumeyes

起動後、usacloud 経由で SSH 接続できることを確認します。

[root@haoki ~]# usacloud server ssh targetserver
connecting server...
        command: ssh root@xxx.xxx.xxx.xxx
[root@localhost ~]#

Apache のインストールと起動

監視対象サーバに Apache をインストールし、自動起動を有効にします。

[root@localhost ~]# dnf install -y httpd
[root@localhost ~]# systemctl enable --now httpd
Created symlink '/etc/systemd/system/multi-user.target.wants/httpd.service' → '/usr/lib/systemd/system/httpd.service'.

外部からの HTTP アクセスを通すため、ファイアウォールで 80 番ポートを開放します。

[root@haoki ~]# ssh root@xxx.xxx.xxx.xxx \
  "firewall-cmd --permanent --add-service=http && firewall-cmd --reload"
success
success

自動復旧スクリプトの作成と cron 設定

管理サーバ（haoki）側に、死活確認と SSH 経由のサービス復旧を行うスクリプトを作成します。

[root@haoki ~]# cat << 'EOF' > /root/auto-recover.sh
#!/bin/bash
TARGET_IP="xxx.xxx.xxx.xxx"

# HTTP 200チェック
STATUS=$(curl -o /dev/null -s -w "%{http_code}" --connect-timeout 5 http://${TARGET_IP}/)

if [ "$STATUS" -ne 200 ]; then
    echo "$(date): [Alert] Status $STATUS. Attempting recovery..." >> /root/auto-recover.log
    # SSH経由でサービスを起動
    ssh root@${TARGET_IP} "systemctl start httpd" \
      && echo "$(date): Recovery command sent successfully." >> /root/auto-recover.log \
      || echo "$(date): Failed to send recovery command." >> /root/auto-recover.log
else
    echo "$(date): [OK] Apache is running fine." >> /root/auto-recover.log
fi
EOF

chmod +x /root/auto-recover.sh

1分ごとに実行するよう cron に登録します。crontab -e で以下の1行を追加します。

* * * * * /root/auto-recover.sh

設定を確認します。

[root@haoki ~]# crontab -l
* * * * * /root/auto-recover.sh

動作確認

監視対象サーバで手動で httpd を停止し、スクリプトが自動で復旧させることを確認します。

[root@localhost ~]# systemctl stop httpd

管理サーバ側でログを監視します。

[root@haoki ~]# tail -f /root/auto-recover.log
Mon Apr 13 11:54:01 AM JST 2026: [Alert] Status 000. Attempting recovery...
Mon Apr 13 11:54:02 AM JST 2026: Recovery command sent successfully.
Mon Apr 13 11:55:01 AM JST 2026: [OK] Apache is running fine.

httpd 停止から約1分以内にスクリプトが検知し、SSH 経由で systemctl start httpd を実行、次の確認サイクルで HTTP 200 が返り「Running fine」と記録されました。

自動復旧が有効なケースと、有効でないケース

自動復旧は、障害の原因が「プロセスの一時的な異常」である場合には有効に機能します。しかし、原因がそれ以外にある場合、再起動は根本解決にならないどころか、障害の発見・対処を遅らせる可能性があります。

自動化でカバーできない領域への対応

サービス自動復旧は、プロセス系の軽障害に対する初動対応として有効です。しかしその範囲を超える障害に対応するには、サーバ内部のログやトラフィックを継続的に監視・分析し、原因を特定したうえで適切な対処を行う体制が必要になります。

• 攻撃トラフィックの検知・遮断（WAF、レートリミット設定など）
• 設定変更の差分管理と、障害時の切り戻し手順の整備
• ディスク・メモリ使用率などリソース系指標の内部監視
• SSL 証明書の有効期限監視と自動更新の仕組み
• アプリケーションログの収集・分析

こうした対応を夜間・休日も含めて継続的に行うには、運用専門チームによるマネージドサービス（MSP）の活用が現実的な選択肢になります。

まとめ

• usacloud と cron を組み合わせることで、不在時のサービス死活監視と自動復旧を実装できる
• プロセスのクラッシュや一時的なコネクション枯渇には有効に機能する
• 外形監視は「HTTP が返るかどうか」しか判断できず、障害の原因は区別できない
• 攻撃・設定誤り・ネットワーク設定の問題など、原因がプロセス外にある障害には自動復旧は無効
• 自動化でカバーできない領域には、内部監視と専門チームによる対処体制（MSP）が必要

さくらのクラウドを使ったサーバの監視・運用体制の整備についてお悩みの方は、ぜひネットアシストにご相談ください。

それではまた！