ohigesankunの日記

とあるweb系企業の一人インフラエンジニアの戯言

Rundeck改善への道(2)

前回のあらすじ

ohigesankun.hatenablog.com

 

簡単にまとめると。Rundeckを導入したものの、GUIが重すぎて使い物にならなくなってきたのを改善したいということです。

 

どう改善するか

導入時に英語だから面倒という理由で公式ドキュメントをちゃんと読まなかった

反省をふまえて今回はじっくり公式ドキュメントを読みます。

 

そしてパフォーマンスに関する部分を見つけました。

以下の4つの観点でのパフォーマンスについて言及しています。

・データベース

・Node execution※簡単に言うとバッチの実行方式

SSLオフロード

・Resource provider※簡単に言うとバッチを実行するノード情報の取得の方式

 

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.

For high performance and scale requirements, you should not use these embedded databases. Instead, use an external database service like Mysql or Oracle. See the Setting up an RDB Datasource page to learn how to configure the Rundeck datasource to your database of choice.

Also, be sure to locate your external database on a host(s) with sufficient capacity and performance. Don't create a downstream bottleneck!

Node execution

If you are executing commands across many hundreds or thousands of hosts, the bundled SSH node executor may not meet your performance requirements. Each SSH connection uses multiple threads and the encryption/decryption of messages uses CPU cycles and memory. Depending on your environment, you might choose another Node executor like MCollective, Salt or something similar. This essentially delegates remote execution to another tool designed for asynchronous fan out and thus relieving Rundeck of managing remote task execution.

Built in SSH plugins

If you are interested in using the built in SSH plugins, here are some details about how it performs when executing commands across very large numbers of nodes. For these tests, Rundeck was running on an 8 core, 32GB RAM m2.4xlarge AWS EC2 instance.

We chose the rpm -q command which checks against the rpm database to see if a particular package was installed. For 1000 nodes we saw an average execution of 52 seconds. A 4000 node cluster took roughly 3.5 minutes, and 8000 node cluster about 7 minutes.

The main limitation appears to be memory of the JVM instance relative to the number of concurrent requests. We tuned the max memory to be 12GB with a 1000 Concurrent Dispatch Threads to 1GB of Memory. GC appears to behave well during the runs given the "bursty" nature of them.

SSL and HTTPS performance

It is possible to offload SSL connection processing by using an SSL termination proxy. This can be accomplished by setting up Apache httpd or Nginx as a frontend to your Rundeck instances.

Resource provider

Rundeck projects obtain information about nodes via a resource provider. If your resource provider is a long blocking process (due to slow responses from a backend service), it can slow down or even hang up Rundeck. Be sure to make your resource provider work asynchronously. Also, consider using caching when possible.

 *1

 

それぞれ簡単に翻訳すると

・データベース

組み込みのデータベースは使うべからず。

もし一般的なスタンドアローンでインストールした場合、組み込みのデータベースを使うことになります。

バージョン1.5より前はHSQLDB、バージョン1.5以降ではH2 databaseを内蔵しています。

HSQLDBとH2 databseのどちらも低パフォーマンスの壁?障壁を持っています。

小規模もしくは中規模でもこの制限にぶちあたるでしょう。

高パフォーマンとスケールのためには、組み込みのデータベースを使わずにMysqlOracleのような外部のデータベースを使いましょう。

Setting up a RDB Datasourceを見て、どのようにRundeckのdatasourceをあなたの選んだデータベースに設定するか学びましょう。

 

・Node execution

もし何百もしくは何千台ものホストでコマンドを実行していたら、同梱されたSSH node executorでは必要としているパフォーマンスを満たせないでしょう。

各々のSSH接続は複数のスレッドを使って、CPUサイクルとメモリを使う暗号化・復号化を行います。

環境によってはMCollective, Saltのようなnode executorを選択するかもしれません。

非同期で行うようデザインされた他のツールを使うことによって、Rundeckのリモートタスクの実行管理を楽にします。

 

SSL and HTTPS peformance

SSLオフロード出来るproxyを使ってSSL接続をオフロード出来るよ!

Rundeckの前段にApacheやNginxを置けば可能だよ。

 

・Resource provider

Rundeckのプロジェクト(※ジョブなどを管理する単位)はノードの情報をresource providerから入手します。

もしresource providerが長時間プロセスをブロックしたら、Rundeckが遅くなったりハングアップするかもしれません。

(だから)resource providerが非同期で動くようにしよう。

可能であればキャッシュを使うことも考えてみよう。

 

ではどうする?

何百台もノードはないので、4つのうち3つを行う予定でいます。

具体的には

  1. MySQLもしくはMariaDBを使う
  2. Rundeckの前段にNginxを入れる
  3. resource providerを非同期にする

 

最後に

Rundeckの公式ドキュメントの英語は読みやすいと思うので、英語の勉強にもってこい

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.

 *1

 Rundeckの公式ドキュメントに"組み込みのデータベースを使うな!パフォーマンスが悪くなるよ"と丁寧に書いてあります。

 

英語だから面倒なので、ちゃんと読まなかった私のミスです・・・

これから重くなったRundeckを改善していきます!

 

英語でも公式ドキュメントはちゃんと読もう!!