AWS Elastic Load Balancer(ELB) 쉽게 이해하기 #1
이 문서를 시작으로 AWS의 부하 분산 서비스인 Elastic Load Balancer, 그에 속하는 L7 로드 밸런서 Application Load Balaner, L4 로드 밸런서 Network Load Balancer에 대해 설명합니다. (Classic Load Balancer에 대해서는 설명하지 않습니다.) Elastic Load Balancer는 대부분의 구성에서 빠지지 않고 사용되는 중요한 서비스로 AWS 네트워크의 한 축을 담당하고 있습니다. 이는 On-premise에서 L4 스위치에 해당하는 기능입니다. 그만큼 비중이 큰 서비스이므로 꼭 알아야 하지만 AWS뿐만 아니라 L4 스위치를 다루어본 적이 없으시다면 ELB를 이해하는 것이 조금은 어려울 수도 있습니다. (L4 스위치 쉽게 이해하기 #1 참고!)
(오류 지적 환영합니다!!)
AWS Elastic Load Balancer(ELB)의 정의와 특징
Elastic Load Balancing는 Amazon EC2 인스턴스, 컨테이너 및 IP 주소와 같은 여러 대상에 대해 수신 애플리케이션 또는 네트워크 트래픽을 여러 가용 영역에 배포합니다.
- 출처 : AWS 설명서 -
Elastic Load Balancer(이하 ELB)는 AWS의 로드 밸런서 서비스입니다. 로드밸런서의 주요 기능은 서버 부하 분산, 즉 로드밸런싱으로 특정 서버에 부하가 몰리지 않도록 적절히 분산하는 것입니다. EC2뿐만 아니라 ECS의 컨테이너, Lambda 등을 상대로 부하분산을 실시합니다. (서버 부하 분산 쉽게 이해하기 참고!) On-premise의 L4 스위치처럼 부하분산뿐만 아니라 부하 분산 대상에 대한 헬스 체크(Health Check), 고정 세션(Sticky), SSL Offload(SSL 암복호화), 헬스 체크를 통한 다운 서버 제외 등이 가능합니다. 이는 부하분산 기능을 하는 L4 스위치의 기본 기능에 해당하며 ELB 또한 당연히 보유합니다.
또한 ELB는 통해 단순 부하 분산을 넘어 HTTP Header를 조작하여 전달 대상을 정하거나 고정 페이지를 반환하며, Amazon Certificate Manager(ACM)의 SSL 인증서를 탑재하여 EC2의 부하를 줄이고, WAF를 앞에 내세워 보안 기능을 강화하거나, Cloudfront를 연결하여 반응 속도를 향상하며 최근에 나온 Global Accelerator를 사용하여 Global Server Load Balancing(GSLB)의 기능을 활성화시키는 등 다양한 기능을 할 수 있습니다.
여담으로 AWS에는 AutoScaling이라는 기능이 있습니다. 사용자가 정한 일정 시간 내 일정 조건을 충족하면 EC2를 추가하거나 삭제하여 필요한만큼의 서버를 유지하며 비용을 최적화할 수 있습니다. ELB는 이 AutoScaling과 연동하여 추가된 EC2를 자동으로 ELB의 부하분산 대상에 포함시키거나 제외할 수 있습니다.
Elastic Load Balancer의 기본 구성
ELB는 AWS의 사용자 정의 네트워크인 Virtual Private Network(VPC)에 탑재되며, 사용자의 요청을 받고 이를 VPC 내의 리소스(EC2 등)에 적절히 부하 분산합니다. 그렇기에 ELB는 외부의 요청을 받아들이는 리스너(Listener)와 요청을 분산/전달할 리소스의 집합인 대상 그룹(Target Group)으로 구성되며 ELB는 다수의 리스너와 대상 그룹을 거느릴 수 있습니다. 그리고 부하 분산 대상인 대상 그룹 내 리소스들은 헬스 체크(Health Check)를 활용해 끊임없이 상태를 확인받습니다.
리스너는 외부의 요청을 받아들이기 때문에 서비스 포트(Service Port)를 보유하고 있으며 외부의 요청은 서비스 포트로 접속하는 요청만을 처리합니다. 웹 서비스의 경우 보통 80 포트를 사용하지요. 대상 그룹 또한 서비스 포트를 보유하고 있으며 부하 분산 대상인 EC2는 해당 포트가 열려있어야 합니다. 그리고 대상그룹의 포트는 꼭 리스너와 포트가 같은 필요는 없습니다. 요청을 검토한 리스너가 요청이 적합한 경우 대상그룹에게 이를 전달할 때 대상 그룹의 포트로 'Port Translation'을 실시하기 때문입니다. L4 스위치와 비교해보면 리스너는 Virtual Server에, 대상 그룹은 Pool에 해당합니다. 아래 그림 2개는 각각 L4 스위치와 ALB의 모습을 나타낸 것입니다.
또한 ELB는 크게 외부 인터넷에서 접속이 가능한, 공인 IP와 사설 IP 모두를 갖는 Internet LB와 내부에서의 접근만을 허용하며 사설 IP를 갖는 Internal LB로 구분됩니다. 이름이 비슷하죠? 보통 웹서비스를 구성할 때 외부 사용자들의 접근을 위한 웹 서버를 Internet LB의 부하 분산 대상으로 삼고, 애플리케이션 서버를 Internal LB의 부하분산의 대상으로 삼아 구성합니다. On-premise에서도 동일한 모습을 나타내는 Legacy 구성이지요.
Elastic Load Balancer의 종류
Elastic Load Balancing은 세 가지 로드 밸런서 유형을 지원합니다.
1. Application Load Balancer
2. Network Load Balancer
3. Classic Load Balancer
로드 밸런서 유형이 구성되는 방법에는 주요 차이점이 있습니다. Application Load Balancer 및 Network Load Balancer를 사용하여 대상을 대상 그룹에 등록하고 대상 그룹에 트래픽을 라우팅합니다. Classic Load Balancer는 로드밸런서에 인스턴스를 등록하고 라우팅합니다.
- 출처 : AWS 설명서 -
ELB는 세 가지의 로드밸런서가 있습니다. Application Load Balancer(이하 ALB), Network Load Balancer(이하 NLB), Classic Load Balancer(이하 CLB) 3가지가 존재합니다. 이 셋 모두 부하분산을 하는 로드밸런서라는 점은 동일하지만 역할이 약간 다릅니다. (차후 자세히 설명하며 Classic Load Balancer에 대해서는 설명하지 않습니다.) 이 셋 중 하나를 선택하여 로드밸런서를 생성하고 그 기능을 사용하게 되는 것입니다. 아래 그림에서 AWS Console 상에서 로드 밸런서를 선택하는 화면을 확인하실 수 있습니다.
Application Load Balancer(ALB)
Application Layer(7 Layer)
사용자가 UI로 접하는 응용 프로그램과 관련된 계층으로 HTTP,FTP,DHCP,SMTP,DNS 등이 있습니다. 여기에 속한 프로토콜들은 어떠한 방법으로든 사용자와 직접 접하게 됩니다.
출처: OSI 7 Layer 쉽게 이해하기
[네트워크 엔지니어 환영의 AWS 기술블로그]
OSI 7 Layer의 7 계층에 해당하는 Application Layer의 특성을 이용하는 로드밸런서입니다. 그중에서도 HTTP, HTTPS의 특성을 주로 다루는 로드밸런서죠. 다시 말해 단순 부하분산뿐만 아니라 HTTP의 헤더 정보를 이용해 부하분산을 실시하는 것이 ALB의 가장 중요한 특징입니다. HTTP 헤더의 값들을 보고 이 요청은 어느 대상그룹으로 보낼지 저 요청은 어느 대상그룹으로 보낼지를 판단할 수 있다는 뜻입니다. 또한 SSL 인증서를 탑재할 수 있어 대상 그룹의 EC2를 대신하여 SSL 암호화/복호화를 대신 진행할 수 있습니다. 자세한 이야기는 차후 'ALB 쉽게 이해하기' 문서에서 다루도록 하겠습니다.
Network Load Balancer(NLB)
Transport Layer(4 Layer)
송신자와 수신자의 논리적 연결(Connection)을 담당하는 부분으로, 신뢰성 있는 연결을 유지할 수 있도록 도와줍니다. 즉 endpoint(사용자) 간의 연결을 생성하고 데이터를 얼마나 보냈는지 얼마나 받았는지, 제대로 받았는지 등을 확인합니다. TCP와 UDP가 대표적입니다.
출처: OSI 7 Layer 쉽게 이해하기
[네트워크 엔지니어 환영의 AWS 기술블로그]
OSI 7 Layer의 4 계층에 해당하는 Transport Layer의 특성을 이용하는 로드밸런서입니다. 즉 TCP와 UDP를 사용하는 요청을 받아들여 부하분산을 실시합니다. 예를 들어 HTTP도 TCP 기반의 프로토콜이기 때문에 ALB를 사용하지 않고 NLB를 사용한다면 이를 받아들여 부하 분산을 실시합니다. 다만 상위 Layer인 HTTP가 아닌 하위 Layer의 TCP Layer에서의 처리이므로 HTTP 헤더를 해석하지 못합니다. 그러므로 HTTP 헤더를 이용한 부하 분산을 불가능하지요. 기타 자세한 이야기는 차후 'NLB 쉽게 이해하기' 문서에서 다루도록 하겠습니다. (TCP/IP 쉽게 이해하기 참고!)
휴~ ELB의 정의만을 다루는데도 글이 길어지는군요. 잠시 쉬었다가 AWS Elastic Load Balancer(ELB) 쉽게 이해하기 #2에서 나머지 이야기를 하도록 하겠습니다!