あなたのAPIモニタリングが1つのデータセンターのサーバーで動作している場合、あなたは部分的な状況しか見ることができません。ブラジルのユーザーは500エラーを受け取るかもしれませんが、モスクワのダッシュボードでは「すべて正常」と緑のステータスが表示されます。異なる国の実際の外部IPを介してリクエストを行わないと測定できない5つの可用性メトリクスを見ていき、複雑なインフラなしでそれを行う方法を説明します。
なぜローカルモニタリングは誤解を招くのか
ほとんどのチームは、UptimeRobot、Pingdom、または自分のcronスクリプトを使用してAPIモニタリングを設定します。これらのリクエストはほとんど常に1つまたは2つの地域から行われます — 通常は、モニタリングサービスのサーバーがあるアメリカやヨーロッパからです。もしあなたのオーディエンスがインド、ブラジル、または東南アジアにいる場合、ローカルプロバイダーがトラフィックを制限したり、CDNノードが過負荷になったり、DNSが古いIPに解決される可能性があります。
もう一つの一般的なシナリオは、CDNやWAF（Cloudflare、Akamai）レベルでのジオブロッキングです。一部のセキュリティルールは特定の国からのIPの範囲全体をブロックし、あなたのAPIは物理的に一部のユーザーにとって利用できなくなりますが、あなたのオフィスのIPからはすべてが正常に動作します。このような問題は、1つの地点からのみテストする場合には診断できません。
第三のシナリオは、Anycastや地域CDNエッジを介した負荷分散です。ドイツからのリクエストは1つのノードに到達し、シンガポールからのリクエストは全く異なるノードに到達し、異なるキャッシュや構成を持つことがあります。地域間でのAPIの動作の違いは理論ではなく、ユーザーが世界中に分散しているチームが定期的に直面する現実です。
外部IPを介してのみ見える5つの可用性メトリクス
以下は、リクエストが物理的に対象国にあるIPアドレスから実行されるときにのみ、可用性の実際の状況を示す5つのメトリクスです。
1. レイテンシ（Latency / RTT）
Round-Trip Time — リクエストを送信してから最初の応答パケットを受け取るまでの時間です。ヨーロッパのサーバーからあなたのAPIまでの遅延は20msかもしれませんが、東南アジアのユーザーは地理的な距離と中間ノードの数（hops）により400-600ms待たされることになります。異なる地域からのレイテンシを測定しないと、サービスが一部のオーディエンスにとってほぼ使用不可能になる瞬間を見逃すことが容易です — 特にリアルタイム操作に依存するAPIにとっては非常に重要です：広告の入札、チャット、フィンテック取引など。
2. TTFB（Time To First Byte）
TTFBは、サーバーがリクエストを処理して応答の送信を開始するまでにかかる時間を示します。このメトリクスはネットワークだけでなく、特定の地域を担当するCDNまたはロードバランサーのノードによっても異なります。しばしば、ある国のエッジサーバーが応答をキャッシュし、50msで返すことがありますが、別の国ではリクエストが毎回オリジンサーバーに到達し、800ms以上かかることがあります。地域間でのTTFBの違いは、CDNの構成に問題があるか、エッジノードのカバレッジが不十分であることを示す確かな兆候です。
3. DNS解決時間
DNS解決は、ユーザーのローカルリゾルバに完全に依存する遅延とエラーの別の原因です。GeoDNS（リクエストの地域に応じて異なるAレコードを設定）を設定している場合、構成のエラーにより、ある国のユーザーが他の大陸のデータセンターに解決されることがあり、大きな遅延が発生します。この問題は、対象国の実際のIPからDNS解決をリクエストした場合にのみ確認できます。ローカルテストは常にあなた自身の地理的位置に対して「正しく」解決されます。
4. 地域ごとの成功リクエストの割合（Uptime）
1つの地点からのモニタリングダッシュボードで99.9%の稼働時間が表示されていても、他の国のユーザーに対して99.9%を保証するものではありません。ローカルプロバイダーは、特定のホスティングプロバイダーへのピアリングに問題を抱えている可能性があり、その結果、国Xからのリクエストの一部がタイムアウトで失敗することがありますが、他の地域では問題が全く認識されないことがあります。実際の稼働時間を確認するには、各地域ごとに成功したリクエストと失敗したリクエストを別々にカウントする必要があります。
5. コンテンツとステータスコードの違い（ジオブロッキングとパーソナライズ）
第5のメトリクスは速度ではなく、応答のコンテンツ自体に関するものです。APIは、WAFのルールにより特定の国に対して403 Forbiddenを返したり、ライセンス制限によりデータの一部を削減したり、ジオに関連付けられたA/Bテストに基づいて異なるコンテンツのバージョンを表示したりすることがあります。自分のIPからのみAPIをテストすると、そのような違いは完全に見逃されます — そしてそれが特定の地域のユーザーからの苦情の原因となることが最も多いのです。
理解しておくべきこと
これら5つのメトリクスは、対象国のネットワークを介して実際にルーティングされるIPからのリクエストを必要とします。特定の国に1つのサーバーを持つVPNや同じ地域のクラウドサーバーは概算の状況を提供しますが、特定のプロバイダーとそのルートを通じてエンドユーザーがサービスをどのように見るかは示しません。
異なる国からのモニタリングの設定方法
設定のロジックは簡単です：あなたは複数の地点から同じHTTPリクエストをあなたのAPIに同時に送信し、すべての5つのメトリクスを記録し、結果を比較します。ステップバイステップで見ると、次のようになります：
- 優先国のリストを作成します — 通常はトラフィックまたは収益のトップ5の国です。
- 各国に対して、その国の実際のIPを持つ出口ポイントを準備します（プロキシサーバーまたは物理サーバー）。
- 各地点から指定された間隔（例えば、5分ごと）で同一のリクエストを送信するスクリプトまたはサービスを設定します。
- 各国ごとに5つのメトリクスをデータベースまたはメトリクスシステム（Grafana、Prometheus、ClickHouse）に別々にログします。
- 特定の国からのレイテンシが1時間で3倍に増加した場合など、メトリクスが基準レベルから逸脱した際にアラートを設定します。
重要なポイントは、まさにステップ2です。必要な国への実際の出口がなければ、他のすべてのステップは無意味です。なぜなら、メトリクスはユーザーが見るものではなく、あなたのモニタリングサーバーが見るものを測定するからです。
モニタリングに適したプロキシの種類
地理的に分散したモニタリングを構築するためには、プロキシサーバーが最も一般的に使用されます — これは、各国に物理サーバーやVPSをレンタルするよりも安価で迅速です。プロキシの種類の選択は、何を測定したいかによって異なります。
| プロキシの種類 | 使用するタイミング | 特徴 |
|---|---|---|
| データセンターのプロキシ | 基本的な可用性とレイテンシのチェック、実際のユーザーのシミュレーションが不要な場合 | 高速、低価格ですが、IPは簡単にデータセンターのものと特定されます — プロバイダーによるジオブロッキングのテストには不向きです |
| レジデンシャルプロキシ | 家庭用プロバイダーを持つ実際のユーザーが見ているものを確認する場合 | IPは特定の国の実際のプロバイダーに属し、ルーティングとWAFのルールをより正確に反映します |
| モバイルプロキシ | モバイルアプリケーションとモバイルトラフィックのAPIの可用性をテストする場合 | モバイルオペレーターのネットワークからのIPで、モバイルトラフィックに特有の遅延やブロッキングを示します |
あなたのAPIが主にデスクトップやサーバーからのウェブトラフィックを提供している場合、基本的なモニタリングを構築するにはデータセンターのプロキシで十分です — それらは安定した速度と予測可能なレイテンシを提供します。しかし、実際のユーザーが直面するものを確認する必要がある場合 — プロバイダーによるジオブロッキングのルールを含む — レジデンシャルプロキシを使用することをお勧めします。モバイルアプリケーションやAPIにリクエストを行うSDKの場合、モバイルプロキシを介したチェックを追加することが合理的です。なぜなら、モバイルオペレーターはしばしばNATや独自のルーティングルールを使用し、家庭用インターネットとは異なるからです。
メトリクス収集のためのPythonスクリプト
以下は、指定された国のプロキシを介してリクエストを送信し、5つのメトリクスのうち4つを収集する簡略化されたスクリプトの例です（コンテンツの違いは応答を照合して別々に比較する必要があります）。このスクリプトは、requestsライブラリと、DNS解決時間を測定するためのsocketモジュールを使用します。
import time
import socket
import requests
def measure_api(url, proxy, country_label):
hostname = url.split("//")[1].split("/")[0]
# 1. DNS解決時間
dns_start = time.time()
try:
socket.gethostbyname(hostname)
except socket.gaierror:
pass
dns_time = time.time() - dns_start
proxies = {
"http": proxy,
"https": proxy,
}
try:
start = time.time()
response = requests.get(
url,
proxies=proxies,
timeout=10,
stream=True
)
ttfb = time.time() - start # おおよそのTTFB
full_load_time = time.time() - start
status_code = response.status_code
success = status_code == 200
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": round(ttfb * 1000, 2),
"total_time_ms": round(full_load_time * 1000, 2),
"status_code": status_code,
"success": success,
}
except requests.exceptions.RequestException as e:
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": None,
"total_time_ms": None,
"status_code": None,
"success": False,
"error": str(e),
}
return result
# 異なる国のプロキシを使用した例
endpoints = [
{"label": "Germany", "proxy": "http://user:[email protected]:port"},
{"label": "Brazil", "proxy": "http://user:[email protected]:port"},
{"label": "Singapore", "proxy": "http://user:[email protected]:port"},
]
API_URL = "https://api.yourservice.com/health"
for ep in endpoints:
data = measure_api(API_URL, ep["proxy"], ep["label"])
print(data)
このスクリプトのプロダクションバージョンでは、結果をデータベース（例えば、ClickHouseやInfluxDB）に記録し、Grafanaを介して視覚化し、しきい値を超えた際にTelegramボットやSlackウェブフックを介してアラートを設定することをお勧めします。スクリプトは、各国ごとに5-15分の間隔でcronやタスクスケジューラを介して実行するのが最適です。
コードを書くことなく迅速に確認する必要がある場合、同様のリクエストはcURLを使用して時間を測定しながら実行できます：
curl -x http://user:[email protected]:port \
-o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
https://api.yourservice.com/health結果の解釈方法
すべての国からのデータを少なくとも1週間収集した後、各地域のベースラインが設定されます。次に、絶対的な数字ではなく、このベースラインからの逸脱を見なければなりません。ブラジルからのレイテンシが安定して350msであれば — それは地理的には正常であり、値が突然1500msに増加した場合に警戒すべきです。同様に、稼働時間についても：不安定なインターネットを持つ複雑な地域での99.5%は受け入れ可能な基準かもしれませんが、95%に低下することは、プロバイダーやCDN側の問題の信号です。
ステータスコード403と451には特に注意が必要です — これらはほぼ常にWAFやCDNによるジオブロッキングを示し、API自体の問題ではありません。このようなコードが特定の国からのみ、特定のタイプのプロキシ（例えば、データセンターのもの）を使用している場合にのみ表示される場合、それは「IPがデータセンターに似ている」という基準でブロックが設定されていることを意味し、実際のジオロケーションに基づいていない可能性があります — この場合、レジデンシャルプロキシを使用したテストがより正確な状況を提供します。
既存のサービス vs 自作のソリューション
自分のスクリプトを維持したくない場合、市場には異なる国にプレゼンスを持つ合成モニタリングの既存サービスがあります：Pingdom、Uptrends、Site24x7、Checkly。これらはインフラを設定する必要を排除しますが、通常は固定されたロケーションのセットに制限され、特定のテストのためのIPの種類（レジデンシャル、モバイル、データセンター）を選択する柔軟性を提供しません。
プロキシに基づく自作のソリューションは、より多くの制御を提供します：あなたのビジネスにとって重要な国をテストし、特定の問題（例えば、ASNによるジオブロッキング）の診断のためにIPの種類を切り替え、余分な仲介者なしでメトリクスを直接あなたのモニタリングシステムに統合できます。両方のアプローチの組み合わせは理にかなったバランスです：基本的なSLAモニタリングには既存のサービス、自作のスクリプトには特定の地域の問題の診断のためのプロキシを使用します。
結論
1つの地点からのローカルモニタリングは、APIの可用性に関する真実の一部しか示しません。実際の状況を把握するには、レイテンシ、TTFB、DNS解決時間、稼働時間、コンテンツの違いを各国ごとに別々に測定し、対象地域のネットワークを通じて実際にルーティングされるIPを介して行う必要があります。これがなければ、ダッシュボードが「すべて正常」と表示している間に、一部のユーザーがサービスを利用できない問題を見逃すことが容易です。
このようなモニタリングを構築するには、レジデンシャルプロキシが最も適しています。特定の国の家庭用インターネットを持つ実際のユーザーが見ているものを確認することが重要です。より安価で迅速な基本的な可用性チェックにはデータセンターのプロキシが適しており、モバイルオーディエンスの問題を診断するにはモバイルプロキシを追加することが理にかなっています。このような組み合わせアプローチは、あなたのAPIが世界のどの地点からでもどのように見えるかを完全に把握するのに役立ちます。