참고 자료

• https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/
• https://www.udemy.com/course/best-aws-certified-developer-associate/

1. 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

2. Load balancing

Load Balances are servers that forward traffic to multiple servers (e.g., EC2 instances) downstream.

🔎 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)가 아니면 해당 인스턴스는 건강하지 않은 상태임.

Load balancer Security Groups

💡 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로 설정할 수 있다.

Classic Load Balancers (v1)

AWS에서 지원하지 않으며 시험에서도 관련 레퍼런스는 모두 제외됨!

Application Load Balancer (v2)

• 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 (v2)

• 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

• 배포 및 확장, 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

• 로드 밸런서는 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으로 설정하여 비활성화 가능
• 요청이 짧은 경우 낮은 값을 설정.

3. 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

• CPUUtilization: 인스턴스 전반에 걸친 평균 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 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋음.

🆕 [DVA-C02] Instance Refresh

• 목표: 시작 템플릿을 업데이트하고 전체 오토 스케일링 그룹을 업데이트함. 이에 따라 모든 EC2 인스턴스를 다시 생성해야 함
  • 인스턴스를 종료한 다음 다시 나타날 때까지 기다리는 대신, 오토 스케일링 그룹의 고유 기능인 인스턴스 새로 고침을 사용할 수 있다.
  • 최소 정상 백분율(minimum healthy percentage)을 설정할 수 있음
  • 워밍업 시간 지정 (인스턴스가 사용 가능할 때까지 얼마나 걸리는지)