ELB (Elastic Load Balancer)

정의와 특징

AWS의 로드 밸런서 서비스이다. 로드밸런서의 주요기능은 서버 부하 분산, 즉 로드밸런싱으로 특정 서버에 부하가 몰리지 않도록 적절히 분산하는 것이다. EC2뿐만 아니라 EcS의 컨테이너, LAmbda 등을 상대로 부하분산을 실시한다. On-premise의 L4 스위치처럼 부하분산뿐만 아니라 부하분산 대상에 대한 헬스 체크(Health Check), 고정 세션(Sticky), SSL Offload(SSL 암복호화), 헬스 체크를 통한 다운서버 제외 등이 가능하다. 이는 부하분산 기능을 하는 L4 스위치의 기본 기능에 해당하며 ELB 또한 당연히 보유한다.

또한 단순 부하분산을 넘어 HTTP Header를 조작하여 전달 대상을 정하거나 고정 페이지를 반환하며, Amazon Certificate Manager(ACM)의 SSL 인증서를 탑재하여 EC2의 부하를 줄이고, WAF를 앞에 내세워 보안 기능을 강화하거나, Cloudfront를 연결하여 반응속도를 향상하며 최근에 나온 Global Accelerator를 사용하여 Global Server Load Balancing(GSLB)의 기능을 활성화시키는 등 다양한 기능을 할 수 있다.

기본 구성

ELB는 AWS의 사용자 정의 네트워크인 Virtual Private Network(VPC)에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스(EC2 등)에 적절히 부하분산한다. 그렇기에 ELB는 외부의 요청을 받아들이는 '리스너'와 요청을 분산/전달할 리소스의 집합인 '대상 그룹'으로 구성되며 ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있다. 그리고 부하분산 대상인 대상 그룹 내 리소스들은 헬스 체크를 활용해 끊임없이 상태를 확인받는다.

리스너는 외부의 요청을 받아들이기 때문에 '서비스 포트'를 보유하고 있으며 외부의 요청은 서비스 포트로 접속하는 요청만을 처리한다. 웹 서비스의 경우 보통 80 포트를 사용한다. 대상 그룹 또한 서비스 포트를 보유하고 있으며 부하 분산 대상인 EC2는 해당 포트가 열려있어야 한다. 그리고 대상 그룹의 포트는 꼭 리스너와 포트가 같을 필요는 없다. 요청을 검토한 리스너가 요청이 적합한 경우 대상 그룹에게 이를 전달할 때 대상 그룹의 포트로 'Port Translation'을 실시하기 때문이다. L4 스위치와 비교해보면 리스너는 Virtual Server에, 대상 그룹은 Pool에 해당한다.

또한 ELB는 크게 외부 인터넷에서 접속이 가능한, 공인 IP와 사설 IP 모두를 갖는 'Internet LB'와 내부에서의 접근만을 허용하며 사설 IP를 갖는 'Internal LB'로 구분된다. 보통 웹 서비스를 구성할 때, 외부 사용자들의 접근을 위한 웹 서버를 Internet LB의 부하분산 대상으로 삼고, 애플리케이션 서버를 Internal LB의 부하분산 대상으로 삼아 구성한다. On-premise에서도 동일한 모습을 나타내는 Legacy구성이다.

ELB 종류

1. Application Load Balancer
2. Network Load Balancer
3. Classic Load Balancer

Application Load Balancer(ALB)

OSI Layer의 7계층에 해당하는 Application Layer의 특성을 이용하는 로드밸런서이다. 그 중에서도 HTTP, HTTPS의 특성을 주로 다룬다. 다시 말해, 단순 부하분산뿐만 아니라 HTTP의 헤더 정보를 이용해 부하분산을 실시하는 것이 ALB의 가장 중요한 특징이다. HTTP 헤더의 값들을 보고 이 요청은 어느 대상 그룹으로 보낼지 저 요청은 어느 대상 그룹으로 보낼지를 판단할 수 있다는 뜻이다. 또한 SSL인증서를 탑재할 수 있어, 대상 그룹의 EC2를 대신하여 SSL 암/복호화를 대신 진행할 수 있다.

Network Load Balancer(NLB)

OSI Layer의 4계층에 해당하는 Application Layer의 특성을 이용하는 로드밸런서이다. 즉, TCP와 UDP를 사용하는 요청을 받아들여 부하분산을 실시한다. 예를 들어, HTTP도 TCP 기반의 프로토콜이기 때문에 ALB를 사용하지 않고 NLB를 사용한다면 이를 받아들여 부하분산을 실시한다. 다만 상위 Layer인 HTTP가 아닌 하위 Layer의 TCP Layer에서의 처리이므로 HTTP 헤더를 해석하지 못한다. 그러므로 HTTP 헤더를 이용한 부하분산이 불가능하다.