短期間で内製化を実現！
手軽で網羅性に優れた監視ツールとして採用

「国を衛る」情報セキュリティのプロ集団

——事業やチーム、役割について教えてください。

山口氏　ラックは、創業者が「国を衛る」という熱い想いで情報セキュリティのプロ集団として事業を始めました。現在では大手企業を中心に、セキュリティソリューションサービス、システムインテグレーションサービス、情報システム関連商品の販売とサービス提供という3つの事業を展開しています。

従業員数がグループ全体で2,100名を超える規模で、われわれはその情報システム部門を担っています。部門には、インフラ開発保守チームとヘルプデスク・インフラ運用チームがあります。私は、開発チームに所属し、クラウドとサーバー関連の業務を担当しています。

そんな中、既存の監視ツールのライセンス切れのタイミングをきっかけに、私とネットワーク担当の2人が監視ツールの要件定義から選定、構築を担当し、現在はSite24x7をチームで運用、保守を手掛けています。

——Site24x7を導入する前に抱えていた課題は何でしたか？

山口氏　ネットワーク機器やサーバーを監視していた既存のツールを導入してから10年ほど経過しており、クラウドシフトへの対応が遅れているという声が上がっていました。ラックはMicrosoft Azureを導入しているのですが、クラウド上のWebシステムを、ネットワークの外からユーザーと同様の方法で監視する「外形監視」を実施する必要もありました。

また、一部にレガシーシステムのOSを使っており、そこにはエージェント入れたくないといった事情もありました。

——Site24x7を見つけた経緯を教えてください。

山口氏　実は私は、2023年に入社したのですが、その前はベンダーの立場で、顧客向けにSite24x7の構築を担当していました。その時は検証段階からの参加でした。顧客が既にSite24x7に決めていて、別のツールからの乗り換えを検討しているという状況でした。主な監視対象はAWS（Amazon Web Services）上のサーバーとURLでした。URLは外形監視です。検証した結果、好感触を得ました。その際は、ネットワークの監視は別のツールを継続利用するという話だったので、サーバーについて私の方で監視の評価をしました。

——今回は比較検討もされたのでしょうか？

山口氏　はい。要件を整理し、SaaS型やオンプレミス型、OSS（オープンソースソフトウェア）や有償ソフトウェアなど、ラックに合うツールをメジャーなものを含めていくつか挙げました。Site24x7は知っていたこともあり評価対象に含めて、評価表に◯×を付けて各ツールを比較してみました。結果的に、Site24x7が最も要件に合うという判断になり、検証することにしました。

——決め手は何だったのですか？

山口氏　課題解決の網羅性と導入コストでした。特にオンプレもパブリッククラウドもネットワークも、全部1つのツールで網羅できることです。

——具体的に今は何をどれくらい監視していますか？

山口氏　ルータやスイッチを合わせて約20台のネットワーク機器を監視しています。加えて、レガシーOSのサーバー約10台も監視しています。これらはベンダーのクラウド基盤にあり、エージェントを入れたくない事情があったため、エージェントレス監視を実施しています。Site24x7の中継サーバー（オンプレミスポーラー）をAzure上に立てることで、環境を実装しています。

Azure周りでいうと、仮想マシン（VM）が約30台、これらはエージェント監視をしています。それから、Express RouteやApplication Gatewayも監視しています。これらはSite24x7にAzureのアカウントを連携させました。企業サイトと会計システム、稟議の申請承認システムなどで使っているAzure上のWebシステムやSaaSも、外形監視の実施対象になっています。

監視したかったものはすべて、Site24x7で対応できました。

——導入コストについても詳しく教えてください。

山口氏　私たちのチームは、内製化を推進しています。今回ですと、クラウド・サーバー担当の私とネットワーク担当の2人で監視システムを構築するので、それにかかる工数も導入コストと考えていました。そのため、設定の容易さが決め手になってきます。

その意味で、Site24x7は設定が容易という印象を持ちました。例えば、エージェントをサーバーに導入すれば、それだけでもう監視が始まります。

以前、OSSや大手ベンダーの監視ツールを使ったことがありましたが、設定すべき項目が多い印象がありました。また、手順も難しい上に、ステップも多いという印象でした。それと比較すると、Site24x7の方がずっと簡単です。サーバー監視を始める前提において、エージェント側（監視対象側）の設定工数で比較すると、Site24x7ならば3分の1くらいに減ります。

過去の事例を紹介します。ある顧客はサーバー1台を監視対象に追加するために、その作業代（メジャーな監視ツールの導入費）としてベンダーに20万円も払っていたのです。その20万円を内製しようと思ったら、その難しい設定自体工数がかかる上に、手順書作って検証してといった手続きが必要です。Site24x7であれば、Web上の手順に沿って、手軽に設定し、検証するというプロセスを内製で実施でき、時間も従来の半分ですみます。その効果は大きいですね。

私が経験したことのあるオンプレミス型の監視ツールは、エージェント側だけじゃなく、マネージャー側の設定にも手間がかかるものでした。SaaS型のSite24x7であれば、マネージャー側の設定はしきい値の設定くらいしかないため、導入までのハードルが劇的に下がります。

——構築にかかった期間はどれくらいですか？

山口氏　かかりっきりではなく、掛け持ちで構築して、1カ月くらいで構築からテストまでを完了しました。迅速に構築できたと感じています。

——無償のメールサポートも活用されていますか？

山口氏　活用しています。まれに、手順書通りに進めていたつもりでも、思うとおりにならないケースがあり、その解決を探るためです。単純に、ツールとしてできることとできないことを、メールで尋ねることもあります。いずれも期待通りの回答を得られて、聞けばすぐにレスポンスが返ってくるので助かっています。

——コストの話でもうひとつ、2つのプランをご契約いただいています。その目的を教えてください。

山口氏　商用環境のツール（CLASSICプラン）は頻繁にいじらないようにしたいので、検証用に小さいライセンス（STARTERプラン）も契約しています。Site24x7はすべてのプランですべての機能を使える上、とても低価格なプランがあるので自然とそういう発想になりましたね。

——日常的にはどのように活用されていますか？

山口氏　ユーザーは、先ほど話した我々開発チームの5名と運用チーム7名の計12名のチームです。Site24x7のTeams連携で、両チーム同時に閲覧できるチャネルで通知を受けます。一次受けは運用チームでやっていこう、開発チームはエスカレーション先としよう、そうやってタスク分けをしています。

私自身の話でいうと、今は通知を見てからホーム画面を見ることが多いです。

ホーム画面

ここで問題のある対象が、色違いで一番上に表示されるので、視覚的に分かり易いです。それをクリックして、その状態などを見にいきます。取得できる項目も多いので、実機を確認しなくてもシステムの状況を把握できるケースが多いです。

もうひとつはアラート画面です。24時間直近で、回復したものも時系列で載ってくるので、ここも見ています。

アラート画面

この標準のインターフェースがわかりやすいというのと、簡単に知りたい情報を確認できるというSite24x7の使い勝手の良さは、これまで使ってきた他の監視ツールと比較してもよいと感じているところです。

——障害を未然防止できたと言える例があれば教えてください。

山口氏　ユーザーに影響が出そうになったことがありました。サーバー監視でディスクの逼迫を検知したケースでした。寸でのところで見つけられて、事なきを得ました。これは効果ですね。

それ以外にも、ネットワーク機器に「障害が発生しているかもしれない」と気づけたケースなどもあり、これらも既に監視の効果として実感していますね。URL監視も始まったので、今後はそれでもシステムトラブルを拾って、ユーザー申告よりも早く気づけるという期待もあります。これまでは、ユーザーからの申告で把握していたことも少なくなかったので。

——運用をはじめてから気づいた良い点があれば教えてください。

山口氏　プロセスごとのCPU利用率が標準で取得されるので、高負荷プロセスをすぐに特定できると感じました。

以前は、調査の都度、その実機に入って状況を見るか、もしくは実機に詳細な情報を取るように仕掛けてデータを取り出し、それをグラフにするところまで手作業で実施したりしていました。導入後は、そういった手間を省けるようになりました。

そのほか、SQL Serverの毎秒書き込みページ数があるしきい値を超えた時に通知するといった監視もできます。他の監視ツールでは通常そこまで参照できないため、そうした機能も活用してみたいです。

——ありがとうございます。最後に、このインタビューの読者に一言お願いします。

山口氏　まずは、1カ月の無料期間に実際に触ってみることをおすすめします。使うとすぐに良さがわかると思います。私は実際に監視サーバーの構築、保守を実施している立場にいるため、今回のような細かい話になってしまいますが、最初はあまり細かく考えなくても問題ありません。