AWS Elastic Load Balancer(ELB) 쉽게 이해하기 #2

지난 시간에 이어서 Elastic Load Balancer(이하 ELB)에 대해 계속 이야기해보겠습니다. 첫 번째 문서에서 ELB는 VPC에 탑재하여 사용하는 서비스라고 말씀드렸습니다. 그렇기에 VPC에서 어떻게 구성되는지, 사용자는 이 VPC 내에 있는 ELB에 어떻게 접근하는지 설명하고자 합니다.

 

가용 영역(Availability Zone)과 로드밸런서 노드(Load Balancer Node) 

로드 밸런서의 가용 영역을 활성화하면 Elastic Load Balancing가 해당 가용 영역에서 로드 밸런서 노드를 생성합니다. 가용 영역에 대상을 등록하지만 가용 영역은 활성화하지 않는 경우 이러한 등록된 대상은 트래픽을 수신하지 않습니다.

- 출처 : AWS 설명서 -

ELB는 VPC 내에서 하나의 형태로 존재하고 다수의 네트워크 인터페이스(Network Interface)를 가지며 사설 IP 혹은 공인 IP와 사설 IP를 모두 보유할 수 있습니다. 이를 로드밸런서 노드(Load Balancer Node)라고 하며 ELB에서 실질적으로 사용자의 요청을 받아들여 부하분산 대상들에게 요청을 나누어주는 역할을 합니다. AWS의 콘솔 상에서는 네트워크 인터페이스의 형태로만 보이기 때문에 EC2 서비스의 네트워크 인터페이스에서 이를 확인하실 수 있습니다. 

로드밸런서 노드는 가용 영역(Availability Zone, 이하 AZ)마다 하나씩 존재합니다. 그리고 가용 영역에 있는 부하분산 대상(EC2 등)에 요청을 전달합니다. 로드밸런서 노드 자신이 소속된 AZ에 있는 부하분산 대상들을 책임지는 것이죠. 즉 VPC에서 ELB를 바라볼 땐 로드밸런서 노드와 EC2의 집합으로 보이며, 이는 각각 리스너(로드밸런서 노드), 대상 그룹(EC2의 집합)에 해당합니다. 

<ELB의 Network Interface(Load Balancer Node)>

<로드밸런서 노드와 EC2(출처 : AWS 설명서>

첫 번째 사진을 보시면 ELB의 Network Interface(Load Balancer Node)를 확인하실 수 있습니다. 인터넷 로드밸런서(Internet Load Balancer)이기 때문에 공인 IP와 사설 IP를 모두 보유하며 VPC 외부의 사용자들이 이 ELB로 작업을 요청할 수 있습니다. 즉 해당 IP에 연결된 Domain Name으로 접속을 시도하는 것입니다. 또한 두 번째 그림에서는 각 AZ마다 탑재되어있는 로드밸런서 노드와 로드밸런서 노드에 연결된 다수의 EC2가 보입니다. AZ가 물리적으로는 하나의 IDC 시설에 해당하므로 같은 AZ에 있는 로드밸런서와 EC2를 서로 연결하는 것이 더 나을 것입니다. 하지만 이로 인해 다른 문제가 생길 수 있는데요. 아래 그림과 함께 보도록 하겠습니다.

<부하 분산이 불균형한 상태(출처 : AWS 설명서)>

위 그림을 자세히 보시면 숫자가 보이실 겁니다. 로드밸런서 노드와 EC2 사이의 각각의 선에 숫자가 적혀 있네요. 저 숫자를 모두 합쳐보면 100이라는 숫자가 나옵니다. 즉, 저 숫자들은 각 EC2에 할당된 요청의 비율을 뜻합니다. 요청이 100개라면 AZ A에 각각 25개를, AZ B에 각각 6.25개를 전달하는 것입니다. 하지만 이는 비효율적입니다. 부하분산 대상들에게 고르게 요청이 전달되지 않고 있다는 뜻이기 때문입니다. AZ A의 부하분산 비중이 훨씬 큽니다. 이렇게 된다면 AZ A의 EC2들에게 부하가 심하게 걸리게 되겠죠.

 이를 보완하기 위한 기능이 교차 영역 로드밸런싱(Cross Zone Load Balancing)입니다. 위의 그림처럼 AZ별 부하분산 대상의 숫자가 균형을 이루지 않는 경우 교차 영역 로드밸런싱을 활성화하면 AZ를 가리지 않고 고르게 부하를 분산합니다. 그리고 아래 그림과 같은 결과가 나오게 되지요. Application Load Balancer의 경우 기본적으로 교차 영역 로드밸런싱이 활성화되어있으며, Network Load Balancer는 기본적으로 비활성화되어있습니다.

<교차 영역 로드밸런싱이 적용된 상태(출처 : AWS 설명서)>

반응형

Elastic Load Balancer의 요청 처리 과정

앞서 ELB는 리스너(로드밸런서 노드)와 대상 그룹(부하분산 대상)으로 나뉘어진다고 말씀드렸는데요. 사용자가 서비스 사용을 위해 접속할 때 로드밸런서 노드의 공인 혹은 사설 IP를 직접 입력하여 접근하는 것은 아닙니다. 아래 그림을 보시면 하단 '기본 구성'에서 DNS 이름을 확인하실 수 있는데요. 사용자는 로드밸런서의 이 'DNS 이름'을 통해 ELB에 접속하는 것입니다. DNS 이름을 통해 접속하면 ELB는 요청을 대상 그룹에 전달할 것이고 대상 그룹의 EC2가 요청을 처리하는 것이지요.

<로드밸런서의 DNS 이름>

그럼 사용자가 ELB에 접근하여 부하분산 대상으로 전달되는 과정, 즉 ELB의 요청 처리 과정을 정리해보겠습니다.

<로드밸런서는 Amazon의 DNS 서버를 이용하여 도메인을 해석하기에 DNS는 Amazon에서 제어>

1. 사용자가 로드밸런서에 접근하기 위해 Amazon의 DNS 서버에 로드밸런서의 도메인 해석을 요청
2. Amazon의 DNS 서버가 로드밸런서 노드 IP 리스트를 사용자에게 전달
3. 사용자는 IP 중 하나를 선택하여 로드밸런서에 접근(+ Port 입력)
4. 사용자는 로드밸런서의 (Port가 일치하는) 리스너에 접근하게 되며 리스너는 이 요청을 받아들여 적절한 대상그룹으로 전달
5. 리스너로부터 전달받은 요청을 EC2가 처리한 후 다시 사용자에게 반환 

위 과정을 요약해보면 다음과 같습니다. 사용자가 로드밸런서의 도메인 이름을 해석하여 도메인에 연결된 IP 중 하나를 택합니다. 그리고 리스너에 접근하고, 리스너는 적절한 대상 그룹에 이 요청을 전달하여 EC2로 하여금 처리하도록 합니다. 

 

Elastic Load Balancer의 구성 요소

마지막으로 그동안 계속 언급해왔던 리스너와 대상 그룹을 포함하여 보안 그룹과 상태체크에 대해 알아보도록 하겠습니다.

리스너(Listener)

리스너는 사용자의 요청을 받아들이고 적절한 대상그룹으로 라우팅하는 역할을 합니다. 그래서 이름에 'Listen' 이 붙는 것이죠. 로드밸런서에 접근한다는 것은 해당 리스너의 포트로 접근하는 것이기에 리스너는 접근을 위한 리스너 ID에 포트를 명시하도록 합니다. 또한 한 개의 로드밸런서는 다수의 리스너를 보유할 수 있습니다. 뿐만 아니라 SSL 인증서를 게시하여 SSL Offload를 실시할 수도 있습니다. (L4 스위치 쉽게 이해하기 #7 참고!)

<로드밸런서의 리스너>

대상 그룹(Target Group)

대상그룹은 리스너가 전달한 요청을 처리하기 위한 부하분산 대상들의 모임입니다. 그렇기에 대상 그룹에 등록된 EC2의 각종 정보(인스턴스 ID, Port, AZ)가 적혀있고, 이 EC2가 전달받은 요청을 처리할 수 있는지를 나타내는 '헬스 체크(Health Check)', 요청 처리에 관련된 모니터링(Monitoring)이 있습니다. 요청 처리에 관련된 모니터링이라 함은 이 대상 그룹에 요청 처리가 가능한 EC2가 몇 개인지, 불가능한 EC2는 몇 개인지를 뜻합니다.

<대상그룹의 모습, 헬스체크를 통과한 EC2와 그렇지 않은 EC2>

위의 그림에서는 헬스 체크를 통과한 'i-00d9aa2699252599a' EC2가 전달받은 요청을 처리할 것입니다.

보안 그룹(Security Group)

ELB 또한 EC2처럼 보안 그룹을 지닐 수 있습니다. 가질 수 있는 이유는 로드밸런서 노드 또한 네트워크 인터페이스의 형태를 띄기 때문이지요. 다시 말해 보안 그룹은 네트워크 인터페이스에 적용되는 것이므로 네트워크 인터페이스를 갖는 ELB 또한 보안그룹을 가질 수 있는 것입니다. 사용자가 전달하는 요청을 처리하기 위해서는 해당 요청의 포트를 보안 그룹에서 열어두어야 합니다.

또한 대상 그룹의 EC2도 로드밸런서 노드가 있는 서브넷에서 오는 요청은 처리할 수 있도록 EC2의 보안 그룹 또한 작업을 해야 합니다. 보안 그룹의 Source IP를 0.0.0.0/으로 허용하는 것은 아니더라도 로드밸런서 노드(네트워크 인터페이스)에 적용된 보안그룹에서의 요청은 허용해야한다는 뜻이지요.

<로드밸런서의 보안그룹>

상태 체크(Health Check)

위에서 언급한 것처럼 대상그룹의 EC2의 상태를 체크하는 것을 말합니다. 상태 체크에 통과하지 못한 EC2는 더이상 요청을 전달받지 못 합니다. 또한 ELB의 상태 체크는 TCP, HTTP, HTTPS가 있으며, 트래픽이 유입되는 포트(서비스 포트)로 헬스체크를 하거나 그렇지 않은 포트로의 헬스체크 또한 가능합니다. 또한 제한 시간이나 간격, 성공 판단 횟수 등을 정의할 수 있습니다.

<대상 그룹의 헬스체크 화면>

유휴 제한 시간(Connection Time Out)

마지막으로 볼 것은 유휴 제한 시간입니다. 보통 Connection Time Out이라고 부르죠. '유휴 제한 시간'은 좀 어색하네요. 사용자가 ELB를 거쳐 EC2에 접근하여 서비스를 접속하면 'Connection(이하 커넥션)'이 생성됩니다. 그리고 이 커넥션을 통해 사용자와 EC2가 통신을 하는 것이지요. 그리고 더 이상의 통신이 없을 때 유휴 제한 시간이 작동하고, 그 시간이 지나면 커넥션이 사라집니다. 즉 어느 정도의 시간동안 통신이 없을 때 커넥션을 삭제할 것인가를 뜻하는 것입니다.

<로드밸런서의 유휴 제한 시간>

여기까지가 Elastic Load Balancer의 기본적인 내용입니다. ELB를 사용하고자 한다면 반드시 알아야 할 부분이니 자세히 숙지하시는 것이 좋습니다. 다음 문서에서는 Application Load Balancer와 Network Load Balancer의 기본에 대해 알아보도록 하겠습니다. 감사합니다.