[Network] NAT와 비슷해! : LB(LoadBalancer) 원리를 이해해보자

🔊 해당 포스팅은 인프런 강의 널널한개발자님의 외워서 끝내는 네트워크 핵심이론 - 응용 내용을 공부하면서 배운 내용을 저만의 방식으로 재정리하고자 하는 목적 하에 작성되는 포스팅입니다. 아래 포스팅에서 사용되는 모든 자료는 제가 직접 재구성했음을 알립니다.

 

우리의 노트북으로 구글 웹서버에 접속할 수 있는 것은 네트워크 덕분이다

---

이번 포스팅에서는 L4 계층인 Transport 계층에서의 스위치인 로드 밸런서(Load Balancer, 이하 LB)라고 불리는 시스템의 동작 원리에 대해 이해해보도록 하자. 로드 밸런서는 한국어로 번역하면 부하 분산기를 의미한다. 여기서 '부하'란, 서버에 들어오는 요청이 많아짐에 따라 발생하는 부하를 의미한다.

1. LB는 NAT와 비슷한 원리로 동작한다!

저번 시간에 공유기가 동작하는 원리인 NAT에 대해 배웠었다. 그런데 부하 분산기인 LB가 동작하는 원리는 NAT 원리와 매우 유사하게 동작하기 때문에 NAT 원리를 이해하고 있다면 LB를 쉽게 이해할 수 있다.

 

먼저 LB는 OSI 7 계층 중 L4 계층에서의 스위치를 의미한다. 실제 물리적인 L4 스위치는 아래와 같이 생겼다. 참고로 앞으로 계속 LB라고 언급하는 것들은 '물리적인' 스위치를 의미한다.

 

부하 분산기인 L4 스위치(출처: 해시넷)

 

LB는 L4 계층에서의 스위치라고 했는데, L4 계층에서의 식별자는 무엇이었을까? 바로 Port 번호이다. 이 말은 L4 스위치가 포트 번호를 기반으로 스위칭한다는 뜻이다. 이런 '포트 번호를 기반으로 스위칭' 한다는 점이 NAT에서와 매우 유사하다. 이렇게 포트 번호를 기반으로 스위칭 하는 것을 활용해서 부하를 분산시키는 것이 LB의 기능이다. LB를 좀 더 명확히 이해하기 위해서 그림으로 살펴보도록 하자.

 

LB를 사용한 부하 분산

 

위 그림에서 Server A,B,C,D는 모두 동일한 기능을 하는 똑같은 서버들이다. 즉, 단순히 clone 해놓은 서버들이다. 이 4개의 서버를 LB로 연결해놓은 상태에서 PC 1,2,3의 요청을 받는 상황이다.

(참고로 PC 1,2,3 입장에서는 Server A,B,C,D를 구분하지 못하고 단순히 LB 서버와 통신한다는 착각을 한다는 점도 알아두자. 이러한 점은 NAT 포스팅에서 배웠으므로 궁금하다면 해당 포스팅을 참고하자)

 

LB는 가장 단순하게 부하를 분산하는 방법으로 라운드 로빈 알고리즘을 선택할 수 있다. 쉽게 말해, 요청을 받은 순서대로 서버에 돌아가면서 부하를 분산하는 것이다. 예를 들어, 가장 먼저 PC 1이 요청을 수행했다. 이 때, LB는 먼저 Server A로 요청을 보낸다. 그런 다음 PC 2가 요청을 하는 경우, LB는 다음 순서로 Server B로 요청을 보낸다. 이런 식으로 계속 반복되는 요청에 대해서 LB는 Server의 순서대로 하나씩 요청을 보내게 된다. 하지만 이러한 방식은 매우 단순하며, 혹시라도 Server 중 한 대에 장애가 생기거나 하는 등 문제가 발생했을 때 대응하지 못한다.

 

그래서 고도화된 방법으로 Manager 서버를 하나 두어서 LB와 Server A,B,C,D들을 모니터링 할 수 있도록 한다. 아래 그림을 보자.

 

Manager Server가 LB와 다른 Server들을 관장한다

 

Manager 서버는 크게 2가지 기능을 한다. 첫 번째 기능은 다음과 같다. 클라이언트에서 들어온 요청을 실질적으로 처리하는 것들 담당하는 Server들이 장애가 발생하지는 않았는지 또는 각 Server의 CPU, 메모리 사용량, 디스크 용량 등을 계속적으로 체크하는 Server들에 대한 헬스 체크 기능을 한다.

 

두 번째로는 클라이언트(그림 속 PC 1,2,3)로부터 온 요청에 대해서 어떤 Server로 보낼지 미리 결정해서 LB에게 알려주는 기능을 한다. 첫 번째 기능과 결부해서 생각해보면 Manager 서버는 상시적으로 관장하고 있는 Server들 중에 클라이언트 측으로부터 들어오는 요청을 여유롭게 처리할 수 있는 Server를 미리 선정해놓고 이를 LB에 알려주는 것이다.

 

그런데 만약에 관장하고 있는 Server들 중에서 특정 서버에 장애가 생겨서 그 서버를 A/S 센터에 맡겨야 한다면 어떻게 될까? 당연히 그런 경우, 장애가 생긴 Server를 빼고 새로운 Server를 집어넣으면 된다. 아래처럼 말이다.

 

만약 Server D에 장애가 생겨 A/S 센터에 맡겨야 한다면?

 

그래서 LB를 활용하는 경우, 위와 같이 특정 Server에 장애가 생기는 경우라도 서비스를 중지하지 않고 운영을 이어나갈 수 있도록 해준다. 이러한 현상을 LB가 무정지 즉, Fault-tolerant 시스템을 가능하게 한다고도 한다. 

 

물론 Server가 아닌 LB 서버가 장애가 날 경우를 대비해서도 추가적인 LB 서버를 두고 LB 간에 연결을 해놓아 이중화를 시켜 무정지 시스템이 가능하도록 해두기도 한다. 또한 Manager Server도 마찬가지로 추가로 서버를 두어 이중화할 수도 있다.

2. LB, Manager, Server들을 모두 Virtualization 시키자!

직전 목차에서 설명하면서 언급한 LB, Manager Server, 요청을 실질적으로 처리하는 Server들 모두 물리적인(Physical) 서버를 의미했다. 그런데 이렇게 물리적인 서버를 관리하다 보면 여러가지 불편한 문제들이 생긴다. 일례로, 특정 서버 하나에 장애가 생기면 정말 그 물리적인 서버를 고치기 위해 A/S 센터에 맡겨야 하는 상황이 발생한다. 그런데 A/S 센터에서 바로 몇 초만에 서버를 고쳐주는 것도 아니고 길게는 몇 일씩 걸릴 수도 있다. 또, A/S 센터에 서버를 옮기고 다니는 시간도 소요될 것이다. 

 

그런데 생각해보자. 물리적인 서버의 원본 이미지에 대한 스냅샷을 따로 만들어두고, 특정 서버가 장애가 발생하면 해당 서버의 원본 이미지로부터 다시 생성할 수는 없을까? 즉, 물리적인 서버들을 소프트웨어화(Virtualization) 시킬 수는 없을까? 당연히 가능하다. 그래서 배포 시스템 설계에서 요즘 대부분의 회사에서 사용하고 있는 Docker, Kubernetes 라는 기술이 많이 사용되고, 이 기술들이 방금 언급한 문제를 해결하는 것이다. 혹시 Docker, Kubernetes를 활용해서 여러 호스트를 관리하는 방법에 대해 궁금하다면 필자의 예전 Docker Swarm, Kubernetes 포스팅을 참조해보도록 하자.

 

LB, Manager, Server들을 모두 소프트웨어화 시키자

3. 여러 대의 LB 장치가 필요하다면? GSLB(Global Server Load Balancing)

1,2번 목차까지 해서 우리는 정말 단순하게 하나의 LB로 여러 대의 서버에 부하 분산을 하는 것을 살펴보았다. 그런데 만약 운영하는 서비스가 글로벌 서비스로 확장한다면 어떻게 될까? 그 때도 하나의 LB로 부하 분산을 하는 것이 가능할까? 그렇게 되면 하나의 LB에 부하가 매우 많이 집중되고 결국 네트워크 통신 속도 저하의 원인이 될 것이다.

 

서비스가 커지면 LB를 글로벌하게 운영할 수 있는 GSLB를 사용해야 한다. GSLB는 DNS 체계를 활용한다. DNS를 활용하는 이유는 우리가 보통 운영하는 서비스들은 모두 웹서버이기 때문이다. 웹서버와 당연히 붙어다니는 개념은 DNS이다. 그래서 엄밀히 말하면 GSLB에 'LB' 라는 단어가 있어서 마치 LB의 또 다른 종류인가 생각하겠지만, 오히려 GSLB은 DNS에 가까우며 굳이 정의를 하자면 GSLB = DNS + LB 도구로 정의할 수 있다. 어떻게 DNS를 활용하는지는 좀 더 밑에서 살펴보자.

 

GSLB의 다른 특징으로, 만약 운영중인 서버들이 넷플릭스나 왓챠와 같은 컨텐츠를 실시간으로 스트리밍하는 서비스라면 각 서버들의 컨텐츠를 동기화하기 위해 CDN(Content Delivery Network)을 이용한다. 그리고 부하 상태, 헬스 체크, 클라이언트의 지리적 위치 등을 고려하기 위해 GSLB를 사용한다.

 

GSLB를 이해하기 위해, 우리는 www.zedd.com  이라는 도메인을 갖는 웹서비스를 운영중이라고 가정하고, 이 서비스를 대한민국 국내의 전국 지역에 운영하고 있다고 해보자. 

 

국내에 서비스한다는 가정하게 GSLB의 사용 예시

 

예시로 서울, 대전, 부산으로 3가지 지역을 나누었고, 각 지역마다 서로 다른 ISP 업체를 사용한다고 가정해보았다. 그리고 각 ISP가 사용하는 DNS 서버가 있을 것이다. LB 1,2,3에 연결되어 있는 모든 서버들은 동일하게 www.zedd.com을 운영하는 동일한 서버들이다.

 

이제 PC 1이 www.zedd.com  이라는 웹서비스에 접근한다고 해보자. 웹브라우저에 www.zedd.com  이라고 입력하고 엔터를 입력했다. 그러면 가장 먼저 PC 1은 ISP로 요청한 후, 연결되어 있는 DNS로부터 www.zedd.com  의 IP 주소가 무엇인지 받아내려고 할 것이다. 하지만 GSLB를 사용하는 구조에서 DNS는 먼저 각 구역에 속하는 LB의 CNAME Record 도메인 주소를 PC 1에 반환해준다.

 

여기서 CNAME Record 도메인 주소라는 것이 등장하는데, 이는 원래 도메인 주소의 별칭(alias) 도메인 주소를 의미한다. 예를 들어, 원래 도메인 주소는 www.zedd.com  인데, 위 그림 속 CNAME Record 도메인 주소들을 보면 a.www.zedd.com, b.www.zedd.com, c.www.zedd.com 이런 식으로 앞에 a,b,c 라는 문자열이 추가로 붙어있는 것을 볼 수 있다.(물론 앞에 a,b,c를 붙힌건 예시일 뿐이다) 앞에 문자열이 붙어있어 서로 다른 도메인 주소이기 때문에 서로 다른 기능을 하는 서버라고 오해할 수 있지만 모두 동일한 기능을 하는 서버를 의미한다. CNAME Record에 대한 구체적인 설명은 다른 블로그 글을 참조해보도록 하자.

 

다시 설명으로 돌아가보자. 아까 PC 1이 처음에 ISP로 www.zedd.com의 IP 주소를 받아내기 위해 요청했지만 CNAME Record 도메인 주소를 반환받았다고 했다. 아래 그림은 서울특별시 지역 부분만 부분 확대를 했다.

 

 

CNAME Record 도메인 주소(a.www.zedd.com)를 반환 받은 PC 1은 다시 ISP에 연결되어 있는 DNS로 해당 도메인의 IP 주소를 요청한다. 그제서야 ISP는 LB 1의 IP 주소인 3.3.3.3을 반환하게 되고, PC 1은 3.3.3.3 IP 주소로 또 요청을 보내게 된다. 그렇게 되면 LB 1로 실질적인 요청이 들어가고, LB 1은 부하 분산 규칙에 기반해서 특정 Server로 요청을 보낸다. 이처럼 대전, 부산에서도 클라이언트 측에서 요청이 발생하면 똑같은 과정이 수행된다. 참고로 여러 LB들을 관장하고 있는 Manager Server는 당연히 GSLB 구조에서도 존재한다. 

 

참고로 PC1이 DNS 서버로 CNAME Record 도메인 주소, 원본 도메인 주소, IP 주소를 서로 주고 받을 때, 매번 PC1이 직접 요청한다고 했지만, 실제로는 PC1과 DNS 사이에 Recursive Resolver 라는 것이 있고 이 Resolver 라는 것이 DNS와 반복해서 서로 요청/응답을 주고 받는 역할을 한다. 포스팅에서는 직관적인 이해를 위해 PC1이 직접 요청하는 것으로 그림을 그렸다

 

위 예시는 국내를 범위로 해서 ISP 단위로 LB를 분리했지만, 전세계에서 운영하는 서비스로 확장되면 당연히 국가 단위로 GSLB를 구성하기도 한다. 만약 전세계 국가로 확대했을 경우, 특정 클라이언트가 어떤 국가에서 요청을 보냈는지 지리적 위치를 판단할 수 있는 방법이 있을까? 가능하다. 바로 IP 주소를 기반으로 판단한다. 물론 IP 주소만을 가지고 자체적으로 판단하는 것은 아니고 IP 주소가 어떤 국가, 어떤 ISP 업체, 어떤 도시에 있는지 매핑되어 있는 일종의 데이터베이스를 활용해서 해당 IP 주소의 정보를 확인할 수 있다. 이러한 데이터베이스를 구축하고 B2B 서비스로 판매하는 회사가 있는데 대표적으로는 MaxMind라는 곳이 있다.

---

이렇게 해서 NAT의 원리랑 동일하게 Port 번호를 기반으로 스위칭하는 부하 분산기인 LB에 대해 알아보았다. 그리고 물리적인 LB의 한계점을 설명하면서 이 LB와 서버들을 소프트웨어화(Virtualization)시켜 요즘 대부분의 회사에서 채택하고 있는 Docker, Kubernetes와 같은 기술이 등장한 이유도 알아보았다. 마지막으로는 LB를 여러개 두는 GSLB에 대해서도 간단히 알아보았다.

 

다음 포스팅에서는 네트워크 포스팅의 마지막인 VPN(Virtual Private Network)에 대해 알아보도록 하자.