로드 밸런서

서버를 여러 대로 늘리는 순간 새로운 문제가 생깁니다. 클라이언트는 어느 서버에 붙어야 할지 모르고, 한 대가 바빠도 나머지는 유휴 상태일 수 있습니다. 장애가 난 서버로 요청이 계속 들어오면 서비스 일부가 죽어도 사용자 입장에서는 전체가 불안정하게 느껴집니다. 클라이언트가 서버 목록을 직접 알고 분산하도록 만들 수도 있지만, 서버 추가나 제거가 있을 때마다 모든 클라이언트를 동시에 업데이트해야 하므로 현실적이지 않습니다. 결국 여러 서버 뒤에 하나의 안정적인 진입점이 필요합니다.

서비스가 한 서버에서 돌아가던 시절에는 확장이 곧 더 큰 머신을 사는 문제였습니다. 하지만 수직 확장은 비용과 한계가 분명했고, 장애가 나면 그 한 대에 모든 서비스가 함께 묶여 쓰러지는 구조이기도 했습니다. 그래서 업계는 여러 대의 비교적 평범한 서버를 묶어 수평 확장하는 방향으로 이동했습니다. 문제는 서버를 늘리는 것 자체보다, 늘어난 서버들 사이로 요청을 안정적으로 배분하고 장애를 흡수하는 일이었습니다. 로드 밸런서는 이 문제를 애플리케이션 코드가 아니라 네트워크 레벨에서 해결하도록 만든 장치입니다. 오늘날 컨테이너 오케스트레이션과 클라우드 서비스가 자연스럽게 로드 밸런서를 전제로 하는 이유도 같은 맥락입니다.

로드 밸런서는 클라이언트에게 하나의 도메인이나 가상 IP처럼 보이지만, 내부적으로는 여러 대상 서버를 묶어 둔 풀을 바라봅니다. 요청이 들어오면 알고리즘과 규칙에 따라 어느 대상으로 보낼지 결정하고, 주기적인 헬스 체크로 죽은 서버는 자동으로 풀에서 제외합니다. 그래서 백엔드 서버 수가 늘거나 줄어도 클라이언트는 같은 진입점만 알면 됩니다. L4 로드 밸런서는 IP와 포트 수준에서 빠르게 분산하고, L7은 URL 경로, 호스트 헤더, 쿠키 같은 애플리케이션 정보를 보고 더 정교한 라우팅을 수행합니다. TLS 종료와 세션 유지, 경로 기반 분기까지 한곳에서 처리하는 경우가 많은 것도 이 구조 덕분입니다.

L4와 L7 로드 밸런서는 둘 다 요청을 여러 대상으로 나눈다는 점에서 같습니다. L4는 TCP나 UDP 수준의 연결 정보만 보므로 빠르고 단순하며, 프로토콜 종류를 크게 가리지 않습니다. L7은 HTTP 의미까지 이해하기 때문에 `/api`와 `/static`을 다르게 보내거나, 호스트 이름별로 백엔드를 나누고, 헤더 기반 정책을 적용하는 식의 고급 제어가 가능합니다. 대신 더 많은 정보를 해석해야 하므로 구성과 운영 고려사항도 늘어납니다. 단순한 연결 분산이면 L4가 충분하고, 애플리케이션 경로와 정책을 기준으로 트래픽을 나눠야 한다면 L7이 적절합니다.

로드 밸런서는 웹 서비스, API 서버, 컨테이너 기반 백엔드처럼 동일한 서비스를 여러 복제본으로 운영하는 대부분의 환경에 적합합니다. 장애 서버를 자동으로 우회하고, 새 버전과 구 버전 사이 트래픽 전환을 제어하고, 인증서 종료 지점을 중앙화할 때 큰 효과를 냅니다. 서버 한 대면 충분한 규모에 무조건 넣으면 구성 복잡도만 늘어날 수 있습니다. 연결이 오래 유지되는 통신이나 세션 상태가 서버 메모리에 강하게 묶인 구조라면 분산 전략과 세션 처리 방식을 더 신중히 설계해야 합니다. 로드 밸런서는 서버를 여러 대 두면 자동으로 필요한 것이 아니라, 여러 대를 하나의 서비스처럼 보이게 만들어야 할 때 가장 큰 가치를 냅니다.