AWS Elastic Load Balancer (ELB)의 특징2

GonnabeAlright·2022년 3월 7일
0
post-thumbnail

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

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

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

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

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

로드밸런서 노드와 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는 기본적으로 비활성화 되어있습니다.

Elastic Load Balancer의 요청 처리 과정

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

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

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

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

✅ 도메인 해석이란 ?

사용자로부터 입력받은 도메인을 운영체제가 ip로 변환하는 과정입니다. 도메인 해석이 이루어지는 과정은 윈도우와 같은 경우에는 hosts 파일에서 도메인을 검색하고 만약 없을시 공유기에 쿼리를 보냅니다. 공유기에서는 다른 지역 네트워크 내의 사용자가 쿼리를 보낸 기록이 있을 수도 있으니 자신의 캐시를 검색해봅니다. 만약 공유기에도 없다면 ISP(Internet Service Provider)에서 찾아봅니다. ISP의 경우에는 사용자들의 요청이 엄청 많이 오기 때문에 캐시에 해당 도메인이 있을 가능성이 매우 높습니다. 한 사용자가 요청을 보낸적이 있으면 캐시에 TTL이 0이 되기 전까지 캐시에 남아있습니다. 만약 이 곳에서도 못 찾는다면 ISP가 클라이언트가 되어 서버들에게 요청을 보냅니다. 그럼 그 서버들도 캐시를 점검하는 조회를 계속해서 하다보면 결국에는 해당 도메인과 매칭되는 ip주소를 찾을 수 있게 됩니다.

Elastic Load Balancer의 구성 요소

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

리스너 (Listener)

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

대상 그룹 (Target Group)

대상그룹은 리스너가 전달한 요청을 처리하기 위한 부하분산 대상들의 모임입니다. 그렇기에 대상 그룹에 등록된 EC2의 각종 정보 (인스턴스 ID, Port, AZ)가 적혀있고, 이 EC2가 전달받은 요청을 처리할 수 있는지를 나타내는 헬스 체크(Health Check), 요청 처리에 관련된 모니터링(Monitoring)이 있습니다. 요청 처리에 관련된 모니터링이라 함은 이 대상 그룹에 요청 처리가 가능한 EC2가 몇 개인지, 불가능한 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가 통신을 하는 것입니다. 그리고 더 이상의 통신이 없을 때 유휴 제한 시간이 작동하고, 그 시간이 지나면 커넥션이 사라집니다. 즉 어느 정도의 시간동안 통신이 없을 때 커넥션을 삭제할 것인가를 뜻하는 것입니다.

0개의 댓글