Cloudflare, Akamai, Google Public DNS(8.8.8.8) 같은 글로벌 서비스가 어떻게 전 세계 어디서나 빠르게 응답하는지 궁금했던 적이 있으신가요? 거의 모두 BGP Anycast라는 기술 위에서 동작합니다.

BGP Anycast — 같은 IP, 여러 곳

Anycast란 무엇인가

IP 주소 통신 방식은 4가지로 분류됩니다.

방식 의미 예시
Unicast 1대 1 일반 웹 접속
Multicast 1대 N (구독자) IPTV
Broadcast 1대 전체 (동일 네트워크) DHCP 요청
Anycast 1대 N 중 가장 가까운 1대 CDN, DNS

Anycast는 “같은 IP 주소를 여러 위치에서 광고하고, 네트워크가 가장 가까운 곳으로 보내준다”는 발상입니다.

BGP가 어떻게 가까운 곳을 고르는가

BGP(Border Gateway Protocol)는 인터넷의 라우팅 결정 프로토콜입니다. AS(Autonomous System) 간 경로 정보를 교환하며, 다음 기준으로 “가장 좋은 경로”를 고릅니다.

BGP 경로 결정 순서 (단순화):
1. AS_PATH 길이 (짧을수록 좋음)
2. Local Preference (사업자 정책)
3. Origin (IGP > EGP > Incomplete)
4. MED (Multi-Exit Discriminator)
5. eBGP > iBGP 선호
6. IGP 코스트
7. 라우터 ID

“가까운 곳”의 정의가 단순한 지리적 거리가 아닌 AS hop 수와 정책의 함수입니다. 그래서 Anycast는 실제로는 “BGP가 좋다고 판단한 곳”으로 가는 셈입니다.

왜 BGP Anycast를 쓰는가

1) 지연 시간 단축

글로벌 사용자가 각자 가장 가까운 PoP으로 자동 라우팅되어 RTT가 줄어듭니다.

2) 부하 분산

한 곳에 트래픽이 몰리지 않고, 지리적으로 분산됩니다.

3) DDoS 분산

공격 트래픽도 자동으로 분산되어 한 곳에서 흡수할 수 없는 규모도 처리 가능합니다.

4) 자동 페일오버

한 PoP이 다운되면 BGP 광고가 사라져 자연스럽게 다른 PoP으로 전환됩니다. DNS 변경 불필요.

5) 단순한 클라이언트 설정

사용자는 IP 하나(예: 1.1.1.1)만 알면 됩니다. 지역별 다른 IP를 관리할 필요가 없습니다.

어떤 서비스에 잘 맞는가

Anycast는 모든 워크로드에 적합한 게 아닙니다.

✅ 잘 맞는 경우

  • 상태 없는 단방향 트래픽 — DNS 쿼리·응답
  • 읽기 위주 캐시 — CDN 정적 콘텐츠
  • 짧은 연결 — 단일 요청·응답
  • DDoS 흡수 — 트래픽 분산

⚠ 주의가 필요한 경우

  • 상태가 있는 긴 연결(TCP) — 경로가 도중에 바뀌면 연결 끊김
  • 세션 어피니티 필요 — 같은 사용자가 같은 서버로 와야 하는 경우
  • 쓰기 트래픽 — 어느 PoP에 쓸지 결정 후 동기화 부담

다만 최근에는 TCP·HTTP도 Anycast로 운영하는 사례가 일반화됐습니다. 대부분의 사용자는 한 세션 동안 같은 PoP에 머무는 경향이 강하기 때문입니다.

실제 사용 예시

Public DNS — 1.1.1.1 / 8.8.8.8

전 세계 수백 곳에서 같은 IP를 광고. 사용자는 가장 가까운 곳에서 응답을 받습니다.

CDN — Cloudflare, Fastly, Akamai

Edge 서버가 Anycast IP로 광고하여, 사용자가 가까운 PoP에서 캐시된 콘텐츠를 받습니다.

DDoS 방어 — Cloudflare Magic Transit

공격 트래픽을 전 세계로 분산해 단일 PoP의 대역폭을 초과하지 않게 합니다.

글로벌 로드밸런서 — AWS Global Accelerator, GCP Global LB

NTP — pool.ntp.org

운영 함정

Anycast는 마법이 아닙니다. 운영해보면 다음 문제들이 드러납니다.

1) BGP 경로 변동 시 연결 끊김

TCP 연결 도중 BGP 경로가 바뀌면, 새 경로의 PoP은 그 TCP 세션을 모르기 때문에 RST가 발생합니다.

  • 해결: 경로 변화 빈도 모니터링, 연결 짧게 유지

2) PoP 간 응답 일관성 부재

같은 사용자가 짧은 시간 내 다른 PoP으로 갈 수 있어 데이터가 다르게 보일 수 있음.

  • 해결: 캐시 일관성 정책(SWR·ETag), DB 동기화

3) 디버깅 어려움

“내 IP는 1.1.1.1에 가는데 어느 PoP에 갔지?” 알기 어렵습니다.

  • 해결: 응답 헤더에 PoP 정보 포함 (예: X-Pop: NRT-1)

4) BGP 광고 손상 시 영향 큼

잘못된 광고가 나가면 모든 사용자가 영향. 2022년 Cloudflare 대규모 장애도 이런 사례.

  • 해결: 광고 변경에 엄격한 검토, 점진 롤아웃

5) DDoS 공격이 한 PoP에 집중

공격자가 특정 PoP의 BGP 경로를 의도적으로 노릴 수 있음.

  • 해결: PoP별 흡수 용량 충분히 확보

호스팅 환경에서 BGP Anycast 활용

자체 BGP Anycast를 운영하려면 다음이 필요합니다.

  1. 자체 AS 번호 (ASN) — 신청·할당받기
  2. PI(Provider-Independent) IPv4/IPv6 블록
  3. 여러 곳의 데이터센터 + 각자 BGP 피어링
  4. 각 PoP에서 동일 IP를 광고하는 라우터 설정
  5. 익명 추적·모니터링 인프라
# 단순화한 BGP 광고 설정 (FRR 예시)
router bgp 65001
 neighbor 192.0.2.1 remote-as 64500
 address-family ipv4 unicast
  network 198.51.100.0/24
 exit-address-family

자체 ASN과 PI 블록 보유는 비용·시간이 큽니다. 대부분의 호스팅 사용자는 Cloudflare·Fastly 같은 Anycast CDN을 앞단에 두는 방식이 현실적입니다.

CDN 없이 Anycast의 이점을 누리는 법

자체 Anycast가 무리라면 다음 옵션이 있습니다.

1) Anycast DNS 서비스 사용

도메인의 권한 DNS를 Cloudflare DNS, Route 53, NS1 같은 Anycast 서비스로. 전 세계 사용자에게 빠른 DNS 응답.

2) Anycast CDN 앞단 배치

오리진 호스팅 1대 + Cloudflare/Fastly 앞단. 정적 자원은 CDN에서, 동적 요청은 오리진으로.

3) Global Accelerator 류

AWS Global Accelerator나 GCP Global LB는 자체 Anycast IP를 빌려주고 트래픽을 가까운 리전으로 보냅니다.

TCP 연결도 Anycast 가능한가

전통적으로 “TCP는 Anycast 어렵다”고 했지만, 다음 환경에서 실제로 동작합니다.

  • BGP 경로가 비교적 안정적 (수시간 안정)
  • 짧은 세션 위주 (HTTP 같은)
  • PoP에서 세션 정보를 백엔드에 위임하지 않음 (Edge에서 종단)

Cloudflare·Fastly가 글로벌 HTTPS를 Anycast로 운영하는 게 그 증거입니다.

측정과 검증

자체 운영이든 Anycast 서비스를 쓰든, 다음 측정으로 효과를 확인하세요.

# 어느 PoP에 닿았는지
curl -sI https://example.com | grep -i pop

# 다양한 위치에서의 RTT
mtr --report --report-cycles 50 example.com

# 외부 측정 도구
# https://www.dotcom-monitor.com (여러 도시에서 측정)
# https://www.cloudping.cloud

지리적으로 다른 위치에서 측정해야 Anycast의 효과가 보입니다.

마무리

BGP Anycast는 글로벌 인터넷이 빠르고 회복력 있게 동작하는 핵심 기반입니다. 호스팅 운영자 입장에서 직접 구축은 비현실적이지만, Anycast DNS + Anycast CDN을 앞단에 두는 것만으로도 글로벌 사용자 경험이 크게 향상됩니다.

TCP-80.NET은 일본 도쿄 IDC를 오리진으로 두고 Cloudflare·BGP 라우팅 가이드를 @tcp80net으로 안내합니다. 글로벌 트래픽을 함께 받는 워크로드라면 전용서버 + CDN 조합을 권합니다.