[참고] Introduction to modern network load balancing and proxying — 로드밸런싱에 대해서 아주 자세하게 설명되어 있는 블로그임
로드 밸런서의 중요 작업
- 서비스 디스커버리 (Service discovery)
- 사용 가능한 백엔드 셋을 결정하는 프로세스는 다음과 같다.
- 정적 환경설정 파일
- DNS
- Zookeeper, Etcd, Consul 등
- Envoy의 범용 데이터 플레인 API
- 헬스 체킹 (Health checking)
- 트래픽을 처리하는 데 백엔드를 사용할 수 있는 지 여부를 결정하는 프로세스
- 헬스체킹은 일반적으로 두 가지 범주로 나뉜다.
- 활성 : 주기적인 간격을 통해 상태 측정 (ex: HTTP 요청을 /healthcheck 엔드포인트에 전송)
- 수동 : 주 데이터 플로우에서 상태를 감지함. (ex: L4 로드밸런서는 연속 3개의 연결 오류가 있는 경우 백엔드가 비정상적이라고 결정, L7 로드밸런서는 연속 세 개의 HTTP 503 응답을 비정상이라고 결정)
- 로드밸런싱 (Load balancing)
- 부하 분산
- 부하를 계산하고 분산하는 알고리즘은 다양함
- 고정 세션 (Sticky sessions)
- 같은 세션에 의한 요청이 같은 백엔드에 도달하는 것이 중요할 수 있음
- 이는 캐싱, 일시적인 복합 구성 상태 등과 관련이 있음
- 많은 L7 로드 밸런서는 고정 세션을 지원함
- 한편, 세션의 고착도(stickiness)는 본질적으로 취약하기 때문에 세션에 의존하는 시스템 설계 시 주의
- TLS 종료 (TLS termination)
- 원문 글 참조, 중요
- 많은 L7 로드 밸런서는 종료, 인증서 확인 및 핀닝, SNI를 사용한 인증서 서비스 등을 포함한 대량의 TLS 작업 처리
- 관측성 (Observability)
- 네트워크는 본직절으로 신뢰할 수 없음
- 로드 밸런서는 작업자가 문제를 해결할 수 있도록 무엇이 잘못되었는 지 파악하는 데 도움이 되는 통계, 추적 및 로그를 보낼 책임이 있음
- 로드밸런서는 관측성에 따라 크게 나뉨
- 진보된 로드밸런서는 숫자 통계, 분산 추적 및 사용자 지정 가능한 로깅을 포함한 로깅을 제공
- 이런 관측성을 얻기 위해 로드 밸런서는 추가적인 작업이 필요함
- 하지만 이렇게 얻은 로깅 데이터의 이득은 성능 약해지는 것 보다 훨씬 큼
- 보안 및 Dos 완화 (Security and Dos mitigation)
- 환경 설정 및 컨트롤 플레인 (Configuration and control plane)
분산 시스템에서 로드 밸런싱의 이점
- 네이밍 추상화 : 클라이언트는 모든 백엔드(서비스 디스커버리)를 알 필요 없이, 로드 밸런서를 통해 이름 확인(name resolution)을 함
- 장애 허용 : 상태 확인 및 다양한 알고리즘을 통해 불량 또는 과부하 상태의 백엔드를 효과적으로 라우팅 가능함
- 비용 및 성능 이점
로드밸런서 VS 프록시
- 로드밸런싱 장치와 프록시는 서로 혼용되어 사용이 많이 되고 위의 참조 포스트에는 동일하다고 생각함
Proxy
- 클라이언트와 서버 사이에 위치해서 그들 간의 http 메시지를 정리하는 대리인처럼 동작
- 서버와 클라이언트 간의 중계 서버로서 통신을 대신 수행하는 역할
- 클라이언트의 대리 역할을 하기도 하고 서버의 대리 역할을 하기도 함
Forward Proxy
- 클라이언트와 인터넷 사이에 위치해서(Proxy가 내 컴퓨터 가까이에 있음) 클라이언트 대신 서버에 요청을 보내주는 역할
- 로컬 네트워크와 인터넷 사이를 오가는 트래픽을 제어할 수 있는 이점이 있음.

Reverse Proxy
- 서버와 인터넷 사이에 위치해서(Proxy가 서버 가까이에 있음) 서버의 응답을 대신 클라이언트에게 전달해 주는 역할
- 네트워크의 가장 끝에 있는 웹 서버의 바로 앞에 위치함. 따라서 웹 서버를 향하는 모든 요청을 처리할 수 있음
- 웹 서버의 보안 기능을 추가하거나, 빠른 웹 서버 캐시를 느린 웹 서버 앞에 배치 함으로 성능을 개선할 수도 있음
