なぜ単一拠点の監視では不十分なのか

監視を1つの地理的拠点だけで実行している場合、まるごと見逃してしまう障害があります。

シナリオ: 米国データセンターがダウン

米国にある監視も同時にダウン (同じインフラに同居しているため)
顧客もサポートチームも障害を確認しているのに、監視は「すべて正常」と表示
監視が復旧してインシデントを報告する頃には、顧客はすでに競合に乗り換えています

シナリオ: リージョン単位のCDN障害

サービスは米国とヨーロッパでは稼働中
しかしアジア太平洋のCloudFlareエッジが障害
米国拠点の監視はこれを検知できません
アジアの顧客は2時間サイトにアクセスできない状態
サポートチケットが殺到して初めて気付くことになります

シナリオ: ISPルーティングの障害

サイトはどこからでも稼働しているが、米国のVerizonの顧客だけはアクセス不可
単一拠点の監視ではこれを見逃します (顧客とは別のISPを使っているため)
Verizonユーザーがサポートに不満を訴えてくる
あなたは「ユーザー側のネットワーク問題」と思い込み、本当は検知できたはずのルーティング問題に気付きません

マルチリージョン監視とは

マルチリージョン監視とは、複数の地理的拠点から同時にインフラをチェックすることを指します。

あなたのインフラ (US East)
    ↑
    ├─ チェック元: 米国 (バージニア)
    ├─ チェック元: EU (フランクフルト)
    ├─ チェック元: APAC (シンガポール)
    └─ チェック元: ブラジル (サンパウロ)

1つでもリージョンから到達できなければ、それは実際の問題です。すべてのリージョンが失敗していれば、自社インフラの問題です。一部のリージョンだけが失敗していれば、地域的な問題 (ISP、CDNなど) です。

検出できるリージョン障害の種類

1. CDNエッジ障害

CDN (CloudFlare、Akamai、Fastly) は各リージョンにPoP (拠点) を持っています。1つが障害になると:

東京エッジがダウン → アジアのトラフィックがセカンダリへ迂回 (低速化)
Nova Uptimeのマルチリージョン監視がレイテンシ増加を即座に検知
顧客からの苦情が届く前にCDNサポートに連絡できます

2. ISPルーティングの問題

ISPはときどきトラフィックを誤ってルーティングしたり、輻輳を起こしたりします。

VerizonのBGP設定ミス → Verizonの顧客が到達不可
Vodafoneの輻輳 → 欧州顧客が10倍のレイテンシを体感
単一拠点の監視ではこれを完全に見逃します

3. リージョンデータセンターのダウン

グローバルにデータセンターを持つ場合:

米国データセンターの障害は、EU/APACから検知すべき (異なるインフラのため)
「監視まで一緒にダウンする」状況を防げます
部分障害も検知できます (3つのうち1つがダウンなど)

4. リージョンごとのレイテンシ劣化

パフォーマンスは地理によって変化します。

平常時: US=50ms、EU=80ms、APAC=120ms
問題発生時: US=50ms、EU=80ms、APAC=800ms
リージョン監視がAPACの遅延を検知し、すぐに調査を開始できます

5. ジオフェンシング / DDoS対策

攻撃の中には特定のリージョンを狙うものがあります。

攻撃者が欧州のISPを攻撃 → EU監視が高レイテンシを検知
米国監視は正常を表示
これがリージョン特有の事象であり、グローバルなインフラ障害ではないと判断できます

マルチリージョン監視のセットアップ方法

ステップ1: 監視拠点を選ぶ#

最小構成 (3リージョン):

北米 (US East か West Coast)
ヨーロッパ (英国かドイツ)
アジア太平洋 (シンガポールか東京)

包括構成 (6リージョン以上):

US East
US West
ヨーロッパ (フランクフルト)
ヨーロッパ (ロンドン)
アジア太平洋 (シンガポール)
アジア太平洋 (東京)
オーストラリア (シドニー)
南米 (サンパウロ)

判断のフレームワーク:

顧客が米国のみ → 2リージョン (East + West)
顧客が米国 + ヨーロッパ → 3リージョン (US + EU + APAC)
真にグローバルな顧客基盤 → 6リージョン以上
99.99% SLAのSaaS → 最低5リージョン

ステップ2: リージョンごとに監視を設定#

ほとんどの監視ツールではリージョンを選択できます。

ドメイン: example.com
リージョン: [US-East ✓] [US-West ✓] [EU ✓] [APAC ✓]
チェック間隔: 1分 (各リージョンで独立)
アラート条件: 2つ以上のリージョンが失敗 もしくは レイテンシ > 1000ms

重要な設定: アラートのしきい値 — 何リージョンが失敗したらアラートを発火させるか?

厳格 (1リージョンの失敗): あらゆる問題に敏感、誤検知が増える
バランス型 (2リージョン以上の失敗): 本当の問題を検知、単一ISPの一時的な不調は無視
緩い (全リージョンの失敗): グローバル障害のみ検知

ステップ3: 重大度に応じたアラートのルーティング#

シナリオごとにルールを変えましょう。

シナリオ1: 1リージョンが失敗
  → オンコールに通知 (リージョン単位の顧客影響の可能性)

シナリオ2: 2〜3リージョンが失敗
  → オンコールに即時通知 (インフラの問題)

シナリオ3: 全リージョンが失敗
  → オンコールに通知 + インシデント対策室を起動

ステップ4: リージョンごとにレイテンシを監視#

応答時間は地理によって変わります。リージョンごとにしきい値を設定しましょう。

US (目標 &lt; 200ms): > 500ms でアラート
EU (目標 &lt; 300ms): > 700ms でアラート
APAC (目標 &lt; 500ms): > 1000ms でアラート

単一のグローバルしきい値は使わないでください — 地理は重要です。

マルチリージョン監視でよくある間違い

間違い1: 監視をインフラと同居させる#

❌ 誤り: インフラが米国。監視も米国。
   結果: データセンターが落ちると、監視も一緒に落ちる。

✅ 正解: インフラが米国。監視は US + EU + APAC から実行。
   結果: EUとAPACが米国の障害を検知できる。

間違い2: 誤検知が多すぎる#

❌ 誤り: どんな理由でもリージョンが失敗したらアラート
   結果: 1日に50件の誤アラート (顧客は競合に乗り換え)

✅ 正解: 2リージョン以上が失敗 もしくは 同一リージョンで3回連続失敗したらアラート
   結果: 本当の問題のみ通知

間違い3: レイテンシの傾向を理解していない#

❌ 誤り: 全リージョンに同じSLA (応答 &lt; 200ms)
   結果: APACで常時アラート (距離による自然な遅延)

✅ 正解: 地理を考慮したSLA (APAC &lt; 800ms)
   結果: 物理的な事実ではなく、本当の問題を検知

間違い4: CDN障害を無視する#

❌ 誤り: オリジンサーバーだけを監視
   結果: CDNがダウンしても監視は「稼働中」、顧客には503が表示

✅ 正解: CDN経由で監視 (公開URL + CDN経路でテスト)
   結果: CDN障害を検知できる

間違い5: リージョンデータを相関させない#

❌ 誤り: 各リージョンのアラートが独立、相関なし
   結果: リージョン問題かインフラ障害か判別不能

✅ 正解: アラート相関: US-Westだけ失敗、US-East + EU + APACは稼働中なら、
   それはUS-West固有。すべて失敗ならインフラ障害。
   結果: 根本原因の特定が高速化

ケーススタディ: Stripeの地域障害 (2023年)#

StripeはEUで30分間の地域障害を経験しました。

米国の監視: すべて緑 (正常)
EUの監視: すべて赤 (障害)

何が起きたか:

Stripeのフランクフルトデータセンターでルーター設定ミスが発生
米国インフラには影響なし
EUの顧客は決済処理ができない状態に

もしStripeが米国拠点の監視しか持っていなかったら:

EUの取引が30分間消失
EU顧客はStripeを「信頼できない」と感じる
「Stripeダウン?」という問い合わせがサポートに殺到

マルチリージョン監視があれば:

問題を即座に検知
フランクフルト固有と判明
フランクフルトのインシデントプロトコルを起動
2分でルーター問題を特定
5分でセカンダリデータセンターへトラフィックを切り替え

Nova Uptime のマルチリージョン監視#

Nova Uptime はマルチリージョン監視に対応しています。

機能:

4以上の地理的リージョンから同時に監視
リージョン別の応答時間トラッキング
リージョン別のアラートしきい値
ダッシュボードでリージョンごとの稼働状況を表示
インシデント履歴で影響を受けたリージョンを表示
APIはリージョン別のチェック結果を返却

セットアップ:

Nova Uptime にドメインを追加
設定でマルチリージョン監視を有効化
リージョンを選択 (自動: US + EU + APAC、もしくはカスタム)
リージョン別にアラートしきい値を設定
ダッシュボードでリージョン別メトリクスを確認

マルチリージョン監視のベストプラクティス

異なるISPから監視する: インフラと同じホスティングプロバイダーから監視しない
実際のユーザー経路をテストする: 顧客向けにCDNを使うなら、CDN経由で監視する
現実的なレイテンシSLAを設定する: 地理的距離を考慮する
リージョン横断で相関させる: 「なぜEUがダウン?」 — インフラ問題かEU固有かを確認
依存サービスも監視する: EUのAPIが米国DBに依存しているなら、米国DBもEUから監視する
リージョン選定を文書化する: なぜそのリージョンを選んだのか? 後任者のために残す
フェイルオーバーをテストする: あえて1リージョンの監視を落として、アラートルーティングを検証
リージョンデータをアーカイブする: SLAレポート用に12か月分のリージョン別メトリクスを保管

まとめ: マルチリージョン監視チェックリスト

今日からグローバル監視を始めましょう: Nova Uptime マルチリージョン監視。米国、EU、APAC、その他から監視可能です。🚀

マルチリージョン監視: 分散チームのためのグローバルカバレッジ