Cloudflareの障害、地域別CDN障害、エッジレベルの劣化は、ステータスページに常に表示されるわけではありません。CDNの東京PoPがダウンしてもグローバルステータスが正常を示している場合、バージニアからの監視では検知できません。
地域障害の検知には、インフラがある場所からではなく、ユーザーが実際にいる場所からの監視が必要です。
午前3時。オンコールのエンジニアがカスタマーサクセスからの通知を受けます：「シンガポールの企業顧客3社がアプリにアクセスできないと報告しています。約2時間前から始まりました。」
監視ダッシュボードを確認すると、すべて正常。Cloudflareのステータスページも正常稼働中。AWSにもインシデントなし。APMも問題のないグラフ。そこで顧客に再試行、キャッシュクリア、ネットワーク確認を依頼します。
しかし問題は続きます。同じ地域からのチケットが増え続けます。最終的に、誰かがシンガポールのVPSからtracerouteを実行し、発見します：トラフィックが502エラーを返すCloudflareエッジに到達している。CDNに1つのPoPに影響する地域障害が発生しており、監視スタックのどれもその地域からチェックしていなかったのです。
2時間のダウンタイム。特定の地域で。アラートはゼロ。これがこのページで取り上げる盲点です。
Cloudflareの障害であれ、Fastlyのエッジ障害であれ、Akamaiの地域劣化であれ、これらの問題を検知するには影響を受けている地域からの監視が必要です。問題が顧客のエスカレーションになる前に検知する方法です。
インターネットは単一のネットワークではありません。シドニーからのリクエストは、フランクフルトからのリクエストとはまったく異なるインフラを通過します。その地域パスのどこかが故障すると、その地域のユーザーだけが影響を受けます。
Cloudflare、Fastly、AkamaiなどのCDNは、世界中で数百のPoP（Point of Presence）を運用しています。特定のエッジサーバーやPoPにハードウェア障害、設定ミス、容量問題などが発生すると、そのエッジにルーティングされたユーザーだけが影響を受けます。95%のエッジが正常なため、CDNのグローバルステータスは「稼働中」のままです。
例：2022年6月、Cloudflareはネットワーク設定変更により19のデータセンターに影響する30分間の障害が発生しました。影響を受けた地域のユーザーにはエラーが表示されましたが、他の地域のユーザーには何も異常がありませんでした。
DNSはすべてのリクエストの最初のステップです。Cloudflareの1.1.1.1やCDNのDNSサーバーが特定の地域で問題を抱えた場合（エニーキャストルートの設定ミス、過負荷のネームサーバーなど）、その地域のユーザーはドメインを解決できません。ブラウザには「DNS_PROBE_FINISHED_NXDOMAIN」と表示されるだけです。
例：地域別DNS問題は、ISPレベルのフィルタリング、ローカルリゾルバの問題、特定の地理的エリアにのみ影響するエニーキャストルーティングの問題によって引き起こされることがあります。
BGPルートリーク、ハイジャック、設定ミスにより、トラフィックが最適でないパスにリダイレクトされたり、完全にブラックホール化されたりすることがあります。ある地域の大手キャリアにルーティング問題がある場合、その地域からCDNやオリジンへのトラフィックが失敗する可能性があります。両方のエンドポイントは完全に正常に機能していてもです。
例：BGPインシデントは定期的に数千のネットワークに影響を与えます。1つの設定ミスのASパスにより、監視場所からは正常に見えながら、国全体からサイトが数時間アクセス不能になることがあります。
特定の国の大手ISPが、ピアリング紛争、混雑、インフラ問題のために、CDNへの接続が劣化することがあります。オーストラリアのTelstraのユーザーは障害を経験しても、同じ都市のOptusのユーザーには問題がないかもしれません。トラフィックが異なるパスを通るためです。
例：ISPとクラウドプロバイダー間のピアリング紛争により、特定の市場の数百万人のユーザーに数週間にわたる劣化が発生した事例があります。
共通点：これらの障害はすべて地理的に限定されています。オリジンは稼働中です。CDNの設定は正しいです。しかし、エッジと特定の地域のユーザーの間のどこかで何かが壊れており、バージニアの1か所からチェックする監視では検知する方法がありません。
ほとんどの稼働監視は、よりシンプルな問題のために設計されました：「サーバーは応答しているか？」CDNで高速化されたグローバルユーザー向けサイトでは、それはもう適切な質問ではありません。
ほとんどの監視サービスはデフォルトで、米国やEUの少数の拠点からチェックします。CloudflareのシンガポールPoPがダウンしても、オレゴンからのチェックは成功します。異なる正常なエッジに到達するからです。一方、APACのユーザーは502エラーを見ています。
AWSからCloudflareへのチェックは、クラウドバックボーン接続を使用します。これは実際のユーザートラフィックを代表しない最適化されたパスです。AWS ap-southeast-1からの合成チェックは、ローカルISPのユーザーに障害が発生しているまさにそのネットワークパスをバイパスするかもしれません。
CDNステータスページは、数百のPoPにわたって集約された内部ビューを反映しています。インフラの5%に影響する地域問題では、ステータスページの更新がトリガーされないかもしれません。しかし、その5%に東南アジア全体が含まれている可能性があります。
HTTPチェックはリクエストが成功したか失敗したかを教えてくれますが、どこで失敗したかは教えてくれません。影響を受けた地域からのtracerouteとレイテンシー分析データがなければ、問題がDNS、特定のネットワークホップ、またはCDNエッジのどれかを判断できません。
Cloudflareには310以上のPoPがあります。監視が3拠点からチェックしている場合、ユーザーが到達する可能性のあるエッジの1%未満しか検証していません。それは障害検知ではありません。幸運を祈っているだけです。
Cloudflare障害や地域CDN障害が検知されない1分ごとに、提供していることすら気づいていない市場で、ユーザー、売上、信頼を失っています。
そのタイムゾーンの営業時間中の地域障害は、何時間もの取引、サインアップ、API呼び出しの損失につながります。ユーザーは「サイトがダウンしている」というメールを送りません。ただ離れるだけです。後で地域メトリクスに落ち込みが見えますが、明確な原因の特定はできません。
企業顧客にはSLAがあります。プラットフォームにアクセスできず、問題の存在すら知らなかった場合、困難な会話になります。「障害を検知できませんでした」は、特に信頼性に対して費用を支払っている場合、信頼を構築する回答ではありません。
Googlebotは世界中の複数の場所からクロールします。ある地域のCDNエッジがエラーや遅い応答を返している場合、クロールバジェット、Core Web Vitalsの評価、最終的にはランキングに影響します。明確な原因なく、特定の市場でトラフィックの減少が見られるかもしれません。
MTTR（平均復旧時間）は問題を検知した時点から始まります。地域的なCloudflare障害が2時間ユーザーに影響した後、顧客チケットで知った場合、実効MTTRに2時間が追加されます。実際のダウンタイムの影響を最小化するには、事前検知が唯一の方法です。
地域障害の検知には、ユーザーがいる場所からの監視と、障害がどこで発生しているかを特定する診断の深さが必要です。
各監視拠点は異なるCDNエッジに到達し、異なるネットワークパスを通過します。地域障害を検知するには、アジア太平洋、ヨーロッパ、南北アメリカ、中東、アフリカなど、重要なトラフィックがあるすべての地域にノードが必要です。「国際」だけでなく、ユーザーがいる具体的な場所です。
50以上の拠点からの監視で主要なCDN PoPとISPパスをカバーします。
シンガポールからのチェックが失敗し、他のすべてからは成功する場合、知る必要があります：DNSか？特定のネットワークホップか？CDNエッジか？影響を受けた場所からのtracerouteとMTRは、根本原因を診断し、Cloudflare、ISP、またはホスティングプロバイダーにエスカレーションするために必要な証拠を提供します。
診断データが「何かが壊れている」を実行可能な根本原因に変えます。
東京からの400msは正常か、それともCloudflareエッジの劣化か？拠点別の履歴データがベースラインを構築し、ハード障害を引き起こさないがユーザー体験を劣化させるレイテンシー増加など、緩慢な障害を検知できます。完全な障害になる前に地域CDN問題を検知できます。
ベースラインが障害になる前の劣化を検知します。
ユーザーが報告する前にCloudflare障害や地域CDN障害を検知する監視を実装するためのステップバイステップガイド。
アナリティクスでユーザーの所在地を確認します。トラフィックの20%がアジア太平洋からの場合、シンガポール、東京、シドニー、ムンバイなど複数の監視ノードが必要です。監視カバレッジを実際のユーザー分布に合わせてください。
CloudflareやCDNを通過するプライマリURLのHTTPモニターを設定します。これらはオリジンではなくCDNエッジに到達するべきです。アプリのドメイン、APIエンドポイント、重要な公開ページを含めてください。
異なる地域には異なるベースラインレイテンシーがあります。合理的な閾値を設定します：ヨーロッパからの500msは許容範囲かもしれませんが、US-Eastから（オリジンがある場合）の500msはCDNエッジの問題を示します。現実的なベースラインを設定するために履歴データを使用してください。
すべての拠点が障害を起こした時だけでなく、特定の地域が障害を起こした時にアラートを設定します。シンガポールのみの障害でも知る価値のある障害です。高優先度のアラートをSlack、PagerDuty、またはインシデント管理システムに送信してください。
アラートが発生した時、迅速に判断する必要があります：Cloudflareの問題か？ネットワークパスの問題か？DNSか？監視拠点からのオンデマンドtracerouteとMTRを有効にして、即座に診断データを収集できるようにしてください。
プロセスを文書化します：Cloudflareの地域障害を確認する方法。CloudflareのステータスAPIを確認する場所。証拠付きのチケットを開く方法。適用可能な緩和策（フェイルオーバー、キャッシュバイパスなど）。これを準備しておくとMTTRが大幅に短縮されます。
地域別のレイテンシーと稼働率をレビューするための週次カレンダーリマインダーを設定します。パターンを探します：APACが一貫して遅いか？特定の拠点で定期的なブリップがあるか？事前のレビューが、ユーザーに大きな影響を与える前に緩慢な劣化を検知します。
地域障害が許容できないサービスでは、DNSがプロバイダー間でフェイルオーバーできるマルチCDN戦略を検討してください。これには各CDNを独立して監視し、トラフィックを切り替えられる自動化が必要です。複雑さはありますが、回復力が得られます。
Latency Globalは、まさにこの種の問題を検知するために構築されました。Cloudflareの障害、地域CDN障害、単一拠点の監視では見逃すネットワーク問題です。6大陸70以上の実拠点から監視し、すべての主要なCDN PoPリージョンをカバーしています。
すべてのチェックには完全なタイミング分析が含まれます。DNS解決、TCP接続、TLSハンドシェイク、TTFB、合計応答時間。特定の地域から障害が発生した場合、その場所からtracerouteとMTRを実行して、ネットワークパスのどこで問題が発生したかを正確に特定できます。料金はシンプルです：$5/月で5モニター、すべての拠点が含まれます。
地域障害の検知には多くの拠点のインフラが必要です。そのため、ほとんどの監視ツールはこの機能を提供しないか、エンタープライズ価格を請求します。私たちはカバレッジと診断の深さという重要な点に集中しています。
地域CDN障害は、CDNネットワーク内の特定のエッジサーバーまたはPoP（Point of Presence）が障害または劣化する一方、他のエッジは正常に稼働し続ける状態です。例えば、CloudflareのシンガポールPoPに問題があっても、米国やヨーロッパのエッジは正常に動作する場合があります。影響を受けたエッジを通るユーザーはエラーや低パフォーマンスを経験し、他のユーザーは何も気づきません。これらの障害は、影響を受けていない地域からのみチェックする監視には見えません。
CDNステータスページは通常、PoP別の健全性ではなく、集約されたグローバルステータスを表示します。エッジの5%が影響を受けている場合、インフラの95%が稼働しているため、全体のステータスは「稼働中」のままかもしれません。ステータスページには更新のタイムラグもあります。問題が検知、確認、投稿されるまでに時間がかかります。また、公開の閾値を満たさないが、ユーザーには影響する問題もあります。複数の拠点からの独立した監視が、地域の可用性について実態を把握する唯一の方法です。
最低限、ユーザーがいるすべての主要地域に監視拠点が必要です：北米、ヨーロッパ、アジア太平洋は最低限です。より良いカバレッジのために、世界中に分散した50以上の拠点がほとんどの地域問題を検知します。重要なのは、監視カバレッジをユーザーの地理に合わせることです。ユーザーの30%がAPACにいる場合、複数のノードが必要です（シンガポール、東京、シドニー、ムンバイ）。すべてのCDN PoPに合わせる必要はなく、主要な地域グループをカバーすることが重要です。
まず、診断の証拠を収集します：影響を受けた場所からのtracerouteとMTR、HTTPレスポンスコードとタイミングデータ、タイムスタンプ。Cloudflareのステータスページとソーシャルメディアで認識があるか確認します。明らかにCloudflareの問題であれば、証拠を添えてサポートチケットを開きます。即時の緩和策として検討できるのは：影響を受けた地域でCloudflareを一時的にバイパス（オリジンが処理できる場合）、マルチCDN機能がある場合はバックアップCDNの有効化、またはCloudflareが解決する間に問題を認識するステータスページの更新です。インシデント後のレビューのためにすべてを文書化してください。
はい、適切な監視の計装があれば可能です。完全なHTTPチェックタイミングは以下を示します：DNS解決時間（DNSが失敗または遅い場合、DNS問題と分かります）、TCP接続時間（ネットワークパスの問題）、TLSハンドシェイク時間（証明書や暗号の問題）、TTFB/応答時間（オリジンまたはエッジの処理問題）。Tracerouteはネットワークパスと、パケットがどこでドロップまたは遅延しているかを示します。影響を受けた地域と正常な地域のこのデータを比較することで、リクエストチェーンのどこで障害が発生しているかを正確に特定できます。
1分間隔のチェックで、障害開始から1〜2分以内に検知できます。ほとんどの監視サービスは一時的なブリップによる誤報を避けるため、2〜3回連続の障害後に確認するので、現実的な検知時間は2〜5分です。これを顧客報告の障害と比較してください。サポートチケットを通じて表面化するまでに数時間かかることがあります。MTTRの違いは大きく、5分と2時間ではユーザーへの影響がまったく異なります。
もちろんです。Fastly、Akamai、AWS CloudFront、Google Cloud CDN、Azure CDN、その他すべてのCDNで地域障害が発生する可能性があります。同じ原則が適用されます：CDNは分散インフラを持ち、分散システムには部分的な障害がつきものです。検知アプローチは同じです。使用するCDNに関係なく、特定のエッジや地域に影響する問題を検知するために、複数のグローバル拠点から監視してください。
CDNステータスページや顧客チケットに頼って地域障害を知るのをやめましょう。エンドポイントを追加し、監視拠点を選択すれば、Cloudflare、Fastly、またはスタックの任意の部分がどの地域で障害を起こしても数分で把握できます。
$5/月 • 70以上の拠点（+40拠点近日追加） • 契約不要 • いつでもキャンセル可能