Rundeckのソースリーディング
- #Java
- #MySQL
- #Performance
- #Troubleshooting
- 2018/12/24
経緯
私は業務でRundeckを使用してジョブの管理をしているのですがRundeckは結構厄介なことが多く、サーバーのCPU使用率が急に上昇したり、メモリを食いつぶされていたり、バックアップが大変だったりと結構困った事があります。
最近もともとJavaで仕事していたこと、Groovyも触ったことがあること、そしてRailsも基本程度は抑えいていることよりRundeckのソースを読んでみました。
それで若干アーキテクチャの部分も調査したためここでまとめておきたいと思います。
ジョブの数多いけどいまだにcronで管理しているあなた！！必見です。
Rundeckってなに
- RundeckはLinuxのcronの様に時刻にプログラムを走らせるように設定できるジョブスケジューラーの一つです。
- Rundeckを使用することでcrontabコマンドで見づらいジョブの管理、管理するジョブが多くなって煩雑化しているジョブ管理を視覚的にも操作的にも管理しやすくすることができる。
Rundeckを使うメリットって
- 先述したようにcrontabで管理するより見える化すること、プロジェクトごとにジョブをまとめておくことが可能、ノードの設定によりジョブを実行する対象の情報を保持することも可能なため複数サーバーに対しての実行も簡単に管理できる。
- SSH接続で使用する鍵の情報もRundeckサーバーで管理することが可能である。
- ジョブが失敗した場合の通知をSlackで通知したりなどのプラグインも揃っているためいちいちShellを書かなくてもできる。
デメリットは？？
- Rundeck自体はオープンソースでソースコードを観ることもできるが、急にCPU使用率高騰やメモリの消費が激しい時などがある。(対策に関しては後述)
- Rundeck専用のサーバーを立てる必要がある。(複数クライアントに対してジョブを実行する場合)
- RundeckのGUIが結構重かったりする
Rundeckのアーキテクチャ
- Rundeckはオープンソースで無料で使用することが可能なため運用コストはサーバーとDB料金だけである。
- Rundeck自体はGrails(JVM言語のGroovyのFW)で書かれている(Grailsの実態はSpringMVCのためSpringMVCがわかっている人はソースを見れば何となく処理を追っていくことができる)
- Rundeckのアプリケーションが参照するDBはデフォルトでJavaで使用される組み込み型のDBであるH2が使用されるようになっている。
- しかしRundeckではジョブの情報をすべてDBで保持している(ログイン情報はサーバーのファイルにて管理しているためDBでは持っていない)ため組み込みのDBを使用するとサーバーへの負荷が高まってしまうためなるべくDBサーバーを別で建ててMySQLやPostgreSQLの様なRDBを使用することが望ましい。
細かい部分のアーキテクチャ
- GrailsFWではjspならぬgspファイルでViewの部分が書かれている。
- TLDとしてgタグが使用できるようになっている(これでformタグやaタグなどが動的に生成することができる)
- 実態はSpringMVCのためDIコンテナを使用しており、アプリケーションの最初の起動の際にDBを作成するようになっている。(applicationContext.xmlで記載)
- grails.xmlを参照するようになっており、ここにDBスキーマが記載されている
- grails-appディレクトリがGrailsアプリケーションの実態である
- DB操作にはJavaではおなじみのHibernateを使用している
- HibernateはORMのツールであるためSQLは直接記載されていない。
- DBコンソールにてEXPLAINコマンドでクエリの妥当性を確認したがクエリ設計には問題はないようにはなっていたはず。
- Controller層からService層の間でDBアクセスをしている記述があるためMySQLならスロークエリとかを出力するように設定してクエリを照らし合わせてみて確認することができる。
Rundeckトラブルシューティング
- DBへのアクセスが遅い
- DBでアクセスの多いカラムにインデックスを貼る
- 同様に一覧画面でのDBアクセスが遅い
- 1プロジェクトに多くのジョブを入れるのではなく分割を行う(ソースを見ると確認できるが全件SELECTを実施しているため多くなれば必然的に遅くなってしまうためなるべくプロジェクト単位を小さくすることで描画速度を改善することができる)
- CPUの使用率が高い
- ジョブのタイムアウト設定をする
- 単にDBの性能が低いケースも考える(メモリが十分でない場合はメモリを食いつぶした後ディスクに書き込みに行くためCPU使用率が高騰してしまう、そのため運用しているRundeckとサーバーの性能が合っているかを検討する(AWSを使用しているならインスタンスクラスを変更するとか))
- ジョブが滞留する
- 上記のCPU使用率の観点からも考え、必要であればコネクションプールの量を増やしたりのチューニングを行う
- MySQLならばスロークエリを出力するように設定をして遅くなっているクエリを確認してみる(私が調査した感じではクエリに問題がある場合は少なくインデックスを貼る程度で改善ができる(そもそもJPAのような記述をしているためクエリに問題があるケースは少ないと思われ))
最後に
Javaできる人はソース読むのが良いと思われる。
Share:
X (Twitter)