만약 당신의 API 모니터링이 하나의 데이터 센터에 있는 서버에서 실행된다면, 당신은 전체 그림의 일부만 볼 수 있습니다. 브라질의 사용자는 500 오류를 받을 수 있지만, 모스크바의 대시보드는 "모두 작동 중"이라는 녹색 상태를 보여줄 수 있습니다. 다른 국가의 실제 외부 IP를 통해 요청하지 않으면 측정할 수 없는 5가지 접근성 메트릭을 살펴보고, 복잡한 인프라 없이 이를 수행하는 방법을 알아보겠습니다.
로컬 모니터링이 속이는 이유
대부분의 팀은 UptimeRobot, Pingdom 또는 매분 엔드포인트에 요청을 보내는 자체 cron 스크립트를 통해 API 모니터링을 설정합니다. 문제는 이러한 요청이 거의 항상 한두 지역에서 발생한다는 것입니다. 일반적으로 모니터링 서비스의 서버가 위치한 미국이나 유럽에서 발생합니다. 만약 당신의 청중이 인도, 브라질 또는 동남아시아에 있다면, 로컬 제공업체가 트래픽을 차단할 수 있고, CDN 노드가 과부하에 걸릴 수 있으며, DNS가 구식 IP로 해석될 수 있습니다.
또 다른 일반적인 시나리오는 CDN 또는 WAF(Cloudflare, Akamai) 수준에서의 지리적 차단입니다. 일부 보안 규칙은 특정 국가의 전체 IP 범위를 차단하여, 당신의 API가 일부 사용자에게 물리적으로 접근할 수 없게 됩니다. 하지만 당신의 사무실 IP에서는 모든 것이 완벽하게 작동합니다. 이러한 문제는 단일 지점에서만 테스트할 경우 진단할 수 없습니다.
세 번째 시나리오는 Anycast 또는 지역 CDN 엣지를 통한 부하 분산입니다. 독일에서의 요청은 하나의 노드에 도달할 수 있지만, 싱가포르에서의 요청은 전혀 다른 노드에 도달할 수 있으며, 다른 캐시 버전이나 구성으로 처리될 수 있습니다. 지역 간 API의 동작 차이는 이론이 아니라, 전 세계에 분산된 사용자를 가진 팀들이 정기적으로 직면하는 문제입니다.
외부 IP를 통해서만 볼 수 있는 5가지 접근성 메트릭
아래는 요청이 물리적으로 목표 국가에 위치한 IP 주소에서 수행될 때만 실제 접근성 그림을 보여주는 5가지 메트릭입니다.
1. 응답 시간 (Latency / RTT)
Round-Trip Time — 요청을 보내고 첫 번째 응답 패킷을 받을 때까지의 시간입니다. 유럽의 한 서버에서 당신의 API까지의 지연 시간은 20ms일 수 있지만, 동남아시아의 사용자는 지리적 거리와 중간 노드(hops)의 수로 인해 400-600ms를 기다려야 합니다. 다양한 지역에서 latency를 측정하지 않으면, 서비스가 일부 청중에게는 거의 사용할 수 없게 되는 순간을 놓치기 쉽습니다. 이는 특히 실시간 작업에 의존하는 API에 매우 중요합니다: 광고 입찰, 채팅, 핀테크 거래 등.
2. TTFB (Time To First Byte)
TTFB는 서버가 요청을 처리하여 응답을 보내기 시작할 때까지 걸리는 시간을 보여줍니다. 이 메트릭은 네트워크뿐만 아니라 특정 지역을 서비스하는 CDN 또는 로드 밸런서의 노드에 따라 달라집니다. 종종 한 국가의 엣지 서버가 응답을 캐시하고 50ms에 제공하는 반면, 다른 국가에서는 요청이 매번 오리진 서버에 도달하고 다시 처리되어 800ms 이상 걸릴 수 있습니다. 지역 간 TTFB의 차이는 CDN 구성 문제나 엣지 노드의 부족한 커버리지의 확실한 징후입니다.
3. DNS 해석 시간
DNS 해석은 지연 및 오류의 별도 원천으로, 사용자의 로컬 해석기에서 완전히 의존합니다. GeoDNS(요청 지역에 따라 다른 A 레코드)가 설정되어 있다면, 구성 오류로 인해 한 국가의 사용자가 다른 대륙의 데이터 센터로 해석될 수 있으며, 이는 큰 지연을 초래합니다. 이 문제는 목표 국가의 실제 IP에서 DNS 해석 요청을 할 때만 볼 수 있으며, 로컬 테스트는 항상 자신의 지리적 위치에 대해 "올바르게" 해석됩니다.
4. 지역별 성공적인 요청 비율 (Uptime)
모니터링 대시보드에서 99.9%의 가동 시간은 한 지점에서 요청하는 경우 다른 국가의 사용자에게 99.9%를 보장하지 않습니다. 로컬 제공업체는 특정 호스팅 제공업체에 대한 피어링 문제를 가질 수 있으며, 이로 인해 X 국가의 일부 요청이 타임아웃으로 실패할 수 있습니다. 반면 나머지 세계는 문제를 전혀 인식하지 못할 수 있습니다. 실제 가동 시간을 보려면 각 지역별로 성공적인 요청과 실패한 요청을 별도로 계산해야 하며, 집계해서는 안 됩니다.
5. 콘텐츠 및 상태 코드의 차이 (지리적 차단 및 개인화)
다섯 번째 메트릭은 속도에 관한 것이 아니라 응답 콘텐츠 자체에 관한 것입니다. API는 WAF 규칙으로 인해 특정 국가에 대해 403 Forbidden을 반환하거나, 라이센스 제한으로 인해 축소된 데이터 세트를 반환하거나, 지리적 A/B 테스트에 따라 다른 콘텐츠 버전을 표시할 수 있습니다. 자신의 IP에서만 API를 테스트하면 이러한 차이는 완전히 간과될 수 있으며, 이러한 차이가 특정 지역의 사용자 불만의 주된 원인이 되는 경우가 많습니다.
중요한 점
모든 다섯 가지 메트릭은 목표 국가의 네트워크를 통해 실제로 라우팅되는 IP에서 요청이 필요합니다. 단일 국가에 있는 VPN 서버나 동일 지역의 클라우드 서버는 대략적인 그림을 제공하지만, 최종 사용자가 특정 제공업체와의 경로를 통해 서비스가 어떻게 보이는지를 보여주지는 않습니다.
다양한 국가에서 모니터링 설정하는 방법
설정 논리는 간단합니다: 여러 지점에서 동시에 동일한 HTTP 요청을 당신의 API에 보내고, 모든 5가지 메트릭을 기록하고 결과를 비교합니다. 단계별로 보면 다음과 같습니다:
- 우선 순위 국가 목록을 작성합니다 — 일반적으로 트래픽 또는 수익이 가장 많은 상위 5개 국가입니다.
- 각 국가에 대해 해당 국가의 실제 IP를 가진 출구 지점을 준비합니다 (프록시 서버 또는 물리적 서버).
- 각 지점에서 설정된 간격(예: 5분마다)으로 동일한 요청을 보내는 스크립트 또는 서비스를 설정합니다.
- 모든 5가지 메트릭을 각 국가별로 데이터베이스 또는 메트릭 시스템(Grafana, Prometheus, ClickHouse)에 별도로 기록합니다.
- 특정 국가에서 latency가 한 시간에 3배 증가하는 경우와 같이 메트릭이 기준 수준에서 벗어날 때 경고를 설정합니다.
핵심 포인트는 바로 2번입니다. 필요한 국가에 대한 실제 출구가 없으면 나머지 단계는 의미가 없으며, 메트릭은 사용자가 보는 것이 아니라 모니터링 서버가 보는 것을 측정하게 됩니다.
모니터링을 위한 프록시 유형 선택하기
지리적으로 분산된 모니터링을 구축하기 위해 주로 프록시 서버를 사용합니다 — 이는 각 필요한 국가에서 물리적 서버나 VPS를 임대하는 것보다 저렴하고 빠릅니다. 프록시 유형의 선택은 무엇을 측정하고자 하는지에 따라 달라집니다.
| 프록시 유형 | 언제 사용해야 하는가 | 특징 |
|---|---|---|
| 데이터 센터 프록시 | 기본적인 접근성 및 latency 확인, 실제 사용자 시뮬레이션이 필요하지 않을 때 | 높은 속도, 낮은 가격, 그러나 IP가 쉽게 데이터 센터 IP로 식별됨 — 제공업체에 따른 geo-blocking 테스트에는 적합하지 않음 |
| 주거용 프록시 | 가정용 제공업체를 가진 실제 사용자가 보는 것을 확인 | IP가 특정 국가의 실제 제공업체에 속하며, 라우팅 및 WAF 규칙을 더 정확하게 반영함 |
| 모바일 프록시 | 모바일 애플리케이션 및 모바일 트래픽에 대한 API 접근성 테스트 | 모바일 운영자의 네트워크에서 IP가 제공되며, 모바일 트래픽에 특화된 지연 및 차단을 보여줌 |
만약 당신의 API가 주로 데스크탑 및 서버에서 오는 웹 트래픽을 처리한다면, 기본 모니터링을 구축하기 위해 데이터 센터 프록시로 충분합니다 — 이들은 안정적인 속도와 예측 가능한 지연을 제공합니다. 그러나 실제 사용자가 겪는 문제를 확인해야 한다면 — 제공업체의 ASN에 따라 설정된 지리적 차단 규칙을 포함하여 — 주거용 프록시를 사용하는 것이 좋습니다. 모바일 애플리케이션 및 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결과 해석하는 방법
모든 국가에서 데이터를 수집한 후 최소 일주일 동안 각 지역에 대한 기준 수준(baseline)이 형성됩니다. 이후에는 절대 숫자가 아니라 이 기준 수준에서의 편차를 살펴봐야 합니다. 브라질에서의 latency가 안정적으로 350ms를 유지하는 것은 지리적으로 정상이며, 값이 갑자기 1500ms로 증가할 경우에만 경고를 발령해야 합니다. uptime의 경우에도 마찬가지입니다: 불안정한 인터넷을 가진 복잡한 지역에서 99.5%는 수용 가능한 기준일 수 있지만, 95%로 떨어지는 것은 제공업체나 CDN 측의 문제 신호가 될 수 있습니다.
403 및 451 상태 코드에 특별한 주의를 기울여야 합니다 — 이들은 거의 항상 WAF 또는 CDN 측의 지리적 차단을 나타내며, API 자체의 문제는 아닙니다. 이러한 코드가 특정 국가에서만 나타나고 특정 유형의 프록시(예: 데이터 센터 프록시)를 사용할 때만 발생한다면, 이는 "IP가 데이터 센터처럼 보인다"는 기준으로 차단이 설정되었음을 의미할 수 있습니다. 이 경우, 주거용 프록시를 사용한 테스트가 더 정확한 그림을 제공할 것입니다.
기성 서비스 vs 자체 솔루션
자체 스크립트를 유지 관리하고 싶지 않다면, 시장에는 다양한 국가에 존재하는 포인트를 가진 합성 모니터링 서비스가 있습니다: Pingdom, Uptrends, Site24x7, Checkly. 이들은 인프라를 설정할 필요를 없애주지만, 일반적으로 고정된 위치 세트로 제한되며 특정 테스트를 위한 IP 유형(주거용, 모바일, 데이터 센터)을 선택하는 데 유연성을 제공하지 않습니다.
프록시 기반의 자체 솔루션은 더 많은 제어를 제공합니다: 비즈니스에 중요한 국가를 테스트하고, 특정 문제(예: ASN에 따른 지리적 차단)를 진단하기 위해 IP 유형을 전환하며, 불필요한 중개자 없이 메트릭을 직접 모니터링 시스템에 통합할 수 있습니다. 두 접근 방식을 조합하는 것은 합리적인 균형입니다: 기본 SLA 모니터링을 위한 기성 서비스와 특정 지역의 문제를 진단하기 위한 프록시를 사용하는 자체 스크립트.
결론
한 지점에서의 로컬 모니터링은 API 접근성에 대한 진실의 일부만 보여줍니다. 실제 그림을 보려면 latency, TTFB, DNS 해석 시간, 가동 시간 및 콘텐츠 차이를 각 국가별로 측정해야 하며, 이를 목표 지역의 네트워크를 통해 실제로 라우팅되는 IP를 통해 수행해야 합니다. 이를 수행하지 않으면, 대시보드가 "모두 녹색"이라고 표시하는 동안 일부 사용자가 서비스 사용에 방해가 되는 문제를 놓치기 쉽습니다.
이러한 모니터링을 구축하기 위해 주거용 프록시가 가장 적합합니다. 특정 국가의 가정용 인터넷을 사용하는 실제 사용자가 보는 것과 동일한 것을 확인하는 것이 중요합니다. 보다 저렴하고 빠른 기본 접근성 검사를 위해 데이터 센터 프록시를 사용할 수 있으며, 모바일 청중의 문제를 진단하기 위해 모바일 프록시를 추가하는 것이 좋습니다. 이러한 결합된 접근 방식은 API가 전 세계의 어떤 지점에서 어떻게 보이는지를 완전하게 보여줍니다.