[매일메일] 로드 밸런싱에 대해서 설명해주세요.

오늘의 질문

내가 아는 로드 밸런싱은 이런 내용이었다.

 

기존의 서버를 하나 사용한다고 가정하면, 해당 서버에 부하나 이런 것들이 몰릴 수 있다. (하나의 서버를 사용한다는 것이 애매할 수 있으니, 하나의 컴포넌트라고 표현)

그래서 이러한 부분을 개선하려고 하는 노력이다.

 

도커를 사용한다는 가정 하에,

기존의 경우 하나의 기능에 대해서 하나의 가상의 컴포넌트 위에 올리고 그 아래 서버가 들어가는 느낌이다.

개선 방법은 nginx라는 웹 서버를 둔다.

(3개의 컴포넌트를 사용한다고 가정)

그리고 웹 서버에서 3개의 컴포넌트를 관리하도록 설계를 한다.

nginx서버 port 1개와 3개의 컴포넌트는 각각의 port를 갖게 될 것이다. 이러한 상황에서 api는 nginx port에 접근하게 되고 nginx서버가 3개의 컴포넌트 port에 접근하게 된다.

이 상황에서 nginx서버가 3가지 포트에 적절히 배분하여 서버 전체가 부하가 과하게 걸려 죽는 경우를 예방하는 것이다.

또한 이 상황에서는 컴포넌트 3개가 동시에 죽는 경우가 없기 때문에 작동하는 API등을 죽이지 않고 패치 적용 등이 가능해진다.

 

이제 공식적인 매일 메일의 답변이다.

Answer:

로드 밸런싱이란 애플리케이션을 지원하는 리소스 풀에 들어오는 네트워크 트래픽(들어오는 요청)을 균등하게 분산하는 것을 의미합니다. 이를 수행하는 로드 밸런서는 애플리케이션 서버 앞단에 위치하며 클라이언트 요청을 지시하고 제어합니다. 이를 통해서 애플리케이션의 가용성, 확장성, 보안 및 성능을 확보할 수 있습니다.

 

라운드 로빈(Round Robin) 방식은 모든 요청이 순서대로 처리되는 방식입니다. 서버가 3대(A, B, C)가 존재하면 요청은 ABCABC 순서대로 전달됩니다. 모든 서버의 처리 능력이 동등하고, 요청의 고른 분산이 중요한 경우 고려해볼 수 있습니다. 구현이 쉬우며 고른 분산을 보장한다는 것이 장점입니다. 하지만, 서버 부하나 응답 시간을 고려하지 않고 서버의 처리 능력이 다른 경우 비효율적이라는 것이 단점입니다.

 

가중치 라운드 로빈(Weighted Round Robin) 방식은 라운드 로빈 방식에 가중치라는 개념을 추가합니다. 각 서버는 처리 능력과 가용 자원에 따라서 가중치를 할당 받게 됩니다. 그리고, 라운드 로빈 방식을 사용하되 가중치가 높은 서버는 가중치에 비례하여 상대적으로 더욱 많은 요청을 받게 됩니다.

 

-> 가중치 라운드 로빈 방법은 각 서버의 처리 능력을 고려한다는 점에서 기존 라운드 로빈 방식에 비하여 우수하다. 하지만, 실시간의 서버 상황을 고려하지 않는다는 점에서 한계점이 있다.

그렇다면,?

 

최소 연결(Least Connections) 방식은 각 서버의 활성 연결 수를 모니터링하고 있는 경우에 사용할 수 있습니다. 가장 적은 활성 연결이 존재하는 서버에게 요청을 전달하는 방식입니다. 각 서버의 처리 능력이 다른 경우에는 적합하지 않을 수 있습니다. 처리 능력이 큰 서버는 상대적으로 활성 연결을 더욱 많이 수립할 수 있기 때문입니다. 최소 연결 방식은 각 서버의 처리 능력이 비슷하지만 특정 이유로 한 서버에 동시 연결 수가 많아 지는 상황이 존재하는 경우 고려해볼 수 있습니다.

로드 밸런싱 대상에 상대적으로 처리 능력이 큰 서버가 존재하는 경우에는 라운드 로빈과 마찬가지로 가중치라는 개념을 사용해볼 수 있습니다. 이를 가중치 최소 연결(Weighted Least Connections) 방식이라고 합니다.

 

최소 응답 시간(Least Response Time) 방식은 각 서버의 응답 시간을 모니터링하고 있는 경우에 사용할 수 있습니다. 응답 시간이 가장 빠른 서버에 요청을 전달하는 방식입니다. 서버들마다 응답 시간이 다양할 경우, 가장 빠른 서버에 요청을 전달하여 사용자 경험을 개선하는데 도움이 될 수 있습니다. 응답 시간을 기반으로 하기 때문에 서버의 부하 상태, 활성 연결 수와 같은 다른 요소들을 고려해야하는 경우에는 적합하지 않을 수 있습니다.

 

IP 해시 방식은 클라이언트 요청의 IP를 기반으로 요청을 전달합니다. IP를 이용해 구한 해시값을 기반으로 요청을 전달할 서버를 결정합니다. IP 해시 방식은 클라이언트와 서버 간의 친화성 유지에 초점을 맞춘 방식으로 클라이언트의 상태에 관리에 용이하다는 장점이 있습니다. 하지만, 상황에 따라서 부하가 균등하게 이루어지지 않는다는 단점이 존재합니다.

 

과정이 어떻게 일어나는지는 이해하고 있었지만, 서버를 어떤 기준으로 선택하는지에 대해서는 인지는 하고 있었지만 따로 찾아보지는 않았떤 것 같다. 이에 대해서 해결할 수 있는 사항이었으며, 실제로 파이썬으로 구현해 볼 예정이다.