Elastic Load Balancing은 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스와 같은 여러 리소스에 자동으로 분산하는 AWS 서비스입니다.
이 서비스가 필요한 이유는 컴퓨팅 자원만 늘린다고 하여 늘린 컴퓨팅에 고객의 요청이 적절하게 부여되지 않을 수 있기 때문입니다
예를들어 EC2 a, b, c가 있다고 가정하며 a에만 고객의 트래픽이 몰린다고 한다면 b,c를 늘린 이유가 없어질 것입니다. 따라서 Auto Scaling을 함에 따라 적절한 트래픽을 분산처리해줄 필요가 있습니다
적절히 분산처리해준다는 것은 ELB가 각 EC2가 처리하는 트래픽을 모니터링하며 그 트래픽의 밸런스를 유지합니다
- 로드 밸런서는 Auto Scaling 그룹으로 들어오는 모든 웹 트래픽의 단일 접점 역할
- 들어오는 트래픽의 양에 맞춰 Amazon EC2 인스턴스를 추가하거나 제거하므로 이러한 요청이 로드 밸런서로 먼저 라우팅됨 -> 요청을 처리할 여러 리소스로 분산
- 예를 들어 Amazon EC2 인스턴스가 여러 개인 경우 Elastic Load Balancing은 워크로드를 여러 인스턴스에 분산하므로 어느 한 인스턴스가 대량으로 워크로드를 처리할 필요가 없게됨
Elastic Load Balancing과 Amazon EC2 Auto Scaling은 별도의 서비스이지만 서로 연동하여 Amazon EC2에서 실행되는 애플리케이션이 뛰어난 성능과 가용성을 제공합니다
ELB는 리전 수준에서 동작하므로 사용자가 추가로 작업하지 않아도 고가용 서비스가 됩니다.
아래는 ELB와 Auto Scaling이 함게 동작하는 과정을 예로 표현하였습니다
ELB & Auto Scaling
- 트래픽 부하 발생
- EC2 증설 및 ELB에게 알림
- 증설된 EC2에 대해 ELB 연결 및 트래픽 분산
- 트래픽이 줄어듦에 따라 EC2 연결 해제 및 종료
내부적 트래픽에서의 동작
ELB는 외부 트래픽에만 사용되는 것은 아닙니다
아래와 같이 각 프런트 엔드 인스턴스는 각 백엔드 인스턴스를 인식한다고 해보겠습니다. 만약 이 상황에서 트래픽 부하가 발생하여 새로운 백엔드 인스턴스를 생성한다고 하면 다시 프런트 엔드 인스턴스들은 해당 백엔드 인스턴스를 다시 가르키게 됩니다. 이 구조는 매우 복잡한 구조를 가지게 됩니다
이는 네트워크 유지 보수를 힘들게 하며 혼란스러운 상황을 야기합니다
프런트가 백엔드 직접 인식
- 각 프런트엔드가 백엔드 인스턴스 인식
- 새로운 백엔드 생성시 유지보수가 복잡해짐
ELB 사용
- ELB를 사용시 ELB로 트래픽이 몰리며 트래픽을 쉽게 관리할 수 있고 프런트엔드는 백엔드의 존재 유무를 알지 못하여도 됩니다
- 만약 트래픽이 증가한다면 새로운 백엔드 인스턴스는 ELB에게 생성되었다는 알림을 주기만 하면 됩니다
- 이후 ELB는 생성된 백엔드 인스턴스로 트래픽을 분산시키며 안정적으로 서비스를 운영할 수 있게 됩니다
