EC2에 이어 ELB(Elastic Load Balancer)와 ASG(Auto-Scaling Group) 기능을 소개한다. ELB는 메뉴 상으로 EC2에 포함되어있지만, EC2에만 사용되진 않는다. EC2, ECS, Lambda 등 여러 서비스로의 로드밸런싱 기능을 맡는다. ASG는 EC2의 자동 스케일링 설정 기능이다. 나의 경험상, EC2를 사용하여 어느정도 서버 지식이 늘었다면, EC2를 private 서브넷 영역에 두고 로드밸런싱하며 오토스케일링으로 좀 더 큰 트래픽을 다룰 준비를 해야한다고 생각한다. 단순히 퍼블릭 영역에 EC2를 두고 퍼블릭 IP로 접속하는 것은 보안에도 좋지않고 구조도 더 확장하기 어렵다. 갈수록 규모가 커져가는 서비스를 다루기 위해, 자동으로 scale-out되고 부하 분산하는 방법을 알아보자.

AWS의 ELB, ASG 서비스에 대해 알아보기 전 먼저 알아야할 개념이 있다.

Scability(확장성)

애플리케이션 혹은 시스템이 적응하여 더 큰 부하를 처리할 수 있는 능력을 말한다.

• 수직 확장성(Vertical Scalability): 하드웨어의 스펙을 높여 더 많은 부하를 처리하는 방식이다. 소위 "scale-up"이라고 한다. 일반적으로 데이터베이스와 같은 비-분산 시스템에서 사용된다. AWS에서는 RDS와 Elasticache가 수직 확장을 지원한다. EC2를 예로 들면, t2.nano에서 u-12tb1.metal로 인스턴스 유형을 변경하는 것을 말한다.
• 수평 확장성(Horizontal Scalability, 탄력성): "scale-out"한다고 한다. 여러 서버에 걸쳐 부하를 분산시키는 분산 시스템을 의미한다. MSA와 같이 현대의 애플리케이션 아키텍처에 일반적으로 적용되며, 고가용성(High Availability)을 포함해 다양한 이점을 제공한다. EC2라면, Auto-scaling group을 설정하고 Elastic Load Balancer를 연결할 수 있다. 더불어 "multi AZ"를 통해 가용성을 높일 수 있다. Auto Scaling Group, Load Balancer 모두에 적용 가능하다.

ELB; Elastic Load Balancer

여러 서버에 트래픽을 분산시키기 위한 AWS 서비스이다. 특정 IP를 화이트리스팅하는 데 유리한 Network Load Balancer(NLB), Layer 7(HTTP, HTTPS)에서 작동하는 Application Load Balancer(ALB) 등 다양한 타입이 있다.

사용 목적

• 다수의 다운스트림 인스턴스에 대한 부하 분산
• expose a single point of access (DNS) to application
• 다운스트림 인스턴스의 실패의 매끄러운 관리
• 규칙적인 헬스 체크
• 웹사이트에 SSL termination(HTTPS)를 제공한다.
• enforce stickiness with cookies (쿠키를 이용한 세션 고정)
• Region에 걸친 고가용성
• 퍼블릭/프라이빗 트래픽의 분리

타입

• Classic Load Balancer: HTTP, HTTPS, TCP (이제는 권장하지 않는 타입이다)
• Application Load Balancer: HTTP, HTTPS, Websocket
• Network Load Balancer: TCP, TLS (secure TCP), UDP
• Gateway Load Balancer: Layer 3에서 작동한다.
  

ALB

• Layer 7에서 작동한다.
• 다수의 HTTP 애플리케이션에 대상 그룹을 거쳐 로드밸런싱한다.
• HTTP와 Websocket을 지원한다.
• redirect를 지원한다.(e.g. HTTP → HTTPS)
• 대상 그룹의 라우팅에 대해 아래 기준으로 가능
  • URL path
  • URL query
  • URL host

*대상 그룹

• EC2 instance(ASG가 관리할 수 있다)
• ECS tasks
• Lambda functions
• IP Addresses: private IPs

NLB

• Layer 4(Transport; TCP, UDP)에서 작동한다.
• 초당 백만 요청을 다룰 수 있다.
• 지연시간 100ms 이하 (vs ALB 400 ms)
• AZ(가용영역) 당 하나의 정적 IP를 가지며, 유동 IP 할당을 지원한다. 특정 IP를 화이트리스팅하는데 장점을 가진다.
• NLB는 극단의 퍼포먼스, TCP 또는 UDP 트래픽에 사용된다
• 프리 티어가 아니다.
• Health Check은 TCP, HTTP, HTTPS 프로토콜을 지원한다.
• NLB만이 static DNS명과 static IP를 지원한다. 반면, ALB는 static DNS명을 제공하지만 static IP는 제공하지않는다.
  → 이는 AWS가 관리하는 인프라가 변경되더라도 ELB가 static endpoint를 사용하여 액세스할 수 있도록 하기 위함이다. 만약 IP가 변경되면 로드밸런서 설정도 변경되어야하기 때문이다.

*대상 그룹

• EC2 instance
• private IP
• ALB

GLB

• 서드파티 네트워크 가상 기기를 배포하고, 확장하고, 관리할 때 사용
  e.g.) 방화벽, 침입 감지 및 예방 시스템, deep packet 분석 시스템, 페이로드 수정, …
• Layer3 (Network layer)에서 작동(IP 패킷)
• 다음 기능을 조합
  • Transparent Network Gateway: 모든 트래픽에 대한 단일 출입
  • Load Balancer: 해당 가상 어플라이언스에 트래픽 분산
• 포트 6081의 GENEVE 프로토콜을 사용한다.

*대상 그룹

• EC2 instance
• private IP

Sticky Sessions

• 같은 클라이언트가 항상 같은 인스턴스에 연결되도록 한다. 대상 그룹에 적용한다.
• CLB, ALB, NLB에 적용 가능하다.
• 로드밸런서가 Cookie를 자동 적용하여, stickiness의 expiration date 정보를 심는다.
• 사용자가 세션을 잃지않도록한다.
• 부하 분산에 어려움이 생길 수도 있다.

Application-based Cookies

• Custom cookie
  • 타겟에 의해 생성된다.
  • 애플리케이션에 필수인 커스텀 속성을 포함할 수 있다.
  • 대상 그룹 별로 반드시 명칭을 지정해야한다.
  • 예약된 쿠키명은 사용하지 않는다.
    e.g.) AWSALB, AWSALBAPP, AWSALBTG
• Application cookie; AWSALBAPP.
  • 로드밸런서가 생성한다.

Duration-based Cookies; AWSALB(ALB), AWSELB(CLB)

• 로드밸런서가 생성한다.

Cross-Zone Load Balancing

• 가용영역이 2개 있고, 각 로드밸런서가 존재할 때, Cross-Zone 로드밸런싱이 적용되어있으면 가용영역에 상관없이 대상 그룹내 인스턴스에 고르게 전달한다.
• 반대라면, 각 해당 가용영역에만 분산한다.

ELB별 비교

• ALB: 기본값:활성, 요금부과X → 단, ELB 설정이 아닌 타겟그룹 설정에서 변경 가능하다.
• NLB & GLB: 기본값:비활성, 요금부과O
• CLB: 기본값:비활성, 요금부과X

SSL/TLS Certificates

• 클라이언트 ↔ 로드밸런서 사이에 트래픽을 전송 중에 암호화하여 보호한다. (전송 중 암호화)
• Public SSL 인증서는 CA(Certificate Authorities)가 발행한다. (e.g. Comodo, Symantec, GoDaddy, …)
• 만료일이 존재하므로, 갱신되어야한다.

로드밸런서

• 일반적으로 클라이언트 요청을 직접 받는 통신에만 암호화를 적용한다. 암호화 과정 자체에 성능 저하가 있기 때문에 보안이 보장받는 VPC 내에서는 필요가 없기 때문이다.
  e.g.) Client-(HTTPS)-ELB-(HTTP)-EC2
• X.509 인증서를 사용한다.
• ACM(AWS Certificate Manager)를 통해 인증서를 관리할 수 있다(자체 인증서를 직접 업로드하여 대체 가능).
• HTTPS listener
  • 기본 인증서를 반드시 지정해야한다.
  • 여러 도메인을 지원하는 optional 인증서 목록을 추가할 수 있다.
  • 클라이언트는 호스트명을 지정하는 SNI(Server Name Indication)을 사용할 수 있다.
  • 레거시 클라이언트에서 오래된 버전의 인증서를 지원하기 위해 보안 정책을 지정할 수 있다.
• SNI
  • 한 웹서버에 여러 인증서를 로딩해야하는 문제를 해결한다.
  • 클라이언트가 처음 SSL handshake 시 타겟 서버의 호스트명을 지정해야한다.
    → 그러면 서버는 맞는 인증서를 찾거나, 기본 인증서를 반환할 것이다.
  • ALB, NLB, CloudFront에만 적용된다. CLB는 지원하지 않는다.
    • CLB: 하나의 인증서만 지원=여러 인증서는 여러 CLB를 생성하여 사용
    • ALB, NLB: 다수의 리스너에 대응하는 다수의 인증서 사용 지원(SNI 사용)

Connection Draining

• 인스턴스가 제거 중이거나 unhealthy할 때 전송 중인 요청을 완료할 시간을 설정한다. 제거 중인 인스턴스로 새 요청이 전달되는 것을 막고, 이미 받은 요청은 처리한다. 해당 시간동안 인스턴스는 삭제되지 않는다.
• 사용자의 요청을 처리 중인 EC2 인스턴스를 바로 삭제하지 못하도록 방지하는 기능이다. 예를 들어 사용자 수가 줄어들면 Auto Scaling이 EC2 인스턴스를 삭제한다. 마침 사용자가 해당 EC2 인스턴스에서 파일을 다운로드하고 있었는데 EC2 인스턴스가 삭제되어버리면 파일 다운로드는 중간에 끊어진다. EC2 인스턴스를 삭제하기 전에 사용자의 요청을 처리할 수 있도록 지정한 시간만큼 기다린다. 그리고 기다리는 동안에는 새로운 커넥션을 받지 않는다.
• 1-3600 초까지 설정할 수 있고, 기본값은 300이다. 0으로 설정하면 비활성화된다.
• 요청이 짧다면 낮게 설정한다.
• 요청이 길면(파일 다운로드 기능 등) 높게 설정해야한다.

ASG

• 웹사이트와 애플리케이션의 부하는 변할 수 있다. 클라우드에서는 이 서버를 빠르게 생성하거나 제거할 수 있다.
• 부하가 증가할 때 scale out한다.
• 부하가 감소할 때 scale in한다.
• 작동하는 EC2 instance의 최소 수와 최대 수를 보장한다.
• 이전 인스턴스가 종료될 경우(예를 들어, unhealthy) 재생성한다.
• 자체 비용은 무료이고 EC2 인스턴스 사용량에 따라 지불한다.

Attributes

• Launch Template을 만들어야한다.(기존 Launch Configuration은 deprecated)
  • AMI + Instance Type
  • EC2 User Data (시작할 때 작업)
  • EBS Volumes
  • Security Groups
  • SSH Key Pair
  • IAM Roles for your EC2 Instances
  • Network + Subnets Information
  • Load Balancer Information
• Min Size / Max Size / Initial Capacity
  • scale out 이벤트 중 ASG는 maximum capacity를 초과할 수 없다.
• Scaling Policies
  • CloudWatch 경보에 기반해 ASG 설정을 할수있다.
  • alarm은 전체에 걸친 ASG 인스턴스에서 계산된 평균 CPU같은 수치를 모니터링한다.
  • scale-out, scale-in 정책을 생성할 수 있다.

Scaling Policies

• Dynamic Scaling Policies
  • Target Tracking Scaling: 가장 간단하고 쉬운 셋업; e.g. “평균 CPU가 40%에 머물길 원한다”로 설정
  • Simple / Step Scaling: “CPU가 70%를 초과하여 CloudWatch alarm이 울리면 2 units를 추가, 30% 미만이 되면 1개를 지워라”
  • Scheduled Actions: 알려진 사용패턴에 기반해 스케일링을 예측한다. e.g.) “금요일 오후 5시에 최소 capacity를 10까지 높여라“
• Predictive Scaling: 이전 부하 history를 분석하여 미래를 예측하고, 해당 패턴에 맞춰 스케일링을 조절하는 스케쥴링을 설정한다.
• 스케일링을 하기에 좋은 척도
  • CPU 사용량(평균 CPU)
  • 타겟 당 요청량: 인스턴스마다 요청 수
  • 평균 네트워크 입출력
  • 다른 커스텀 metric(CloudWatch를 사용하여 푸시)
• Scaling Cooldowns
  • 스케일링 활동 이후, 쿨다운 기간에 들어간다(default: 300초)
  • 쿨다운 동안, ASG의 인스턴스 추가 또는 제거는 일어나지 않는다.

Instance Refresh

• launch template를 업데이트하고, 모든 인스턴스를 재생성하고 싶을 때, Instance Refresh를 사용할 수 있다.
• min healthy percentage를 세팅한다.
• 웜업 타임(인스턴스를 사용할 준비가 될 때까지 얼마나 걸릴지)을 지정한다.