예) 3개의 인스턴스와 탄력적 로드 밸런서가 있을 때, 세 명의 사용자가 탄력적 로드 밸런서에 바로 연결되고, 첫 번째 것에 하나의 백엔드 EC2 인스턴스에서 로드가 전송되도록 하여 EC2 인스턴스들 사이에 밸런스를 맞추게 됨 여기서 사용자는 백엔드 인스턴스를 모르게 되며 탄력적 로드 밸런서에 연결하기만 하여 단지 연결성의 한 끝 부분만 제공
Why use a load balancer?
여러 다운스트림 인스턴스에 부하 분산
애플리케이션에 대한 단일 액세스 지점 (DNS) 노출
상태 확인 메커니즘을 사용해 다운스트림 인스턴스의 장애를 원활하게 처리
인스턴스에 대한 정기적인 상태 확인 수행
웹사이트에 SSL 종료 (HTTPS) 제공
쿠키로 접착력 (고정성) 강화
영역 간 고가용성
공용 트래픽과 개인 트래픽을 분리
Why use an Elastic Load Balancer?
탄력적 로드 밸런서는 관리된 로드 밸런서 AWS가 이를 관리하고 작동할 것이라고 보증하며 업그레이드와 유지관리, 고가용성을 보장 AWS는 로드 밸런서의 동작을 조정할 수 있는 몇 가지의 구성 노브 (knobs) 를 제공
자체 로드 밸런서를 설정하는 것은 비용이 적게 들지만 훨씬 더 많은 노력이 필요하며, 확장성 측면에서 특히 힘듦
로드 밸런서는 많은 AWS 제공 서비스와 통합될 수 있음 예) EC2, EC2 자동 확장 그룹, Amazon ECS, AWS Certificate Manage (ACM), CloudWatch, Route 53, AWS WAF, AWS Global Accelerator이 있으며 시간이 지남에 따라 더욱 증가
Health Checks
상태 확인은 탄력적 로드 밸런서에서 EC2 인스턴스가 적합하게 작동하는지 검증하는 방법 작동하지 않을 경우 인스턴스로 어떤 트래픽도 보내지지 않으므로 이는 로드밸런서에 중요
상태 버튼을 확인하기 위해 포트와 라우트를 사용 (port and route)
예) HTTP 프로토콜이 존재하고 포트는 4567, 엔드 포인트는 /health 이 때 라우터가 앱의 관점에서 앱의 상태를 확인하는 것이 가장 쉬운 방법으로 HTTP의 상태 코드가 200 (OK) 가 아닌 경우, 인스턴스가 비정상적으로 표시되며 인스턴스에 트래픽을 보내지 않음
Types of load balancer on AWS
AWS에는 4가지 종류의 관리형 로드 밸런서가 존재
Classic Load Balancer, CLB (2009년, V1 - old generation) HTTP, HTTPS, TCP, SSL, secure TCP와 호환되지만 더이상 사용하지 않기를 권장
Application Load Balancer, ALB (2016년, v2 - new generation) HTTP, HTTPS, WebSocket 프로토콜을 지원
Network Lad Balancer, NLB (2017년, v2 - new generation) TCP, TLS (secure TCP), UDP 프로토콜을 지원
Gateway Load Balancer, GWLB (2020년) 네트워크 계층 (3계층)을 운영하며, IP 프로토콜을 지원
차세대 로드 밸런서를 사용하는 것이 더 많은 기능을 제공
일부 로드 밸런서는 내부 (개인, 프라이빗) 또는 외부 (공공, 퍼블릭) ELB로 설정 가능
Load Balancer Security Groups
사용자들은 HTTP나 HTTPS를 사용하는 어느 곳에서부터 로드 밸런서에 접근할 수 있으므로 로드밸런서 보안 그룹 룰은 포트 80, 443이며 0.0.0.0/0으로 어디에서나 가능하며 로드 밸런서에 사용자들이 연결되도록 허락
EC2 인스턴스는 오직 로드 밸런서로부터 직접 오는 트래픽만 허락하므로 (로드밸런서에서 비롯된 트래픽만 허가) EC2 인스턴스의 보안 그룹 룰은 포트 80에서 HTTP 트래픽을 허락
