GSLB, 트래픽이 높을 때 로드밸런싱하기

LB, 로드 밸런싱

로드 밸런싱에는 여러가지 종류가 있다.

L4, L7이 대표적이다.

그 중에서 L7은 현재 어떻게 쓰이고 있는지 GSLB를 통해서 알아보자

 

 

---

 

GSLB란 무엇일까?

 

Global Server Load Banlancing은 DNS기반으로 사용자가 원하는 엔드포인트에 안정적인 트래픽을 로드밸런싱하는 서비스를 말한다.

 

요약하자면

 

- DNS 기반의 로드밸런싱 서비스

- 헬스 체크 모니터링이 가능한 DNS

- 서비스의 안정성을 높일 수 있는 다양한 로드밸런싱 정책을 적용할 수 있는 솔루션

 

서비스가 제공하는 기능은 크게 4가지가 있다.

1. 트래픽 분산(Site Load Banlancig)
2. 재난복구(Disaster Recovery)
3. 성능(Network Proximity, Geographic Proximity)

여기서 SLB라는 것이 많이 나오는데

SLB는 Server Load Balancing이다.

SLB가 L4에서 Switch를 통해 서버의 Health Check를 하면서 Load Balancing을 했다면

GSLB는 Geographic하게 지리적으로 여러 개의 Site에서 동일하게 작동하는 것이다.

---

예시

■ 구성

• 총 4대의 www.example.com 웹서버 중, 2대는 한국(KR) 사이트에 2대는 미국(US) 사이트에 위치함
• 각 사이트 웹서버 앞단에는 SLB가 위치하여 사용자는 www.example.com 웹서버의 IP 주소(10.1.1.10 ~ 13)가 아닌 SLB의 Virtual IP 주소(1.1.1.1, 2.2.2.2)로 접속을 요청하고, SLB가 Destination IP 주소 변환 후 웹서버로 전달
• 한국 사이트에는 GSLB와 example.com DNS 서버가 위치함 

 

■ 서비스 로직

1. 사용자가 www.example.com에 접속하기 위해 Local DNS 서버로 DNS Query를 보내고, Local DNS 서버는 Root DNS, .com DNS 서버를 거쳐
2. GSLB로 www.example.com에 대한 DNS Query를 보냄
3. GSLB는 DNS Proxy로 동작하며, 따라서 이 DNS Query를 그대로 example.com DNS 서버로 전달
4. example.com DNS 서버는 www.example.com에 대한 IP 주소(SLB의 Virtual IP) 1.1.1.1과 2.2.2.2가 미리 등록되어 있어 그 값을 GSLB로 전달, 전달 시 TTL은 300초라고 가정
5. GSLB는 나름의 정책(뒤에서 설명)을 통해 1.1.1.1과 2.2.2.2 중에 사용자를 위한 최적의 사이트를 결정하고 또한 TTL을 작은 값으로 변경(예. 10초) TTL 값 변경은 Local DNS 서버가 바인딩 정보(www.example.com에 대한 IP 주소)를 최소 시간 동안만 캐싱하게 하기 위함
6. GSLB의 정책(GSLB Policy)을 통해 결정된 웹서버 IP 1.1.1.1(혹은 IP 주소 리스트의 순서를 바꿔 1.1.1.1, 2.2.2.2로)과 변경된 TTL 값이 Local DNS로 전달되고,
7. Local DNS는 사용자 단말에게 그 값을 전달
8. 이제 사용자는 www.example.com의 IP 주소 1.1.1.1을 목적지로 하여 한국 사이트 SLB1으로 HTTP GET을 보내고, SLB1은 다시 나름의 정책(서버 Health/Load 등 고려)을 적용하여 최종 서버인 10.1.1.10으로 HTTP GET 메시지를 전달

---

기업들의 GSLB 적용

역시 많은 기업들이 GSLB를 제공하고 있다.

국내기업을 예로 들면 네이버 클라우드가 있다.

https://blog.naver.com/n_cloudplatform/221206343859

GRM이 있다.

아마존에는 ELB가 있다.

https://aws.amazon.com/ko/elasticloadbalancing/

---

 

ELB에 대해서 더 알아보자

Application Load Balancer가 우리가 말하는 GSLB와 같다.

 

하지만 AWS가 주장하는 기능은 아주 많다.

GSLB는 L7 LB로 Application Load Balancer의 기능을 보면 된다.

 

Application Load Balancer의 구성 요소

-Listener

-Target Group

-Load Balancer

Application Load Balancer가 작동하는 순서

1. 클라이언트에서 요청을 보냄
2. LB가 요청을 받아 우선 순위에 따라 Listener 규칙을 평가 후 적용할 규칙 지정
3. 규칙 작업의 Target Group 에서 특정 Target을 선택

 

** LB를 할 때 적용되는 Default Algorithm은 Round Robin

** Target을 추가, 제거하더라도 수행에 문제 없음

** ELB에서는 LB의 확장을 지원함

AWS에서 공식적으로 지원하는 기능(Link)

여기서 우리가 중요하게 생각하는 기능을 빨간색으로 바꾸었다.

• 경로 조건에 대한 지원. 요청의 URL을 기반으로 요청을 전달하는 리스너에 대한 규칙을 구성할 수 있습니다. 이를 통해 애플리케이션을 규모가 더욱 작은 서비스로 구성하고, URL 콘텐츠를 기반으로 요청을 올바른 서비스로 라우팅
• 호스트 조건에 대한 지원. HTTP 헤더의 호스트 필드를 기반으로 요청을 전달하는 리스너에 대한 규칙을 구성, 따라서 단일 로드 밸런서를 사용하여 여러 개의 도메인에 요청을 라우팅
• HTTP 헤더 조건 및 메서드, 쿼리 파라미터, 소스 IP 주소 등 요청의 필드를 기반으로 하는 라우팅을 지원
• 단일 EC2 인스턴스의 여러 애플리케이션으로 요청을 라우팅하는 것을 지원, 인스턴스 또는 IP 주소를 각각 다른 포트에 있는 여러 대상 그룹에 등록
• 한 URL에서 다른 URL로 요청을 리디렉션하는 작업을 지원
• 사용자 지정 HTTP 응답 회신을 지원
• 로드 밸런서의 VPC 외부 대상을 포함하여 IP 주소로 대상을 등록하는 것을 지원
• Lambda 함수를 대상으로 등록하는 작업을 지원
• 요청을 라우팅하기 전에 기업 또는 소셜 자격 증명을 통해 애플리케이션의 사용자를 인증할 수 있도록 로드 밸런서를 지원
• 컨테이너화된 애플리케이션을 지원, Amazon Elastic Container Service(Amazon ECS)는 태스크를 예약할 때 사용되지 않는 포트를 선택하고 이 포트를 사용하여 대상 그룹에 태스크를 등록, 이를 통해 클러스터를 효율적으로 사용
• 상태 확인은 대상 그룹 수준에서 정의되고 많은 CloudWatch 지표가 대상 그룹 수준에서 보고되므로 각 서비스의 상태를 독립적으로 모니터링, Auto Scaling 그룹에 대상 그룹을 연결하면 필요에 따라 동적으로 각 서비스를 확장
• 액세스 로그는 추가 정보를 포함하며 압축된 형식으로 저장
• 로드 밸런서 성능을 개선

---

출처

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/introduction.html

https://aws-hyoh.tistory.com/128

https://www.netmanias.com/ko/post/blog/5620/dns-data-center-gslb-network-protocol/global-server-load-balancing-for-enterprise-part-1-concept-workflow

https://kafcamus.tistory.com/52