みなさんこんにちは。レッドハットの杉村です。Ansible のテクニカルサポートをしています。
昨日8月24日に Red Hat Ansible Tower Performance Improvements between 3.6 and 3.7 の記事が公開されました。Ryan Petrello, Imaanpreet Kaur, Charan Raj Musali によって書かれたものです。早速許諾を得まして、翻訳してこちらで紹介します。
お客様から「ジョブイベントが Tower UI に出てこない」と指摘をいただき、ジョブのステータスの更新を見ようとしてもぜんぜん出てこないという重大な問題が発生していました。Red Hat Ansible Tower がよりリアルタイムにジョブのステータスの更新状況を提供できるようにするために行った、パフォーマンスの改善について説明します。
パフォーマンスの改善
3.6と3.7リリースの間で、大幅なパフォーマンスの向上を行うことで、イベント処理、ジョブの実行性能、そしてユーザーインターフェイスが改善しました。この作業は、お客様と Red Hat Scale and Performance チームの共同で行われました。
- 標準出力の取り込み速度を大幅にスピードアップするために、イベント処理に顕著なパフォーマンスの向上を追加しました。
- Ansible Towerを更新して、クラスター化とイベント配信でRabbitMQに依存しないようにしました。 イベント処理の新しい依存関係としてRedisが追加されました。
- 同時に多くのユーザーがAnsible Towerにログインしているときの、さまざまなジョブビューのユーザーインターフェイスのパフォーマンスが向上しました。
- ジョブの依存関係やスケジューリングアルゴリズムの最適化により、ジョブ実行のパフォーマンスが向上し、プレイブックと並列ジョブを実行するための標準出力の書き込み速度が向上しました。
- Ansible Towerの速度低下を防ぐために、非常に多数のホストを持つインベントリのイベント処理を修正しました。
- 実行中のジョブが改善され、関連するインベントリの更新がブロックされなくなりました。
構築およびパフォーマンステスト
ジョブの実行時間とジョブ結果の処理時間の間の遅延、および実行中のパフォーマンスベンチマークをよりよく把握するために、平均的な本番環境と同等のHAクラスタで Ansible Tower を構成しました。
構成
| Node-A | Node-B | |
|---|---|---|
| Tower Version | Red Hat Ansible Tower v3.6.2 | Red Hat Ansible Tower v3.7.1 |
| CPU | X5650 @ 2.67GHz 24 Core | X5650 @ 2.67GHz 24 Core |
| RAM | 98GB RAM | 98GB RAM |
- VM イメージはそれぞれディスクを分離しています。
適切なベンチマークを行うには、バージョン間で行われたパフォーマンスの向上を比較するのに十分な数のジョブイベントが必要でした。 この目標を達成するために、100個の仮のホスト (ansible_connection: local を使用) を含むインベントリファイルと100個のイベント/ホストを生成するジョブを作成して、10万個のジョブイベントを生成しました。 特定のインベントリーで10個のジョブを同時に起動すると、10万件のイベントが発生し、これは私たちのニーズには十分でした。
パフォーマンスの結果
ジョブ実行時間
10個並列での平均実行時間の結果です。
Ansible Towerが10個の同時ジョブを完了する期間は、v3.6.2とv3.7.1で同じですが、パフォーマンスの急激な低下は見られませんでした。
ジョブイベントの処理時間
10個並列で実行したジョブイベントの平均処理時間の結果です。
Ansible Towerがすべてのジョブ結果を処理するのにかかる時間は大幅に改善されました。Ansible Tower v3.7.1でのイベント処理はv3.6.2と比較して82.56％高速化されました。 これは大きな改善であり、ユーザーエクスペリエンスが大幅に改善されます。
ジョブイベント間の必要時間
10個並列で実行したジョブイベント間に必要な時間の平均です。
Ansible Tower v3.7.1では、ジョブの完了後にすべてのジョブ結果を処理するために必要な追加の時間が、v3.6.2と比較して95.77％削減されました。 繰り返しになりますが、パフォーマンスの大幅な改善がここにはっきりと示され、ジョブイベントに関するユーザーエクスペリエンスがよりスムーズになります。
まとめ
Ansible Tower v3.7.1から利用可能になったパフォーマンスの改善により、Ansible Towerはすべてのジョブを短い時間で処理できるようになりました。これにより、ユーザーはAnsible Towerダッシュボードでジョブステータスの更新をよりリアルタイムですばやく確認でき、よりスムーズで全体的に満足のいくユーザーエクスペリエンスを実現できます。
Ansible Towerの詳細情報に興味がある場合、Ansible Towerのドキュメントをご確認ください。 最新バージョンをダウンロードしてインストールするには、Ansible Tower インストールおよびリファレンスガイドにアクセスしてください。最近のAnsible Towerリリースのリリースノートを表示するには、リリースノート3.7.xおよびリリースノート3.6.xにアクセスしてください。 Red Hat Ansible Automation Platformの詳細に興味がある場合は、電子書籍をチェックしてください。
docs.ansible.com docs.ansible.com docs.ansible.com www.ansible.com
著者について
Ryan Petrelloは、Red Hat Ansible Towerのプリンシパルソフトウェアエンジニアで、Towerのバックエンドサービスのエンジニアリングを指揮しています。 Imaanpreet Kaurは、Red Hat Scale and Performance チームのソフトウェアエンジニアです。 彼女は、Red Hat SatelliteとAnsible Towerでパフォーマンスレビュー/チェックを行います。 Charan Raj Musaliは、Red Hat Scale and Performance チームのアソシエイトソフトウェアエンジニアです。 彼は、Ansible Towerのパフォーマンスレビュー/チェックを行います。
翻訳者より
3.5 以前のバージョンの Ansible Tower ではデータベースに格納されたジョブイベントの数が膨大のとき、ダッシュボードの表示に時間がかかる、ジョブが実行できないなどといったパフォーマンスの問題を抱えていました。「管理ジョブ」の機能で古いデータを定期的に削除していただき、データベースの負担を軽減させるしか方法がなかったのです。
3.6 からは PostgreSQL を 10 にアップデートし、さらに INDEX の有効活用を図ることでジョブの標準出力をより高速に扱えるようになりました。他にはプロジェクトのロックも排除し、並列実行であってもリソースを有効に活用できるようになりました。
3.7 ではさらに、この記事で見てきたように RabbitMQ を置き換えるなどのアーキテクチャからの見直しがされ、アプリケーション側もレコード数の増加に伴うデータベース側の負荷を抑えるように改善されました。
もし古いバージョンをお使いの方でパフォーマンスの問題にお困りでしたら、格段に高速化した 3.7 (現時点での最新版は 3.7.2) への更新を是非ともご検討ください。
Ansible Towerの評価ライセンスリクエストはこちらからご利用いただけます。
Happy Automation!
