AWS[ELB,CLB,ALB,NLB,GWLB,ASG]

Scalability & High Availability

• Scalability (확장성): 애플리케이션 / 시스템이 조정을 통해 더 많은 양을 처리할 수 있는 능력을 의미.
  • Vertical Scalability (수직 확장성)
  • Horizontal Scalability (수평 확장성) = elasticity (탄력성)
• Scalability is linked but different to High Availability!
  (확장성은 고가용성과 연결되어 있습니다)

Vertical Scalability(수직 확장성)

• 인스턴스의 크기를 확장하는 것.
• 예를 들어, 애플리케이션이 t2.micro에서 실행되고 있을 때, 수직 확장을 하면 t2.large에서 실행됨.
• 수직 확장은 데이터베이스와 같이 분산되지 않은 시스템에서 흔히 사용됨.
• RDS, ElastiCache는 수직 확장이 가능한 서비스.
• 일반적으로 수직 확장의 한계가 있음. (hardware limit)

Horizontal Scalability(수평 확장성)

• 애플리케이션의 인스턴스 / 시스템 수를 늘리는 것.
• 수평 확장을 하는 것은 분산 시스템이 있다는 것을 의미함.
  • 웹이나 현대 애플리케이션은 대부분 분산 시스템으로 이루어져 있다!
• Amazon EC2와 같은 클라우드 제공 업체 덕분에 쉽게 수평 확장이 가능.

High Availability

• 일반적으로 수평 확장과 함께 사용되는 개념.
• 애플리케이션 또는 시스템을 적어도 둘 이상의 AWS의 AZ나 데이터 센터에서 가동 중인 것을 의미.
• 고가용성의 목표: 데이터 손실에서 살아남는 것. 따라서 센터 하나가 멈춰도 계속 작동이 가능하게끔 하는 것.
• 고가용성은 수동적일 수 있음. (ex. RDS Multi AZ)
• 고가용성은 능동적일 수 있음. (ex. 수평 확장)

High Availability & Scalability for EC2

• 수직 확장: 인스턴스의 크기를 늘림 (= scale up / down)
  • From: t2.nano - 0.5G of RAM, 1 vCPU
  • to: u-12tb1.metal – 12.3 TB of RAM, 448 vCPUs
• 수평 확장: 인스턴스 수 증가 (= scale out / in)
  • Auto Scaling Group
  • 로드 밸런서
• 고가용성: 같은 애플리케이션을 실행하는 인스턴스를 다양한 AZ에 걸쳐 실행
  • Auto Scaling Group multi AZ
  • Load Balancer multi AZ

---

Load balancing

Load Balances are servers that forward traffic to multiple servers (e.g., EC2 instances) downstream.(로드 밸런싱은 여러 서버(예: EC2 인스턴스)로 트래픽을 다운스트림으로 전달하는 서버입니다.)

Why use a load balancer?

• 부하를 다수의 다운스트림 인스턴스로 분산하기 위해서.
• 애플리케이션에 단일 액세스 지점(DNS)을 노출함.
• 다운스트림 인스턴스의 장애를 원활하게 처리함.
• 인스턴스에 정기적으로 헬스 체크를 수행함.
• 웹 사이트에 대한 SSL 종료(HTTPS)를 제공함.
• 쿠키로 정적 분배를 적용함.
• 영역 간 고가용성
• 공용 트래픽과 개인 트래픽을 분리함.

Why use an Elastic Load Balancer?

• Elastic Load Balancer는 관리형 로드 밸런서임.
  • AWS가 관리하며, 어떠한 경우에도 로드 밸런서가 작동할 것을 보장.
  • AWS는 업그레이드, 유지 관리 및 고가용성을 책임짐.
  • AWS는 몇 가지 구성 놉(configuration knobs)도 제공함.
• 자체 로드 밸런서를 설정하는 것은 비용이 적게 들지만, 많은 노력이 필요함. 따라서 Elastic Load Balancer를 사용하는 것이 좋음.
• 다수의 AWS 서비스들과 통합되어 있음.
  • EC2, EC2 Auto Scaling Groups, Amazon ECS
  • AWS Certificate Manager (ACM), CloudWatch
  • Route53, AWS WAF, AWS Global Accelerator
• Elastic Load Balancer는 애플리케이션에 사용 가능한 정적 DNS 이름을 제공함

Health Checks(상태 확인)

• 로드 밸런서에서 Health Checks(상태 확인)은 매우 중요함.
• 이를 통해 로드 밸런서가 전달하는 트래픽을 처리할 수 있는 인스턴스의 가용성을 파악할 수 있음.
• 상태 확인은 특정 포트와 라우트(/health가 일반적)에서 수행됨.
• 응답이 200(OK)가 아니면 해당 인스턴스는 건강하지 않은 상태임.

---

Types of load balancer on AWS

AWS는 4가지의 관리형 로드 밸런서를 제공한다.

• Classic Load Balancer (v1 - old generation)– 2009 – CLB
  • HTTP, HTTPS, TCP, SSL (secureTCP)
• Application Load Balancer (v2 - new generation) – 2016 – ALB
  • HTTP, HTTPS, WebSocket
• Network Load Balancer (v2 - new generation) – 2017 – NLB
  • TCP, TLS (secureTCP), UDP
• Gateway Load Balancer – 2020 – GWLB
  • Operates at layer 3 (Network layer) – IP Protocol
    더 많은 기능을 가지고 있는 새로운 세대의 로드 밸런서를 사용하는 것이 좋다. 일부 로드 밸런서는 내부(private) 또는 외부(public) ELB로 설정할 수 있다.

---

Application Load Balancer (ALB)

• Layer 7, 즉 HTTP 전용 로드 밸런서.
• 여러 머신(target group) 간 다수 HTTP 애플리케이션의 라우팅에 사용됨.
• 동일 EC2 인스턴스 상의 여러 애플리케이션에 대한 로드 밸런싱 (ex. containers)
• HTTP/2와 WebSocket 지원.
• 리디렉션 지원 (ex. HTTP에서 HTTPS로)
• 대상 그룹(target groups)에 따른 라우팅:
  • URL 경로를 기반으로 라우팅
    (example.com/users & example.com/posts)
  • URL 호스트 이름 기반으로 라우팅
    (one.example.com & other.example.com)
  • 쿼리 스트링, 헤더를 기반으로 라우팅
    (example.com/users?id=123&order=false)
• ALB는 마이크로 서비스나 컨테이너 기반 애플리케이션에 가장 적합함. (ex. Docker & Amazon ECS)
• ECS의 동적 포트로 리디렉션하는 포트 매핑 기능이 있음.
• In comparison, we’d need multiple Classic Load Balancer per application

HTTP Based Traffic

Target Groups

• EC2 인스턴스 (Auto Scaling Group으로 관리될 수 있음) - HTTP
• ECS 작업 (ECS 자체에서 관리됨) - HTTP
• 람다 함수 - HTTP 요청이 JSON 이벤트로 변환됨
• IP 주소 - 프라이빗 IP 여야 함
  ALB는 여러 대상 그룹으로 라우팅할 수 있으며, 헬스 체크는 대상 그룹 수준에서 이루어진다.

Query String(쿼리 문자열) / Parameters Routing(매개 변수 라우팅)

Good to Know

• 고정된 호스트 이름 (XXX.region.elb.amazonaws.com)
• 애플리케이션 서버는 클라이언트의 IP를 직접적으로 보지 못함.
  • 클라이언트의 실제 IP는 헤더 X-Forwarded-For에 삽입됨.
  • 포트(X-Forwarded-Port)와 프로토콜(X-Forwarded-Proto)도 얻을 수 있음.

---

Network Load Balancer (NLB)

• Layer 4 (Layer 7보다 하위 계층)
  • TCP 및 UDP 트래픽을 인스턴스로 전달.
  • 초당 수백만 건의 요청 처리 가능.
  • 지연 시간이 짧음. (약 100 ms / ALB는 400 ms)
• 가용 영역 당 하나의 고정 IP를 가짐
• 탄력적 IP를 각 가용 영역에 할당할 수 있음. (helpful for whitelisting specific IP)
• Not included in the AWS free tier
  NLB Keywords: 고성능, TCP, UDP, 고정 IP

TCP (Layer 4) Based Traffic

Target Groups

• EC2 인스턴스
• IP 주소 - must be private IPs
• Application Load Balancer
• Health Checks support the TCP, HTTP and HTTPS Protocols
  

---

Gateway Load Balancer(GWLB)

• 배포 및 확장, AWS의 3rd party 네트워크 가상 어플라이언스의 플릿 관리에 사용됨.
• Example: 방화벽, 침입 탐지 및 방지 시스템, 딥 패킷 검사 시스템, 페이로드의 조작 등
• Layer 3 (모든 로드 밸런서보다 낮은 수준에서 실행됨) - IP 패킷의 네트워크 계층
• 투명한 네트워크 게이트웨이 - 단일 엔트리 / 출구
• 로드 밸런서 - 가상 어플
  라이언스로의 트래픽 분산
• 포트 6081에서 GENEVE 프로토콜 사용
  

Target Groups

• EC2 인스턴스
• IP 주소 - must be private IPs
  

---

Sticky Sessions (Session Affinity) - 고정 세션

• 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것.
  
• 로드 밸런서 뒤에 있는 동일한 인스턴스로 항상 리디렉션 되도록 고정 세션을 구현할 수 있음.
• 이는 Classic Load Balancer, Application Load Balancer 에서 설정할 수 있음.
• 고정 세션에 사용되는 "쿠키"는 클라이언트에서 로드 밸런서로 요청의 일부로서 전송되는 것임. 만료 기간을 포함하고 있음.
• 사용 사례: 사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용.
• 고정 세션을 활성화하면 백엔드 EC2 인스턴스에 부하 불균형이 발생할 수 있음.

Cookie Names

Application-based Cookies 애플리케이션 기반 쿠키

• Custom cookie
  • Generated by target
  • 애플리케이션에서 필요한 사용자 정의 속성을 포함할 수 있음
  • 쿠키 이름은 각 대상 그룹마다 개별적으로 지정해야 함
  • AWSALB, AWSALBAPP 또는 AWSALBTG는 사용 불가 (ELB에서 사용되기 때문)
• Application cookie
  • Generated by the load balancer
  • Cookie name is AWSALBAPP

Duration-based Cookies 기간 기반 쿠키

• Generated by the load balancer
• ALB인 경우엔 AWSALB, CLB인 경우엔 AWSELB

---

Cross-Zone Load Balancing

Application Load Balancer

• 대상 그룹 레벨에서 비활성화할 수 있지만 기본적으로 활성화됨.
• 가용 영역 간 데이터에 대한 요금 없음.

Network Load Balancer & Gateway Load Balancer

• 기본적으로 비활성화됨.
• 활성화하면 가용 영역 간 데이터에 대한 요금이 청구됨.

Classic Load Balancer

• 기본적으로 비활성화됨.
• 활성화하면 가용 영역 간 데이터에 대한 요금 없음.

---

SSL/TLS - Basics

• SSL 인증서: 클라이언트와 로드 밸런서 간의 트래픽을 암호화하여 전송 중에 보호. (in-flight encryption)
• SSL: 연결을 암호화하는 데 사용되는 보안 소켓 계층 (Secure Sockets Layer)
• TLS: 새로운 버전의 SSL. 전송 계층 보안 (Transport Layer Security)
• 요즘에는 TLS 인증서가 주로 사용되지만 사람들은 여전히 SSL이라고 부름.
• 인증 기관(CA)에 발급됨. (Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt 등이 있음)
• SSL 인증서에는 만료 날짜가 있어서 주기적으로 갱신해야 함.

Load Balancer - SSL Certificates(SSL 인증서)

• 로드 밸런서는 X.509 인증서 (SSL/TLS 서버 인증서)를 사용함.
• AWS에는 이 인증서들을 관리할 수 있는 ACM (AWS Certificate Manager)가 있음.
• ACM에는 사용자 지정 인증서를 업로드할 수 있음.
• HTTPS lisenter:
  • 기본 인증서를 지정해야 함.
  • 다중 도메인을 지원하기 위해 선택적으로 인증서 목록을 추가할 수 있음.
  • 클라이언트는 SNI (Server Name Indication)를 사용하여 도달하는 호스트 이름을 지정할 수 있음.
  • 보안 정책을 지정하여 SSL/TLS 이전 버전 (레거시 클라이언트)을 지원할 수 있음.

SSL - Server Name Indication(표시) (SNI)

• SNI는 여러 개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹 사이트를 지원할 수 있도록 함.
• 확장된 프로토콜로, 클라이언트가 초기 SSL 핸드셰이크 단계에서 대상 서버의 호스트 이름을 지정하도록 함.
• 이를 통해 SNI는 호스트 이름을 통해 올바른 인증서를 찾거나 기본 인증서를 반환함.

참고:

• SNI는 ALB & NBL (newer generation), CloudFront에서만 작동함
• CLB에서는 작동하지 않음.

Elastic Load Balancers - SSL Certificates

Classic Load Balancer (v1)

• 하나의 SSL 인증서만 지원함.
• 여러 개의 인증서로 여러 호스트 이름을 지원하기 위해서는 CLB 자체를 여러 개를 사용해야 함.

Application Load Balancer (v2)

• 여러 개의 SSL 인증서를 사용하는 여러 개의 리스너를 지원함.
• Server Name Indication (SNI)을 사용하여 작동함.

Network Load Balancer (v2)

• 여러 개의 SSL 인증서를 사용하는 여러 개의 리스너를 지원함.
• Server Name Indication (SNI)을 사용하여 작동함.

---

Connection Draining(연결 드레이닝)

• Feature naming:
  • CLB: Connection Draining
  • ALB & NLB:Deregistration Delay (등록 취소 지연)
• 인스턴스가 등록 취소(de-registering), 혹은 비정상적인 상태(unhealthy)에 있을 때 인스턴스에 어느 정도 시간을 주어 in-flight 요청, 즉 활성 요청을 완료할 수 있도록 하는 기능.
• 등록 취소 중인 EC2 인스턴스에 새 요청을 보내지 않도록 함.
  
• 1-3600초 사이의 값 설정 가능 (기본값: 300초)
• 0으로 설정하여 비활성화 가능
• 요청이 짧은 경우 낮은 값을 설정.

---

Auto Scaling Group

웹 사이트나 애플리케이션의 부하는 변할 수 있다. 이때 사용자는 클라우드에서, 즉 AWS에서 서버를 빠르게 생성하고 종료할 수 있다.
이를 자동화하고 싶다면, ASG (Auto Scaling Group)을 생성할 수 있다.

ASG의 목표:

• 부하 증가에 따라 EC2 인스턴스를 추가하여 스케일 아웃
• 부하 감소에 따라 EC2 인스턴스를 제거하여 스케일 인
• 최소 및 최대 실행 중인 EC2 인스턴스 수 보장
• 새로운 인스턴스를 로드 밸런서에 자동 등록
• 한 인스턴스가 비정상(unhealthy)이면 종료하고 이를 대체할 새 EC2 인스턴스를 생성

ASG는 무료! (EC2 인스턴스와 같은, 생성된 하위 리소스에 대한 비용만 내면 됨)

Auto Scaling Group in AWS

Auto Scaling Group in AWS with Load Balancer

Auto Scaling Group Attributes(특성)

• Launch Template (이전에는 Launch Configurations라는 용어 사용함)
  • AMI + InstanceType
  • 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(초기 용량)
• Scaling Policies

CloudWatch Alarms & Scaling

• ASG를 CloudWatch 경보에 기반하여 스케일 인 및 스케일 아웃할 수 있음.
• 경보는 지표(평균 CPU, 사용자 지정 지표 - custom metric)를 모니터링 함.
• 평균 CPU와 같은 지표는 전체 ASG 인스턴스에 대해 계산됨.
• 경보를 기반으로
  • scale-out 정책(인스턴스 수 증가)를 만들 수 있음
  • scale-in 정책(인스턴스 수 감소)를 만들 수 있음

Auto Scaling Policies

Dynamic Scaling Policies 동적 조정

Target Tracking Scaling 대상 추적 크기 조정

• 가장 간단하고 쉽게 설정할 수 있는 방법
• ex. 평균 ASG CPU가 약 40% 대에 유지되도록 함

Simple / Step Scaling 단계 크기 조정

• CloudWatch 경보가 트리거될 때 (ex. CPU > 70%), 2 유닛 추가하도록 설정
• CloudWatch 경보가 트리거될 때 (ex. CPU < 30%), 1 유닛 제거 설정

Scheduled Actions 예약된 크기 조정

• 알려진 사용 패턴에 기반하여 스케일링을 예상
• ex. 매주 금요일 오후 5시에 최소 용량을 10으로 증가

Predictive Scaling 예측 조정

Predictive scaling 예측 조정

• 부하를 지속적으로 예측하고 미리 스케일링 일정을 예약하는 것

Good metrics to scale on

• CPU Utilization: 인스턴스 전반에 걸친 평균 CPU 사용률
• RequestCountPerTarget: EC2 인스턴스 당 요청 수가 안정적인지 확인하기 위해 사용
• Average Network In / Out (if your application is network bound)
• Any custom metric (that you push using CloudWatch)

Scaling Cooldowns

• 스케일링 활동이 발생한 후, 쿨다운 기간에 진입. (기본값 300초)
• 쿨다운 기간 동안 ASG는 추가 인스턴스를 실행 또는 종료할 수 없음. (to allow for metrics to stabilize)
• Advice: 즉시 사용이 가능한 AMI를 사용하여 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋음.