로드밸런서와 웹

#네트워크/웹

여기서는 로드밸런서의 기본적인 구조와, 사용사례를 간단히 정리해본다.

1. 부하 분산

로드밸런서는 이름처럼, 부하 분산(Load Balancing)을 위해서 생겨난 시스템이다.

만약 서비스의 사용량이 늘어서 서버가 감당하지 못하게 된다면 어떻게 해야할 것 같은가?

단순하게 생각하면 그냥 서버 스펙을 올리는 것만으로 해결을 할 수도 있을 것이다. 단순 서버 업그레이드를 scale-up이라고 부른다.

하지만 서버 스펙을 올리는 데는 한계가 있고 교체도 쉬운 작업이 아니다.
2배 비싼 서버를 사더라도 성능이 2개 증가하는게 아니고, 서버 스펙에는 상한선이 존재한다. 게다가 서버 교체는 필연적으로 다운타임을 수반한다.

이런 구조는 당연히 서비스에 크나큰 차질을 줄 수 있는 부분이다.
그래서 생긴 것이 부하 분산 매커니즘이다.

기본 원리는 대단한 것이 아니다.
여러개의 서버를 병렬로 띄우고, 몸빵을 해주는 "로드밸런서"라는 것을 앞에 두는 것이다.

로드밸런서는 많은 일을 하지 않기 때문에 단일 머신으로도 아주 높은 처리량을 가질 수 있다.
요청이 들어오면 딱 개별 서버들에 일감 분배해주고, 응답이 돌아오면 다시 전달해주는 그 정도만 해주기 때문이다.
서버 사용량이 친다 싶으면, 그냥 서버를 하나 더 띄워서 로드밸런서에 연결만 하면 된다. 이런 서버의 병렬 확장을 scale-out라고 부른다.

이런 병렬 구조는 사용량 확장에만 장점이 있는 것이 아니고, 가용성 확보에도 유리하다. 서버가 하나 터져도 다른 서버가 일하면 되기 때문이다.

이외에도 다양한 관리상의 장점이나, 무중단 배포 등의 장점이 존재한다.

2. Network Level 로드밸런서 (L4)

https://levelup.gitconnected.com/l4-vs-l7-load-balancing-d2012e271f56
이게 약간 초기 형태의 로드밸런서라고 할 수 있다. 이건 요즘 기준에서 보자면 아주 낮은 수준에서의 부하 분산을 처리하는 시스템이다.

TCP, UDP 같은 기반 통신 프로토콜 수준에서 라우팅을 수행하는게 특징이다.

장점

낮은 패킷 레벨에서 동작하는거라 꽤 가볍고 빠르다.
제공 플랫폼에 따라서 고정 IP 등의 옵션을 제공하기도 한다. (AWS NLB)

단점

일반적인 웹 환경에서 필요로 하는, TLS, 보안 기능, DoS 방지, 모니터링 등의 다양한 기능을 제공하지 못한다.

AWS에서

AWS에는 L4 로드밸런서로 Network Loadbalancer(NLB)라는 서비스를 제공한다.
일반적인 웹서버 서빙 용도로는 잘 사용하지 않고, LB 자체에 고유 IP가 필요하다거나, 내부 접근용 private LB가 필요하다거나 하는 한정적인 상황에 보조적으로 사용된다.

3. Application 로드밸런서 (L7)

요즘 로드밸런서라고 하면 보통 다 이걸 가리킨다.
애플리케이션, HTTP/HTTPS 수준의 완성된 웹 수준 라우팅을 제공하는 시스템을 말한다.

장점

웹서버 관리에 필요한 다양한 기능들이 사전에 제공된다. (보안, TLS 등)

단점

HTTP handshake, TLS를 포함해서 처리하는 것이 꽤 많기 때문에, L4 로드밸런서에 비하면 로드밸런서에 몰리는 부하가 조금 더 큰 편이다.
속도 자체도 비교적 느리다.

AWS에서

AWS에서는 Application Loadbalancer(ALB)라는 이름으로 제공된다. 특별한 이유가 없다면 서버를 구축할때 기본 옵션이 된다.

4. 무중단 배포

로드밸런서는 단순 부하분산에만 목적이 있는 것이 아니라, 배포를 안전하게 하기 위한 수단으로서도 존재한다.
자세한 것은 별도 포스트를 참조한다.
https://blog.naver.com/sssang97/223418573577

5. 로드밸런서 구현체

직접 오픈소스 가져다가 로드밸런서를 구축하고 싶다면 몇가지 선택지가 있다.

nginx
haproxy
envoy

기본적으로 가장 많이 사용되는게 nginx고, haproxy가 전통의 강자 같은 포지션이다.

AWS/GCP 같은 클라우드를 쓴다면 클라우드에서 제공하는 관리형 로드밸런서를 쓰는 편이 좋다.
로드밸런서는 가용성과 확장성이 중요한데, 그걸 직접 비용 효율적으로 관리하는건 거의 불가능하다.

6. HTTP1와 HTTP2(TLS)

HTTP2는 HTTP1에 비하면 연결 관련 효율성이 꽤 뛰어난 것이 특징이다.
그러면 로드밸런서 환경에서는 HTTP2 구성을 하려면 어떻게 해야할까? HTTP2의 특이한 점 중 하나는 TLS 설정이 필수라는 것이다.

일반적으로 웹 서버는 다음과 같은 계층 구조를 가질텐데

여기서 가장 간편하게 HTTP2를 제공하는 방법은 Client<>LB에만 HTTP2를 구성되게 하고, LB<>Server 통신은 그냥 HTTP1로 통신하게 하는 것이다.

이게 클래식한 기본 구성이다.
심지어 AWS에서는 2020년까지는 이런 구성만 가능했다.

이러면 클라이언트<>LB 수준에서는 멀티플렉싱 등이 효율적으로 동작한다는 장점이 있지만, HTTP/2 Push 같은 강력한 기능을 활용할 수 없다는 단점이 있다.
그리고 (내부망을 신뢰할 수 없다면) LB<>서버 사이에 뭔가가 탈취될 수 있다는 불안에 갇힐 수도 있다.

아무튼 여기서 뭔가를 더 원한다면 LB<>서버 사이에도 HTTP2를 구성해서 End2End로 HTTP2 통신이 이어지게 하곤 한다.

이러면 물론 손이 가는 부분이 늘어나고 단점도 있다.

단점

LB만 TLS 같은 인증 책임을 갖는게 아니라, 서버들도 인증서 들고서 책임을 갖고 있어야 한다. 관리지점이 분산된다.
TLS 같은 인증, 보안 관련 처리는 공짜가 아니다. 결국 CPU 리소스도 추가로 먹고 그러는 거다.

장점

HTTP2의 기능과 성능 이점을 최대한으로 활용할 수 있다.
최대한의 보안 구조를 내세울 수 있다.

여기에는 딱히 정답이라 할건 없고, 선택의 여지가 있다.

참조
https://serverfault.com/questions/68753/does-each-server-behind-a-load-balancer-need-their-own-ssl-certificate
https://wtarreau.blogspot.com/2006/11/making-applications-scalable-with-load.html
https://stackoverflow.com/questions/36049597/does-http-2-need-to-be-implemented-end-to-end-to-be-useful
https://serverfault.com/questions/836568/terminate-http-2-on-aws-alb
https://levelup.gitconnected.com/l4-vs-l7-load-balancing-d2012e271f56