アプリケーションが突然ダウンしてしまったらどうなりますか？
開発者の皆さんなら、きっと一度はこのような経験があるはずです。ローカル環境では完璧に動いていたコードが、Linuxサーバーにデプロイして数時間後に原因不明で停止してしまう。メモリリークによるRAMのオーバーフローや、OSアップデート後の自動再起動などが原因かもしれません。
午前2時にウェブサイトがダウンし、クライアントからの電話で起こされるのは、まさに悪夢です。慌ててSSHでサーバーにログインし、手動でスクリプトを再実行するのは単なる応急処置に過ぎません。systemdも非常に強力ですが、今回はより「ソフト」で開発者に優しいツール、Supervisordをご紹介します。これは、アプリが転んでも自力ですぐに立ち上がれるようにしてくれる、強力な助っ人です。
Supervisordとは何か？なぜ開発者に支持されるのか？
簡単に言うと、SupervisordはPythonで書かれたプロセス管理システム（Process Control System）です。あなたが預けたプログラムを常に監視する、忠実な執事のような役割を果たします。もしスクリプトが停止しても、Supervisordは瞬時にそれを再起動します。
なぜ<a href="https://itfromzero.com/ja/linux/systemd-run%e3%82%92%e4%bd%bf%e3%81%84%e3%81%93%e3%81%aa%e3%81%99%ef%bc%9alinux%e3%82%b9%e3%82%af%e3%83%aa%e3%83%97%e3%83%88%e3%81%aecpu%e3%81%a8ram%e3%82%92%e3%80%8c%e5%8d%b3%e5%ba%a7%e3%81%ab.html">systemd</a>で済ませないのでしょうか？ 実際、systemdはシステム全体の低レイヤーな管理に適しています。一方で、Supervisordは以下のような利点から、開発者にとって非常に使い勝手が良いのです。
- 設定が極めて簡単： 数行の
.confファイルを書くだけで完了します。複雑なSystem Unitの構文を学ぶ必要はありません。 - ログでディスクが一杯にならない：
stdout/stderrからログを自動収集し、ログローテーション（log rotation）をサポートします。各ログファイルの最大サイズを50MBなどに制限できます。 - ユーザーへの権限委譲： 開発者がsudoやroot権限をシステム管理者に要求することなく、自分のプロセスを管理できます。
- グループ管理： 1つのコマンドで20〜30個のワーカーを一括で起動・停止できます。
実践経験：50個のクローラースクリプトから学んだ教訓
かつて、ECプロジェクトでデータ収集用のクローラースクリプト群を管理していた際、ログの肥大化に悩まされました。20GBのSSDしかない古いCentOS 7サーバーで、エラーが発生したスクリプトが無秩序にログを書き込み続け、一晩でサーバーがフリーズしてしまったのです。
Supervisordに移行した後、状況は一変しました。各スクリプトの古いログファイルを最大5ファイル、各10MBに制限するように設定しました。その結果、ディスク容量には常に余裕ができ、チームのジュニアメンバーも自信を持って設定を変更し、システムを壊すことなくsupervisorctl updateを実行できるようになりました。チームのワークフローは以前の3〜4倍スムーズになりました。
1分でできるSupervisordのインストール
ほとんどのLinuxディストリビューションでは、公式リポジトリにSupervisordが用意されています。
Ubuntu/Debianの場合
sudo apt update
sudo apt install supervisorCentOS/AlmaLinux/Fedoraの場合
sudo yum install epel-release
sudo yum install supervisorインストールが終わったら、サーバー起動時に自動実行されるように有効化しましょう。
sudo systemctl start supervisord
sudo systemctl enable supervisord核心は設定ファイルにあり
Supervisordは/etc/supervisor/conf.d/にある設定ファイルを読み込みます。すべてを1か所に書くのではなく、管理しやすいようにアプリごとに個別のファイルを作成しましょう。
例えば、/var/www/myapp/app.pyにPythonスクリプトがある場合、設定ファイルmyapp.confは以下のようになります。
[program:myapp]
command=/usr/bin/python3 /var/www/myapp/app.py
directory=/var/www/myapp
user=deployuser
autostart=true
autorestart=true
startsecs=10
stderr_logfile=/var/log/myapp/myapp.err.log
stdout_logfile=/var/log/myapp/myapp.out.log
stdout_logfile_maxbytes=20MB
stdout_logfile_backups=5主要なパラメータの解説：
- autorestart: アプリが停止（終了コードが0以外）した場合、Supervisordが即座に再起動します。
- startsecs=10: アプリが少なくとも10秒間安定して動作した場合にのみ、起動成功とみなされます。これにより、クラッシュを繰り返す無限ループを防ぎます。
- stdout_logfile_maxbytes=20MB: ログファイルが20MBに達すると、自動的に圧縮され、新しいファイルが作成されます。非常に安全です！
supervisorctlによるプロフェッショナルな運用
これは、システムファイルを直接触らずにプロセスを制御するためのCLIツールです。設定ファイルを修正した後は、以下の2つのコマンドでSupervisordに通知するだけです。
sudo supervisorctl reread
sudo supervisorctl updateアプリが稼働中か停止中かを確認するには、以下を使用します：
sudo supervisorctl statusヒント：tailコマンドを使わなくても、以下のコマンドでアプリのリアルタイムログを確認できます：
sudo supervisorctl tail -f myapp大量のキュー処理（Queue）への対応
LaravelやNode.jsを使用していて、同時に10〜20個のワーカーを動かす必要がある場合、設定を複数のファイルにコピーしないでください。numprocsを使用しましょう。
[program:laravel-worker]
command=php /var/www/project/artisan queue:work
process_name=%(program_name)s_%(process_num)02d
numprocs=10
autostart=true
autorestart=true
user=www-data上記の設定により、Supervisordは自動的に10個のワーカープロセスを並列で作成します。1つがハングアップしても、残りの9つは正常に動作し続け、システムがボトルネックになるのを防ぎます。
まとめ
Supervisordを使用することで、サーバーが安定するだけでなく、夜もぐっすり眠れるようになります。深いシステム管理のスキルがなくても、アプリの「突然死」やログの散乱問題を根本的に解決できます。
ぜひ次のプロジェクトで試してみてください。DockerやGoなどの複雑なアプリの設定でエラーが発生した場合は、下のコメント欄でお知らせください。サポートさせていただきます。快適なサーバー管理を！
