AWS Network Intro - Elastic Load Balancer

서비스를 구축하고, 운영하면서 해당 서비스에 많은 트래픽이 몰렸을 때,

오토스케일링과 같은 클라우드의 서비스를 통해 부하분산을 알아서 처리하게 만들어 주어야 하는데

이러한 부분을 해결할 수 있는 것이 ELB입니다.

 

On Premise의 L4 Switch와 동일한 역할을 하는 것으로,

AWS에서는 CLB, ALB, NLB 총 3개의 로드벨런서가 있습니다.

이중화 및 삼중화를 구성하였을 때도, 로드벨런서를 통해 서비스를 운영 할 수 있으며,

로드벨런서의 DNS를 통해 외부 인터넷에서 접속하여 ELB - EC2 내부망 통신을 하게끔 구성하여

안전한 서비스를 할 수 있도록 구성할 수 있습니다.

 

하지만, ELB를 사용할 때 고려해야 할 부분들이 있습니다.

 

1. ELB는 기본적으로 라운드로빈 방식으로 트래픽을 분산 하는데, 

이를 쿠키 또는 세션을 사용하여 트래픽을 분산하는 기능입니다.

즉, 특정 사용자가 접속을 시도 했을때 처음 접속된 서버로 계속해서 접속되도록 트래픽을 처리하는 방식입니다.

 

2. SSL Termination

ELB는 SSL 기반의 HTTPS 프로토콜을 지원할 수 있습니다.

ELB 설정에 SSL 인증서를 세팅해놓으면 Client --> ELB는 SSL, ELB --> 백엔드 EC2까지는 HTTP로 통신을 하게 됩니다.

즉 서버의 입장에서는 ELB를 Client로 인식하는 형태이고, 따로 서버에 SSL 인증서와 관련된 세팅을 할 필요가 없습니다.

 

3. X-forwarded for Header

ELB가 EC2 인스턴스 앞에서 로드밸런싱을 하게 되면 EC2 입장에서 incoming address를 ELB의 주소로 인식하게 됩니다.

어플리케이션에 따라서 client의 ip를 알아야 할 경우가 있는데,

EC2 입장에서는 ELB가 request를 하는 주체가 되기 때문인데,

이러한 문제를 해결하기 위해서 ELB는 원래의 client ip를 X-forwarded-for (XFF) 헤더 안에 실어서 보내줍니다.

EC2에서는 이 XFF HTTP Header를 열어 봄으로써 원본 client ip를 알아내 활용할 수 있습니다.

 

4. Sticky Session

ELB가 추가적으로 제공하는 기능중에 하나가 sticky session이라는 기능입니다.

이 기능은 client로 부터 들어오는 http request를 항상 같은 ec2 인스턴스로 라우팅을 해주는 기능인데,

ELB의 sticky session의 원리는 cookie를 사용하는 것입니다.

Sticky session 기능을 on 해놓으면, http response에 cookie를 세팅하여,

해당 client가 가는 ec2 instance에 대한 정보를 저장해 놓는 방식입니다.

 

몇 가지 추가 설정이 필요한데, 애플리케이션이 이미 http cookie를 사용하고 있으면,

해당 cookie 명을 넣어서 사용중인 애플리케이션 cookie를 사용하게 하고,

만약에 애플리케이션이 cookie를 사용하지 않으면, 별도로 ELB가 cookie를 만들도록 합니다.

 

5. 마지막으로 ELB 사용 및 테스트시 주의할점을 몇가지 언급해보면 다음과 같습니다.

 

ELB로 성능 테스트를 하다 보면, 부하가 일정 수준으로 못 올라가는 경우에 

ELB에서 Network In/Out bound 쪽에서 병목이 있는 것을 발견할 수 있는데, 

이는 ELB의 용량이 충분하지 않기 때문입니다.

 

ELB는 자체적으로 scaling을 하기는 하지만, 이 scaling이 그리 빠르지 않습니다.

따라서 성능 테스트를 할 경우에는 wramp up 기간을 둬서 충분히 부하를 줘서

인위적으로 ELB를 scaling하게 해 놓은 후에, 부하 테스트를 해야 ELB 단의 병목을 피할 수 있습니다.

 

또는 wramp up 이 되었는지 여부가 확실 하지 않으면,

DNS look up으로 몇 개의 ELB 인스턴스가 생성되었는지 확인해보거나, 

제일은 Amazon쪽에 부하 테스트 기간을 알려주면 미리 Amazon 쪽에서 ELB 를 scaling 해 줍니다.

 

그리고 부하테스트를 하다 보면, 특정 EC2 Instance나 특정 Availability Zone으로 몰리는 현상이 있을 수 있습니다.

특정 Zone으로 부하가 몰리는 현상은 흔히 발생하는 데, ELB 자체가 완벽하게 트래픽을 분산해 주지 않기 때문입니다.

다만 특정 Zone이나 Instance로 몰리는 현상이 아주 심할 경우에는 몇 가지 요인을 생각해볼 수 있는데, 

먼저 부하 테스트 쪽의 DNS 캐시를 의심해 봐야 합니다.

 

ELB간의 로드밸런싱은 DNS Round Robin을 사용하기 때문에, 

클라이언트 쪽의 캐쉬를 지워주지 않으면 그 시간동안 계속해서 특정 ELB 인스턴스에만 부하를 주게 됩니다.

특정 인스턴스로 몰리는 현상의 경우 Sticky Session을 사용하는 경우, 

클라이언트 쪽의 Cookie를 지워 주지 않아,

해당 Cookie를 참조해서 계속 같은 EC2 인스턴스로 부하가 가는 경우가 많습니다.

 

그래서 ELB 기반의 부하테스트를 할 때에는 고성능 적은 수의 클라이언트 보다는

많은 수의 저성능 클라이언트를 사용해 부하를 골고루 나눠 지게 하는 것이 좋습니다.

 

혹은 현재 ALB의 타겟 그룹에서 가중치 기반으로 여러 분산처리를 할 수 있도록 구성도 가능하기 때문에

이러한 부분도 고려하여서 구축하는 것도 하나의 방법일 수 있습니다.

---

Classic Load Balancer

출처 AWS

Classic Load Balancer는 각 서비스 별로 LB를 구축해야 합니다.

즉, 하나의 서비스가 여러 호스트 헤더 기반으로 이루어져 있을 경우

각각의 도메인을 CLB에 매핑시켜주고 해당 포트로 CLB를 각각 구성해야 합니다.

---

Application Load Balancer

반면, ALB의 경우에는 하나의 ALB만을 가지고 모든 서비스를 통합하여 구축할 수 있습니다.

위와 같이 호스트 헤더 기반으로 하나의 ALB에서 타겟그룹을 포트별로 구성해 준 후

리스너 룰을 만들어 적용할 수 있습니다. 

 

물론 패스 기반으로도 구성이 가능하기 때문에 모든 서비스에 대해 메인 Domain만 ALB에 매핑 시킨 후

안에서 호스트 헤더 기반으로 처리한다던지, 패스기반으로 처리하여 하나의 DNS 레코드만 사용하실 수 있습니다.

실제로 이제는 CLB에 대한 업데이트가 진행되는 부분이 없기 때문에 Http 통신으로 구축하는 서비스라면,

ALB를 사용하시는 것이 비용적으로나, 성능면에서 더 좋습니다.

 

두 Load Balancer의 차이점을 다음와 같은 표에서 간략하게 볼 수 있습니다.

Feature	Classic Load Balancer	Application Load Balancer
Supported Protocols	HTTP, HTTPS TCP, SSL	HTTP, HTTPS HTTP2, WebSockets
Sticky Session(cookies)	Yes	Yes
Idle Connection Timeout	Yes	Yes
Connection Draining	Yes	Yes
Cross-Zone Load Balancing	Yes	Always Enabled
Health Check	Yes	Enabled
CloudWatch Metrics	Yes	Enabled
Access Logs	Yes	Enabled
Dynamic Ports	No	Yes
Deletion Protection	No	Yes
Request Tracing	No	Yes
AWS WAF	No	Yes
Host-based Routing	No	Yes
Path-based Routing	No	Yes

---

마지막으로 Network Load Balancer 입니다.

출처 AWS

하지만 위의 두 LB 모두 급격하게 몰려오는 트래픽에 대해서는

Pre-warm을 신청해 놓지 않으면 수요를 바로 감당하기 어렵습니다.

두 LB 모두 오토스케일링이 되며 정성적으로 처리를 하는데 까지는 일정한 시간이 필요할 수 있습니다.

 

이러한 부분과, Public IP가 변동된다는 점 때문에,

방화벽이 특정 고정된 Public IP만 허용할 수 있는 경우에는 NLB를 사용하셔야 합니다.

TCP 트래픽 로드 밸런싱에 이상적인 NLB는 짧은 대기 시간을 유지하며 초당 수백만 건의 요청을 처리 할 수 ​​있습니다.

NLB는 가용성 영역 당 하나의 고정 IP 주소를 사용하며,

갑작스럽고 불안정한 트래픽 패턴을 처리하도록 최적화되어 있습니다.

 

실제 AWS 개발팀에서 테스트를 해 본 결과 수백 대의 EC2 인스턴스로 클러스터에서

초당 150 만 건의 요청을 시작으로 신속하게 초당 300만 건의 요청과 총 대역폭의 30Gbps를 처리하였습니다.

 

이렇게 각 특성 혹은 구축 하고자 하는 부분에 따라 로드벨런서를 선택하여 진행하시면 됩니다.

간단하게 각 Load Balancer의 특징을 알아보았습니다.