Zabbix Conference Japan 2022レポート

1、より広く、より深いモニタリングを——これまでもこれからもぶれないZabbixのコアーー「Zabbix Conference Japan 2022」レポート

デジタルトランスフォーメーション(DX)やハイブリッドワークなど、今、さまざまな企業や組織が進めるあらゆる取り組みは、IT技術の上に成り立っていると言ってもいいだろう。これらIT技術が安定的に期待された役割を果たし続けるには、適切なモニタリングに基づく運用が欠かせない。

それを支えてきたオープンソースの監視ソリューション、「Zabbix」の年次カンファレンス「Zabbix Conference Japan 2022」が11月17日、18日に渡って開催された。

2022年は、Zabbixとして初の海外法人であるZabbix Japanの設立から10年目となる節目の年だ。久しぶりに来日したZabbixの創設者兼CEOのAlexei Vladishev氏は、「(日本法人代表の)寺島さんをはじめとするチームメンバー、そして日本のZabbixユーザーやコミュニティ、パートナーの方々に対し、これまでの支援に心からお礼を申し上げます」と述べ、ともに10周年を祝った。

進むDXの中、レガシーからクラウド、コンテナまで幅広い環境をサポート

Vladishev氏は講演の中で、あらためて「Zabbixは無償で、ユニバーサルで、かつエンタープライズレベルのオープンソースの監視ソリューションです」と強調した。

ITシステムはもちろん、ハイパフォーマンスコンピューティング(HPC)や組み込み、あるいはクラウドなど幅広い領域で活用されるほどユニバーサルであり、しかも、さまざまな既存のITインフラと統合可能だ。そして、データ収集とそれに基づく分析、トレンド予測やアラート、問題対応に至るまで、エンタープライズクラスのモニタリングソリューションに必要なすべての機能がオールインワンで提供される。

一方で、オープンソースソフトウェア(OSS)であり基本的には無償で利用できる。ライセンスの自由度も高く、監視対象のデバイスやサービスが増えても制限はない。それゆえにユーザーベースも広く、Zabbixに関するノウハウを持った認定エンジニアを探すのも容易だ。

Vladishev氏はこうした特徴を踏まえ、「Zabbixは、フリーかつ自由度が高いオープンソースで、Zabbix社やパートナーが提供するサポートサービスによる手厚い支援が受けられる商用ソリューションです。二つの世界のいいところ取りをしたソリューションと言えます」と述べた。

こうしたメリットが受け入れられ、Zabbixのユーザーはグローバルに広がっている。確実に把握しているだけでもFortune 500社のうち100社以上で使われている上に、米国のあるグローバル企業のように、1台のZabbix Serverで数十万台ものデバイスを監視するほど大規模に活用している事例も珍しくない。こうしたユーザーのニーズに応えるため、Zabbix社では日々、パフォーマンスの改善に尽力しているとした。

もう1つ、特に強化しているのが多様なプラットフォームへの対応だ。Vladishev氏は「ユーザーに選択の自由を提供することが重要だと考えています」とし、幅広いLinuxディストリビューションへの対応はもちろん、Dokcerイメージ形式で活用できるほか、Kubernetes環境、さらにAWSやAzure、GCPといった主要なクラウド環境にインストールし、モニタリングを行えることを説明し、次のように述べた。

「今、多くの企業はレガシーなシステムから新しいテクノロジへと移行するDXに取り組んでいます。Zabbixの利点は、旧来のテクノロジ、レガシーなシステムやアプリケーションだけでなく、クラウドやハイブリッドクラウド、Kubernetesといった新たなテクノロジ、両方をサポートすることです」(Vladishev氏)

そして今後も、インテグレーションチームを中心に、さまざまなサービスやアプリケーション、ネットワーク機器との統合・対応を進めていくとした。

すでにZabbix 6.2ではVMwareプラットフォームへの対応を強化し、より深くモニタリングが行えるようになったほか、Cisco MerakiやHPEのネットワークプラットフォームの監視、VeloCloudやKubernetes監視用のテンプレート強化を図っている。また、Amazon CloudWatchをはじめ、各種クラウドサービスが提供しているサービスのモニタリングや、ServiceNow、Jiraといったチケット管理製品、あるいはSlackやMicrosoft Teamsなどのコミュニケーションツールとの連携も進めているという。

Vladishev氏は合わせて、Zabbixのセキュリティ面での取り組みについても紹介した。「今やセキュリティは非常に重要な課題です。Zabbixでは専門のセキュリティチームを立ち上げ、高度なセキュリティ標準に沿ってZabbixを開発するとともに、Zabbixインフラの保護に努めています」という。

具体的には、最小権限の原則に基づき、Zabbixエージェントはroot権限がなくてもインストールできるようになっている。Zabbixのコンポーネント間の通信はTLSやHTTPSによって暗号化され、管理インターフェイスを利用するには二要素認証が必要だ。そして、パスワードやAPIキー、トークンといったZabbixに関連するセンシティブな情報は、外部のシークレット管理ソリューションと連携し、安全に保管する仕組みを整えている。

近年では、OSSに存在する脆弱性を狙った不正アクセスも増えている。Zabbixでは、HackerOnetと連携してバグバウンティプログラム(脆弱性報奨金制度)を開始したほか、脆弱性情報をセキュリティアドバイザリーの形でWeb上で公開し、Zabbix本体はもちろん、依存するソフトウェアで発見された脆弱性情報も把握できる体制を整えた。

さらに「高いセキュリティスタンダードに沿ってZabbixを開発していくことも重要で、年内にISO 27001認証を取得する見込みです」(Vladishev氏)とし、引き続きセキュリティの確保に取り組んでいくとした。

ユーザー視点での監視やプロキシの無停止アップグレードなども——多数の新機能を盛り込む6.4

続けてVladishev氏は、今後のロードマップについて紹介した。Zabbixにこれからどのような機能を搭載していくかについては、基本的に同氏が責任を負っている。ただ、ユーザーやパートナーが「Feature Request」というチケットを作成し、「こんな機能が欲しい」と思ったチケットに投票する仕組みが用意されており、これが優先順位を決定する要素の一つとなっているという。

毎回そうだが、Zabbixはバージョンアップのたびに多くの新機能を追加し、機能改善を施してきた。バージョン6.4では、

  • スクリプト機能の追加:複数のステップによって構成される複雑なモニタリングシナリオを定義し、それに沿ってデータの収集・監視が可能になる
  • ブラウザエミュレーション:WebアプリケーションやWebサービスをエンドユーザーの視点でモニタリングできるようになる
  • イベント分類の追加:単純に「問題」として通知するのではなく、根本原因を示す「cause」と、それによって引き起こされる「symptom」に分けて把握できるようになる
といった機能が追加されるほか、相関分析エンジンの強化、可視化機能の強化など、盛りだくさんの機能強化が図られる予定だ。

中でも、運用を担う現場の担当者にとって歓迎されそうな機能が、「Zabbixプロキシの無停止アップグレード」や「監視設定の即時同期」だ。

「現時点では、Zabbix ServerとProxyは同時にアップグレードしなくてはなりませんが、6.4ではそれを非同期で行えるようになります。まずServerをアップグレードしてから、順次、複数のProxyをアップデートすることが可能です。しかもその間、プロキシは継続してデータ収集・処理が行えます」(Vladishev氏)

また、構成変更に応じて監視対象に新しいデバイスやアイテム、トリガーを追加した際には、すぐにその情報がプッシュされ、スピーディに構成変更が反映される。「数時間ではなく数分でデータ収集が行えるようになります」(Vladishev氏)

さらに、7.0での実装が予定されていたテンプレートのバージョン管理も繰り上げて搭載される。「テンプレート管理がより簡素化され、どの種類の、どのバージョンのテンプレートを使っているかを把握し、どれをアップグレードすべきかがわかりやすくなります」とVladishev氏は述べた。

その先の7.0でも、クラウドやKubernetesの監視および可視化の強化に加え、イベント相関分析エンジンの強化など、多くの機能が搭載される予定だ。そしてその先では、「Zabbixでセキュリティやコンプライアンスのモニタリングも行えるようにしていく計画です。また、APMやトレーシング、オープンテレメトリスタンダードとの統合なども計画しています」とし、引き続きたゆまぬ強化を進めていくとした。

10年を経て、単なる「サポート」のイメージを越えた包括的な支援を提供するZabbix Japan

Zabbix Japan代表の寺島 広大氏がZabbixと出会い、大きな可能性を感じてラトビアに足を運んだ後、日本法人を立ち上げたのは2012年のことだ。これはZabbix LLCにとっても初めての海外法人だった。それから10年、サポートとトレーニングという2つのサービスを中心にZabbix Japanは順調に成長を遂げている。

「これまで、Zabbix Japanに寄せられた問い合わせ件数はトータルで1万4000件に上ります。実際にはパートナー様で解決した問い合わせもあり、相当な数のお問い合わせをいただいています。また、Zabbixのトレーニングは約4000人に実施してきました」(寺島氏)

寺島氏がZabbix Japanを立ち上げてから今に至るまで、たびたび尋ねられたのが「果たしてOSSを扱っていて、ビジネスとして、会社として成り立つのか」という質問だったそうだ。だが寺島氏は、この話題は今年でもう終わりにしたいという。「パートナーも売り上げも順調に伸びており、会社として十分安定し、成り立っています」という。

Zabbix Japanの事業の大きな柱がサポートだ。設立時には「シルバー」「ゴールド」「プラチナ」という3つのプランを用意してスタートしたが、その後、さまざまなニーズに応えながらサポートメニューを拡張してきた。

その1つが「ベーシック」プランだ。提供の契機となったのは、2013年に日本で独自に販売を開始したZabbixアプライアンスの存在だ。「ハードウェアおよびファームウェアのサポートに、Zabbixを知らない人に向け、3時間で『どこから設定すればいいか』がわかる入門トレーニングを付けました」(寺島氏)。同時に、ファームウェアなどのダウンロードが可能なカスタマーポータルも構築した。

サポートメニュー自体も拡張していった。problemテーブルのレコード肥大化問題を解消する機能なども盛り込まれている「Zabbix-enterprise-utils」や「設定バックアップツール」など、Zabbix運用においてかゆいところに手の届くツール群も提供している。

さらに2022年5月には、元々はパートナー向けに実施していた「勉強会」を、「ショートトレーニング」という形でゴールド・プラチナサポート向けに提供を開始した。

寺島氏は、「サポートに入っている方向けに、さまざまなツールやトレーニングを拡充する取り組みを進めてきた10年間でした。これからの10年間もこれまで地道にやってきたことを続け、サービスや支援を強化していきます」と述べ、Zabbix Japanでは補えない部分はパートナーの力を借りつつ、引き続きメニューを拡充していく方針を示した。

一般にサポートというと、トラブルが発生した時の技術的な問い合わせ対応、というイメージが強い。だが寺島氏はそのイメージを変えていきたいという。

具体的には、ツールやトレーニングなども合わせて提供するさまざまなサポートの集合体として、「サポート&サブスクリプション」という名称に変更し、今後も高い顧客満足度を維持していきたいとした。合わせて、日本の顧客から寄せられたさまざまな要望を本社に橋渡しする役割も強化し、コミュニケーションを図っていく。こうした取り組みを通して、引き続きZabbixの顧客を支援していくと宣言した。

2、環境が変化しても基盤を支え続けるZabbix、その最新動向を一挙紹介

Zabbix 1.0α1がリリースされてから20年以上、そして日本法人であるZabbix Japanの設立からちょうど10年という節目の年を迎え、「Zabbix Conference Japan 2022」が2022年11月17日、18日に開催された。クラウドサービスが浸透し、モバイルやリモートワークを含む新しい働き型が広がるなど、この間にはIT環境も社会環境も大きく変化したが、Zabbixは少しずつ進化し、パートナーを増やしながら新たなニーズに応えてきた。セッションではそうした最新動向・ソリューションや活用事例が紹介された。

Zabbix 4.2からデータベースとしてサポートされた「TimescaleDB」、その実力は?

Zabbixをはじめとするオープンソースソフトウェアの構築・サポートを提供しているSRA OSS LLCでマネージャを務める赤松俊弘氏は、「ZabbixにおけるTimescaleDBの利用方法とパフォーマンス」と題し、Zabbix 4.2以降で新たにバックエンドデータベースとしてサポートされたTimescaleDBを採用した場合、パフォーマンスはどの程度向上するか、実際に試してみた結果を紹介した。

TimescaleDBは、PostgreSQLの拡張モジュールとして開発された「時系列データベース」だ。名前の通り時系列データを扱うことに特化しており、使いやすさとスケーラビリティ、信頼性の高さが特徴だ。

TimescaleDBは、全体の時系列データを管理する「ハイパーテーブル」と一定期間のデータのみを保持する子テーブルである「チャンク」というアーキテクチャで構成されている。このため、Zabbixのバックエンドデータベースとして活用する際には、保存期間を過ぎたデータベースを定期的に削除する「Housekeeper」処理時の負荷を抑えられる他、圧縮機能を用いてストレージ容量を節約できることなどが利点だ。ただ利用に当たっては、ZabbixとPostgreSQL、TimescaleDBそれぞれについて、どのバージョンが対応しているか確認する必要がある。

赤松氏は、Zabbix 6.0.9でホスト数500、アイテム数3万5000という検証環境を用意し、TimescaleDBを利用した場合にどのくらいパフォーマンスが改善するかを検証。PostgreSQLでは一回のHousekeeperに約20時間かかっていたのが、わずか約6.9秒で、ほとんど負荷がかからずに処理できることが確認できた。history Syncerプロセスでのデータベース書き込み負荷やCPU負荷も抑えられることが明らかになった。

「PostgreSQLとパフォーマンスを比較した結果、履歴データについては削除処理は大幅に、データ更新・挿入の処理も比較的負荷を軽減できることが観測できました。TimescaleDBをZabbixのデータベースとして利用することにメリットを感じていただけるのではないでしょうか」(赤松氏)

「担当者が限られる」「設定が複雑、面倒」という声を解決するEnterpriseサポート

Zabbix日本法人の設立以前から認定パートナーとなり、Zabbixパートナー会の幹事会社でもあるインフォコムの上級主任、吉田和也氏は、「Zabbixの分からないを解決。Zabbix Enterpriseサポートのご紹介」と題し、実際にユーザーから寄せられた声を元に、監視システムにどのような課題がつきまとっているかを説明した。

同社がカンファレンスで行ったアンケートによると、2018年も、また3年後の2021年でも、「分かる担当者が限られてしまう」「設定が複雑、面倒」といった声が多く寄せられていた。「Zabbixの設定が複雑・面倒だったり、担当者が限られてしまうという課題がなかなか解決できず、ずっと残っている状況が伺えます」

この状況に対してインフォコムでは、オフィシャルサポートの1つである「Zabbix Enterpriseサポート」の活用を推奨している。サポートを導入することで、技術的な問い合わせへの対応が得られるだけでなく、Zabbix社が公開しているナレッジベースや各種ツールが活用できる。特に、監視設定のバックアップ・リストアができ、履歴を残しておける「Zabbix設定バックアップツール」の利用は非常に多いという。

インフォコムではさらに10年にわたるサポート経験をベースにした知見、ノウハウを生かし、顧客が目的を達成するための支援を提供していくとした。

枯れたバージョンよりも最新版を——顧客が抱く、素朴な悩みへズバリ回答

長年システム監視設計業務に携わってきたアシスト主任の塩澤正寛氏は、「Zabbixを使う時にはココを検討!実際に頂いたリアルなお悩みポイントを解説」と題し、実際に寄せられた声に基づいて、「環境構築」「機能」「運用」という3つの観点で顧客が悩みがちなポイントへのアドバイスを紹介した。

まず環境構築に関しては、「どのバージョンを採用すればいいか」という声が多いという。しばしばITの世界では「枯れた」1つ前のバージョンが好まれるが、Zabbixに関しては「今後のバージョンアップ対応やその頻度を考えると、新しいバージョンの方がいいとご案内しています」(塩澤氏)。また、他の監視ツールから移行する場合には、監視項目や通報・通知方式の机上検討にはじまり、エージェントの同居の可否や並行稼働期間のタイミング、配布方法など、さまざまな事柄を事前に確認、検討しておくことが重要だとした。

機能面でもさまざまな質問が寄せられるという。中でも「テンプレートはどのように使えばいいか」という声が多いそうだ。Zabbixでは柔軟にテンプレートを活用できるがゆえの疑問だろう。塩澤氏は、デフォルトテンプレートに加え、一部にカスタマイズを加えた「カスタムテンプレート」、自作する「個別テンプレート」と、OS種別ごとのテンプレートを、監視項目別に割り当てることがポイントであり、将来的に監視対象を追加する際の展開も容易になるとした。

最後は運用面だ。ここでよくある疑問が「監視抑止の恒久対応、一次対応はどのように行うか」だという。監視の抑止は、Zabbixの管理インターフェイス上で手動で行えるほか、スケジュール設定やトリガーの内容に手を加えることでも対応できる。ただ、塩澤氏は「ユーザー目線では、緊急対応や夜間対応時の監視の抑止は確実に対応していく必要があります。ですので、どうやってミスなく抑止し、また抑止したものを解除できるかがポイントになるでしょう」とし、JP1のような他のツールと連携して一括管理することも1つのやり方だと紹介した。

グラフィカルなレポート作成を支援する「ExReport」など、ツボを押さえたツール群

2007年から、Zabbixを活用してのシステム・監視サービスを「ZABICOM」という名称で提供してきたNTTコミュニケーションズのインフラエンジニア、坂井佑至氏は、「痒いところに手が届く!NTTコミュニケーションズオリジナルのZabbix拡張機能のご紹介」と題し、同社が独自に開発したZabbix拡張機能を紹介した。

1つは、定期的に作成するレポートの素材となるグラフをまとめて出力できる「ExReport」だ。Webインターフェイス上で、出力したいデータと期間を指定すると、当該のグラフと元のデータがエクスポートされる。すでに官公庁や金融・製造業などで活用されているという。

2つ目は、多数の拠点にまたがり、監視対象機器の状態を3次元情報で表示する「T-View」だ。Zabbixの情報を元に現在のネットワーク構成を3次元で可視化し、さらに障害情報やトラフィック情報を重ねて描画できる。また、過去の障害発生状況を後から確認できる「リプレイ再生機能」も備えており、Interop 2022のNOCでも活用されたという。

3つ目は、大量のアラートを1つにまとめ、ホストグループ単位で障害イベントの中身と件数を確認できるようにする「GatherAlert」だ。似たようなアラートが大量に送信され、本当に重要な障害通知を見落としてしまう、といった事態を避けることができ、メール基盤への負荷も軽減できる。平日・休日の区別や時間帯に基づいて通知先を振り分けることも可能となっている。

同社ではさらに、Zabbixの設定情報や監視データのバックアップを行ったり、ネットワーク機器のポート管理表やラック搭載図を自動生成するツールなど、ニーズに合わせてさまざまな拡張ツールを作成、提供している。

Zabbixの冗長化方式は一長一短、各々の特徴を理解した上で選択を

アークシステムのシステム構築スペシャリスト、新井健志氏は、「Zabbix環境の冗長化手法 早わかり解説! ~Native HAってどうよ?~」と題し、Zabbix環境を冗長化する複数の方法と、それぞれのメリット、デメリットを解説した。

まず最初の選択肢は、Zabbix 6.0で登場した「Native HA」だ。Zabbixの標準機能として、アクティブスタンバイ方式でのフェイルオーバーが可能になる。ただ「フロントエンドやZabbixデータベースといった部分には冗長化機能は提供されないため、AWSやAzureを初めとするクラウド環境と組み合わせるか、Zabbixデータベースに何らかの形でマネージドサービスを組み合わせるといった考慮が必要です」(新井氏)。また、重複検知の抑止についても考慮などが必要だとした。

2つ目は、RedHat High Availabilityアドオンなどのソフトウェアを使ってHADクラスタを構築する方式で、クラウド環境はもちろん、オンプレミス環境での運用にも適しているという。そして、「オンプレミス環境の場合は、データベースが単一障害点とならないように高可用性ディスクを利用したり、Zabbixデータベースの冗長性を何らかの形で担保するといった配慮が必要です」と新井氏は説明した。

3つ目は、Zabbix Japanが提供する「設定バックアップ同期ツール」を用いた、アクティブ-アクティブ方式での冗長化だ。2台のZabbixサーバが同時に動き、同時にデータを収集するため、理論上、障害発生時のダウンタイムは発生しない上に、異常検知時の重複・欠落もない。前提としてZabbix Enterpriseサポート契約が必要になり、トラフィックや監視の機器の負荷が2倍になり、発報抑止や監視設定の整合性確保といったポイントがあるものの、「現時点ではこの方式が一番やりやすいと考えています」(新井氏)

一方でNative HA方式については、データベースがマネージド環境で提供されることも含め、クラウド環境での導入に優位点がある。こういった特徴を踏まえ、冗長化方式を選択することが重要だとした。

広がるクラウド活用、Zabbixから監視を行う際のポイントは?

クラウド環境の活用が広がる中、クラウド環境でZabbixを使いたい、あるいはクラウド環境の監視をZabbixで行いたいといったニーズも高まっている。Zabbix Japanでサポートエンジニア兼トレーナーを務める渡邉隼人氏が、「クラウドで使用するZabbixの機能Tips」と題してそのポイントを紹介した。

渡邉氏によると、「オンプレミス環境にあるZabbixサーバからクラウド上のZabbixエージェントの監視はできますか」という質問がしばしば寄せられるという。答えは「イエス」だ。クラウド上の仮想マシンにZabbixエージェントをインストールすれば、さまざまなリソースやログの監視が行える。また、その通信は暗号化できるほか、Zabbixのプロキシを間に置くことで、データをいったんまとめた上でZabbixサーバに送信させる形とすれば、データロスを抑えつつ転送容量の節約が可能になるという。

また、Zabbix 6.0から実装されたZabbix HAでは、アークシステムの新井氏も説明した通り、サードパーティ製のツールなどを別途組み合わせる必要なくZabbixの冗長化が行える。ただ、Zabbixデータベースの冗長化までは行わないため、ここが単一障害点になる恐れがあった。そこを補う手段として、Amazon RDSをはじめとするクラウド事業者が提供するデータベースサービスを組み合わせる、という手がある。書き込むデータ量に見合ったスペックかどうかといった注意点はあるものの、基本的には問題なく動かせるという。

ただ、クラウドサービスにはIaaS以外に、エージェントのインストールができないSaaSや一部のPaaSも多々あり、これらの監視を行いたいといった要望も少なくない。「そういったサービスについては、サービス提供元からAPIが提供されていると思います。ZabbixではAPI連携を行ってそれらを監視できます」(渡邉氏)

そしてZabbix 6.2では、AWSとAzure向けの監視テンプレートが標準テンプレートに追加された。Zabbix社が標準で提供するため、これらを利用していれば問い合わせ対応をはじめとするサポートの対象となる。ただ、このテンプレートは、Zabbix 6.2で追加された関数を組み合わせることでクラウド監視を実現しているため、残念ながら6.0ではそのまま使うことはできない。もし利用したい場合には、ポイントリリースではあるがZabbix 6.2へのバージョンアップが必要になるという。

渡邉氏は最後に「長期的に利用したい場合には、7.0のLTSのバージョンから使っていただくことになると思いますが、そのころにはテンプレートがもっと充実し、さらに使いやすいものになってくるでしょう」とした。

先入観を持たず、運用以外の幅広い領域でZabbixを活用する三菱UFJ

Zabbixというと、運用フェーズでITシステムの監視に活用するもの、というイメージが強い。もちろんそこでも有効活用できるが、MUFGグループのITを担う三菱UFJインフォメーションテクノロジーのシニアITスペシャリスト、勝野基央氏は「運用フェーズやシステム部門以外でのZabbixの活用」と題し、意外な領域でのZabbix活用例を紹介した。

1つ目は、いわゆるATMシステムの監視業務だ。さまざまな店舗に置かれているATMは、バックグラウンドのサーバ群と連携しながら稼働している。サーバ群についてはZabbixや他の製品を用い、システムの稼働状態を監視していたが、全国に点在するATMについては、横に置かれているインターホンを介してコールセンターに連絡が行き、そこから状況を把握する形となっていた。このため、人と人を介したコミュニケーションの中で伝言ゲームのような形になってしまう課題があったという。

「トラブルが起こったときに最適な対処を行うには、サーバやハードウェアの状態だけでなく、末端の現場の状態、業務の状態を踏まえて複合的な視点で見ることが必要です」(勝野氏)。そこで、実際のATMの状況などを簡単に把握できるアプリケーションを用意すればいいのではないかという考えから、Zabbixの活用に思い至ったという。

「今、ATM端末が何台稼働し、何台止まっているか、それはどのサーバの配下で起こっているかといった情報を、Zabbixを活用して自動的に取得するようにしました。またダッシュボードを整形し、ITにあまり関わりのない業務統括部門にも受け入れやすい形を取りました」(勝野氏)

この取り組みを通じて、「Zabbixはシステム運用部門が監視に使うものというイメージが非常に強いと思いますが、業務アプリケーションライクに利用できる可能性も秘めていると感じています」と勝野氏は述べ、インフラエンジニアだからこそ提案できるソリューションがあるのではないかと呼びかけた。

2つ目の取り組みは、RPA、いわゆるロボットの動作に対する監査指摘対応だ。同社グループではさまざまなRPAを開発し、ファットクライアント、つまりパソコン上で動作させている。その数はすでに300台を超えており、さらに週に10台といったペースで増えている状態だった。これらのRPAの稼働に対し、サーバと同様に「きちんと動作しているか、リソースは正常か、また不正なログインはないか」といった事柄を見るべきだと、監査の中で指摘されたという。

そこで解決策として採用したのが、使い慣れているZabbixだ。さらにAnsibleを組み合わせ、Zabbixのエージェントのインストール、エージェントの起動、Zabbixへの登録といった一連の流れをボタンを押すだけで自動的に導入される仕組みを整え、担当者が詳細を認識しなくとも自動的に監視を開始できる体制を整備した。

今では400台を超えるRPAの監視を行っているが、「AnsibleやZabbixを組み合わせることで、1台当たり1時間以上かかるような作業を自動化でき、コスト効果も発揮できています」(勝野氏)。副次的な効果として、今まで知見を持たなかった部署がわかりやすいWeb GUIに触れることで、新たに「こういうことをやれないか」「こういったところを楽にできないか」といったアイデアが出てくるようになったという。

3つ目は開発フェーズでの活用だ。同社グループでは前述の通りRPA開発が盛んに進められており、常時50名から100名が並行して開発プロジェクトを進めている。運用フェーズに入ったシステムには監視部門があり、常時監視を行っているが、開発環境となるとそこまで目が行き届いているわけではない。このため開発環境で障害が起きてしまうと、業務影響こそ生じないもののプロジェクトには大きな影響が生じていた。また、障害に気付いた担当者が個別に問い合わせを寄せるため、「そもそも開発環境で一体何が起きているか」という全体の状況も共有できていなかったという。

そこでやはり活用したのがZabbixだ。Zabbixで障害を検知すると、API連携によってRedmineにチケットを登録し、インフラ部署とRPAの開発を行う部署の関連するメンバーに通知が行く仕組みを構築した。このチケットを参照することで、トラブル対応に着手しているのか、解消しているのかといった進捗が確認できる。これにより、関係者で状況を共有し、さらに対応に当たる担当の明確後、クローズまで着実に管理を行える仕組みが整った。

勝野氏は最後に「Zabbixというと、システムが稼働しはじめた後に運用部門が活用するものという色合いが強いものですが、多様な場面で活用できるポテンシャルを持っています。先入観を持たずに、どういった場面で使えるかを検討できるといいと思います」とした。さらに、部署の垣根を越えてフロント側にもソリューションを提案することで、より大きな効果を得ることができるとした。

誰もがぶつかるZabbix運用の最初の壁? データベース肥大化に立ち向かったエーピーコミュニケーションズ

エーピーコミュニケーションズでサーバインフラエンジニアとしてシステムを支えている池上裕幸氏は、まだZabbixの経験自体は数ヶ月で「初心者」だという。同氏はZabbixデータベースの肥大化と、それに伴って発生した事象にどのように対処したかを「Zabbix初心者が課題対処(DB肥大化・新規構築)から学んだ・学んでいること」で紹介した。

トラブルのはじまりは「Zabbixの動作が遅い、ログインできない」という連絡を受けたことだったという。調べてみると、Zabbixデータベースを動かすサーバのディスク領域が100%使われていることが判明した。領域自体が書き込み不能となっており、ダッシュボードへのログインすらできない状況になってしまっていたそうだ。

池上氏は取り急ぎ、データベース以外のファイルを別領域に退避させ、調査に取りかかった。調べていくと、データベースのテーブルも破損し、監視機能不全の状態に陥っていることも判明した。「そもそもディスク領域が逼迫したのはなぜかを調べるため、サイズの大きいファイルを確認したらすぐに該当のものが見つかりました。history_logのテーブルのデータファイルが100GBを超える容量になっていました」(池上氏)

この状況がいつ発生したかを追ってみたところ、ネットワークの利用状況の変化にともなって監視データが増加し、それがhistory_logテーブルを大きくしていたそうだ。

池上氏は根本的な対策に向け、history_logテーブルのサイズを縮小できないかあれこれ試してみたものの、芳しい効果は得られなかった。結局、Zabbixデータベースのストレージエンジンとして採用していたmyisamの仕様上、いったん記憶領域として確保された領域を解放するにはテーブルの再構築が必要と判明。監視を止めるわけにはいかなかったため、新たにZabbix 6.0 LTSで、データベースにMariaDB、ストレージにinnoDBという組み合わせで新規環境を構築し、監視機能の移行を進めているという。

新規環境の構築に当たってはこの教訓を踏まえ、Zabbix自体のチューニングに加え、InnoDBでも定期的にData Freeの領域を解消させる処理を追加したり、ディスクの空き容量を確保した上でテーブルの再構築を行うなど、さまざまなところに気を配っている。

池上氏は「Zabbixの運用上、ディスク領域の管理や定期的なメンテナンスも重要であることを実感しました」とのべ、引き続き、新旧環境の差分を補い、本当の意味で監視ツールとして扱う知識やノウハウを身につけるべく、地道に学び続けていきたいという。

Nagios、Cactiも入り交じる30環境をZabbixに統合したNTTコミュニケーションズ

NTTコミュニケーションズではさまざまな保守運用業務を通してITインフラの安定運用を支援している。同社の今井聡氏は、Zabbixのほか、WATT、Nagios、Cactiといった複数の監視マネージャが入り交じる状態となっていた約30種類の監視環境をZabbixに統合するまでのプロセスを紹介した。

今井氏が所属する保守運用チームでは、保守センターを通して23社の環境を監視してきた。ただ、従来の監視マネージャーはシングルポイントで動いており、もし壊れてしまった場合は夜間でも駆けつけて対応していたという。また基本的には一対一の関係で監視を行っており、顧客が増えるにつれて監視サーバも、また見るべき監視マネージャーも比例して増えていく状態となっていた。結果として、それらが動くサーバの保守・サポート期間も課題となっていたという。

さらに「会社の命題として、コスト削減のために自動化したいという要請もありました。しかし個社ごとに監視マネージャーが別れているだけでなく、通知メールのフォーマットや監視項目もバラバラで自動化がしにくい状況でした」(今井氏)

そんな中でも何とか自動化しやすくし、駆けつけ対応も減らすために同氏が考えたのが、乱立していた監視マネージャのZabbixへの統合だ。当初は10案件程度の統合を提案したところ、上司からは何と全案件、30案件を統合して欲しいという返事が返ってきて「頑張って対応しました」という。

統合後の環境では、物理サーバ上にHyper-Vを搭載し、その上にZabbixを構築し、約3万8800ホスト、12万4800アイテムを監視対象にしており350VPSの性能を確保している。それまで個別に表示していた監視画面もZabbixの画面上で複数社の状況を表示できるようになった。またHAクラスタソフトの「Pacemaker」を利用して冗長化も図っている。

構築に当たっては、ストレージで採用したiSCSIをDACケーブルで利用した際のみに生じる特殊なバグに遭遇した場面もあり、メーカーと連絡を取りながら解決に当たったという。ユニークな点として、基本的にHyper-Vの基盤としてのみ使うことから、GUIを持たずCUIで構築される「Windows Server 2019 Core」を採用した。必要なリソースが少なくて済み、モジュールも少ないためセキュリティアップデートも少なくて済み、リスクも低いといったことがメリットだ。

30案件を18カ月で移行する、つまり1ヶ月に1案件以上移行するというある意味強行スケジュールだったため、移行時にもさまざまな知恵を絞った。特殊なものは除いて、極力共用利用ができるよう標準テンプレートを作成したり、同社のZABICOMチームから提供を受けたツールを活用してホストやインベントリ情報の一括登録を試みたりと、なるべく効率的に進める方法を模索した。ただ、さすがに1万ものホストのインベントリを一気に登録したところキャッシュがあふれてしまい、Zabbixサーバが停止する状態に陥ったという。「横着はだめということがよくわかりました」(今井氏)

また3万8000件を対象にpingをするとプロセスが足りなくなり、やはりエラーが生じた。「リソースだけでなく、プロセス数などそれ以外のところもきちんと見なければいけません」(今井氏)。こういった課題に直面するたびに設定を見直し、チューニングすることで対応した。また、ZabbixとNagiosとで監視間隔の設定が異なることを踏まえ、「最長検知時間」を合わせる工夫も行ったという。

今も移行作業は続き、残り4カ月で7案件というところまで来た一方で、統合後の環境の運用もスタートしている。運号フェーズでも無駄なアラート・通知を省くため、たとえば問題を手動で復旧させた場合にはSNMP Trapで回復メールが飛ばないよう通知抑止を行ったり、Zabbix Senderのコマンドを利用し、故障を通知するメールにtracerouteの結果を付け加えて送るようにするなど、運用現場で求められるさまざまな機能を追加した。こうした工夫を凝らしながら、全30案件の移行を引き続き進めていくという。

カンファレンスへ戻る