はじめに
こんにちは、プロダクツ本部 プロダクツエンジニアグループ ビジネスアプリケーションチームのNTです。
今回は常々なんとかしたいと思っていたcronの管理の問題について、RundeckというOSSを利用してみた際の結果、その感想についてをまとめてみました。同じくcronからの脱却を考えている方に参考になれば幸いです。
[Rundeck公式サイト]Rundeck Runbook Automation
経緯
さて、何故今回cronをやめてRundeckへ移行したかと言うと、主に以下の点で現状の管理に不満が出始めたからになります。
- ジョブを追加/停止する際に該当のサーバーへ入らないと変更できない
- ジョブの実行状況がひと目でわからない
- 複数のサーバーのジョブスケジュールをまとめて操作できない(稀)
簡単にまとめますと、cronでは当然個々のサーバーに紐づいているので、それが足かせとなっている状態ですね。
以前からもっと管理がしやすい方法へ移行したいと思っていた中、調査した中で一番使用実績があると感じたものがRundeckでしたので、こちらへ移行をしようと決意した流れとなります。
構築環境
今回使用した環境は、以下の通りとなります。
- AlmaLinux 9.2（Turquoise Kodkod）
- 2vCPU
- 4GBメモリ
- Rundeck ver.4.15.0 (Community版)
AlmaLinuxもバージョン9での動作確認が進みある程度8との差について把握してきたので、今回はバージョン9.2での構築になります。またスペックについては、Rundeckが推奨するスペック通りにVMの割り当てを行ってみました。
インストール方法については今回割愛しますが、公式サイトに各OS/ディストリビューション毎の手順が載っていますので、そちらを参考に導入しています。
Installing on CentOS or Red Hat Linux distributions
Rundeckに移行した結果
さて、ここからは実際にRundeckへ移行してみた結果について、良かった点といまいちだった点を列挙してみました。これらはあくまでも私個人の意見ですので、参考程度でよろしくお願いします。
良かった点
スケジュール実行のジョブ管理が一元管理できた
これについてはそもそもRundeckを導入しようと思ったきっかけになるので、まあ特に説明は不要ですね。今までは先述した通り個別のサーバーで管理を行っていたので、良くも悪くも管理が分散されておりどのサーバーにどのバッチが存在するかは、資料を残していない限り記憶ベースでの運用になってしまっていました。
Rundeckに移行してからは当然ですが1つの画面で管理できるので、運用という面において非常に楽になりました。操作の慣れは必要ですが直感的なUIを備えているので、1時間も触っていれば理解するのには十分だと思いました。
ジョブの一覧画面、ここでまとめて操作できます
ジョブのログをRundeck上で見れるようになった
今まではジョブの実行ログはサーバーへ入り、直接ログディレクトリへ移動し、ログファイルを開いて確認していました。一番確実な方法ですが、当然サーバーが多いとどのサーバーに存在するジョブなのかを全て把握しておかないと分からなくなるので、運用コストは高い状態でした。
Rundeckでは実行したジョブの標準出力を受け取り保存する機能があるので、Rundeck上の実行ログから直接ログが見れるようになり、運用コストがかなり軽減されました。
標準出力の内容を確認可能
順番が重要なジョブの管理が楽になった
例えばAのジョブを実行した後にBのジョブを実行するといった風に、この順番でないと駄目というパターンが存在すると思います。この場合cronではある程度Aのジョブの実行時間を見積もりBのジョブの実行タイミングを調整していました。ただ、想像に難くないですが、Aのジョブが何らかの理由で長引いてしまいBとバッティングすることもしばしばありました。
RundeckではJenkinsにもあるようなジョブ同士の連携と同じ様な機能があり、ジョブの中でステップと呼ばれている実行の道筋を計画することができます。Aを実行した後にBを実行する、なんてことも簡単にできました。
ちなみに、ステップに登録した全てのジョブを同時に実行もできますし、サーバー毎のパラレル実行なんてことも可能です。
ステップの同時実行はストラテジの設定で
重複実行の制御と失敗時の通知をジョブ側でしなくても良くなった
これは結構嬉しい機能で、重複実行の監視や失敗時の通知は自前での制御でやってきましたが、これらも全てRundeckの標準機能で制御できます。設定も難しくなく、全移行の前提であればプログラムの設計にも大きく影響すると思います。
通知の設定も簡単にできる
イマイチだった点
さて、結構良い事ずくめに見えますが、ここからは実際に運用してみて初めて分かった・実感したイマイチな点になります。
ログが大きいとサーバーのLAが急激に上がる
何よりも一番困った現象がこれでした、1回のジョブ（厳密に言えばステップ）で出力されるログの量が多いと、ログがロード中の表示のまま固まります。それだけで済めばまだマシなんですが、サーバーのLAも急激に上がりCPUのスレッドの限界数まで張り付きます。
その結果何が起こるかと言うと、本来実行されるべきだったジョブの実行がされずにスルーされてしまい、また実行中のジョブの結果が受け取れないのか永遠に実行中になってしまう現象が起こりました。
良い点として挙げた「重複起動の制御」が働いてしまい、そのジョブはKillしないと二度と実行されない事になり、2回ほどこれで大変な思いをしました。
もしかしたらサーバー本体のスペックがギリギリなのかもしれませんが、調べてみるとStackOverflow等のコミュニティサイトでも似たような報告があるので、Rundeck自体の作りの問題かも知れません。
リモート実行の設定がやや複雑
この点に関しては表裏一体で、RundeckではJenkinsと同様にリモートサーバー内のバッチ等を実行する機能が備わっていますが、この設定が少し複雑に感じました。というのも複数のリモートサーバーでジョブを実行する事も可能でかなり汎用性が高い分、単純なリモート実行をするだけの場合は設定項目が多すぎました。
正直これに関しては慣れが大きいと思いますので、デメリットとはならないですが、カスタマイズできる項目であれば環境によって使い分けることが可能なのでより良くなるのではないかと思いました。
Rundeckへの移行は正解なのか？
まだRundeckを構築し運用した期間もせいぜい2ヶ月程度ですが、良かった点とイマイチだった点で述べた通りどんな使い勝手かを知るには十分でした。ジョブ実行管理はどこのシステムでも課題に上がると思いますが、ログの表示の問題さえ回避できれば十分良いOSSだと思います。
cronにはcronなりの良さはあります、OS標準で入ってますしスケジュール実行の記法だけ覚えれば誰でも使えます。何故別の管理方法に移行するかを明確にした上で、自身の要件と照らし合わせればRundeckへの移行は大きな選択肢になり得ます。
今回はログの問題点の解決方法を模索しながら、もう少し運用しつつ様子見をしようと考えています。今回試してみたものはCommunity版となり、運用上必要だと思われる複数の機能が追加されたEnterprise版も存在しますので、本格的な運用を見越して移行する場合にはこちらの検討をしてみても良いと思います。
