GSLB, CDN - 트래픽을 분산하는 방식 (+ DSR, AWS)

 

 

트래픽(Traffic)이란 인터넷에서 송수신되는 데이터 전송량을 의미한다. 우리는 이 트래픽을 분산시킬 수 있도록 개발하고 인프라를 구성한다. 트래픽을 분산하는 것을 로드 밸런싱(Load Balancing)이라고 한다. 로드밸런싱이 필요한 이유는 티켓팅을 할 때 지나친 트래픽이 발생하면 서버가 다운되기도 하고, 사용자에게 좋은 품질의 서비스를 제공하기 위해서다. 

 

이 글은 트래픽을 분산하는 방식인 CDN과 GSLB를 소개하고, DSR과 AWS 서비스를 함께 설명할 것이다.

 

1️⃣ GSLB(Global Server Load Balancing)

DNS를 이용한 로드밸런싱

 

[그림1] GSLB (출처 : https://www.samsungsds.com/kr/network-gslb/gslb.html)

 

 

GSLB를 간단하게 설명하면 'DNS를 이용한 로드밸런싱'이라고 한다. DNS(Domain Name System)는 전 세계의 호스트 이름을 IP주소로 변환해 주는 디렉터리 서비스다. 그래서 GSLB는 전 세계에 분산된 데이터센터를 대상으로 로드 밸런싱을 수행한다.

 

GSLB는 글로벌 특정 지역에 트래픽이 증가할 경우에 DNS 기반으로 인접 지역으로 네트워크 트래픽을 자동 분산한다. 뿐만 아니라, 특정 서버에 장애가 발생할 경우에는 네트워크 트래픽을 정상 리소스로 로드 밸런싱함으로써 서비스가 안정적으로 지속될 수 있도록 한다.

 

 

📌 GSLB가 트래픽을 분산하는 방식

• 지리적 위치 기반 : 클라이언트의 위치에 따라 가까운 데이터 센터로 연결
• 지연 시간 기반 : 가장 응답 시간이 빠른 서버로 연결
• 서버 가용성 기반 : 특정 서버에 장애가 발생하면 자동으로 다른 서버로 트래픽 전환

 

💬 DSR(Direct Server Return)

DSR은 요청은 로드 밸런서를 통해 받지만, 응답은 클라이언트에게 직접 반환한다. 일반적인 서비스들은 로드 밸런서를 통해 요청을 받고 응답을 전달하는데 이 방법은 라우터에 부하가 크다. 특히 OutBound 트래픽에 대해서 부하가 크기 때문에 기업에서는 DSR을 통해 라우터의 부하를 최소화한다. 예를 들어 네이버, 쿠팡 홈페이지를 들어가보면 알겠지만 수많은 이미지와 영상들이 존재하기 때문에 당연히 InBound보단 OutBound 트래픽이 크다고 하는 것이다.

 

[그림2] DSR (출처 : https://tech.kakao.com/posts/306)

 

위 사진에서 클라이언트(카카오톡유저)가 데이터를 요청한다고 가정해보자.

 

클라이언트(카카오톡유저)는 IP 주소 211.115.115.100을 가진 목적지로 데이터를 요청한다. L4 스위치는 트래픽을 10.10.10.X 대역의 서버로 로드 밸런싱하며, 해당 서버(Real Server Farm)는 요청을 처리한다. 이번에는 L4 Switch를 거치지 않고 직접 클라이언트에게 전송한다. 이때 발신 IP를 10.10.10.X가 아닌 로드 밸런싱 전의 목적지 IP인 211.115.115.100으로 변환한다. 이는 네트워크 통신에서 대상 IP를 검사하여 일치하지 않을 경우 패킷을 폐기하기 때문이다.

 

이렇게 DSR을 이용하면 응답 속도를 빠르게 만들 수 있고, 트래픽이 많을 경우 로드밸런서의 부하를 줄일 수 있다.

 

 

kakao는 로드 밸런싱을 위한 메커니즘으로 L3DSR 방식을 사용하고 있다고 한다. 이 글을 참고하면 좋을 것 같다.

kakao의 L3DSR 구성 사례 - tech.kakao.com

 

 

2️⃣ CDN(Content Delivery Networks)

캐싱 서버를 전 세계에 위치시킨 로드 밸런싱

만약 Netflix가 데이터 센터를 하나만 가지고 있다면 어떤 문제가 발생할까?

 

1. 지리적 위치 : 클라이언트가 데이터 센터로부터 지리적으로 먼 경우, 서버로부터 클라이언트로의 패킷 경로는 수많은 통신 링크과 ISP를 거쳐야 하기 때문에 서비스 제공 속도가 느려진다.
2. 중복 비용 : 오징어 게임처럼 인기 있는 비디오는 같은 통신 링크를 통해 여러 번 반복적으로 전송된다. 네트워크 대역폭의 낭비와 ISP들에게 동일한 데이터를 전송하는 것에 대해 중복 비용을 지불하게 된다.
3. 장애 위험 : 한 번의 장애로 전체 서비스가 중단될 수 있는 위험이 있다.

 

이러한 문제들이 있기 때문에, 콘텐츠 제공 회사는 CDN을 사용한다. CDN은 다수의 지점에 분산된 서버들을 운영하며 정적 콘텐츠의 복사본을 여러 분산 서버에 저장한다. 그리고 클라이언트는 최선의 서비스를 제공받을 수 있는 지점의 CDN 서버로 연결된다.

 

 

🤖 CDN의 동작 방식

만약 사용자가 콘텐츠를 요구하면 가장 가까운 엣지에서 해당 콘텐츠가 있는지 확인한다. 없다면 네트워크를 통해 원본(Origin)으로부터 빠르게 콘텐츠를 받아오고 캐시에 저장한다. 로컬에 있다면 Cache Hit이므로 그대로 반환한다. 덕분에 우리는 동영상과 같은 무거운 데이터를 고객에게 빠르고 효율적으로 전달할 수 있다.

 

캐시의 고질적인 문제인 '데이터 무결성'은 캐시 무효화 정책을 통해 해결한다. CDN 서버는 TTL에 따라 콘텐츠를 저장한다. TTL의 기간이 끝나지 않았다면 콘텐츠를 유효하다고 본다. 만약 TTL 기간이 남은 컨텐츠를 내가 오리진에서 업데이트를 진행했어도 CDN 서버의 콘텐츠는 그대로다. 이때 캐시 무효화를 진행하면 특정 파일들을 무효화(삭제)할 수 있다. 그러면 다른 유저가 같은 파일을 요청하면 다시 오리진에서 파일을 받아온다.

 

* TTL : Time To Live, 데이터가 유지될 시간을 결정함.

 

TTL의 기간이 끝나지 않았다면 컨텐츠를 유효하다고 본다. 만약 TTL 기간이 남은 컨텐츠를 내가 오리진에서 업데이트를 진행했어도 CDN 서버의 콘텐츠는 그대로다. 이때 캐시 무효화를 진행하면 특정 파일들을 무효화(삭제)할 수 있다. 그러면 다른 유저가 같은 파일을 요청하면 다시 오리진에서 파일을 받아온다.

 

 

📡 CDN 클러스터 선택 정책

CDN 구축의 핵심 중 하나는 클러스터 선택 정책이다. 클러스터란 여러 서버를 하나의 네트워크로 연결하여 데이터를 처리하고 관리하는 집합체이다. 앞서 CDN의 동작 방식을 설명할 때 가장 가까운 엣지에서 해당 콘텐츠가 있는지 확인한다 고 했는데, 이때 클러스터 선택 정책을 사용한다고 생각하면 된다.

• 지리적으로 가장 가까운 클러스터 할당하기 : 가장 가까운 클러스터가 항상 최적의 성능을 제공하는 것은 아니다. 네트워크 혼잡이나 ISP 경로 문제로 인해 실제로는 더 느릴 수도 있다.
• 실시간 성능 측정(Real-time Measurement) : CDN은 주기적으로 클러스터와 클라이언트 간의 지연 시간과 손실 성능을 실시간 측정한다. 각 클러스터가 ping이나 DNS 질의 같은 probe 메시지를 주기적으로 LDNS들에게 전송하게 할 수 있다. (LDNS는 메시지에 응답하지 않음.) 따라서 실시간 성능 측정을 함께 사용한다.

 

💬 AWS Global Accelerator

AWS Global Accelerator는 AWS 내부 네트워크(Backbone Network)를 활용하여 트래픽을 가속하는 서비스이다. CDN과 달리 정적 콘텐츠뿐만 아니라 API, VPN, IoT 등 TCP/UDP 기반 트래픽에도 적용할 수 있다. 당연히 퍼블릭 인터넷보다 빠르고 안정적인 경로 제공  하고, 사용자의 위치에 따라 가장 가까운 AWS 리전으로 트래픽을 자동 라우팅한다.

 

🔗 참고 : https://aws.amazon.com/ko/global-accelerator/

네트워크 가속 서비스 - AWS Global Accelerator - AWS