Overview

네트워크 기술 하나 중 Anycast 는 DNS 서비스에서 주로 사용하고 있지만 KAKAO는 Anycast 기술을 확장하여 여러가지 어플리케이션 서비스에 사용되고 있습니다.

특히 서버에서 Quagga 오픈소스를 이용하여 KAKAO 자체 망을 이용한 각 글로벌 POP 에 비용 절감 및 고 가용성 용도로도 많이 사용되고 있습니다.

Anycast 란?

Anycast 라는 용어가 매우 생소한데요. Anycast 란 용어는 네트워크 용어 입니다. 우리가 보통 알고 있는 IP주소는 Unicast IP이며 이것은 고유한 IP주소입니다. Anycast IP는 서로 다른 곳, 서로 다른 호스트 끼리 동일한 IP주소를 가질 수 있는 개념입니다. 그런데 이때의 문제점은 가끔 사무실에 출근하면 누군가 내 IP를 써서 IP충돌나듯이 IP가 충돌나겠죠^^.

그러나 이 충돌된 IP들의 회피 방법은 BGP와 같은 라우팅 프로토콜에 의해서 해결합니다. 라우팅 프로토콜에 의해 이 충돌난 IP에 대해서 가장 최적의 경로의 IP를 가진 서버를 1개 선택해서 라우팅 해줍니다. (사무실과 같은 L2 에서는 IP가 충돌나면 사용이 불가능하지만 라우터 같은 L3 에서는 충돌나도 가능합니다. 같은 IP를 각 라우터들이 어나운스 하며 가장 가까운 곳으로 판된되는 쪽으로 사용합니다.)

라우팅 코스트가 가장 적은 쪽의 경로를 선택, 라우팅 코스트가 같다면 로드 발란싱

Anycast DNS

Anycast 는 주로 DNS 서비스에 많이 활용 됩니다. Anycast 기법을 사용하여 DNS 서버를 지역별 분산 구성하여 DNS 질의를 요청한 클라이언트와 가장 근접한 DNS 서버가 처리하도록 하여 응답속도와 안정성을 향상 시킨 DNS를 말합니다. 항상 네트워크 경로상 가장 가까운 DNS 서버가 응답합니다. 또한 가장 가까운 DNS가 장애가 발생되면 라우터에서 어나운스가 되지 않아 자동으로 빠지며 그 다음 가까이 위치에 있는 DNS가 대신 처리합니다.

Google public DNS를 Anycast로 구성하여 가장 가까운 지역에서 DNS서비스를 받는 과정

Anycast DNS 도입배경

Anycast 가 도입된 이유는 2002년 10월 root DNS DDoS공격으로 전 세계 13개 root DNS중 8개가 다운, 2003년 1.25 인터넷 대란때 5개의 root DNS가 웜으로 DDoS공격당하여 전세계 DNS가 마비되어서 개선안으로 Anycast 기술을 사용하게 되었습니다. Anycast IP를 이용하여 DNS를 적절히 분산구성하여 한쪽 지역이 무너지더라도 다른 지역에서 서비스를 받을 수 있도록 하였습니다.

Google public DNS

가장 좋은 예제로는 우리가 잘 알고 있는 Google public DNS의 IP 8.8.8.8 도 Anycast로 구성되어있으며 전세계 국가에 분산 되어있고 그 규모는 엄청 납니다. Google public DNS를 쓰면 자신이 속한 지역에서 라우팅 경로가 가장 최적인 지역의 DNS 서비스를 받고 Google 서비스에 대한 서비스도 최적에 있는 지역에 서버에 서비스 받습니다. 아시아에선 대만과 홍콩에 있네요.

참고: https://developers.google.com/speed/public-dns/faq#locations

KAKAO의 Anycast 활용 사례

Anycast 는 주로 connectionless UDP 프로토콜에 최적화된 DNS에 주로 쓰이고 있습니다. 그 이유는 상황에 따라서 네트워크 경로가 바뀔 수 있으므로 한쪽 서버로 세션을 지속적으로 상태 보존이 필요한 TCP 프로토콜에는 부적합하다는 판단 때문입니다. 그러나 Web Cache 등의 경우엔 트랜잭션을 보장해야 되는 부분이 없어 KAKAO는 이러한 부분에 TCP 프로토콜인 Contents Cache 서비스 부분에도 활용하기로 했습니다. 또한 Floating IP Address 용으로 Anycast 관련된 기술을 활용하여 Virtual IP 방식으로 동작시켜 원래 Anycast 목적과는 다른 용도로 사용하고 있습니다.

KAKAO DNS

KAKAO 도메인을 전세계 알리기 위한 각 지역별 KAKAO 글로벌 POP에 배치하여 국내 인터넷 사이트 중 가장 빠른 DNS 서비스를 제공합니다.

구성하게 된 계기는 해외에서 국내 사이트를 호출하면 굉장히 느린데 그 느린 이유 하나가 도메인 응답만 수 초가 소요됩니다. 대부분 국내 웹 사이트들은 글로벌하게 사용하지 않으므로 각 지역의 사용자가 사용하는 지역 DNS에 도메인 Cache가 되지 않고 모두 한국에 각 도메인 소유의 권한 DNS 서버까지 왕복하는 시간이 걸리며 이로 인해 DNS 응답만 수 초가 걸릴 수 도 있습니다.

또한 GSLB 장비의 사용으로 GSLB 헬스체크로 인한 TTL이 짧은 GSLB 주소로 CNAME 위임을 하게 되는데 이러면 위임된 GSLB 장비까지 질의가 왕복 되고, 짧은 도메인 TTL로 인한 각 사용자 지역의 DNS에 Cache가 잘되지 않아 시간은 더 소요됩니다.

GSLB CNAME 위임은 DNS 응답 속도 측면에서 매우 안 좋은 방법입니다. 또한 속도를 빠르게 하기 위해서 고가의 GSLB 장비를 각 글로벌 POP 지역에 배치하면 비용이슈가 있습니다.

따라서 KAKAO는 GSLB Edge DNS Cache를 각 글로벌 POP에 배치해 Anycast로 구성하여 이러한 경우에도 가장 빠른 응답을 줄 수 있도록 노력하고 있습니다.

KAKAO는 가장 빠른 DNS 응답을 위해 노력하고 있습니다.

KAKAO Cache DNS

KAKAO는 여러 IDC를 사용하고 있는데 IDC 내부에 서버들이 가장 빠른 내부 DNS 서비스를 받기 위해서 사용됩니다. IDC 마다 Anycast 방식으로 구성해 한쪽 IDC가 무너져도 안정적인 내부 DNS 서비스를 위한 용도 입니다. 또한 서버의/etc/resolv.conf의 nameserver 주소를 통합시켜 OS DNS 정책을 표준화 할 수 있습니다.

KAKAO Contents Cache Server

DNS 뿐만 아니라 각 글로벌 지역에 분산된 KAKAO 자체 글로벌 POP 을 이용하여 사용자가 가장 빠른 지역으로 Cache 서비스를 받기 위해서 사용됩니다. KAKAO는 GSLB + Anycast 함께 조합으로 사용자가 사용하는 지역 DNS IP Source 기반인 GSLB 으로만 부정확한 부분을 최소화 하고 있습니다.

동남아 국가 모바일에서는 사용자가 Google public DNS, OpenDNS 및 정책 필터링으로 지정된 DNS로 사용 하는 부분이 있어 이 부분을 제대로 컨트롤 할 수 없는 부분이 있는데 Google public DNS source Physical IP의 정확한 위치 추적 및 Anycast 조합으로 사용자가 가장 가까운 Contents Cache Server 를 만나게 해줍니다.

또한 블랙베리의 BIS망을 분석하고 최적화 하여 블랙베리에서도 KAKAO는 빠른 응답을 주도록 노력하고 있습니다.

Floating IP Address 용

서버에 Physical IP를 사용되면 잦은 IP 변경시 네트워크 VLAN 변경등 어려움이 따르므로 손쉽게 컨피그 수준으로 IP 를 조정하여 이용합니다. 이것은 Anycast 의 기본 목적과는 다른 목적으로 Virtual IP 용으로 사용됩니다.

Anycast의 장단점

장점은

L4/L7 같은 로드 밸런싱 장비가 필요 없는점: 글로벌 POP에 서버 가용성 및 성능 로드 발란싱을 위해서 비싼 L4/L7장비를 내보내지 않아도 됩니다. 라우터 + 서버로만 동작. LVS 등 서버 로드 밸런싱 기법이 있지만 구성을 위한 추가 서버가 필요하게 되므로 결론적으로 서버 대수를 줄일 수 있습니다.
사용자와 가장 가까운 지역으로 안내
L4/L7 에서 인바운드 대규모 트래픽이 들어오면 장비에서 입력 트래픽 자체가 버티기 힘들지만 서버로 직접 들어오기 때문에 서버를 분산하여 입력 대규모 트래픽을 처리 할 수 있는 용도로 사용 할수 있습니다.
우리나라와 연결된 KAKAO 1개 글로벌 POP이 국제 회선 문제등으로 장애시 다른 Anycast 지역으로 자동 우회 합니다. 이에 따라 회선을 이중화 하지 않아도 되며 속도 측면엔 다른 Anycast 지역으로 우회하기 때문에 복구 될때 까지 차선의 지역으로 인해 약간 느려질 수 있으나 회선 이중화 비용을 절감할 수 있습니다.
오픈소스로 구현해서 비용이 들지 않고 구성이 간단하고 안정성이 뛰어납니다.

단점은

네트워크 적으로 가까운 곳을 택하기 때문에 지리적인 지역성을 따르지 않을 수도 있습니다. 예를들어 가까운 싱가폴 인접지역 사용자가 싱가폴 POP으로 들어오면 좋지만 네트워크적으로 미국이 가까워 미국으로 가는 경우가 있습니다. 이것은 ISP 마다 라우팅 정책이 있으므로 컨트롤이 어렵습니다. 특히 KAKAO와 비슷한 방법으로 Google, 아마존, 아카마이등 자체망을 운영하는 곳과 정확한 위치 연동이 어려운 부분이 있습니다. (ex. Google public DNS 홍콩 POP지역 경우는 Physical IP는 정보는 미국이지만 실제 서버는 홍콩에 있기 때문에 홍콩에서 매우 가깝게 응답 됩니다.)
라우터에서는 라우터 이기 때문에 L4/L7 와 달리 서버의 어플리케이션의 헬스체크가 안되어서 이상동작 여부를 판단 할수 없습니다. KAKAO에서는 자체 모니터링 툴을 이용해서 어플리케이션 장애시 서버의 BGP 데몬을 직접 컨트롤하여 서비스 제외하도록 하고 있습니다. (서버가 죽으면 서버에서 BGP 어나운스를 하지 않기 때문에 이러한 경우는 자동 서비스 제외가 됩니다.)

실제 구현 예제

KAKAO에서는 오픈소스를 이용하여 구성하였는데요, 그 구체적인 예제는 아래 링크에 잘 설명되어 있습니다.

참고: Anycast DNS - Part 5, Using BGP

대략적인 예제 토폴로지는 아래와 같습니다.

예제 토폴로지

서버 측면에서 구성 방법을 설명 드립니다. (모든 서버는 동일한 설정을 갖습니다.)

예제의 IP 설명
Anycast IP :192.168.1.3
서버의 Anycast AS : AS65000
Anycast Host의 Physical IP : 172.16.1.3
라우터의 IP : 172.16.0.1
라우터의 AS : AS65002

서버에 Anycast IP를 사용할 Loopback IP를 설정합니다.

ex) CentOS(RedHat) 기준

cat /etc/sysconfig/network-scripts/ifcfg-lo:0
#ANYCAST Loopback
DEVICE=lo:0
IPADDR=192.168.1.3
NETMASK=255.255.255.255
NETWORK=192.168.1.3
BROADCAST=192.168.1.3
ONBOOT=yes
NAME=loopback:0

Quagga bpgd.conf 설정은 아래와 같습니다.

cat /etc/quagga/bgpd.conf
!
! Zebra configuration saved from vty
!   2013/06/21 11:53:36
!
hostname anycast-host001
password *************             # 콘솔 Password 시스코 라우터 명령어로 조작
log file /var/log/quagga/bgpd.log
log stdout
!
router bgp 65000                   # 라우터와 통신하기 위한 사설 AS
bgp router-id 172.16.1.3      # Anycast 서버의 Physical IP
network 192.168.1.3/32
neighbor 172.16.0.1 remote-as AS65002        # 라우터의 AS 및 IP
neighbor 172.16.0.1 prefix-list PERMIT-DEFAULT in
neighbor 172.16.0.1 prefix-list ANYCAST out
!
ip prefix-list ANYCAST seq 5 permit 192.168.1.3/32
ip prefix-list PERMIT-DEFAULT seq 5 permit 0.0.0.0/0
ip prefix-list PERMIT-DEFAULT seq 10 deny 0.0.0.0/0 le 32
ip prefix-list REJECTALL seq 5 deny 0.0.0.0/0 le 32
!
line vty
!

이후, 라우터 세팅
동작 순서

Anycast Loopback IP up

# ifup lo:0

BGP up

# /etc/init.d/bgpd start

telnet 2605 콘솔 포트로 BGP 콘솔로 들어가서 시스코 라우터 명령어로 CLI 가능합니다.

ex) 서버에서 라우터와 BGP 연결 상태를 보는 예제

telnet 127.0.0.1 2605
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.Hello, this is Quagga (version 0.99.20.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification

Password:
anycast-host001> en
anycast-host001# show ip bgp summary
BGP router identifier 172.16.1.3, local AS number 65000
RIB entries 5, using 480 bytes of memory
Peers 1, using 4560 bytes of memory

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
172.16.0.1      4 65000  235327  224046        0    0    0 11w0d19h        0

Total number of neighbors 1

간단한 쉘방식의 self 모니터링의 예제 (cron 등에 넣어서 사용)

ex) 예제에서는 DNS 응답이 이상하면 bgp 데몬을 자체적으로 내려서 서비스 제외합니다.

#!/bin/bash
DNSUP=`/usr/local/bin/dig @192.168.1.3 www.kakao.com A +short`
if [ "$DNSUP" != "110.76.141.122"];
then
echo "Stopping Anycast...."
/etc/init.d/bgpd stop
else
echo "Everything's good... Do nothing..."
fi

[Quaaga] 팁

마지막으로 Quagga 를 이용하면서 실제 구현하면서 알게된 몇가지 팁을 소개합니다.

Quagga 에는 라우팅 프로토콜에 따라서 몇가지 레이어로 나뉘어져있는데 각 레이어는 별도의 데몬으로 동작합니다. 커널 라우팅과 다른 라우팅 데몬과 연계할 필요없이 Anycast 로만 동작시킬려면 해당되는 라우팅 프로토콜 관련 데몬 1개만 올리면 됩니다. 하위 레이어 중 zebera 데몬 구성을 하지 않아도 되므로 구성을 간단하게 할 수 있습니다.

ex) KAKAO는 bgpd 데몬만 올려서 사용합니다.

라우터에서는 L4/L7 과 같이 헬스체크 기능이 없으므로 문제가 생기면 모니터링 데몬을 만들어서 해당되는 라우팅 데몬만 내리면 라우터에서 자동 제외 됩니다. bgp 데몬을 soft하게 내려주면 패킷이 하나도 빠지지 않아서 최신 L4 L3DSR Loopback 을 내릴때 L4가 헬스체크 감지할동안 손실이 있는데 이 부분이 없습니다.

ex) KAKAO는 bgpd 데몬을 내려 서비스를 안전하게 제외합니다.

Conclusion

Anycast 는 글로벌 서비스에서 매우 유용하고 필수적인 기술이라고 판단되며 일반적으로 DNS로만 사용하지만 KAKAO에서 실험과 실제 서비스에 적용결과 DNS외에 Contents Cache 서비스에서도 문제 없이 동작하였습니다.

특히 사용자가 사용하고 있는 지역 DNS source IP 기반으로 하는 GSLB 만으로는 일부 모바일 및 사용자가 지정한 Google public DNS 사용 및 일부 국가의 필터링을 위해 지정된 DNS 사용등 으로 정확한 타케팅을 할 수 가 없습니다.

Anycast 로 이러한 부분을 어느정도 해소 할수 있을것이란 판단이 들며 서버에서 올릴 수 있는 Quagga 외 ExaBgp 등 다양한 오픈소스네트워크 라우팅 프로토콜 데몬으로 전용 네트워크 장비 없이 손쉽게 구현할 수 있겠습니다.

kakao의 Anycast 활용 사례