Amazon ELB

Amazon ELB

AWS에서는 ELB(Elastic Load Balancing)이라는 로드 밸런싱 기술을 제공한다. 즉, 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산하여 애플리케이션 가용성을 향상시키고, HTTP, HTTPS, TCP, SSL 등 다양한 프로토콜을 지원한다.

또한, AWS의 CloudWatch 기능을 이용하여 로그와 메트릭을 모니터링할 수 있으며, AWS의 오토 스케일링 기능과 결합해서 트래픽이 증가할 때 자동으로 인스턴스를 추가하거나 제거하면서 애플리케이션 가용성을 유지할 수 있다.

 

부하 분산

위에서 언급한 로드 밸런싱을 한국말로 부하 분산이라고 한다. 부하분산은 서버가 클라이언트 요청을 받아 처리하는 과정에서 발생하는 부하(연산 작업)에 대해 동일한 목적을 수행하는 다수의 서버에 분산 처리하는 기능을 말한다. 이러한 부하분산을 로드 밸런싱이라고 하고, 부하분산을 수행하는 대상을 로드 밸런서(Load Balancer)라고 한다.

부하분산을 사용하면 다음 장점을 얻을 수 있다.

• 트래픽을 분산하여 처리량 향상
• 서비스를 안정적으로 유지할 수 있는 내결함성 및 고가용성 향상
  • 고가용성: 시스템이나 지속적으로 작동 가능하도록 하는 기능
  • 내결함성: 시스템의 일부 구성 요소가 작동하지 않더라고 계속 작동할 수 있는 기능

 

Amazon ELB 구성 요소

Amazon ELB는 아래 세 가지 요소로 구성되어 있다. 위 그림처럼 사용자와 인스턴스 간 로드 밸런싱 통신을 할 수 있도록 로드 밸런서가 위치하고 있고, 로드 밸런서는 대상 그룹을 통해 로드 밸런싱 대상을 지정하고 상태를 확인한다.

• 로드 밸런서
  • 여러 대의 EC2 인스턴스, IP 주소, 람다 등을 사용하여 트래픽을 대상 그룹에 있는 인스턴스로 분산시켜 애플리케이션의 가용성을 유지하는 역할을 한다.
  • 로드 밸런서는 사용자 요청을 받아 애플리케이션 서버로 전달하고, 애플리케이션의 서버의 응답을 사용자에게 반환한다.
• 대상 그룹
  • 로드 밸런서에서 분산할 대상의 집합을 정의하는 구성 요소이다.
  • 대상 그룹의 인스턴스에 대해 정적 또는 동적으로 구성할 수 있으며, 라우팅 규칙에 따라 요청을 받아들일 대상 그룹을 선택한다.
  • 로드 밸런서는 대상 그룹에 포함된 대상들의 상태를 정기적으로 확인하여 장애 발생 대상을 자동으로 제외한다.
  • 대상 종류에는 인스턴스, IP, 람다, 다른 ALB가 있다.
  • HTTP, HTTPS, gRPC, TCP 등 다양한 프로토콜을 지원한다.
  • 교차 영역 로드 밸런싱, 고정 세션 등의 다양한 알고리즘을 지원한다.
• 리스너
  • 로드 밸런서로 들어오는 요청을 처리하는 주체로 들어오는 트래픽의 프로토콜과 포트 번호 단위로 어떻게 처리할지 정의하는 구성 요소이다.
  • 리스터는 로드 밸런서에게 클라이언트 요청을 수신하고, 해당 요청을 처리할 대상 그룹을 선택하는 역할을 한다.
    • 예를 들어, HTTP : 8080 포트로 트래픽을 받아서 A 대상 그룹의 80번 포트로 배분할 수 있다.
    • 예를 들어, HTTP POST 요청이 들어왔을 경우 에러 페이지와 같은 지정된 응답을 전달할 수 있다.
  • 리스너 내 규칙은 ELB가 요청을 분배하는 기준이 된다.

 

Amazon ELB Node와 동작 방식

ELB가 생성되면, 선택한 각 가용 영역(AZ)의 서브넷 안에 Public 또는 Private IP를 가진 노드(Load Balancer Node)가 프로비저닝된다. 이 노드들은 로드 밸런서의 일부로 포함되어 클라이언트가 DNS 요청을 통해 로드 밸런서에 접근할 때 실제로는 각 노드의 IP를 통해 트래픽이 대상 그룹(Target Group)으로 전달된다.

로드밸런서는 기본적으로 DNS 기반으로 동작한다. DNS 요청 시, 로드 밸런서는 현재 활성화된 노드들의 랜덤 IP 목록을 반환하고, 클라이언트는 그 중 하나의 IP를 선택하여 요청을 보내게 된다. 노드 수는 트래픽 필요에 따라 최대 ALB 기준 100개까지 증설이 가능하고, 노드 수 증감에 따른 IP 변경을 반영하기 위해 DNS TTL(Time to Live)은 일반적으로 1분으로 설정하는 것을 권장한다.

ELB가 동작하는 과정을 정리하면 다음과 같다.

1. 클라이언트 요청 수신: 로드 밸런서에서 클라이언트를 요청 수신한다.
2. ELB 노드 IP 목록 전달: 로드 밸런서는 클라이언트한테 IP 랜덤 목록을 전달하고, 클라이언트는 보통 목록 첫 번째 IP를 선택하여 해당 노드로 요청한다.
3. 대상 그룹 선택: 수신한 클라이언트 요청을 처리할 대상 그룹을 선택한다. 대상 그룹은 인스턴스, IP 주소, 람다 함수, ALB 등 여러 유형의 대상으로 구성된다.
4. 트래픽 분산: 선택된 대상 글부에 요청을 처리할 대상을 선택하고 해당 대상으로 요청을 분산한다.
5. 응답 반환: 분산된 요청을 대상에서 클라이언트에 응답을 반환한다. 

 

ELB의 경우 DNS 기반으로 접속하여 프로비전된 노드의 IP 목록 중 하나를 전달한다. ALB와 달리, LNB는 위 그림처럼 이 노드 중 하나를 Elastic IP로 고정할 수 있고, 이미 생성된 NLB에 EIP를 붙이고 싶은 경우에는 노드 재생성이 필요하다.

만약 EIP를 붙이고, 해당 IP로 직접 요청하는 경우 해당 가용 영역에 EC2 인스턴스가 없는 경우에는 교차 영역 로드 밸런싱을 활성화하지 않으면 다른 가용 영역의 인스턴스로 요청을 전달할 수 없기 때문에 주의해야 한다.

 

Amazon ELB 종류

Amazon ELB에서 제공하는 로드 밸런서 종류는 트래픽의 프로토콜 종류나 서비스의 목적과 대상에 따라 네 가지로 분류할 수 있다.

 

ALB(Application Load Balancer)

ALB는 OSI 모델의 7계층에서 라우팅 동작하는 로드 밸런서로, HTTP/HTTPS 같은 웹 애플리케이션 프로토콜을 지원한다. ALB는 대상 그룹(Target Group) 단위로 트래픽을 분산하며, 각 대상 그룹은 ALB가 요청을 전달할 EC2 인스턴스, 람다 함수, 컨테이너 및 IP 주소로 라우팅하는 기능을 제공한다.

ALB는 다음 특징이 있다.

• HTTP 헤더를 확인하여 다양한 라우팅 기능을 제공한다.
  • 경로 기반 라우팅: URL 경로를 기반으로 요청을 분산한다.
  • 호스트 기반 라우팅: 호스트 이름을 기반으로 요청을 분산한다.
  • 쿼리 문자열 기반 라우팅: URL 쿼리 문자열을 기반으로 요청을 분산한다.
• 오토 스케일링과 함께 사용하여 확장성 있는 애플리케이션을 구성할 수 있다.
• 대상 그룹 내 인스턴스에 대해 상태 검사를 수행하고, 문제가 발생하면 자동으로 장애 조치를 취할 수 있다.
• Amazon CloudWatch Logs와 통합되어 로그 및 지표 데이터를 수집하고 모니터링 및 분석을 할 수 있다.

 

NLB(Network Load Balancer)

NLB는 OSI 4계층의 로드 밸런서로, TCP, UDP, TLS 프로토콜을 지원한다. HTTP/HTTPS 프로토콜을 지원하여 헤더, 쿠키, 세션 등 활용이 가능한 ALB와 달리, 클라이언트와 로드 밸런서 간 연결을 TCP 레벨에서 유지하므로 ELB 중 가장 빠르고 높은 처리량을 지원하여 대규모 트래픽을 처리할 수 있다. 이를 위해 NLB는 높은 처리량, 초당 연결 수, 대역폭 등 기능을 제공하며 동일한 IP 주소에서 여러 대상 그룹을 지원할 수 있다.

NLB는 다음 특징이 있다.

• 높은 처리량: 초당 수백만 개의 연결을 처리할 수 있다.
• 빠른 응답 시간: 빠른 응답 시간을 위해 최적화된 L4 로드 밸런싱 알고리즘을 사용한다.
• 높은 가용성: 여러 가용 영역에서 인스턴스를 실행하고 매우 빠른 인스턴스 검색을 수행하여 신속하게 장애를 복구한다.
• IP 주소 보존: Elastic IP를 할당하여 IP 고정이 가능하다.
• 모니터링: AWS CloudTrail, Amazon CloudWatch Logs 같은 모니터링 기능을 지원한다.

 

CLB(Classic Load Balancer)

CLB는 Amazon ELB의 가장 초기에 출시된 로드 밸런서로, 4계층과 7계층 프로토콜을 모두 지원한다. HTTP/HTTPS 요청에 따른 최신 HTTPv1.2 프로토콜과 TCP의 SSL/TLS 암호화 프로토콜도 지원하며, SSL 인증서를 사용한다. 예전에 사용되던 타입이으로 현재는 잘 사용하지 않는다.

 

GWLB(GateWay Load Balancer)

GWLB는 네트워크 트래픽을 서드 파티의 방화벽/어플라이언스 장비로 부하분산 처리하는 로드 밸런서로, GWLB를 사용하면 해당 장비를 쉽게 배포하고 확장 및 관리할 수 있다.

 

교차 영역 로드 밸런싱(Cross-Zone Load Balancing)

Amazon ELB는 여러 가용 영역에서 로드 밸런서 노드를 실행하며, 각 노드는 가용 영역 내 대상 그룹으로 요청을 분산한다. 이때, 대상 그룹에 등록된 대상이 여러 가용 영역에 걸쳐 있다면 기본적으로 로드 밸런서는 동일한 비중으로 가용 영역 내에 있는 대상으로 트래픽을 분산한다.

이는 대상 그룹의 가용성을 높이는 방법이지만, 위 그림처럼 가용 영역 내 인스턴스 수량이 불균형할 때는 일부 인스턴스로 트래픽이 몰리고 다른 인스턴스는 유휴 상태가 되는 불균형 처리 문제가 발생할 수 있다. 클라이언트가 ELB 도메인 주소로 트래픽을 전송하면, 도메인을 해석하여 50:50 비중으로 각 가용 영역에 위치한 로드 밸런서로 전달하고, 로드 밸런서에서 50이라는 비중에서 인스턴스만큼 나눠 트래픽을 로드 밸런싱할 것이다. 따라서 ap-northeast-2a 인스턴스에 트래픽 부하도가 높아지게 되어 전체적으로 로드 밸런싱이 불균형해지는 것을 확인할 수 있다.

이런 불균형 로드 밸런싱을 해결하는 데 Amazon ELB에서 제공하는 교차 영역 로드 밸런싱 기능을 사용할 수 있다. ELB 교차 영역 로드 밸런싱(cross-zone load balancing)은 트래픽을 분산하는 기준이 가용 영역이 아닌 대상 그룹에 속한 자원을 기준으로 균일한 비중의 로드 밸런싱을 수행하여 불균형 문제를 문제를 해결할 수 있다.

위 그림처럼 대상 자원의 비율에 따라 가용 영역을 교차하기 때문에 각 10의 비중을 맞추어 균일하게 열 대의 인스턴스 대상에 로드 밸런싱하는 것을 확인할 수 있다. 교차 영역 로드 밸런싱은 ALB를 사용할 떄 기본적으로 활성화되어 있으나, NLB는 비활성화되어 있다. 또한, 교차 영역 로드 밸런싱을 사용할 때는 가용 영역 간에 통신 비용이 발생할 수 있다.

 

 

Auto Scaling Groups(ASG)

AutoScaling Group은 EC2를 모니터링해서 인스턴스를 자동으로 생성, 종료하며 스케일링을 관리하는 서비스이다. 사용자의 설정에 따라 최소, 최대, 원하는 인스턴스 수를 유지하며, 트래픽 변화나 장애 상황에 따라 자동으로 확장 또는 축소시킬 수 있다.
CPU의 부하나 특정 시간에 인스턴스 수를 조정하는 등의 다양한 스케일링 정책을 지원하고, ELB, CloudWatch와 연동하여 효율적인 확장 정책을 구성할 수 있다.

아래 실습 그림처럼 ELB와 AutoScaling Group을 연동하는 것이 일반적인 아키텍처이다.

 

ALB + Auto Scaling Group 실습

실습은 아래 순서로 진행할 예정이다.

1. 시작 템플릿 생성
2. Auto Scaling Group 생성 및 테스트
3. 대상 그룹 생성 + ALB 생성
4. ALB와 연결 및 테스트
5. AutoScaling Group의 인스턴스 증감에 따른 ALB 연동 확인
6. 리스너 간단 테스트

 

시작 템플릿 생성

• 시작 템플릿 생성하기 위해 이름 및 Amazon Linux 2023 AMI 선택
• 인스턴스 유형으로 t2.micro을 선택한다.

#!/bin/bash
sudo -s
dnf install httpd -y
service httpd start
chkconfig httpd on
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id)
echo "$INSTANCE_ID" >> /var/www/html/index.html

• IAMReadOnlyAccess 권한을 가진 demo-iam-role-for-ec2 역할 선택한다.
• 사용자 데이터(User Data) 스크립트 활용하여 웹서버 설치 및 인스턴스 아이디 표시한다.
  • 웹 서버를 치하고 웹서버를 실행시킨 다음 자신의 인스턴스 id를 index.html에 넣는 작업

 

Auto Scaling Group 생성

• 이름 지정하고, 이전에 만든 시작 템플릿을 설정한다.

• EC2의 t2.micro 인스턴스가 생성될 VPC 및 서브넷을 선택한다.

• 원하는 초기 용량 및 최소, 최대 용량을 설정한다.

• 태그 탭에서는 Name 키로 Demo-My-ASG 값을 설정한다.

• 활동에서 Auto Scaling Group의 이력을 확인할 수 있다.
• EC2 인스턴스나 ASG의 인스턴스 관리 탭에서 가용 영역에 잘 분산되어 생성된 t2.micro 유형의 EC2 인스턴스를 확인할 수 있다.

 

대상 그룹 생성

• 대상 유형으로 인스턴스, IP 주소, 람다, ALB를 선택할 수 있는 것을 확인할 수 있다.
  • IP 주소의 경우 Private IP만 가능하다. Public IP를 라우팅이 불가능하다.
• 대상 그룹에서 상태 확인할 수 있는 경로를 지정한다.
  • 고급 상태 검사 설정에서 간격, 실패 전체 횟수 등을 설정하고, 실패 전체 횟수를 넘으면 트래픽 대상에서 제외된다.

 

• 자동으로 ALB에서 등록시키기 만들기 위해 인스턴스를 별도로 지정하지 않는다.
• 대상 그룹을 생성한다.

 

ALB(Application Load Balancer) 생성

• 로드밸런싱을 통해 트래픽을 분산할 가용 영역을 선택한다.
• ASG(AutoScaling Group) 생성 시 EC2가 두 개의 가용영역에서만 프로비저닝되도록 설정했으므로 위처럼 설정한다.

 

리스너 및 대상 그룹 설정

• HTTP 80번 포트로 받아서 이전에 지정한 대상 그룹으로 전달할 수 있도록 한다.

 

ALB와 ASG 연동

• ALB에서 들어오는 트래픽을 ASG로 전달하기 위해 생성한 ASG 설정에서 로드 밸런싱 편집을 진행한다.
• 위 사진처럼 체크박스를 선택한 후 생성한 ALB의 대상 그룹으로 설정한다.
• 지금부터 만들어지는 ASG의 EC2 인스턴스는 대상 그룹에 종속되고, ALB가 트래픽을 받아 대상 그룹에 전달한다.

 

테스트

• ALB의 도메인 이름으로 요청하면 각각 요청이 로드 밸런싱되어 인스턴스 id가 계속 바뀌는 것을 확인할 수 있다.

 

ASG 테스트

• 세부 정보  탭 > 상태 확인 > Elastic Load Balancer 상태 확인 켜기를 설정한다.
  • 해당 설정이 선택되지 않으면 애플리케이션이 비정상적이라도 인스턴스 자체가 정상적이라면 정상이라는 것으로 판단한다.
  • 해당 설정을 통해 애플리케이션의 상태까지 체크하는 것이 좋다.

• 인스턴스 내 ssh 접속하여 웹 서버를 중지한다.

 

대상 그룹 설정

ASG 설정

• 대상 그룹에서 헬스체크를 통해 비정상으로 트래픽 대상에서 제외되는 것을 확인할 수 있다.
• ASG에서도 비정상 인스턴스를 Unhealthy로 판단하여 새로운 인스턴스(i-0549738ac1688e858)을 생성한 것을 확인할 수 있다.

 

 

 

 

출처

쉽게 설명하는 AWS 기초 강의

AWS 교과서