はじめに

平素は大変お世話になっております。
クイックガードのパー子です。

Webサービスを立ち上げたら真っ先に導入したい監視項目の 1つに、URL監視が挙げられます。

URL監視とは、その名のとおり URL に対して監視リクエストを飛ばし、そのレスポンスの中身や応答時間を見てサービスの状態を判断する監視手法のことです。
(「外形監視」や「Synthetic Monitoring」と呼ばれることもありますが、人によって異なる意味で使い分ける場合もあるので注意が必要です。)

サービスの安定稼働のためにはいろいろな種類の監視が必要ですが、小規模なサービスでは包括的な監視体制を組む余力がないケースも多いでしょう。
そのような場合でも、URL監視は「サービスをユーザに提供できていない」という重大な障害を直接的に検知できるコストパフォーマンスのよい監視項目なので、なにはなくともこれだけは最優先で入れておきたいものです。

一方で URL監視の導入方法には多数の選択肢があり、いずれも特色があるため、どの方法を選んだらよいかわからない… とお悩みの方も多いのではないでしょうか。

そこでこの記事では、URL監視を導入するにあたって代表的な選択肢と考慮すべき点、選び方の指針を紹介します。

URL監視を取り巻く状況

HTTP、SMTP、DNS や TCP、ICMPなどの各種レイヤーのプロトコルに対応した監視ツールや SaaS は多くありますが、この記事では特に HTTP に着目します。

一昔前は単純な死活監視のための仕組み (= 例えば、一定間隔で応答時間と HTTPステータス・コードを見るだけ、など。) のみを備えたプロダクトが多かったのですが、最近は柔軟なシナリオで詳細なメトリクスを収集し、パフォーマンスの問題を深く分析できる高機能なものが増えたように思います。

特に CI/CDパイプライン や APM (= Application Performance Monitoring)、分散トレーシングとの連携機能、カスタム・スクリプトによるヘッドレスWebブラウザの自動操作機能を備えた SaaS が目立ち、それらは漏れなく (つぶさに調べたわけではないので個人的な感覚ですが) サービス名に「Synthetic」を冠している印象です。
これはつまり Webサービスの監視レベル で規定されるうちの Level 4相当であるという表明なのでしょう。

  • Level 1　Uptime Monitoring – Availability of a Critical Page
  • Level 2　Transaction Monitoring – Availability of a Critical Process
  • Level 3　Performance Monitoring – Performance of a Critical Page
  • Level 4　Synthetic Monitoring – Performance of a Critical Process
  • Level 5　Customer Journey Monitoring – Level 1 to 4 plus Security Information

「Synthetic = 合成」と呼ばれる所以は、フロントエンドのパフォーマンス計測のコンテキストでよく対比される RUM (= Real User Monitoring) が実際のトラフィックを観測するのに対し、固定されたラボ環境下でツールによって生成される疑似的なトラフィックを利用するという意味だと推測されます。
(調べてみたものの Synthetic Monitoring と呼ばれ始めた経緯がわからなかったので、ご存知の方は是非ご教示いただけますと幸いです。)

このように、一口に URL を監視すると言っても、「原始的な死活監視」と「パフォーマンス計測」に二極化しているのがこの領域の現状です。

選択肢

URL監視の導入方法には 3つの選択肢があります。

SaaS

1つ目の選択肢は SaaS です。

クラウドの登場以前は自前で監視システムを構築するのが主流でしたが、近年は各社から多種多様な SaaS が提供されています。

SaaS のメリットは、素早く導入できて運用の手間がかからないことです。
ただし、事業者都合の強制メンテナンスが発生した場合、その間は監視機能が制限されることもあるので注意が必要です。

多くの SaaS が存在し、サービスごとに特色があるので、用途に合ったものをよく吟味しましょう。

系統としては大別して以下の 4つに分けられます。

お手軽 (特化) 系

死活監視のための URL監視に特化したサービスで、単機能ですが簡単に導入できることが特徴です。

シンプルな操作感で設定項目も多くはないため、操作にとまどうことなく使い始められるでしょう。
無料プランでも充分に実用的な死活監視を実現できます。

お手軽 (クラウド・プロバイダ) 系

クラウド・プロバイダによって提供される、簡易的な死活監視を目的としたマネージド・サービスです。

監視対象が当該クラウド内のサーバである場合に特に有用で、例えばさくらのシンプル監視ならば以下の場合に無料となります。

監視対象がIPv4アドレスかつ、弊社サービス(さくらのVPS、さくらの専用サーバ等)で提供するグローバルIPアドレスの場合

統合監視サービス系

オールインワンの監視ラインアップの 1つとして URL監視機能を提供しているサービスです。

同社の他サービスとの連携が容易な点や、監視機能を 1か所でまとめて管理できる点が魅力です。

Mackerel は 株式会社はてな が開発する統合監視サービスで、CRE (= Customer Reliability Engineer) による充実したサポートが期待できます。

Synthetics系

従来の死活のみを目的とした URL監視に加えて、高度なパフォーマンス計測や挙動の記録を可能にするものです。

運用フェーズの「監視」に留まらず、開発からデリバリーにわたって継続的な「計測」を実現します。

New Relic、Datadog は監視サービス大手であり、Synthetic Monitoring以外にも多くのプロダクトを提供しています。

CloudWatch Synthetics は AWS の監視サービスのブランドである CloudWatch の 1機能で、2020年に一般公開 された比較的新しいサービスです。

自前構築

2つ目の選択肢は、自分でサーバを用意して、OSS や商用製品の監視ツールをインストールする方法です。

OSS なら求める要件に合わせて自由にカスタマイズでき、一方、商用製品なら (一般的にサポート費用込みの価格設定であるため) 手厚いサポートを期待できますが、その反面、自分で運用しないといけない点は大きなデメリットです。
「監視システムの障害でサービス異常を検知できない」などということがあってはならないため、なによりも可用性の確保が重要です。

Nagios や Zabbix は長い歴史があり、また、Prometheus はコンテナ環境の監視ツールとしてデファクト・スタンダードとなっているため、運用するうえでの知見が豊富に蓄積されています。

MSP

最後の選択肢は MSP の利用です。

MSP とは Managed Service Provider の略で、システムの管理や監視などの運用業務を請け負う事業者のことを指します。

顧客に代わって監視設計から障害時の一次対応まで丸ごと引き受けるのはもちろんのこと、以下のような付随サービスも提供します。

  • ベンダーやクラウド・プロバイダへの問い合わせ代行
  • システム健全性に関する定期的なレポート
  • システム安定化のための改善提案
  • システム障害の予兆を検知した時点でのプロアクティブな予防措置

MSP の最大の特長はその柔軟性にあり、MSP独自の監視ツールと 24時間365日の有人対応により、顧客ごとにカスタマイズされた監視体制を敷くことができます。
それゆえ、複雑な判断要件が存在し、有人による臨機応変な対処を求められるシステムで最適な選択肢と言えます。

特に考慮すべき項目

世の中には多くの SaaS、ツール、MSP が存在します。
「一定間隔で監視リクエストを飛ばしてレスポンスをチェックする」という基本は変わりませんが、それぞれの特色があるので、自分のユースケースに合っているものを選ぶのが大事です。

以下、選定にあたって特に考慮すべき点をいくつか列挙します。

何を監視するか

まず、どんな目的でどんなメトリクスをどんなトリガーで取得したいのかを決めたいところです。

単に死活を監視したいだけなら HTTPステータス・コードや応答時間、レスポンスの中身を定期的に取得できればよいでしょうし、開発プロセスと統合して継続的にパフォーマンスをモニタリングしたいなら詳細な性能メトリクスを柔軟なトリガーで収集して、場合によってはスクリプトでテスト・シナリオを定義できたりしたほうがよいでしょう。

最初にこのような要件を明らかにすることで、膨大な監視ソリューションの選択肢を特定の方向性で絞り込むことができます。

なお、「単純な死活よりももう少し深く監視したいが、どのメトリクスを見たらよいかわからない…。」という場合は Apdex (= Application Performance Index) や The Four Golden Signals、REDメソッド などの切り口が参考になるでしょう。

予算

予算が最大の制約要因になることも多いでしょう。

無料で導入できる SaaS や OSS がある一方、当然ながら高機能、高分解能のプラン/製品は相応の価格が設定されています。

監視プロダクトそれ自体の利用/購入価格だけでなく、監視体制を維持、運用してインシデントに対処する人的コストまで含めて考慮する必要があります。

監視サーバのロケーション

どこから監視リクエストを飛ばすのかも気にしないといけません。

世界中で利用される Webサービスの場合は、どの地域からも正常にアクセスできていることをチェックするために、グローバルな複数の拠点から監視リクエストを飛ばして多面的に正常性を監視するのが望ましいです。

ローカルな Webサービスであっても監視システムを自前構築した場合は注意が必要で、最低でも監視対象のサービスとは物理的に離れた位置に監視システムを構築したいものです。
(同一拠点に構築してしまうと、拠点レベルの障害が発生した場合に監視システムまでダウンしてしまって、障害を検知できないおそれがあるためです。)

選び方の指針

以上を踏まえて、最適な監視ソリューションの選び方について指針を紹介します。

大前提

まず大前提として、よほどの事情がない限り OSS や商用製品を用いて自前で監視システムを構築、運用するのはオススメしません。

監視システムのアーキテクチャは年々複雑化しており、また、高い可用性が求められるため、要所の冗長化は必須です。
構築と維持には専門性とコストが必要となるため、気軽かつ安価に SaaS を利用できるようになった現代においては SaaS を第1候補に考えるべきでしょう。

無料で小さく始めたい

  • 予算が少ない。
  • 最低限の死活監視ができていればよい。
  • 何をしたらよいかわからない。

このような場合は SaaS のお手軽系から始めてみるのがよいでしょう。

初めて導入するなら特化系を。
何らかのクラウド・プロバイダを利用しているなら当該プロバイダが提供する監視サービスを調べてみましょう。
(ただし、クラウド・プロバイダのレベルで障害が発生した場合でも検知できように、監視対象のワークロードとは独立した場所から監視していることは確認しておきたいです。)

無料プラン、または利用量に応じた従量課金で小さく利用を開始して、Webサービスの拡大に追随して監視も充実させていくことができます。

URL以外もまとめて監視したい

URL監視だけでなく、サーバのリソース負荷やプロセスの状態、内部ネットワークのトラフィックもまとめて監視したい場合はオールインワンの統合監視サービス系がよいでしょう。

複数の監視ツールを行ったり来たりしてシステムの健全性を確認したり、同じような設定 (特にメンバーの権限管理やアラート設定) を入れて回ったりしなくて済むので、運用負荷の軽減が期待できます。

パフォーマンスを継続的に監視したい

Webサービスのパフォーマンスを継続的に計測し、一定の性能を維持するための指標としたいなら Synthetics系がよいでしょう。

特に開発からリリースの各段階で頻繁に計測を実行して、指標の劣化があれば早期に対処することが望ましいので、CI/CD への組み込みやすさやスクリプトによるブラウザの自動操作機能の有無が重要になります。

APM と連動してフロントエンドからバックエンドまで一気通貫で計測結果を統合して表示してくれるプロダクトもあるので、より深く計測したいならそのようなものを選ぶとよいでしょう。

既成のものでは合わない

SaaS や商用製品では監視要件を満たせない場合は、OSS の監視ツールを改造して自分で運用することになります。

  • 運営する Webサービスの規模が大きすぎて、SaaS を使うと予算内に収まらない。
  • 業界標準や法規制により SaaS を使えない。
  • 特殊なネットワーク構成のため SaaS を使いづらい。

ただし、改造の難しさや運用の手間がネックになるので、どうしても既成のプロダクトが合わない場合のみこの手段を採用するべきでしょう。

どれも難しそう

  • 本業に注力したいので、監視周りを丸投げしたい。
  • 自分たちの Webサービスに合う監視ソリューションがよくわからないので相談したい。
  • というか、何もかもわからないので監視実現のための筋道を立てるところから手伝ってほしい。

このような場合は MSP をオススメします。

弊社クイックガードはお客さまの抱えている問題に応じて、実動からコンサルティングまで幅広く柔軟なご支援を提供します。
お気軽にお問合せください。

まとめ

Webサービスの運用に欠かせない URL監視について、その現状と、導入方法の主な選択肢として SaaS、自前構築、MSP の 3つを見てきました。

続いて、選定するうえで特に注意したい点として、監視の目的 (= 何を監視したいのか？)、予算、監視システムのロケーションの 3点を挙げました。

最後に、それらを踏まえて、どのようなケースでどの選択肢を採用すべきか、選び方の指針を紹介しました。

  • まずは SaaS を第1候補に、用途に合わせて系統を選択。
  • 特殊な監視要件がある場合は OSS をカスタマイズして自分で監視システムを構築。
  • 困ったら MSP に相談。

この記事が URL監視導入のお役に立てば幸いです。
今後ともよろしくお願い申し上げます。