GSLB의 이해와 서비스 예시

이번에 면접에서 인프라 관련 질문을 받았는데, 트래픽이 심한 사이트의 로드 밸런싱에 대한 내용이었다.

그래서 AWS 공부했던 내용을 떠올리고 ELB 얘기를 열심히 했는데...

갑자기 들어온 질문.

DNS에서 로드 밸런싱을 하는 방법은 없을까요?

 

아쉽게도 여기서 더 좋은 대답을 해내지는 못했지만, 면접 후에 GSLB에 대해 공부해 보라는 조언을 받았다.

GSLB가 뭘까? 그리고 왜 필요할까? 이 글은 그 대답을 위해 작성되었다.

---

DNS

Domain Name System(DNS)은 사람이 읽을 수 있는 도메인 이름(예: kafcamus.tistory.com)을 기계가 읽을 수 있는 IP 주소(예: 192.0.0.1)로 변환한다.

좀 더 자세히 알아보자. 한국인터넷정보센터의 DNS에 대한 설명 이미지를 먼저 보겠다.

네트워크 상에서 컴퓨터간 구별을 위한 IP 주소를 사람이 외울 수 없기 때문에, 우리는 각각의 주소에 할당할 도메인 주소 체계를 만들었다. 이러한 도메인 주소 체계는 수직적으로 구성되며, 최상위 도메인부터 트리 형태로 접근하여 원하는 주소를 찾을 수 있도록 되어있다.

이러한 작업을 수행하기 위해 도메인 네임 서버(Domain Name Server)가 존재하며, 한국에서는 ISP를 비롯하여 한국인터넷진흥원(KISA) 등에서 제공하는 도메인 네임 서버가 운영중에 있다. 또한 구글에서 제공하는 public DNS 등도 운영중에 있다.

 

그런데, 여기서 한가지 질문이 생긴다.

만약 내가 어떤 링크에 접속하려고 하는데, 해당 사이트가 트래픽이 매우 많은 사이트(예: 재난지원금 신청 사이트, 백신 접수 사이트 등등...)라면 어떨까?

DNS에서 해당 도메인에 할당된 IP만 전달하면, 과연 해당 사이트에서 적절하게 로드 밸런싱을 보장할 수 있을까?

여기서 하나의 아이디어가 생긴다. DNS 자체에서 로드 밸런싱을 해주면 어떨까?

---

GSLB

Global Server Load Balancing(GSLB)는 DNS 서비스 기반으로 사용자가 원하는 엔드포인트(서버 혹은 도메인) 및 정책을 이용해 안정적으로 트래픽을 로드밸린싱하는 서비스이다.

(위의 설명은 TOAST의 GSLB 서비스 소개에서 인용)

또한 이를 위해, 각각의 분산된 서버 혹은 도메인의 헬스 체크 모니터링을 수행하고, 다양한 로드 밸런싱을 수행할 수 있는 서비스 라고도 할 수 있다.

 

이러한 서비스가 왜 필요할까? 몇 가지 예시를 들어 보자.

• 트래픽 분산: 앞선 예시처럼 트래픽이 몰리는 서비스라면, 여러 개의 서버를 운영하면서 GSLB를 통해 각 서버의 IP를 분산시켜 전달할 수 있다.
• 재난 복구: 어떤 서비스가 재해나 사고로 운영 중지되었다면, 백업 서비스나 분산된 다른 서비스로 적절히 로드밸런싱을 할 수 있다.
• 성능: 만약 여러 리전에 서비스가 분산되어 있다면, 지리적으로 가깝거나 레이턴시가 짧은 주소로 연결하여 성능을 향상시킬 수 있다.

---

DNS vs GSLB

그렇다면 기존 DNS와 비교했을 때 GSLB가 어떤 강점을 가질까?

NETMANIAS TECH-BLOG의 글을 바탕으로 분석해 보았다.

Issue	DNS	GSLB
재난 복구	헬스 체크를 수행하지 못하므로, 특정 서버가 다운되어도 요청을 보냄	헬스 체크를 통해 다운된 서버로 사용자가 연결되는 것을 방지
사이트 로드 밸런싱	서버의 부하를 알 수 없으므로 과부하된 서버가 있어도 요청을 보내게 됨	서버의 부하 상태를 체크하고 적절하게 로드 밸런싱을 수행할 수 있음
네트워크 근접성	사용자와 서버 간의 RTT(Round Trip Time)을 측정할 수 없어 망 상태를 고려한 서버 선택이 불가	사용자와 서버 간의 RTT를 측정하고 응답이 빠른 서버로 사용자를 연결 가능
지리적 근접성	사용자의 지리적 위치를 고려하여 응용 서버를 선택할 수 없음	사용자의 지리적 위치를 고려하여 응용 서버를 선택할 수 있음

---

실제 서비스 예시: GRM

그렇다면 GSLB 서비스의 예시로는 어떤 것이 있을까?

먼저 네이버클라우드의 Global Route Manager(GRM)을 보자.

해외에서도 늘 막힘 없는 서비스를 제공하고 싶다면? 똑똑한 DNS 기반의 GSLB를 이용해보세요! - Glo

해당 블로그에서 GSLB 서비스에 대한 소개 뿐 아니라, 여러 작동 로직을 소개하고 있다.

 

GRM을 적용 시 4가지 로드밸런싱 정책 타입을 제공한다고 한다.

• Roundrobin: IP를 여러 개 등록하고 헬스 체크를 통해 문제가 있는 리소스를 제외할 수 있는 정책
• Weighted: 주소별로 응답 비율을 다르게 할 수 있는 정책
• GeoLocation: 국가/IP 대역 기준으로 사전에 설정된 Rule에 따라 응답 주소를 분산하는 정책
• Failover(예정): 특정 IP나 복수개의 IP가 다운되었을 때, Backup IP로 응답할 수 있도록 하는 정책

이 이미지는 Roundrobin 방식의 예이다. 더 자세한 예는 NCP 블로그 참조

실제 서비스 예시: Route 53

다른 예시도 한번 보자. AWS에서 제공하는 DNS 서비스인 Route 53 역시 이러한 GSLB 기능을 제공한다.

Route 53은 애플리케이션, 웹 서버 등 리소스에 대한 성능을 모니터링하는 헬스 체크 기능을 제공하며, 이에 더해 라우팅 정책을 적용하여 최고의 연결성을 사용자에게 제공할 수 있다.

 

AWS의 라우팅 정책 문서를 보면, Route 53을 통해 다양한 라우팅 정책을 적용할 수 있음을 알 수 있다.

라우팅 정책 선택 - Amazon Route 53

• 단순 라우팅 정책: 도메인에 대해 하나의 리소스만 있는 경우
• 장애 대응 라우팅: 장애 대응을 통해 가용 리소스 쪽으로 트래픽을 라우팅
• 지역 DNS 라우팅: 사용자의 지역에 따라 가장 가까운 엔드포인트로 트래픽을 라우팅
• 지연 기반 라우팅: 지연이 짧은 리소스에 라우팅해 최저 지연 시간으로 리소스 제공

위의 정책 외에도 가중치 기반 정책 등의 다양한 정책이 존재한다.

---

마치며

GSLB가 무엇인지 정리해 보려다가, 얼결에 서비스 소개까지 써버렸다.

요새 면접때문에 참 힘들지만, 한편으로는 재미있는 경험을 많이 쌓고 있다.

합격과 불합격을 넘어, 뭐 어쨌든 개발을 즐기는 동료와 이야기를 나누고

겸사겸사 모르는 것 몇 개 배워가는 시간이 소중하다. GSLB도 이 기회 아니었으면 몰랐겠지.

 

늘 이렇게 느긋한 삶을 꿈꾸나, 어째 갈수록 빠듯한 마음이 아쉽다.

아무쪼록, 도움이 되기를 바라며 글을 마친다.

 

출처

• NETMANIAS TECH-BLOG: Enterprise를 위한 GSLB(Global Server Load Balancing) (링크)
• TOAST 블로그: GSLB 서비스 소개(TOAST Service 들여다 보기) (링크)
• AWS docs: 라우팅 정책 선택 (링크)
• Naver Cloud Platform 블로그: Global Route Manager(GRM) (링크)
• Baeldung: Introduction to the Domain Name System(DNS) (링크)
• 한국인터넷정보센터: DNS란? (링크)

 

잘못된 내용이 있다면 댓글 부탁드립니다.