 本記事は TechHarmony Advent Calendar 2024 12/16付の記事です。 |
こんにちは。SCSKの上田です。
今回は、2024年6月にリリースされたZabbix7.0の性能限界を調査してみました。本内容は、2024年11月に開催されたZabbix Conference Japan 2024において、弊社が発表した内容になります。
当日の発表を見ていただいた方も、見逃してしまった方も、是非ご覧ください。
Zabbix Conferenceとは？
Zabbix Conferenceとは、オープンソースの統合監視ソフトウェアであるZabbixのユーザー、開発者、パートナーが集まる公式イベントです。 最新のZabbixの機能や活用事例、ベストプラクティスなどを共有し、参加者同士のネットワーキングを促進することを目的としています。
Zabbix開発チームやパートナーによる講演、ユーザーによる事例発表、技術相談会など、Zabbixに関する様々な情報が集まるイベントとなっています。
毎年SCSKもパートナーとして出展しており、今年は筆者の上田が登壇させていただきました。本記事では、登壇時に発表した内容について説明いたします。
タイトルは、「～限界シリーズ～ 第2弾 Zabbix7.0のパフォーマンス限界調査編」です。当日の資料は以下に掲載されておりますので、本記事とあわせてご確認ください。
背景
タイトルにある“限界シリーズ”とは、2年前に開催されたZabbix Conference Japan 2022で弊社が発表したシリーズです。
我々ITエンジニアは、常に「お客様の要件に対して最適なアーキテクチャを設計する」ということを生業にしています。
しかし、時には「どこまで行けるのか？」「限界はどこなのか？」という意味のないことを追求したくなるのが、エンジニアの性というものです。
そんな考えから始まった、“限界シリーズ”。2年前は、当時最新バージョンで合ったZabbix6.0を使って、「1台のZabbixサーバで何台まで遅延なく監視できるのか」ということを検証しました。
※当時の資料は以下に掲載されておりますので、是非ご覧ください。
さて、今年の6月にZabbix7.0がリリースされ、以下のような新機能が追加されました。
Zabbix7.0の新機能
この機能は、ポーリング処理を行うPoller(ポーラー)プロセスが同期処理から非同期処理に変更になることで、監視処理の速度が向上しました。
ポーリング処理とは、Zabbixサーバが定期的に監視対象機器の状況を確認する（監視データを取得する）処理のことです。
要するに、監視データの収集速度が向上したということになります。
本機能の詳細については、以下の記事でも紹介しておりますので、そちらもご覧ください。
Zabbix 7.0 新機能検証 (ポーリングの高速化編) – TechHarmony
この機能が追加されたことで、Zabbix6.0に比べて性能が急激に向上したと思われます。
そこで、Zabbixの「新たなる限界」を探るべく、「Zabbix7.0の性能限界調査」を行いました。
検証の概要
検証の概要を説明します。
検証の方針
- Zabbix6.0と7.0の性能を検証し、比較
- 物理マシンはZabbix6.0アプライアンス（ZS-7600）を使用（7.0での検証時はバージョンアップを実施）
- 性能の限界は、「以下の条件のいずれかを満たすこと」と定義
- Pollerプロセスのビジー率100%
- CPU使用率50%以上
- メモリ使用率90%以上
- キューが溜まり続けている
CPU使用率を低く見積もっているのは、Web管理画面にリソースを使うため実質50%が限界だと考えたからです。
検証環境
検証環境は、以下のように用意しました。
- 複数台の仮想基盤サーバに対し、複数の仮想サーバを立てる
- 仮想サーバにzabbix-agentをインストール、それらに対して監視を行い性能検証
- まず6.0で検証を行い、限界に達したら続いて7.0で検証
検証環境
なお、立てられる仮想サーバーの数には限りがあるため、今回は、1つの仮想サーバを複数のホストとして登録する形で検証を行っています。
設定パラメータ
以下のようにパラメータを設定しています。
| 対象 | 項目 | デフォルト値 | 設定値 |
| Zabbix Server6.0 | StartPollers | 3 | 1000 |
| Timeout | 3 | 20 | |
| Zabbix Server7.0 | StartAgentPollers | 1 | 30 |
| Timeout | 3 | 20 | |
| Zabbix Agent | StartAgents | 3 | 100 |
| UserParameter | ー | sleep.3,sleep 3 && echo “finish“ | |
| Timeout | 3 | 20 |
いくつか、設定の意図を解説します。
| 項目 | 意図 |
| StartPollers | Pollerプロセスの数を変更可能（6.0）。今回は最大値の1000で設定 |
| StartAgentPollers | Pollerプロセスの数を変更可能（7.0）。最大値は1000ですが、1プロセスのメモリ使用量が大きくチューニングして30に設定 |
| StartAgents | AgentがPollerプロセスを待ち受けるインスタンスの数を変更可能。今回の検証環境では1台の監視対象サーバを複数のホストとして登録して監視するため、Agent側でも効率的にポーラー処理に対応できるよう、最大値の100で設定 |
| UserParameter | 3秒待機してfinishの文字列を返すアイテムを定義。 今回の検証環境では、サーバーとエージェントが同じフロアの同じNW上にあり、遅延が全く発生しませんでした。実監視環境のNW遅延やサーバー負荷を考慮して、3秒のsleepを入れています。 なお、今回は1ホストにこのアイテムだけを設定して監視を行っています。 |
検証フロー
検証のフローは、以下の図のようになっています。
検証フロー
検証結果
それでは、ここから実際の検証結果を見ていきます。
Zabbix6.0の場合
6.0は、以下のような結果になりました。
| 限界ホスト数 | 21,000台 |
| 性能限界条件 | Pollerプロセスのビジー率100% |
| NVPS ※1秒当たりの監視データ数：New Value Per Second |
334.7 |
ホスト数が21,000台の時に、Pollerプロセスのビジー率が100%に達しました。
6.0の限界値
この時のNVPSは334.7でした。ZS-7600の監視推奨台数はNVPS 約333.3のため、ほぼ推奨値通りの値に落ち着きました。
この時、キューは最大30秒までたまり続けていて、とても監視できるような状態ではないことが分かります。
6.0性能限界時のキュー状況
Zabbix7.0の場合
続いて7.0です。6.0の限界に対して、いったいどれくらい限界が上がっているのでしょうか？
6.0の限界値である21,000台で試してみると、Pollerプロセスのビジー率は約0.05%と、6.0から約1/2000まで落ちていました。
21,000台時点のPollerプロセスビジー率
ここから3,000台ずつホスト数を増やしていきましたが、ビジー率は全く上昇しません。
一気に飛んで・・・・117,000台を超えたところで、ようやくビジー率が1%を突破しました。この時点で1%なので、Pollerプロセスのビジー率では性能限界条件を満たすことは無さそう。。
ということで、この時のCPU使用率を調べてみると、約30%前後でした。どうやら、先にCPU使用率の限界が来そうです。
117,000台時点のCPU使用率
そして、さらにホスト数を増やしていき・・・
ホスト数200,000台の時点で、CPU使用率が50%を超えて限界を迎えました。
7.0の限界値
| 限界ホスト数 | 200,000台 |
| 性能限界条件 | CPU使用率50%以上 |
| NVPS ※1秒当たりの監視データ数：New Value Per Second |
2,270 |
WEB管理コンソールを開いてみると、CPU使用率は90%前後になり、想定通りここが限界となりそうです。
この時のキューは6.0と同じく最大30秒までたまっており、とても監視できるような状態ではないことが分かります。
まとめ
最後に、検証全体のまとめです。
検証の結果
| 項目 | Zabbix6.0 | Zabbix7.0 |
| 限界時のホスト数 | 21,000台 | 200,000台 |
| NVPS | 334.7 | 2,270 |
| 性能限界条件 | Pollerプロセスのビジー率100% | CPU使用率50%以上 |
ホスト数上限は10倍、NVPSは7倍に向上しています。
このことから、Zabbix7.0では、Zabbixサーバ1台当たりの監視性能が飛躍的に向上したことが分かります。
チューニングしたパラメーター
| 項目 | デフォルト値 | 設定値 | 意図 |
| StartAgentPollers | 1 | 3０ | 最大値(1000)にするとOSのメモリが不足したため |
| CacheSize | 128M | 512M | ホスト、アイテム数の増加により不足したため |
StartAgentPollersは、Pollerプロセスの数を変更するパラメーターです。7.0では並列処理ができるようになったことにより、1プロセスのメモリ使用量が大きくなっています。そのため、他のプロセスとの合計メモリ使用量が80%程度になるようにチューニングしました。
CacheSizeは、コンフィグレーションキャッシュのサイズを変更するパラメータです。今回の検証ではホスト数63,000台を超えたあたりでConfiguration cacheが100%に近づいてしまいました。キャッシュが不足するとサービスの再起動が発生するため、余裕をもって、使用量が50%程度になるようにチューニングしました。
総括
Zabbix7.0では、Pollerプロセスの並列処理により、6.0から10倍近く性能が向上しました。
また、今回の性能限界はCPU使用率によるもののため、アプライアンスよりも高スペックのマシンを用意すれば、さらに多くの監視を実施することができると考えています。
但し、アプライアンスはデフォルトでカーネルパラメータ、DBなどをチューニングしており、
検証の中でもいくつかのパラメータを変更しているため、
性能を最大限に引き出すには適切なチューニングが必要だと考えられます。
SCSKでは、Zabbixに対して適切なチューニングを行い、最適な監視環境を提供いたします。
Zabbix 7.0を活用した監視環境をお求めの方は、ぜひSCSKまでお声掛けください！
最後に
今回は、Zabbix Conference Japan 2024で発表した内容を記事にしてみました。
また、イベント当日は、現地・オンラインあわせて約200名の来場者の前で登壇させていただくという、大変貴重な経験ができました。ご来場いただいた方々、イベントを運営いただいたZabbix Japanのスタッフの方々には改めてお礼申し上げます。ありがとうございました！
今後ともSCSKとZabbixをよろしくお願いします。
弊社ではZabbix関連サービスを展開しています。以下ページもご参照ください。
★SCSK Plus サポート for Zabbix★
★YouTubeに、SCSK Zabbixチャンネルを開設しました！★
★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★