사용자가 많은 서비스의 경우 단일 서버를 사용하면
충돌 또는 성능 저하가 있을 수 있음
하지만, 서버 성능 올리기(스케일 업)은 한계가 있다.(비용, 장비 한계 등)
이런 문제를 해결하기 위해, 로드 밸런싱 패턴은 네트워크 요쳥과 이를 처리할 worker node 사이에 dispatcher를 둔다.
디스패처는 각 클라이언트로부터 요청을 이용 가능한 워커 중 하나로 라우팅시킨다.
클라이언트의 수가 증가하거나 클라이언트의 요청 전송 속도가 빨리지면 더 많은 워커를 추가시키며 부하를 분산시킴
시스템을 크게 변화시키지 않아도 확장이 가능하다.
예를 들면, 대표적으로 우리가 프론트엔드-백엔드로 이뤄진 웹에서 프론트엔드가 받은 사용자 요청을 중간에 있는 디스패처가 적절한 백엔드 노드에 전송한다고 보면 된다.
로드 밸런싱 패턴에는 두 가지 기법이 있다.
1. 클라우드 로드 밸런싱
관리형 클라우드 서비스를 사용하여 요청을 처리한다. 특이 사항으로는 로드 밸런싱 역할을 하는 인스턴스 또한 한 개 존재할 경우 단일 장애점이 될 수 있으니 그룹화하여 존재하게 한다.
2. 메시지브로커/메시지 큐 등 사용
메세지브로커의 주 목적이 로드 밸런싱은 아니지만, 이를 적절히 활용할 경우 로드 밸런싱이 될 수 있다.
단방향으로 생산 및 소비가 정해져 있는 환경 혹은 비동기 통신 상황에서 유용하다.
주의사항으로, 메세지브로커는 반드시 서비스 간 내부적으로 사용되어야 한다.(즉, 외부 서비스로부터 메시지를 받아서 전달하거나 하면 안된다.)
분산시스템에서 주로 구현하며, 메세지브로커의 일시적 장애는 큰 문제가 되지 앟는다.
이렇게 두 가지 로드 밸런싱 기법에 대해 알아보았다.
마지막으로, 로드 밸런싱 기법에는 몇가지 주의사항들이 있다.
- 클라이언트에게 받은 요청을 로드 밸런서가 worker nodes에 라우팅할 때, 어떤 알고리즘을 사용하는지가 중요하다.
대표적으로 이런 알고리즘들이 있다.
- Round Robin : 각각의 수신 요청을 연속적으로 다음 워커 인스턴스에 라우팅 -> stateless 할 때만 정상 작동
- Sticky sessio : 특정 클라이언트 요청을 특정 워커 노드에 라우팅 -> 요청들이 전반적으로 짧은 세션일 때 유용
- Least Connection : 현재 가장 적은 요청을 처리하고 있는 worker node로 라우팅 -> 장시간 연결하는 SQL, LDAP 등
- 오토 스케일링으로 로드 밸런싱과 함께 사용되는 경우가 많다. 트래픽이 높을 때 자동으로 시스템 확장하여 대응, 낮을 때 시스템을 축소하여 비용 절감할 수 있다.
