AWS - Elastic Load Balancer(ELB) & Elastic Beanstalk(EB)

Load Balancer

---

서버나 인프라에 가해지는 작업량, 혹은 트래픽 부하를 로드라고 한다. 한 서버가 모든 로드를 다 부담할 때 트래픽이 너무 많다면 장애가 발생할 것이다. 이럴 때 이러한 로드를 여러 리소스에 분산시키는 것이 로드밸런서이다. AWS에는 로드밸런서 서비스로 ELB(Elastic Load Balancer)가 있다.

 

로드밸런서는 OSI 7계층에서 3, 4, 7계층에 존재할 수 있다. 각각 IP, TCP/UDP, 그리고 HTTP 기반으로 트래픽 분산을 수행한다. AWS에서는 3계층 로드밸런서로 GWLB(Gateway Load Balancer)가 2020년 쯤 출시되었는데, 시험에선 어쩌다 한 번 나오고 대부분 4계층 로드밸런서인 NLB(Network Load Balancer)와 7계층 로드밸런서인 ALB(Application Load Balancer)가 자주 나온다.

 

ELB의 외부 접근 여부는 선택이다. 인터넷으로부터의 부하를 분산하려면 external ELB가 가능하고, 내부적인 네트워크 상에서의 로드밸런싱만 필요해 외부에 노출하고 싶지 않다면 internal ELB가 가능하다. ELB도 특정 VPC와 subnet에 소속되어야 한다. 인터넷 연결이 필요하다면 Public subnet에 존재해야하고, 내부적으로 두고싶다면 Private subnet에 위치시킬 수도 있다. 특정 subnet에 소속되는 것이니 해당 subnet의 NACL(Network Access Control List)에도 영향을 받는다.

 

ELB도 인스턴스라서 Security Group을 부착해서 인바운드와 아웃바운드에 대한 정의를 해주어야한다. 예를 들어 인터넷으로부터 트래픽을 받는 ELB라면 0.0.0.0의 모든 HTTP 혹은 HTTPS를 인바운드 트래픽으로 허용해야하고 분산되는 EC2 인스턴스들은 해당 ELB의 인바운드 트래픽을 허용해야한다.

 

연결된 타겟들의 상태를 자체적인 Health Check를 통해서 진행한다. 트래픽 분산 대상 중 Health Check가 unhealthy인 대상이 있다면 그 인스턴스는 회피하고 트래픽 분산을 진행한다. 특정 인스턴스의 장애 발생 시 장애를 쉽게 극복할 수 있는 방법이다.

 

ALB - Application Load Balancer

7계층 로드밸런서로 HTTP 1.1, 2.0, HTTPS, WebSocket을 지원한다. 리스너를 설정해 HTTP 요청을 HTTPS로 리다이렉트가 가능하지만, 그 반대는 당연히 안된다. 기본적으로 AWS에서 제공하는 고정된 hostname을 가지고 있다. 고정 IP 등은 사용하지 못한다.

 

타겟 그룹으로 여러 인스턴스에 분산이 가능하다. 타겟 그룹이란 어떤 인스턴스, 컨테이너, 포트로 포워딩할 것인지에 대한 타겟의 그룹이다. 밸런싱 대상들을 타겟 그룹으로 정하는 것이고, 인바운드에 관한 설정은 리스너와 보안 그룹으로 정해야한다. 타겟으로는 EC2 인스턴스, ECS 태스크, 람다, 그리고 특정 IP 주소를 정할 수 있다.

 

일반적으로 EC2 인스턴스들을 ELB에 연결하고, LB 호스트 명은 DNS에 연결해서 단일 지점으로 접근을 관리하는 것이 권장된다.

ALB가 연결되면 클라이언트의 요청을 온전히 EC2 인스턴스에 전달하는 것이 아니다. 그렇기 때문에 분산 받는 EC2 인스턴스나 컨테이너는 클라이언트 IP 주소나 포트를 확인하지 못한다. 이를 확인하기 위해선 x-forwarded-for과 x-forwarded-port를 요청 헤더에서 확인해야한다.

 

리스너

ELB가 먼저 요청을 받게 되면(Listen), 그에 맞는 행위를 규칙으로 정할 수 있다. 우선 규칙에서 정할 수 있는 라우팅 방식은 다음과 같다.

1. URL Path - 경로 기반
   요청이 http://{hostname}/{path}라면 path에 해당하는 경로를 파악해 그에 맞는 대상 그룹으로 연결시킬 수 있다.
2. Host - 호스트 기반
   요청이 위와 같을 때 hostname에 해당하는 부분에 따라 그에 맞는 대상 그룹으로 연결시킬 수 있다. 호스트 기반과 경로 기반을 결합해서 라우팅 규칙을 만들 수도 있다.
3. HTTP Method
   GET, POST, PUT, DELETE 등 HTTP Method에 따라 그에 맞는 대상 그룹으로 연결 할 수 있다.
4. IP 주소
   케이스가 제한적이겠지만, 요청의 IP 주소를 보고 라우팅을 정할 수도 있다.
5. Query String
   http://{hostname}/{path}?{queryString} 형식의 요청에서 Query String에 해당하는 부분에 맞는 타겟 그룹으로 연결할 수도 있다.

위와 같이 규칙에서 라우팅 방식으로 정할 수도 있고, 개별적으로 Condition을 세팅해서 어떤 대상 그룹으로 포워딩할지, 혹은 Redirect나 Fixed Response로 연결할 지에 대한 설정도 할 수 있다. 예를 들어 HTTP에서 HTTPS로의 리다이렉트가 있고, 지원하지 않는 요청이면 에러 페이지로 Fixed Response를 설정할 수도 있다. 같은 조건이 달성된다면 개별적으로 설정된 Priority로 타겟 그룹을 찾아간다.

 

Sticky Session - Session Affinity

여러 EC2 인스턴스로 분산하다보면, 세션 정보가 랜덤하게 갱신되기 마련이다. 이를 극복하기 위해 JWT 등의 상태 비저장 방식이나 세션 클러스터를 사용할 수도 있지만, 세션이 생성되었던 인스턴스로 밸런싱을 해줄 수도 있다. ALB에서 Sticky Session을 활용하면 그러한 방식을 사용할 수 있다. 특정 쿠키를 사용해서 이를 판단하는데, 쿠키의 이름은 기본적으로 제공해주기도 하지만 직접 설정해줄 수도 있다.

 

기본적으로 제공되는 쿠키는 AWSALB, AWSALBAPP 등이 있다.

 

분산을 억지로 몰아주는 것이기 때문에 당연히 성능의 이점이 줄어든다.

 

NLB - Network Load Balancer

NLB는 TCP/UDP 기반의 고성능 로드밸런서이다. IP 주소와 포트를 기반으로 로드밸런싱을 수행한다. 하지만 지원하는 프로토콜은 TCP, UDP, TLS이다. 특이하게도 TLS를 지원하며, HTTP가 아니라 HTTPS 기반의 요청이라면 TLS 리스너를 설정해 처리할 수 있다!

 

TCP/UDP 기반이기에 HTTP보다 확인해야할 정보가 적고, 그렇기 때문에 성능이 굉장히 빠르다! 그만큼 비싸고, HTTP보다 적은 정보를 확인하기 때문에 정교한 라우팅 등의 기능성은 부족하다.

 

subnet 당 한 고정 IP 주소만 보유할 수 있다. 애플리케이션이 여러 IP 주소를 보유한다면 서브넷에 IP 주소를 할당해 로드밸런싱을 처리할 수 있다.

 

타겟으로는 EC2 인스턴스, 사설 IP 주소, 로드밸런서를 지정할 수 있다. NLB로 우선적인 밸런싱을 수행한 후 ALB를 뒷단에 연결해 부족한 기능성을 보완할 수 있다.

 

Health Check

NLB도 연결된 타겟들의 상태를 확인하는데, 타겟이 지원하는 방식으로 Health Check를 수행 가능하다. 연결된 타겟들의 상태를 확인할 땐 HTTP 기반으로 수행할 수 있다. 그렇기 때문에 ALB와도 연결이 가능한 것이다. NLB라고 무조건적으로 TCP/UDP 기반이라고 외우면 안된다. NLB도 TLS를 수신할 수 있을 뿐만 아니라, Health Check는 HTTP 기반도 가능하기 때문이다.

 

GWLB - Gatway Load Balancer

GWLB는 AWS의 3계층 로드밸런서이다. 트래픽을 실질적으로 분산시키기보단 주로 트래픽 모니터링, 필터링, 보안 등의 용도로 사용된다. 보안을 위한 서드파티 응용이 필요할 시 사용될 수 있다. 아주 자세한 건 거의 나오지 않지만, 보안과 로드밸런싱이 엮여있는 문제라면 고민해 볼 수 있다. 6081 포트를 사용하는 GENEVE 프로토콜을 지원한다. 보안과 로드밸런싱이 엮여도 해당 프로토콜이 아니라면 고려하지말자.

 

Cross-Zone LB

LB는 특정 subnet에서만 분산을 할 수도 있지만, 그 범위를 VPC로 넓혀 AZ를 넘나들며 좀 더 효율적인 분산을 달성할 수도 있다.

 

예를 들어 a AZ의 subnet에 8개의 인스턴스가 존재하고, b AZ의 subnet에 2개의 인스턴스가 존재할 때, LB가 b AZ의 subnet에 위치했다고 가정해보자. LB는 기본적으로 같은 b AZ의 subnet에 있는 인스턴스에만 트래픽을 분산할 것이다. Cross-Zone을 활성화하면 a AZ까지 범위를 확장해 트래픽을 분산한다.

 

ALB는 이 설정이 기본적으로 활성화되어있다. NLB는 그렇지 않다.자세하게 따지자면 ALB는 애플리케이션이 장애를 잘 예방하고 잘 대응할 수 있는 가용성과 탄력성을 보장하기 위해 존재하기 때문에 AZ 간 데이터 전송 요금이 발생하지 않는다. 반면 NLB는 단일 AZ에서 트래픽 분산 시 비용이 낮아지는데, Cross-Zone을 활성화하면 데이터 전송 요금이 추가적으로 발생한다. ALB는 7계층 로드밸런서이고 NLB는 네트워크 레벨 트래픽을 처리하기 때문에 성능이 우월하면서도 독립적인 트래픽 처리를 위해 존재하는 의미가 크다고 생각한다.

 

EB - Elastic Beanstalk

EC2의 용량, 로드밸런싱, 스케일링, 모니터링 등 완전 자동화를 지원해주며 애플리케이션의 배포를 자동으로 관리해주는 솔루션이다. 하나의 EC2 인스턴스를 사용하며 완전 관리형이기 때문에 AWS에서 높은 가용성을 제공해준다.

 

EB는 인스턴스가 아닌 서비스이기 때문에 IAM Role을 부여해서 EB 실행 시 할 수 있는 권한의 범위를 제어해주어야 한다.

개발자는 애플리케이션 코드만 작성하면 되니 매우 편리하지만, 싱글 인스턴스를 사용하며 자세한 시스템을 조정하지 못하므로 소규모 집단에 적합하다. 인스턴스의 빠른 생성, 고가용성을 보장해주며 AWS에 더 많은 관리 포인트를 이관하니 운영 오버헤드가 낮은 솔루션이다.

공부할 때 작성했던 간단 요약

Load Balancer

• 로드를 분산 → 부하를 분산 → 트래픽 분산 ⇒ 클라이언트는 알바없음
• 싱글 포인트 엑세스 (DNS) ⇒ SSL 설정 가능
• 장애 시 분산으로 극복
• 로드밸런서가 주기적으로 인스턴스 ✨health check✨
  • 살아있는거에 트래픽을 보낼 수 있기 때문. → 상태 모니터링
• 여러 리소스 사용 → Stateless 요청 처리 적합 (Cookie 등) or Session Cluster
• 고가용성!!

Elastic Load Balancer

• 조금 더 비싸도 관리형이기 때문에 편함. AWS Service랑 연결돼서 좋음
• internal, external 설정 가능 - 인터넷 facing 설정 ⇒ Internal은 왜 필요한가?
• ✨Security Group✨ 부착
  • EC2 인스턴스 앞단에 LB가 와야하니 EC2의 인바운드는 LB를 허용해야함
• Classic Load Balancer (예전꺼 - 잘 안씀)
  • HTTP, HTTPS, TCP, SSL

Application Load Balancer (새 거) - ✨7계층✨

• HTTP (2), HTTPS, WebSocke
• HTTP를 HTTPS로 변환 가능 (반대는 불가)
• target group으로 ✨여러 인스턴스 밸런싱✨가능
  • 어떤 인스턴스 / 컨테이너 / 포트로 포워딩할 것인지 타겟 ⇒ outbound만 정하는거지, inbound는 리스너 Rule로 설정
  • EC2
  • ECS task
  • Lambda
  • IP 주소
• 포트포워딩으로 ✨한 인스턴스에 여러 컨테이너✨로 밸런싱 가능
• 라우팅 방식
  • URL path ⇒ 도메인 별로 다른 인스턴스/컨테이너로 연결!! ⇒ MSA!!!!
  • URL hostname
  • HTTP method
  • IP
  • Query String
• Listener - 외부 요청을 Listen
  • Rule을 개별적으로 Condition 세팅해서 어떤 target group으로 포워딩할지 설정 가능! Redirect, Fixed Response 설정도 가능.
  • 같은 조건이면? Priority로 설정
• 기존으로는 고정된 hostname ⇒ EC2에는 LB만 allow하고 LB 호스트명은 DNS에 연결해서 싱글 포인트 엑세스
• LB에서 우선적으로 클라랑 연결 후 연결 끊고 LB가 인스턴스랑 연결 ⇒ 인스턴스 / 컨테이너는 클라이언트 IP 못 봄 ⇒ 헤더의 ✨x-forwarded-for(port)✨로 확인

Network Load Balancer - ✨4계층✨

• ✨TCP, TLS, UDP✨
• 그냥 성능 좋은 LB. ALB보다 기능성(정교한 라우팅)은 후달림
• external, internal 설정 가능 → internet facing
• ✨High Performance! Ultra-low Latency✨ ⇒ 엄청 많은 요청 처리 가능 ⇒ 비쌈!
• AZ(서브넷) 당 한 고정 IP만 보유.
  • ✨애플리케이션이 여러 IP를 보유한다면✨, 서브넷에 IP를 할당해 로드밸런싱을 처리
• SG 인바운드는 ? 인터넷 페이싱이면 HTTP가 맞겠지 → 요청은 받고 로드밸런싱을 TCP / UDP 기반으로 진행
• Target Groups
  • EC2 인스턴스
  • 사설 IP (온프레미스, AWS 인스턴스 가능)
  • LB - NLB + ALB 조합 ⇒ 네트워크 요청은 TCP / UDP를 갖고 있기 때문에 NLB의 고성능을 이용해 1차적인 LB를 하고, HTTP 라우팅을 ALB에다 위임 ⇒ 고성능 + 저지연 (NLB) + 기능성 (ALB)
  • Health check는 대상 타겟이 수신하는 프로토콜로!
• Listener
  • TCP / UDP / TLS 등으로 수신
  • LB의 포트를 듣고 있다가 해당 프로토콜, 포트의 요청이 들어오면 LB → 분산

Gateway Load Balancer (제일 최신) - 3계층

• 서드파티 응용을 위한 LB
• ✨GENEVE - 6081 포트✨ 사용

Sticky Sessions (Session Affinity)

• 사용자를 구분해 LB가 사용자가 같은 인스턴스로 가도록
• Cookie 사용 / NLB는 그냥 가능
• 당연히 성능 안 좋음. 분산 덜 됨.
• LB, Target에서 조작 가능. 기본 쿠키 이름 존재
  • AWSALB
  • AWSALBAPP

Cross-Zone LB

• ALB의 소속 서브넷마다 그 서브넷의 인스턴스로만 분산할건지, AZ를 넘어서 분산할건지.
• ALB는 기본 True. 나머지는 기본 False
  • ALB는 라우팅하는게 네트워크 앞단이라 그런거 아닐까? VPC 밖에서의 라우팅..?!
  • NLB는 AZ 별로 내부적인 라우팅이 기준이라 그런거 아닐까..?!? 4계층. 이후 데이터가 AZ를 넘어가면 과금.

Connection Draining

• Deregistration Delay
• 일정 시간(1~3600초) 이후 stop하거나 unhealthy면 deregister하는 행위 및 주기

EB - Elastic Beanstalk

• 용량, LB, 스케일링, 모니터링 자동화
• 배포 자동 관리
  • 싱글 인스턴스
  • ✨고가용 배포✨
• IAM Role을 부여해서 권한 위임
• 소규모 집단 적합
• 💫복잡한 애플리케이션, 고가용성💫 등 필요 시
  • AWS에 더 많은 관리 포인트를 이관
  • 인스턴스의 빠른 생성에 적합
• 구성
  • Application
  • Version
  • Env - AWS 리소스, 티어(웹, 워커 등), 기타 사용자 정의 env