강남 출근길 직장인들로 꽉찬 카페를 상상해봅시다. 이 카페로 로드 밸런서를 이해해봅시다. 모든 손님(트래픽)이 한 명의 바리스타(서버)에게만 주문을 하면 어떻게 될까요?
바리스타는 주문 처리 속도(서버 응답 시간)가 점점 늦어지고 과부하가 걸려 결국 주문이 누락되고 손님들은 만족도가 떨어지게 됩니다. 커피 한 잔 주문하면 10분이 걸린다고 상상해보세요. 엄청 답답하겠죠.
만약 로드 밸런서가 있다면?
이제 이 카페에 로드 밸런서가 있는 상황을 봅시다. 카페에 여러 명의 바리스타가 있고, 카페 매니저(로드 밸런서)가 각 손님의 주문을 고르게 분배합니다. 손님들은 빠르게 원하는 커피를 받고, 바리스타는 효율적으로 일할 수 있습니다. 로드 밸런서 덕분에 문제가 해결됐죠?
서버 환경에서도 이와 같이 로드 밸런서가 클라이언트의 요청을 여러 서버에 균등하게 분배합니다!
로드 밸런서의 유형
로드 밸런서는 하나만 있는게 아닙니다. 로드 밸런서 뒤에 있는 서버에게 요청을 어떤식으로 분배 하냐에 따라 라운드 로빈, 가중치 할당 방식, 최소 연결 수 방식, 최소 응답 시간 방식 등으로 나뉩니다. 가장 간단하게는 서버 1
에 한 번, 서버 2
에 한 번, 서버 3
에 한 번 그리고 다시 서버 1
에 한 번 이런식으로 돌아가면서 분배하는 방식이겠죠? 이게 앞서 말씀 드린 라운드 로빈 방식입니다.
헬스 체크(Health Check)
또한 로드 밸런서는 자기가 관리하는 서버에 문제가 있나 검사하는 헬스 체크를 주기적으로 합니다. 말 그대로 “너 건강해?” 물어 보는거죠. 대부분 GET 요청으로 특정한 주소로 물어보는 방식으로 헬스 체킹을 합니다. 이때 200 응답을 받으면 건강한 상태로 간주하고, 200이 아닌 5XX 번대 같은 HTTP 코드를 받으면 건강하지 않다고 판단해 트래픽을 그쪽 서버로 보내지 않습니다. 로드 밸런서 참 똑똑하죠?
스케일링
로드 밸런서를 사용하면 뒷단의 서버를 손 쉽게 확장 하거나 축소 할 수 있습니다. 예를 들어 서버가 1~3까지 있었는데 트래픽이 급증하게 되면 서버를 늘려야겠죠? 이때 서버4를 추가 하는 등 유연한 확장을 할 수 있습니다. 반대로 트래픽이 잠잠해지면 다시 서버 4를 줄일수도 있겠죠!
로드 밸런서의 장점
정리 하자면 로드 밸런서는 이런 장점을 가지고 있습니다.
성능 최적화: 각 서버의 부하를 줄여 전체 시스템의 성능을 향상시킵니다.
고가용성: 하나 이상의 서버가 실패해도 서비스가 계속 유지됩니다.
유연한 트래픽 관리: 트래픽이 많은 시간에도 서비스가 안정적으로 운영됩니다.