[AWS] 로드 밸런서 ELB (ALB, NLB, CLB, GWLB) 쉽게 특징과 차이점 정리

◇  공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇

 

 

ELB

 

 

ELB (Elastic Load Balancing) 

ELB는 하나 이상의 가용 영역(AZ)에 있는 애플리케이션에게 들어오는 트래픽을 자동으로 분산한다.

AWS에는 4 종류의 로드 밸런서가 있다.

ELB는 AWS의 로드 밸런스 종류 전체를 통틀어 칭하는 말이다.

트래픽 분배

 

ELB의 4가지 종류

1. Classic Load Balancer (CLB)
2. Application Load Balancer (ALB) 
3. Network Load Balancer (NLB)
4. Gateway Load Balancer (GWLB)

 

 

	ALB	NLB	CLB
레이어	Layer 7	Layer 4	Layer 7, Layer 4
프로토콜	HTTP, HTTPS	TCP, UDP, TLS	HTTP, HTTPS, TCP, SSL/TLS
WebSocket 대응	✅	✅	❌
Host와 Path-Based의 라우팅, URL의 쿼리문자열의 라우팅	✅	❌	❌
고정 IP 주소 부여	❌	✅	❌

 

 

 

ELB 의 특징/기능

• 애플리케이션의 가용성(High Availability)과 확장성(Auto Scaling)을 향상시킨다.
• ELB는 EC2뿐만 아니라 ECS, Lambda 등 다양한 서비스와 연계하여 트레픽 부하를 분배 할 수 있다.
• Health Checks 기능:
  
  • 서버의 상태를 정기적으로 확인하고, 문제가 있을 경우 트래픽을 해당 서버로 전송하지 않는다.
    

    

• [Connection Draining] 기능: Unhealthy 됐을 때 지정된 시간만큼 연결을 기다려준다 
  • 기본(Default)으로 켜져있다. ALB(와 CLB)만 지원한다
  • 서버에 오류가 발생했을 때, 다른 서버에 트래픽을 이동시키기 전에 기존 연결을 기다려주는 시간
  • 예시) Connection Draining을 200초로 설정하면, 서버에 오류 생긴 후 200초 동안 그나마 기존 연결을 기다려주고, 다른 서버에 트래픽을 이동한다.
    

    

• [Slow Start Configuration, 느린 시작 구성]: 새로 시작된 서버를 위해 천천히 트래픽을 부하 
  • ALB와 NLB만 지원한다
  • Slow Start Configuration은 새로운 인스턴스가 부하가 걸리기 전에 천천히 트래픽을 수신하게 만드는 기능이다.
  • 이 방식은 서버가 처음부터 갑자기 모든 트래픽을 받는 것을 방지하고, 서버가 정상적으로 작동할 수 있도록 점진적으로 트래픽을 분배한다.

 

ELB 4가지 로드 밸런서

1. Classic Load Balancer (CLB)

ELB중에 가장 오래된 서비스. No 추천!
AWS에서는 신규 생성으로 권장하지 않으며, 기존 사용자에게는 계속 지원중 (그래서 최근에 쓰는 걸 본적 없음)

 

• HTTP, HTTPS, TCP, SSL 트래픽을 처리.
• Layer 4 와 Layer 7에서 동작. (Transport & Application Layer)
• 기본 기능을 제공하지만, ALB 및 NLB에 비해 고급 기능이 부족하다.

참고) Layer란? 관한 내용→ https://jibinary.tistory.com/177

[네트워크] OSI 모델 (OSI 7-Layer Model) 아주 쉽게 개념 정리

 

 

 

2. Application Load Balancer (ALB)

가장 많이 사용되는 로드밸런서 (가장 똑똑하다)

• HTTP/HTTPS을 지원한다. 
• Layer 7에서 동작 (Application 계층에서 동작)
• 고급 라우팅 기능을 지원한다.
  • Path-Based Routing(경로 기반 라우팅), Host-Based Routing(호스트 기반 라우팅) ,URL 쿼리 문자열에 따른 라우팅 (밑에서 설명)
• (Docker) 컨테이너화된 애플리케이션과의 통합을 용이하게 한다.
• 고정 IP 주소(Elastic IP)를 사용할 수 없다.
  • 고정 IP 주소를 사용할 수 있는 NLB를 앞에 놓아 고정 IP 주소가 있는 것처럼 사용 할 수는 있다.
• Sticky Session 사용 가능하다 (밑에서 설명)

 

📌 Host(호스트) and Path(경로) Based Routing 기능

https://youtu.be/4vRoQfK4pGc?si=k2YB3SrZeLc79O7E

[호스트(Host) 기반]
클라이언트가 요청한 접속 URL의 FQDN(완전 도메인 이름)에 따라 라우팅할 수 있는 기능.

예를 들어, 클라이언트의 접속 URL이 "http://www1.example.com"일 경우 웹 서버 1에 접속하게 하고, "http://www2.example.com"일 경우 웹 서버 2에 접속하게 할 수 있다.

 

[경로(Path) 기반]
경로 기반 라우팅이란, 클라이언트가 요청한 접속 URL의 경로에 따라 라우팅할 수 있는 기능.

예를 들어, 클라이언트의 접속 URL이 "http://www.example.com/web1/"일 경우 웹 서버 1에 접속하게 하고, "http://www.example.com/web2/"일 경우 웹 서버 2에 접속하게 할 수 있다.

 

[URL Query 문자열 기반]
클라이언트가 요청한 접속 URL의 쿼리 문자열에 따라 라우팅할 수 있는 기능. URL 쿼리 문자열은 브라우저가 웹 서버에 전송하는 데이터를 URL에 표현한 것이다.

예를 들어, URL이 "http://www.example.com/web?lang=kr"일 경우 "lang=kr"가 URL 쿼리 문자열에 해당한다.

클라이언트의 접속 URL이 "http://www.example.com/web?lang=kr"일 경우 한국어 사이트로 접속하고, "http://www.example.com/web?lang=en"일 경우 영어 사이트로 접속하게 할 수 있다.

 

 

📌 [Sticky Session] 기능: 세션 정보가 저장된 쪽으로 지속적 연결

Cookie의 유효시간 동안에 클라이언트가 동일한 백엔드 인스턴스(서버)에 접근할 수 있도록 하는 기능.
이를 통해 클라이언트는 같은 인스턴스에 연결된 상태를 유지하게 되며, 세션 상태를 인스턴스별로 저장해야 하는 애플리케이션에 유용하다.

(예시)

아마존 쇼핑사이트가 2개의 백엔드 서버와 로드밸런서로 운영 중이다.
유저가 장바구니에 상품을 저장시켰다. (한쪽의 백엔드 서버를 이용)
근데 갑자기 로드밸런스가 다른 백엔드 서버로 트래픽을 이동시키면 상태(세션) 정보가 사라지기 때문에 장바구니에 있던 상품들은 사라지게 될 것이다. 이걸 방지하는 것이 "Sticky Session"이다.

 

📌 [Listener Rules, 리스너 규칙]

(ALB에서만 사용 가능) Listener Rules는 수신한 요청을 어떻게 처리할지에 대한 규칙을 설정한 기능이다.
위에서 설명한 호스트/경로 기반 라우팅은 Listener Rules을 통해서 라우팅한다.

• 요청의 경로(Path) 또는 호스트 이름(Host)을 기준으로 규칙/조건을 설정하여, 특정 URL로 들어오는 요청을 다른 타겟 그룹으로 라우팅할 수 있다.
• 헤더 또는 쿼리 문자열의 내용에 따라 요청을 다르게 처리할 수도 있다.
• HTTP로 들어오는 요청을 HTTPS로 리다이렉트 할 수 있다.

https://aws.amazon.com/blogs/aws/new-host-based-routing-support-for-aws-application-load-balancers/

3. Network Load Balancer (NLB)

대규모 네트워크 트래픽에 특화되어 있어 빠른 응답 속도를 보여주는 로드밸런서

 

• TCP, UDP, TLS를 지원한다. 
• Layer 4에서 동작 (Transport Layer)
• 고성능, 상당히 낮은 Latency(지연)으로 대량 트래픽을 처리할 수 있다.
• 고정 IP 주소(Elastic IP)를 사용할 수 있다.
  • 이로써 클라이언트는 항상 동일한 IP 주소로 연결할 수 있다. (DNS Name과 IP 주소 둘다 사용 가능)
  • (ALB는 고정 IP 주소를 사용 할수 없다)
• Lambda는 NLB와 사용 할 수 없다. ALB는 사용가능 (HTTPS 기반의 트래픽을 처리하기 때문에)
• Sticky Session 사용 불가

 

 

4. Gateway Load Balancer (GWLB)

위의 로드밸런서들과 달리 트래픽을 체크하는 로드 밸런서

 

• TCP/UDP 트래픽을 처리
• Layer 4에서 동작 (Transport Layer)
• 방화벽, 침입 탐지 및 방지 시스템(IDS/IPS), 심층 패킷 검사 시스템과 같은 가상 어플라이언스를 배포, 확장 및 관리할 수 있다.
• 트래픽이 도달하기전에 먼저 트래픽을 검사하거나 분석하는 작업을 먼저 수행할 수 있게 하는 서비스.

 

 

---

🤔 SAA-C03 문제

한 회사가 AWS에 배포된 3계층 웹 애플리케이션을 운영하고 있습니다. 웹 서버는 VPC의 퍼블릭 서브넷에 배포되어 있으며, 애플리케이션 서버와 데이터베이스 서버는 동일한 VPC의 프라이빗 서브넷에 배포되어 있습니다. 회사는 AWS Marketplace에서 서드파티 가상 방화벽 장비를 검사용 VPC에 배포했습니다. 이 장비는 IP 패킷을 수신할 수 있는 IP 인터페이스로 구성되어 있습니다.

솔루션 아키텍트는 웹 서버에 도달하기 전에 애플리케이션으로의 모든 트래픽을 검사하기 위해 웹 애플리케이션을 방화벽 장비와 통합해야 합니다.

가장 적은 운영 오버헤드로 이 요구 사항을 충족하는 솔루션은 무엇입니까?

 

1. 애플리케이션의 VPC의 퍼블릭 서브넷에 Network Load Balancer를 생성하여 트래픽을 방화벽 장비로 라우팅합니다.
2. 애플리케이션의 VPC의 퍼블릭 서브넷에 Application Load Balancer를 생성하여 트래픽을 방화벽 장비로 라우팅합니다.
3. 검사용 VPC에  transit gateway를 배포합니다. 라우트 테이블을 구성하여 들어오는 패킷을 트랜짓 게이트웨이를 통해 라우팅합니다.
4. 검사용 VPC에 Gateway Load Balancer를 배포합니다. 들어오는 패킷을 수신하고 방화벽 장비로 패킷을 전달하는 게이트웨이 로드 밸런서 엔드포인트를 생성합니다.

정답

정답. 4번

검사용 VPC에 Gateway Load Balancer를 배포합니다. 들어오는 패킷을 수신하고 방화벽 장비로 패킷을 전달하는 게이트웨이 로드 밸런서 엔드포인트를 생성합니다.

 

 

참고자료) 

https://aws.amazon.com/blogs/aws/elb-connection-draining-remove-instances-from-service-with-care/

ELB Connection Draining – Remove Instances From Service With Care | Amazon Web Services

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html

Sticky sessions for your Application Load Balancer - Elastic Load Balancing