[Network] GSLB (Global Server Load Balancing)

알고 있어야하는 내용

- DNS

- Load Balancing

 

위 내용과 관련된 내용은 생략해서 적었다.

---

 

왜 GSLB가 나오게 됐을까?

---

나름대로 이해한 내용을 정리해보았다.

 

물리적인 거리의 한계

유럽에서 살고 있는 사용자가 티스토리에 접속한다고 가정해보자. 사이트가 마법처럼 뿅하고 바로 접속되는 것이 아니니 어떤 과정을 거칠 것이다. 마침 티스토리의 데이터센터가 한국에만 있다고 해보자. 보통 우리가 네트워크 패킷을 주고 받았을 때의 과정을 공부했던 것을 간단하게 이야기하자면 사용자 컴퓨터에서 시작해 유럽의 어느 통신사 DNS에 도착할테고, 해당 DNS는 어떤 과정을 거쳐서 티스토리의 IP 주소를 알려줄 것이다. 이때 IP 주소는 티스토리의 데이터센터가 한국에만 있다고 가정했으니 한국의 IP 주소를 받을 것이다.

 

https://www.submarinecablemap.com/country/south-korea

 

그러면 유럽에서 다시 티스토리 IP 주소로 패킷을 요청한다. 이때 해외에서 한국까지 네트워크 패킷을 전송하려면 보통 해저케이블을 사용한다. 위 사진처럼 한국에 많은 해저케이블이 깔려있는데, 유럽에서 요청한 네트워크 패킷은 유럽에서 시작해 한국에 도착하고, 통신사의 백본 네트워크에 가서 티스토리 서비스를 하는 데이터 센터로 이동한다. 이후 다시 응답을 할 때는 비슷한 과정을 반복할 것이다.

 

여기서 가장 긴 거리로 이동하는 곳은 해저케이블인데, 해저케이블은 광케이블을 사용해도 유럽 → 한국, 한국 → 유럽까지의 물리적 거리가 너무 멀다보니 느리게 패킷을 주고 받을 것이다. 특히 게임하는 사람들은 한국에서 유럽, 미국 게임 서버에 접속하면 핑이 굉장히 높은게 그런 이유다.

 

이렇게 해외에서 한국 서비스에 접근한다면 해외에 데이터센터가 있지 않는 이상 국내 데이터센터로 접근하면 오래 걸려서 사용자 만족도가 점점 떨어진다. 실제로 사용자 만족도가 떨어지게 된다면 해당 서비스를 사용하지 않게되는 케이스가 많다고 한다.

---

만약 서버에서 장애가 발생해 특정 IP 주소가 먹통인상황

왼쪽, 가운데 (크롬), 오른쪽(터미널에서 dig naver.com 입력)

크롬에서 네이버를 입력 했을 때의 네트워크 헤더 정보를 확인해보면 이렇게 IP 주소가 살짝 다른 것을 볼 수 있다. 귀찮으면 터미널에서 `dig naver.com`을 입력해보면 된다. 참고로 같은 URL로 dig 명령어를 실행하다보면 IP 주소의 순서가 달라지는걸 확인할 수 있다.

 

여기서 만약 223.130.200.xxx의 IP 주소 2개 모두 장애가 발생했다고 가정해보자. 사용자는 naver.com을 입력했더니 DNS는 223.130.200.xxx 주소를 제공할 때도 있을 것이고, 사용자 컴퓨터는 그 IP 주소로 패킷을 보냈더니 장애가 발생한 상황이라 패킷이 오지 않거나, 에러페이지가 나올 것이다. 이처럼 DNS는 장애가 발생했는지의 여부를 파악하지 못한채 IP 주소를 제공하므로 장애가 발생하면 사용자 만족도는 낮아질 수 밖에 없다.

 

총 정리하자면 GSLB가 나온 이유는 지리적인 이유 + DNS의 기술적 한계점를 보완해주는 기술이라고 보면 된다.

---

 

 

GSLB

---

GSLB의 역할

Akamai, Cloud Flare, Kemp Technologies 이런 기술 블로그 글을 확인해보니 아래와 같이 정리할 수 있다.

전세계적으로 분포한 인터넷 트래픽을 적절한 데이터센터에 분산해 네트워크 부하를 줄이고, 고가용성을 제공해 안정적인 서비스를 제공하는 기술

---

DNS와 GSBL의 비교

 

아래 링크에 궁금한 점이 잘 나와있고, 이걸 토대로 간단하게 정리한거라 제대로 볼 사람은 아래 링크를 통해 보는게 좋아보인다.

- KT 유클라우드, GSLB로 무중단 서비스 지원

- Enterprise를 위한 GSLB 1편: 개념 및 서비스 로직

- Enterprise를 위한 GSLB 2편: Site/Server 선택 정책 (1)

- Enterprise를 위한 GSLB 2편: Site/Server 선택 정책 (2)

 

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

 

DNS와 GSLB를 비교하면 위 사진으로 정리가 된다.

 

1. 재해 복구(DR): 헬스 체크를 통해 서버가 다운되더라도 다른 서버로 연결되게 한다. (DNS는 헬스 체크 없음)

2. 사이트 부하 분산:  트래픽이 몰리면 자동으로 트래픽이 없는 서버로 분배한다. (DNS는 트래픽 감지 없음)

3. 네트워크 근접성: Local DNS와 SLB 사이의 RTT를 측정해 네트워크상으로 가까운 서버의 IP 주소를 알려준다. (DNS는 RTT 측정 없음)

4. 지리적 근접성: 사용자의 지리적 위치에 가까운 서버의 IP 주소를 알려준다. (DNS는 지리적 위치를 고려하지 않음)

---

KT GSLB의 동작 방식 (큰 흐름만)

https://www.netmanias.com/ko/post/blog/5617/dns-data-center-gslb-kt-network-protocol/global-server-load-balancing-gslb-service-for-kt-ucloud

 

5를 제외한 1부터 8까지는 일반적인 DNS에 IP 주소를얻어 요청 패킷을 보내는 동작인데, 5번의 GSLB Policy에서 GSLB가 관여한다. 현재 구조는 active - backup(standby)이고, 여기에 나온 서버 1, 서버 2는 nginx와 같은 SLB(Server Load Balancing)이다. 만약 Server 2의 SLB가 관리하는 모든 서버가 터지면 2.2.2.2의 SLB는 active인 GSLB 1에게 보고해 DNS Query가 들어오면 자동적으로 1.1.1.1만 응답 패킷에 넣게 된다.

---

KT GSLB의 세부 동작 방식

https://www.netmanias.com/ko/post/blog/5622/dns-data-center-gslb-network-protocol/global-server-load-balancing-for-enterprise-part-2-site-server-selection-policy-1

 

GSLB가 특정 지역의 SLB IP 주소를 선택하는 것도 누군가가 결국은 코딩을 해야하니 위 방식으로 되어있다.

위에 큰 흐름을 잠깐 언급한 내용은 1번 과정의 Server Health 내용이다. 이후에는 아래 순서로 후보군들을 걸러 걸러 선택한다.

 

1. 서버 상태 확인

2. 세션, 네트워크 부하가 적은 SLB 선택

3. 네트워크 관점에서의 근접성

4. 지리적 관점에서의 근접성

5. 현재 TCP, UDP 커넥션 연결이 적은 SLB를 선택

6. 운영자가 설정한 사이트 선호도(우선순위)로 선택

7. 트래픽 분배를 위해 덜 선택된 서버

8. Round Robin, Weighted Round Robin으로 서버 선택

* 7, 8은 가장 마지막 방법이라 둘 중에 하나만 선택 가능함

 

더 자세한 내용이 궁금한 분은 1편, 2편을 참조하면 된다.

 

 

https://www.netmanias.com/ko/post/blog/5624/dns-data-center-gslb-network-protocol/global-server-load-balancing-for-enterprise-part-2-site-server-selection-policy-2

 

이 사진을 보니 KT는 SLB를 사용하는 것으로 보인다.

---

 

 

GSLB를 기반으로 어디서 활용할 수 있을까?

---

네이버 D2 기술블로그에 간단하게 GCDN(Global Content Delivery Network)이라는 기술도 사용한다고 나와있다.

(https://d2.naver.com/helloworld/6070967)

 

보통 CDN이라하면 보통 잘 바뀌지 않는 html, css, js, 이미지 파일등을 전송하는데, 여기서도 GSLB 기술을 사용하여 가장 가까운 CDN 서버로 전송하는 것이다. 이러면 결국 GSLB처럼 먼 해외에 사는 사용자는 서비스중인 해외 데이터센터에서 파일을 가져와 한국 데이터센터에서 네트워크 통신하는 것보다 더 빠른 속도를 체감할 수 있다.

 

이런 목적으로 사용한다고 생각해보니 글로벌 서비스를 운영한다면 여러 데이터센터에서 서버가 구동될테니 CDN 서버처럼 일반 서버와 다른 자체 서버를 가지고 있다면 비슷하게 사용하지 않을까 생각한다.

---

 

 

이외에 읽으면 좋은 링크

- ZDNET: 효율적인 부하 분산 라우팅을 위한 GSLB 기술 활용

 

 

취준할 때는 큰 흐름의 패킷 이동과 관련해 간단하게만 공부한 내용인데, 제대로 공부해보니 "왜 GSLB가 나오게 됐을까?"라는 의문에 대한 자료가 잘 만들어져 있어서 공부하기 편했다.