Ch19. 프론트엔드의 로드밸런싱

이번 장에서는 사용자 트래픽을 여러 데이터센터에 조절해서 전달하는 로드밸런싱에 대해 간략하게 알아보도록 하자.

 

모든 일을 힘으로만 해결할 수는 없는 법

현실적으로 절대 장애가 일어나지 않는 네트워크는 존재하지 않는다. 따라서 장애가 최대한 적게 나도록 구조를 개선해야 하는데 로드밸런싱이 큰 역할을 수행한다. 예를 들어서 특정 요청을 어느 데이터센터에 얼마나 많은 서버들이 처리할 것인지를 결정하기 위해 트래픽 로드밸런싱을 도입하기도 한다. 요청의 종류는 다양하겠지만 검색, 비디오 요청은 아래와 같은 처리가 필요하다.

• 검색  요청: 요청에 대한 지연응답 시간을 최소화하기 위해 라운드트립 타임(round-trip time, RTT)을 측정해서 가장 가까운 데이터센터로 보내야 한다.
• 비디오 요청: 지연응답 시간을 희생하더라도 처리량을 극대화하기 위해 현재 가장 사용량이 적은 링크를 통해 전달되어야 한다.

요청의 종류뿐만 아니라 캐시 활용 여부, 네트워크 혼잡 상황 등 대형 시스템을 위한 로드 밸런싱은 결코 직관적이고 정적이지 않다. 위 예시는 이해를 돕기 위해 최대한 단순화한 것이다.

 

DNS를 이용한 로드밸런싱

클라이언트는 HTTP 요청을 보내기 전에 DNS를 이용해 IP 주소를 먼저 조회한다. 이 DNS 조회 과정에는 DNS 로드밸런싱을 적용한다. 가장 간단한 방법은 DNS 응답에 여러 개의 A 또는 AAAA 레코드를 리턴하여 클라이언트가 임의의 IP 주소를 선택하게 하는 방법이다.

 

위 예시는 개념적으로는 구현하기 간단해 보이지만 클라이언트의 행동을 넘어서는 수준의 제어는 가능하지 않다는 점과 클라이언트가 가장 가까운 주소를 결정할 수 없다는 문제점이 존재한다. 물론 공인 네임서버의 애니캐스트 주소를 사용하고 DNS 질의가 가장 가까운 주소로 전달된다는 사실을 이용하면 가장 가까운 주소 문제점은 해결할 수 있다.

 

 

가상 IP 주소를 이용한 로드밸런싱

가상 IP 주소(Virtual IP Address, VIPs)는 어느 특정 네트워크 인터페이스에 할당되지는 않는다. 다만 여러 장치에 의해 공유될 뿐이다. 하지만 사용자의 입장에서 볼 때, VIP는 보통의 IP 주소일 뿐이다. 이 방법을 이용하면 이론적으로는 상세 구현(특정 VIP 백엔드에 존재하는 머신의 수 등)이나 설비의 유지보수 등을 드러내지 않을 수 있다. 사용자가 알지 못하게 머신을 업그레이드하거나 추가하는 등의 작업이 가능하기 때문이다.

 

VIP 구현에서 가장 중요한 부분은 네트워크 로드밸런서이다. 밸런서는 패킷을 수신하고 이를 VIP 백엔드의 머신 중 하나에 전달한다. 그런 후 해당 백엔드 머신이 요청에 대한 추가 작업을 수행하게 된다.

 

밸런서가 백엔드의 어느 머신이 요청을 수신할 것인지를 결정하는 방법은 여러 가지가 있다.

 

대표적으로 부하가 가장 적은 머신을 선택하는 방법이 있다. 하지만 이 방법은 요청을 반드시 같은 머신이 수신해야 하는 상태가 있는 프로토콜을 사용하게 되면 실용성이 급격히 무너진다. 이 문제를 해결하기 위해서는 어느 머신이 최초의 패킷을 수신했는지를 확인하기 위해 모든 네트워크 연결을 추적해야 한다. 혹은 패킷의 일부를 이용해 연결 ID를 만들고 해당 ID를 이용하여 백엔드를 선택하면 된다. 하지만 연결 ID를 만드는 방법도 단점이 존재하며 최종적으로 구글에서는 패킷 캡슐화 방법을 사용해서 문제점을 해결했다고 한다.

 

정리

로드밸런서란, 네트워크 트래픽 혹은 애플리케이션의 요청을 여러 서버에 고르게 분산시키는 장치라는 것을 알게 되었다. DNS, 가상 IP 주소 등 다양한 방법을 활용하여 로드밸런싱을 수행할 수 있다는 점도 알게 되었다. 하지만 실무에 바로 적용하기에는 너무 포괄적인 개념과 방법이 나와있어서 아쉬웠다.