Rundeck改善への道(1)
Rundeck導入の経緯
Rundeck導入以前はcronでバッチを管理していました。
あるあるですが、cronだと色々不便でした。
- サーバに入らないとどの時間にどのバッチが実行されるか分からない
- 一元管理しづらい※今考えるとgitで管理すれば解決できた
- 重複実行されると困るバッチの制御が面倒
- ログの管理が面倒
- 通知の実装が面倒
これらを解決するためにRundeckを導入しました。
導入した結果
- サーバに入らないとどの時間にどのバッチが定義されてるか分からない
⇒GUIから簡単に確認できる
- 一元管理しづらい※今考えるとgitで管理すれば解決できた
⇒Rundeckサーバ上で一元管理
- 重複実行されると困るバッチの制御が面倒
⇒GUIから簡単設定
- ログの管理が面倒
⇒標準出力に出しておけばOK
- 通知の実装が面倒
⇒メールはもちろん、webhookがあるのでslackなどにも通知が可能
ただし、いいことばかりではありません。
使い続けるうちにGUIがとても重くなり使いものにならなくなりました・・・
原因は導入時の設定にありました。
Rundeckはデフォルトでバッチの実行履歴などをH2 Databaseに保存します。
※バッチ実行時のログはデフォルトでファイルに吐かれます
実行履歴が溜まってくるとH2 Databseがとても遅くなってきます。
Performance
Increasing performance is generally done using a "divide and conquer" strategy wherein various non job related processing is offloaded from the Rundeck webapp.
Database
Don't use the embedded database. If you install the vanilla standalone rundeck configuration, it will use an embedded database. Rundeck versions prior to 1.5, use the Hypersonic database (HSQLDB). Versions 1.5 and beyond include the H2 database. Either HSQLDB or H2 has a low performance wall. Rundeck users will hit this limitation at a small-medium level of scale.
Rundeckの公式ドキュメントに"組み込みのデータベースを使うな！パフォーマンスが悪くなるよ"と丁寧に書いてあります。
英語だから面倒なので、ちゃんと読まなかった私のミスです・・・
これから重くなったRundeckを改善していきます！
