あなたのクラウドコンソールは緑色です。アラートは静かです。そしてサポートキューにはログインできない顧客が溜まっています。
その組み合わせは多くのチームが認めるよりも一般的で、通常は設定ミスではありません。クラウドネイティブな監視はレポート対象のインフラ内で実行されるため、そのインフラが不調の日には、その自己テレメトリが独立した答えを提供する最後の場所となります。
もし今クラウドインフラ監視ツールを比較しているなら、そのギャップが機能マトリックスよりもショートリストを決めるべきです。以下に、提供者の監視が何を見えて何を見えないか、実際に起きた障害に対してベンダーをテストする方法、そしてチームが約6ヶ月後に驚く価格条件を解説します。
このガイドの内容
- なぜクラウドプロバイダーの監視は障害を検知できないのか
- クラウドネイティブ監視が実際に測定するもの
- クラウドダッシュボードで緑のまま表示される3つの障害
- クラウドインフラ監視ツールの評価方法
- ショートリストテストに含めるべき指標
- クラウド監視の料金でチームが引っかかるポイント
- ベンダー面談で毎回尋ねるべき質問
- クラウドインフラ監視の結論
- よくある質問
なぜクラウドプロバイダーの監視は障害を検知できないのか
すべての監視システムには視点があります。あなたのプロバイダーの視点は自社のネットワーク内にあります。
まず定義です。ここでいうクラウドネイティブ監視とは、プラットフォームにデフォルトで付属するリソースメトリクスとアラームを指します—Amazon CloudWatch、Azure Monitor、Google Cloud Monitoring—提供者がそれらと共に販売するすべての可用性機能ではありません。
これらのデフォルトは有用です。CloudWatchはインスタンスがCPU100%に張り付いていること、Auto Scalingグループが容量を追加したこと、データベース接続が枯渇していることを知らせます。本物のシグナルなので、それらの収集は続けてください。
しかしチェックはプロバイダーのコントロールプレーン内で、プロバイダーのネットワーク経由で、プロバイダーのAPIに対して実行されます。もしコントロールプレーンが劣化すれば、メトリックパイプラインもそれに伴って劣化します。そして遅延したメトリクスはダッシュボード上では正常なメトリクスとまったく同じに見えます：アラームは鳴りません。アラームをトリガーするデータが届かないからです。
この第二の制限は顧客向けサービスにとって特に重要です。これらのデフォルトメトリクスはあなたのリソースを測っており、サンパウロのユーザーとus-east-1のロードバランサー間の経路は測りません。DNS解決、BGPルーティング、CDNエッジ挙動、TLS交渉、第三者スクリプト、WAFルール―これらはすべてその境界の外側にあり、それらのいずれかがサービスをダウンさせてもCPUやメモリは変わらないことがあります。
障害ドメインの内部にある監視システムは、そのドメインが壊れていることを最後に知らせるシステムです。
でもCloudWatch Syntheticsはすでにこれをやっているのでは？
部分的にはそうで、この反論は本気で考慮すべきです。主要なプロバイダーは皆何らかの形でこの機能を販売しています：CloudWatch Syntheticsのカナリア、Route 53のヘルスチェック、Azure Monitorの可用性テスト、Google Cloudのアップタイムチェック。これらは実際にエンドポイントにリクエストを送信し機能します。
問題はそれらがどこから実行されるかです。これらのチェックは同じプロバイダーのインフラ上で実行され、同じコンソールに結果を投稿します。プロバイダーのリージョン外のカバレッジは薄く、広範な地域イベントがチェックとワークロードの両方に影響を与える可能性もあります。有用なツールですが独立したツールではありません。
独立性こそが本当の要件で、それをベンダーに問い返すのは正当なことです。多くのサードパーティの監視サービスも主要クラウド上で動作しています。ですのでチェックの場所を尋ねてください：複数プロバイダーとキャリア運営ノードにまたがるネットワークなのか、それともすでに使っているクラウドの3つのレンタルリージョンなのか。Dotcom-Monitorはリージョンを借りるのではなく自身のグローバル監視ネットワークを運営しているため、チェックが意味を持ちます。
あなた自身でこの仕組みを作ることも可能です。Prometheus Blackbox Exporterはエンドポイントをプローブします。1〜2箇所の視点であればそれも妥当な答えです。しかし必要な地域が数十に増え、リアルブラウザによるレンダリングが必要で、しかもプローブ自体のオンコール対応者が必要となればコストが上がります。
いずれにせよ、チェックは監視対象のシステム外から実行してください。合成監視はあなたが設定したスケジュールで公開インターネット経由でリクエストを送ります。もし一つでも失敗すれば、顧客からではなくチェックから通知が届きます。
クラウドネイティブ監視が実際に測定するもの
レイヤーごとに分けるとこうなります。現在のカバレッジと照らし合わせてからベンダーと話してください。
| レイヤー | デフォルトのクラウドメトリクス | 独立した外部チェック |
|---|---|---|
| インスタンスのCPU、メモリ、ディスク | あり、詳細も可 | なし |
| マネージドデータベース及びキューの健全性 | あり | 間接的に、アプリ挙動を通じて |
| オートスケーリングとデプロイイベント | あり | なし |
| パブリックDNS解決 | 部分的、VPC内から | あり、世界中の実際のリゾルバーから |
| エッジでのTLS証明書の有効性 | 部分的 | あり |
| ユーザーへのネットワーク経路とルーティング | なし | あり |
| CDNとエッジキャッシュの挙動 | なし | あり |
| 完全なログインまたはチェックアウト経路 | なし | あり |
| サードパーティAPIとスクリプトの障害 | なし | あり |
どちらの列も互いに代替しません。あなたのプロバイダーのツールは何か異常があることがわかった後の原因解析には最適な計測器です。外部チェックは何かがおかしいと最初に教えてくれ、プロバイダー自身のパイプラインが停滞した時も報告し続けます。弊社のインフラ監視の対象範囲についての投稿がリソースレベル側をより詳細に解説しています。
両方を使いましょう。予算も両方分を見込んでください。
クラウドダッシュボードで緑のまま表示される3つの障害
これはパターンであり、ケーススタディではありません。AWS、Azure、Google Cloud上で数年運用すれば、少なくとも一つは見覚えがあるでしょう。
ユーザーの半数で壊れたDNSレコード
誰かが移行中にレコードを更新します。権威DNSサーバー上では変更は正しいため内部チェックはすべて通過します。しかし古いエンドポイントは前のTTLが切れる前に廃止され、世界中の再帰リゾルバーは古いアドレスをキャッシュし続け、期限切れまで古いアドレスを返し続けます。あなたのトラフィックの一部はもう応答しないものを叩き続けます。
あなたのインスタンスは健康です。ロードバランサーもトラフィック減を確認しつつ異常は報告しません。これを検知するには、複数の地域から実際のクライアントのように外部から名前解決を行う必要があります。これがDNS監視の役割であり、リゾルバーの場所が評価に重要な理由です。
ロードバランサーで期限切れになった証明書
今は自動更新なので、壊れても静かに失敗します。ジョブが壊れて誰も気付かず、リスナーまたはCDNエッジの1箇所で証明書が期限切れになります。
背後のインスタンスは正常です。CPUも問題ありません。アプリケーションログはリクエストの減少を示しエラーは出しません。一方でブラウザは全ての訪問者に中間警告を表示します。外部からチェーンを辿るSSL証明書監視が数週間前にこれを検知します。
通常稼働とマークされたリージョン
プロバイダーのステータスページは通常、内部確認を待って色が変わります。これは何百万もの顧客に対する誤報を避ける合理的な方法ですが、同時にインシデントよりも遅れる傾向にあります。多くのチームはダッシュボードが黄色に変わる前にエラーを目撃します。
もしあなたのインシデント対応がステータスページ待ちなら、検知時間を誰か他のレビューに渡していることになります。独立チェックはあなた独自のタイムラインを提供します—インシデント中も、SLAと照合するための事後もです。それが稼働率およびSLAレポートを信用に足るものにします。
クラウドインフラ監視ツールの評価方法
多くのベンダー比較は機能をランキングします。これはほとんど役に立ちません—機能リストは似通っており、その半分は別ブランドで同じ機能を記述しています。代わりに自分の障害を使ってテストしてください。
ステップ1：実際に経験した直近5件のインシデントを書き出す。メモリではなくチケットシステムから抽出し、どのように発見したかを記録してください。複数件顧客からの発見なら、ダッシュボードの問題ではなく検知の問題です。
ステップ2：ベンダーがどこからチェックを実行しているか調べる。回数ではなく場所のリストを聞き、その所有者も尋ねてください。北米・西欧に30箇所集まっていても東南アジアのユーザーへの意味はありません。既存クラウドのリージョンを借りているだけだと地域障害時に役立ちません。
ステップ3：トップページのピングではなく多段階の操作をテストする。トップURLの200 OKはほぼ意味がありません。ログイン、検索、カート追加、スコープ付きテスト資格情報で認証されたAPI呼び出しをスクリプト化してください。ステータスコードチェックはどんなテストでも通りますが、あなたに損害を与える障害を見逃します。EveryStepスクリプティングは記録された操作経路に対応します。
ステップ4：トライアル中に意図的に何かを壊す。コントロールしているステージングホスト名にチェックを向けて、DNSレコードを引き下げるかハード500を返してください。アラートの時間と内容を確認してください。トライアルで最も有用な1時間です。
ステップ5：目が覚めるようなアラートとして読み取る。失敗したステップ、場所、エラークラス、応答時間が示されていますか？それとも「サイトダウン」ですか？この違いがオンコールエンジニアが午前2:04に修正開始か調査開始かを決めます。アラート連携がPagerDuty、Slack、Teams、Webhookなど既存ツールに対応しているかを確認してください。
ステップ6：内部システムへの連携も確認。管理パネル、内部API、ステージング、VPNの背後など公開されていないシステムが多いです。公衆インターネットしか見えないツールでは2つ目を購入する羽目になります。プライベートエージェントはネットワーク内からチェックし同じコンソールに報告します。
ステップ7：翌年の規模で請求額をモデル化。現在のチェック数を倍にし、実際に運用したい間隔で計算し、それを文書で依頼してください。
ショートリストテストに含めるべき指標
可用性割合は経営層向け資料に載りますが評価中は最も役立たない数値です—稼働率の数字はあなたが気にする障害を打ち消します。代わりに以下を求めてください：
- 検知時間。障害発生からアラート到着までの分数。これが購入の正当化となる数字です。
- 地域別応答時間。グローバル平均ではなく地域ごとのp95。遅い市場を隠しません。
- レイヤー別エラー内訳。DNS、TCP、TLS、HTTP、コンテンツアサーション。レイヤー名を示さず「失敗」とだけ報告するツールは解析をあなたに戻します。
- 障害確定動作。アラート発火に必要な同意場所数と速度。緩すぎればノイズ、多すぎれば遅延。
- 生のチェックデータの保持期間。報告はサマリーで十分ですが、事後レビューには個別チェックが必要です。
分散バックエンドはこれを複雑にします—依存関係は部分的に故障し症状は移動します。分散システムの監視ガイドが詳述しています。
クラウド監視の料金でチームが引っかかるポイント
監視費用は監視対象のインフラ以上に速く膨らむ傾向があります。次の点に注意してください：
オートスケーリング環境でのホストあたり課金。監視ホスト単位で課金され、トラフィックに応じてフリートが拡大すれば費用も跳ね上がります。揮発インスタンスのカウント方法と期間を尋ねてください。
カスタムメトリクスと高カードリナリティのタグ。クラウドネイティブ監視は通常、カスタムメトリクス1件あたり月額課金です。顧客IDやコンテナIDなど高カードリナリティなタグを追加すると、意図せずに数が爆発的に増えます。
取り込み、保持、ユーザー数、SMS。ログ量は減らないため、各階層の境界でどうなるか、保持料金が取り込みと別かチェックしてください。プラットフォームによってはユーザー数でも課金し、サポート担当者に読み取り権限を与えるだけで予算の問題になります。SMSや音声アラートは別途メーターリングするところもあります。
チェック頻度。実行ごとに課金するベンダーなら、5分間隔から1分間隔に変えるとコストは5倍になります。計画階層により実行回数をバンドルしたり上限を設けるところもあり多様ですが、無料ではなく、短時間障害を捕捉できるかどうかを左右します。実際に使う頻度でサービスごとに価格を計算してください。Dotcom-Monitorの価格設定はチェック単位かつ間隔単位なので、最初から計算しやすいです。
合計額を自身のサービスのダウンタイムのコストと比較してください。多くのチームにとって監視費用は1時間の大きな障害に比べれば小さいものですが、更新時の交渉前に比較を文書化しましょう。
ベンダー面談で毎回尋ねるべき質問
デモに持参してください。回答はツールの選別を速めます：
- チェックロケーションの所有者は？自社ノード、キャリア施設、AWS／Azure／Google Cloudから借りているリージョン？
- チェックは実ブラウザかHTTPクライアントか？それがキャッチするものにどう影響する？
- OAuthやSSOが必要なエンドポイントはどう監視している？
- 何ヶ所が障害を起こすとアラートが上がる？調整は可能？
- 生のチェック結果はどの程度保持している？エクスポート可能？
- チェック数2倍、間隔半分にしたら請求額はどうなる？
ベンダーの安定性、サポート、契約条件など広範な選定プロセスは別途監視プラットフォーム選定ガイドラインにまとめています。
クラウドインフラ監視の結論
プロバイダーの監視は維持してください。リソースレベルの診断に最も優れたツールであり、すでに展開済みで基本メトリクスは計算資源に付随しています。カスタムメトリクスやログ、保持のコストには注意しつつも使い続けましょう。
ただし障害検知にだけは使わないでください。システム内部からレポートし、デフォルトメトリクスはネットワーク経路、パブリックDNS解決、エッジ証明書、顧客が依存するログイン経路を見ません。これらが最初にあなたのサポートキューに届く障害なのです。
有効な評価は短期間で済みます：過去の実際のインシデントを書き出し、その障害に対して候補製品をテストし、トライアル中に何か壊し、実運用する構成で価格を計算する。もし最後の5件の障害を5分早く検知できるツールなら自己回収しています。
外部チェックが何を捉えるか見てみよう
Dotcom-Monitorはあなたのクラウドインフラに対し、グローバルネットワークのロケーションから実ブラウザおよびプロトコルチェックを実行し、ファイアウォールの背後向けにはプライベートエージェントも提供します。無料トライアルを開始し、最も不安なサービスにチェックを向けてみてください。
インフラ監視を探るか、ウェブアプリケーション監視をご覧ください。
