로드 밸런싱은 꼭 서버 개발자가 알아야만 한다 - 로드밸런싱 기초

서버 개발자라면 꼭 로드밸런싱은 알아야만 한다.

 

물론 클라우드 로드 밸런서 사용할수도 있다. 그러면 몰라도 되냐고? 아니다. 갑자기 한 인스턴스만 계속 죽는다. 왜일까? 알아보니 그 인스턴스로 부하가 몰리고 있었다. 클라우드에서 제공해주는 로드 밸런서가 만능이 아니기 때문이다. 여러 설정값이 있고 우리의 서버 목적에 따라 설정해줄수 있어야만 한다. 뿐만 아니다. 때론 로드 밸런서를 사용하지 못하는 특수한 케이스도 있다. websocket과 같은 세션을 유지해야 할경우, 세션서버를 만들 경우, redis 클러스터를 사용하지 않고 부하분산을 해야 할경우 등... 우리는 직접 로드밸런싱 처리해야 할때가 많다. 그래서 우리(서버 개발자)는 로드밸런싱을 어떻게 해야 하는지 이해해야만 한다. 그렇지 않으면 좋은 서버개발자가 될수 없다. 그럼 좋은 서버개발가 되기 위한 여정을 시작해보자.

 

로드 밸런싱이란 무엇일까?

위키 백과에서는 다음과 같이 정의하고 있다.

부하분산 또는 로드 밸런싱(load balancing)은 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다.

 

머 이정도만 이해해도 로드 밸런싱을 이해하는데는 큰 문제가 없다. 하지만 왜 우리가 둘 이상 셋 이상의 장치에 작업을 분산해야만 하는걸까? 우리는 로드 밸런싱 이전에 스케일업과 스케일 아웃에 대해서 알아야만 한다.

 

IT의 기술은 나날히 발전해왔고, 결국 이는 트래픽의 증가와 서버에서 처리해야 할 연산이 많이짐을 의미한다. 한대의 컴퓨터(서버)로 도저히 처리할수 없을 지경에 이르자 개발자들은 두가지 방식을 사용했다. 

 

스케일업

스케일 아웃

 

스케일 업은 컴퓨터(서버)의 성능을 올리는 것이다. cpu 많은 컴퓨터를 사용하는 것이다. 4 core 8 core 늘리면 된다. 물론 한없이 스케일업 할수 있으면 좋겠지만, 물리적으로 한계가 있다. 뿐만 아니라 돈도 많이 든다. 그래서 나온게 스케일 아웃이다.

 

스케일 아웃은 여러대의 컴퓨터에 부하를 처리하는 것이다. 요즘 붐이 일고 있는 마이크로 아키텍처가 스케일 아웃을 대표적인 예라고 할수있다. 이때, 우리는 로드 밸런싱를 해야만 한다. 각 트레픽을 어느 서버로 보낼지를 결정하는 기술이 바로 로드 밸런싱라고 할수 있겠다.

 

물론 미래 기술의 발전으로 한대의 서버로 모든 트래픽과 연산을 처리할날이 오면 우리는 스케일 아웃을 할 필요가 없다. 로드 밸런싱 또한 할 필요가 없다. 하지만 아직 그러기에는 너무 먼 훗날이다..... 그래서 우리는 결국 로드 밸런싱에 대해서 공부해야만 한다.

 

그럼 로드 밸런싱이 무엇인줄 알았다. 이제 무엇을 더 알아야 할까? 
로드 밸런싱 알고리즘

 

라운드로빈

클라이언트에서 받은 요청을 순서대로 서버에게 할당하는 방식이다. 아주 쉬운 알고리즘이고, 구현 또한 간단하다. 그렇기에 response time이 짧고 세션이 없는 서버 로드 밸런싱에 사용하기 좋은 방식이다. 

 

가중치 라운드 로빈

각 서버에 가중치를 줘서 라운드 로빈을 하는 방식이다. 가중치를 어떻게 주냐에 따라서 활용방식은 무궁무진하다. http server에서 주로 사용한다. 서버의 성능이 각기 다를때 사용하면 좋다. 

 

최소연결 방식

각 서버의 세션접속수가 가장 적은 서버에 연결하는 방식이다. 세션서버에서 주로 사용한다. 서버의 성능이 비슷할때, 그리고 각 세션의 연산 일정할때 최대의 효율을 낼수 있다.

 

최소연결 가중치 방식

최소 연결에 가중치를 준 방식이다. 요구가 동일할때, 가중치가 높은 서버에 접속된다. 서버의 성능이 동일 하지 않을떄, 각 세션에서 사용하는 연산이 일정하지 않을때, 사용하면 좋다.

 

최소 응답시간 방식

현재 연결상태와 응갑시간을 고려해 응답시간이 빠른 서버에 요청하는 방식이다. response 시간을 줄이고 싶을때 사용하면 좋다. 

 

IP 해시 방식

IP를 해싱하여 특정 노드에 항상 접속하기 위한 방식이다. 동일한 IP면 항상 같은 노드로 접속된다는게 특징이다. database의 파티셔닝 할때 많이 사용한다. 또한 세션서버에서도 많이사용된다. 

 

우리는 위 로드 밸런싱 알고리즘 중에 하나를 선택해야만 한다. 어떤 선택을 하냐에 따라 서버의 성능,속도,비용에 큰 영향을 끼친다. 물론 속도가 빠르다고 무조건 좋은것도 아니다. 비용이 적게 나온다고 무조건 좋은 것도 아니다. 상황에 따라 위 개념을 가지고 최적의 선택을 하면된다.

 

필자는 세션 서버일 경우는 최소연결 방식을 사용하고, 비 세션서버일 경우는 라운드 로빈 또는 최소 응답시간 방식을 사용한다. 물론 간단한 케이스가 아니면, 가중치는 거의 넣는다. 그리고 세션 서버를 개발할때, 특정 종류의 세션이 특정노드로 가야만 한다면 해싱방식을 사용한다. 해싱 알고리즘도 여러가지가 있는데 그건 다음에 한번 다뤄보겠다.   

 

오늘은 로드밸런싱에 대해 알아보았다. 앞으로 서버 개발 하면서 많이 부딪힐 내용이니 머리속에 세겨두자. 물론 기억 안나면 다시 검색하면 된다. 대검색의 시대가 아닌가? 하지만 기억하자. 결국 서버 개발자는 로드 밸런싱에 있어서는 정말 빠삭해야만 한다. 그리고 경험도 많이 해바야 한다. 그래야 좋은 서버개발자로 성장할수 있다. 암기가 중요한게 아니라 결국 응용이다.  그럼 오늘은 여기서 이만!!