監視基盤の技術選定、最初の直感が3回ひっくり返った話

出発点：監視が「見に行かないと見えない」状態

障害の検知がユーザーからの問い合わせ頼みになっていました。HTTPが返ってきているか、エラーレートが跳ねていないか、そういった基本的な外形監視すら入っていないサービスが複数ある。

「監視を入れる」という判断自体は難しくありません。問題はどうやって入れるかです。

ここで最初に自分に課した制約がひとつあります。将来的に内部のメトリクス（RDS、ECS、SQSなど）も同じ画面で見たいというゴールを、選定の前提に置くことです。「まず外形監視から」は正しいアプローチですが、ステップ1の選択がステップ2以降を縛るかもしれない。それを意識しながら調べ始めました。

第1ラウンド：SaaSの料金を実際に調べたら、想定と違った

最初に「外形監視SaaS」の候補をピックアップしました。UptimeRobot、Hyperping、Instatus、Better Stack。どれも見かけの料金は安い。でも「10名のチームで使う」という条件で実際の料金ページを掘り下げたら、印象が変わりました。

見かけの価格と実態の乖離

Hyperpingは1〜5名なら$74/月ですが、6名以上になった瞬間に$199/月にジャンプします。「うちは5人以内だから$74で済む」とはなりません。10名で使う前提なら、いきなり最上位プランです。

Better Stackはさらにやっかいで、月額$29〜という表示が最低ラインに過ぎません。オンコール通知を受け取れる「Responder」のシートごとに課金が発生するため、10名全員がアラートを受け取れる構成にすると$290〜$340/月になります。「閲覧専用なら安くなる」と思うかもしれませんが、アラートを受け取れない人が出てきます。

InstatusはPro $20/月で無制限メンバー、という破格の条件がありますが、これはステータスページ寄りの製品で、監視機能の充実度は他と比べると落ちます。SSOが要件に入ると一気に$300/月になる点も注意が必要です。

UptimeRobotは追加シートが$1.5/月と安く、10名でも$40〜45で収まるのが現実的でした。

10名・50モニター・ステータスページ1つという条件で並べると、こうなります。

料金ページには「シンプルな価格設定」と書いてあることが多いですが、チーム利用の実態に合わせて試算すると全然シンプルじゃない、というのが正直な感想です。

第2ラウンド：「既存のJenkinsで自前構築」という選択肢

SaaSの価格が固まったところで、もう一方の軸として「Jenkins拡張」のコストを見積もりました。

うちではすでにJenkinsのマスターが稼働しています。毎朝コストやAPI利用状況を取得してオリジナルダッシュボードを生成し、Teamsに通知するという運用を別の用途でやっていて、そのJenkinsをそのまま使えます。

エージェントはスポットインスタンス（t3.medium、東京リージョン）を使っていて、1時間あたり$0.018。1日24回の監視ジョブを回すとして、1回あたりの実行時間を5〜10分程度と見積もると、月額$1〜2程度です。ランニングコストとしては実質ゼロに近い。

開発人件費を含めたTCOで比較する

ランニングだけ比較すると「Jenkinsが圧倒的に安い」ですが、ここで落とし穴があります。SaaSは導入が楽な分、Jenkins拡張より開発工数が少なくて済む。月額$40の差を開発工数の差で割ると、回収に5〜8年かかる計算になります。

ただし、これはPhase 1だけで見た場合の話です。

将来的に内部メトリクスを追加するPhase 2のことを考えると、構造が変わります。

外形監視SaaSを選んだ場合、Phase 2で「内部メトリクスが載せられない」という問題にぶつかります。そこで結局Jenkinsでダッシュボード基盤を作ることになり、Phase 1でサボった開発工数がそのままツケとして回ってきます。

全フェーズを通したトータルで見ると：

開発工数はほぼ同等、ランニングは桁違いに安い。この数字が出て「Jenkins拡張でいこう」という方針になりました。

プロジェクト計画書を作る：「重すぎた」最初の版

方針が固まったので、プロジェクト計画書を作り始めました。最初の版は丁寧に作りすぎました。閾値定義書、通知設計書、ページ設計書、ジョブ設計書、ダッシュボード設計書……フェーズごとに成果物ドキュメントを積み上げていく構成になっていました。

これはスキルの高いエンジニアが1人で動くという実態と合っていない。技術的な開発作業は楽観値よりさらに早く終わる可能性が高い。実際に時間がかかるのは他チームへのヒアリングや閾値の合意形成、他の業務との並行による中断と再開のコストのほうです。

「動くものを先に作り、運用しながら改善する」という方針に切り替えて、計画書を書き直しました。成果物は「コードそのもの」「エンドポイント/閾値一覧（スプレッドシート）」「運用メモ」の3つに絞る。工数も大幅に圧縮されました。

工数見積もりはレンジで持つ

単一値の見積もりは精度が甘くなりがちです。そこで楽観〜悲観のレンジで持つように変えました。

タスクの性質に応じてレンジ幅を変えています。設定・会議系は小幅、設計・定義系は中幅、開発・実装系は大幅。各タスクに「なぜブレるのか」の要因も書き添えました（例：「各サービスの現状に大きく依存」「閾値の合意形成に時間がかかりがち」）。

結果的にPhase 0〜3の合計は楽観37〜悲観66人日、スケジュールは3〜4.5ヶ月というレンジになりました。

第3ラウンド：PMレビューで見えてきた穴

計画書ができたので、シニアPMの目線でセルフレビューをかけました。そこで気になった点がいくつかあります。

重大な穴①：成功指標がない

「障害に早く気づけるようになる」という定性的な目標は書いてあるのに、「5分以内に検知できること」という数値がない。これだとプロジェクト完了時に成功か失敗かを判定できません。「感覚頼りの運用から抜け出す」ことを目的にしているのに、判断基準が感覚のままというのは自己矛盾です。

重大な穴②：監視間隔1時間では「人間より先に気づく」を達成できない可能性がある

計画書に「1時間おき」と書いていましたが、1時間間隔の監視では最悪59分間気づかないことになります。ユーザーからの問い合わせが平均30分以内なら、現状と変わらない可能性がある。

「なぜ1時間なのか」の根拠が書かれておらず、サービスの重要度に応じた間隔の差分けも検討されていませんでした。

重大な穴③：Jenkins SPOF の対策が弱い

計画書に「cron / 別経路のヘルスチェックで監視する」と書いてありましたが、「別経路って何？」という話です。Jenkinsが落ちたことに気づいて、誰が復旧するのか。Jenkinsが長時間ダウンした場合、監視データの欠損はどう扱うか。

監視基盤という「見張り番」の役割を、見張られる側と同じインフラに載せることへの構造的な弱点が、十分に対処されていませんでした。

この「監視間隔」と「SPOF」という2点は、技術選定の判断そのものを揺るがす指摘でした。

第4ラウンド：CloudWatch Syntheticsという選択肢が浮上

「監視間隔を短くしたい」「JenkinsのSPOFをどうにかしたい」という2つの課題を抱えたとき、Amazon CloudWatch Syntheticsというサービスを改めて調べました。

CloudWatch Syntheticsとは

AWS純正の外形監視サービスです。Canary（Node.js / Python のスクリプト）を定期実行し、エンドポイントの死活・レスポンスタイムを監視します。結果はCloudWatchメトリクスとして記録され、CloudWatch Alarms → SNS → Teams Webhookの経路で通知できます。

最大の特徴は最短1分間隔で実行できること、そしてAWSマネージドサービスなのでJenkinsのようなSPOFが発生しないことです。

コストを試算する

Canary 1回あたり$0.0012です。実際の構成で計算すると：

UptimeRobotの$40〜45と同水準か、間隔の設計次第でそれより安くできます。

「いいとこ取り」になりうる理由

外形監視SaaSとJenkins拡張の両方の弱点を同時に解消できる可能性があります。

さらに大きいのがPhase 2の軽さです。RDSやECSのメトリクスはCloudWatchに元々データがある。Syntheticsで外形監視を始めた後にPhase 2に進むとき、必要なのはCloudWatch Alarmsの設定を追加するだけで済む可能性があります。Jenkins拡張で独自スクリプトを書いていくよりもトータルの開発工数が一番軽くなりそうです。

2つのアプローチの検討

Syntheticsを使う場合、大きく2つの進め方があります。

アプローチD-1：Synthetics主軸

外形監視も内部監視もCloudWatchに一本化します。ダッシュボードはCloudWatch Dashboard、ステータスページはS3静的ページを別途構築します。Phase 2がほぼ設定作業だけになるのが最大のメリットです。

アプローチD-2：Synthetics + Jenkinsハイブリッド

外形監視はSyntheticsに任せ、ダッシュボードの生成と通知は既存のJenkinsを活かします。JenkinsはすでにHTML自動生成の仕組みを持っているので、その資産を捨てずに済みます。ただし「監視はSynthetics、ダッシュボードはJenkins」という二系統管理になることは許容が必要です。

ただし、確認が必要なことがある

CloudWatch Dashboardはエンジニア向けの運用画面として機能的ですが、「開発者とユーザーが同じ目線で見られるステータスページ」という当初のゴールを満たせるかどうかは、実際に作ってみないとわかりません。またCanaryはLambdaベースのスクリプトなので、Jenkinsのシェルスクリプトとは開発・デプロイの作法が変わります。チームのAWS経験値次第では学習コストも発生します。

ガントチャートを作る過程で気づいたこと

計画書にガントチャートを追加した際、依存関係を整理していくと面白いことがわかりました。

全体の工数は楽観37〜悲観66人日ですが、クリティカルパスは43日です。つまり並行して進められるタスクが23日分あります。逆に言えば、クリティカルパス上のタスクが1日遅れると、全体が1日遅れる。

各フェーズのボトルネックを整理するとこうなります。

Phase 2の「RDSフリーズ検知」は手法が未確立のため、これは開発タスクというより研究タスクです。タイムボックスを設けて「N日調査して実現可能性を判断する」というアプローチが必要で、場合によってはスコープを後回しにする判断も選択肢として持っておくべきだと気づきました。

また、冒頭に「全体の4フェーズ、9週間」を一目でわかるサマリーガント、次に全タスクの依存関係をフローチャートで可視化、その後に詳細ガントを配置するという「ズームイン」型の構成にしたところ、だいぶ読みやすくなりました。いきなり23タスクのガントチャートを見せると、全体像がわからないまま細部に引き込まれてしまいます。

「決める前に詳細を作りすぎない」という教訓

選択肢がA〜D（外形監視SaaS・統合型SaaS・Jenkins拡張・CloudWatch Synthetics）の4択になったとき、計画書の構成そのものを見直しました。

最初の計画書はJenkins拡張ありきで、フェーズごとの詳細なタスクブレイクダウンまで書き込んでいました。でもどの案を選ぶかがまだ決まっていない段階で、特定の案の詳細設計を作り込んでも、ひっくり返されたらすべて無駄になります。

計画書を「各案の概算工数比較と、Phase 0での検証方針」に絞って作り直しました。詳細なフェーズ計画は、案が決まってから作る。案Cの詳細計画は付録として残しましたが、意思決定の主役ではなくなりました。

概算の精度と精緻化のタイミング

現在の概算は±40〜50%の精度と捉えています。Phase 0で1サービス分を実際に動かしてみることで、次のことが判明します。

Phase 0完了時点で精度は±15〜20%に改善される見込みです。詳細計画はそのタイミングで作る、という設計にしています。

意思決定ドキュメントの温度感

計画書を何度か書き直す中で、もうひとつ気づきがありました。

最初の版は「推奨案はJenkins拡張です」「SaaSは現時点で候補外とします」という断定的な書き方をしていました。論理的には正しい。でもそれだと、読み手が「自分たちで考えた」という感覚を持ちにくくなります。

変えたのはトーンです。「調査の結果こういうことがわかりました、どう判断しますか？」という書き方にする。事実とデータを並べて、消去法の流れを作る。そうすると読み手が自分で「やっぱりDだな」と結論に至れる。

すっと体に入ってくる意思決定は、こちらが押し込んだものより、相手が自分で辿り着いたものの方が多い気がしています。

「どれがいいと思う？」と聞かれたときの答え方

計画書は中立に書いても、口頭で意見を求められることはあります。そのときのスタンスを決めておきました。

「案D（CloudWatch Synthetics）が最も合理的だと考えています。理由は3つです。AWSマネージドなのでSPOFがない、Phase 2以降でCloudWatchの既存メトリクスをそのまま使えるので開発工数が一番軽い、TCOも低い。ただし1点だけ確認が必要で、CloudWatch Dashboardの表現力が要件を満たすかどうかです。これはPhase 0で実際に作ってみないとわかりません。なので、Phase 0でまず案Dを試作して、ダッシュボードが許容範囲なら案Dで進め、不足なら案C（Jenkins）にフォールバックするという進め方を推奨します。」

ポイントは3つです。推奨を1つに絞る、弱点を自分から言う、ダメだったときの代替を先に示す。「A〜Dそれぞれに長所短所があります」では、意見を聞いた意味がない。

今どこにいるか

まだPhase 0（方式確定とPoC）の手前にいます。この記事自体が「選定プロセスの記録」であって、実装に入ったわけではありません。

CloudWatch Syntheticsを実際に触ってみた後、また記録を残そうと思います。

参考書籍

監視基盤の設計や技術選定をさらに深く学びたい方には、以下の書籍が参考になります。

監視設計の体系的な知識

SREの考え方と実践

AWS運用の基礎知識