로드 밸런서
▶아키텍처 다이어그램
점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
서비스 트래픽이 늘어 서버를 여러 대로 늘렸는데, 사용자는 어떤 서버에 접속해야 할지 모릅니다. 특정 서버에 트래픽이 몰리거나, 한 서버가 다운되면 그 서버로 향하던 요청이 모두 실패합니다. 애플리케이션 코드에 분산 로직을 넣는 것은 모든 클라이언트를 바꿔야 하므로 비현실적입니다.
로드 밸런서는 클라이언트에게 단일 진입점(VIP 또는 도메인)을 제공하고, 뒤에 있는 서버 풀로 요청을 분산합니다. 주기적인 헬스 체크로 각 서버 상태를 확인하고, 응답이 없는 서버는 풀에서 자동으로 제외합니다. L7 로드 밸런서는 URL 경로나 HTTP 헤더를 보고 어느 서버로 보낼지 더 세밀하게 결정할 수 있습니다.
L4(TCP/UDP) 로드 밸런서와 L7(HTTP) 로드 밸런서는 둘 다 트래픽을 나누지만 인식하는 정보가 다릅니다. L4는 IP와 포트만 보고 분산해 빠르고 범용적이며, L7은 HTTP 헤더, URL 경로, 쿠키를 보고 라우팅해 더 세밀한 제어가 가능합니다. 단순 부하 분산이면 L4, 경로 기반 라우팅이나 SSL 종료가 필요하면 L7을 선택합니다.
서버 한 대의 성능 한계에 도달하면 더 큰 서버로 바꾸거나(수직 확장), 서버를 여러 대로 늘리거나(수평 확장) 해야 합니다. 수직 확장은 비용과 물리적 한계가 있어 수평 확장이 선호됐고, 여러 서버로 늘리면 트래픽을 어떻게 나눌지 문제가 생겼습니다. 로드 밸런서는 이 문제를 애플리케이션 밖에서 해결하는 인프라 계층이 됐습니다.
웹 서비스, API 서버, 컨테이너 서비스, 무중단 배포에 적합합니다. 단일 서버로 충분한 소규모 서비스에는 오버엔지니어링일 수 있고, WebSocket처럼 고정 연결이 필요한 경우 세션 어피니티(sticky session) 설정을 신경 써야 합니다.