[AWS SAA-C03] 8장 High Availablity & Scalabitity : ELB, ASG

아 한 시간 동안 내용 정리한 거 다 날아감 진짜 짜증난다; ㅠ

 

Scalability & High Availability

스케일링 (Scalability)

• 애플리케이션이나 시스템이 부하 증가에 따라 자원을 늘려 처리량을 견딜 수 있는 능력
• 스케일링 종류:
  • 수직 스케일링 (Vertical Scaling)
    • 기존 인스턴스의 사양을 늘려 성능 향상 (예: t2.micro -> t2.large)
    • 하드웨어 제약으로 인해 한계가 있다. 
    • ex) DB 서버 (RDS, ElastiCache) 
  • 수평 스케일링 (Horizontal Scaling)
    • 인스턴스/시스템의 대수를 늘려 부하 분산 (클라우드 환경에서 흔히 사용 -> EC2 등의 클라우드 서비스 이용 시 쉽게 구현 가능)
    • ex) 분산 시스템 (웹 애플리케이션)
• 스케일링과 고가용성은 관련이 있지만 별개 개념이다. 

고가용성 (High Availability)

• 주로 수평 스케일링과 함께 사용
• 최소 2개의 데이터센터 (AZ, Availability Zone)에 애플리케이션/시스템을 구축하여 데이터센터 장애 발생 시에도 서비스 지속 가동
• 고가용성을 보장하는 두가지 방법
  • Passive : 시스템 구성 시 대기 시스템을 추가적으로 마련하여 운영하는 방식. 정상 운영 시에는 주 시스템만 작동하며, 주 시스템에 장애가 발생하면 자동 또는 수동으로 대기 시스템으로 전환하여 서비스를 유지 (ex. RDS multi-AZ)
  • Active: 여러 시스템을 동시에 실행하여 서비스를 제공하는 방식. 각 시스템은 서로 동일한 작업을 수행하며, 하나의 시스템에 장애가 발생해도 나머지 시스템들이 서비스 지속을 보장 (ex. horizontal scaling)

EC2에서의 고가용성과 스케일링

• 수직 스케일링: 인스턴스 사양 변경 (t2.nano -> u-12tb1.metal)
• 수평 스케일링: 인스턴스 대수 늘리기 (Auto Scaling Group, Load Balancer)
• 고가용성: multi-AZ에 걸쳐 동일한 애플리케이션 실행 (Auto Scaling Group multi AZ, Load Balancer multi AZ)

 

 Load Balancer

• 로드 밸런서 : 여러 서버 (예: EC2 인스턴스)에 트래픽을 분산시켜주는 서버. 즉, 사용자 요청이 단일 진입점을 통해 들어오면 로드 밸런서가 이를 여러 서버로 효율적으로 분배해 처리량을 늘리고 성능을 향상

ELB

 

로드밸런서를 사용하는 이유

• 여러 서버 간 부하 분산: 사용자 트래픽을 단일 서버에 집중시키지 않고 여러 서버로 분산시켜 전체 시스템 성능을 유지
• 단일 진입점(DNS) 제공: 사용자는 도메인 이름과 같은 단일 엔드포인트만을 통해 쉽게 애플리케이션에 접속할 수 있다. 로드 밸런서가 내부적으로 서버들을 관리한다.
• 서버 장애 처리: 특정 서버에 문제가 발생하더라도 로드 밸런서는 정상적인 서버로 트래픽을 유도하여 서비스 지속 가동을 보장한다.
• 정기적인 health check: 로드 밸런서는 주기적으로 서버 상태를 확인하여 문제가 있는 서버는 트래픽 분산에서 제외한다.
• 웹사이트 SSL 종료 (HTTPS): 로드 밸런서에서 SSL 인증서를 종료하여 개별 서버에 별도로 인증서 설정을 하지 않아도 된다.
• 쿠키 기반 세션 유지 (Stickiness): 특정 세션을 유지하기 위해 쿠키를 사용하여 사용자를 항상 동일한 서버로 연결할 수 있다.
• AZ 간 고가용성: 로드 밸런서는 여러 AZ에 분산된 서버들과 함께 작동하여 하나의 AZ의 장애에도 서비스 지속을 보장한다.
• public 트래픽과 private 트래픽 분리: 로드 밸런서는 public 트래픽과 private 트래픽을 분리하여 보안을 강화한다. (ex. 사용자의 public 트래픽을 private 로드밸런서 통해 내부 서버들로 분산)

 

왜 AWS의 ELB를 사용하는가?

 

ELB는 AWS에서 제공하는 로드밸런서 서비스이다. 

 

• 관리 편리성: AWS가 ELB의 가동, 업그레이드, 유지보수, 고가용성을 책임지므로 사용자가 쉽게 사용한다. 
• 간편한 설정: ELB는 기본적인 설정만 필요하며 복잡한 설정 없이 빠르게 사용 가능
• 다양한 AWS 서비스와 통합: ELB는 EC2, EC2 자동 스케일링 그룹, Amazon ECS, AWS Certificate Manager(ACM), CloudWatch, Route 53, AWS WAF, AWS Global Accelerator 등 다양한 AWS 서비스와 통합되어 쉽게 사용 가능하다. 

ELB의 Health Check 기능

• 로드 밸런서는 Health Check를 통해 트래픽을 전달할 대상 서버의 상태를 확인한다.
• 일반적으로 특정 포트와 경로 (예: /health)를 이용하여 서버 상태를 확인하며, 응답 코드가 200(성공)이 아니면 해당 서버는 Health Check 에서 제외된다. 

헬스체크

 

 

AWS의 4가지 ELB

AWS에서는 총 4개의 ELB를 제공한다. 

밑에 내용이 어어어어어엄청 길고 많은데,... 그냥 몇 계층에서 사용되는지, 타켓 그룹은 뭘 가질 수 있는지 등이 크게 구별되는 차이점 같으니, 이런 것들을 중점으로 구분하면 좋을 듯 하다. (뇌피셜임)

 

(Gemini가 만들어준 비교표)

	ALB	NLB	GLB
트래픽 유형	HTTP/HTTPS	TCP/UDP	HTTP/HTTPS, TCP/UDP
로드 밸런싱 계층	L7	L4	L3, L4
주요 기능	레이어 7 로드 밸런싱, 다양한 건강 검사, WAF 통합	고성능, 저지연 처리, 대규모 트래픽 지원	여러 VPC 간 트래픽 라우팅, 높은 가용성
적용 사례	웹 애플리케이션, 모바일 백엔드, API 게이트웨이, 마이크로서비스 아키텍처	온라인 게임 서버, VoIP, 스트리밍 미디어 서비스, 고성능 네트워킹 애플리케이션	대규모 웹 애플리케이션, 마이크로서비스 아키텍처, 여러 VPC 환경
권장 사항	새 애플리케이션에 적합	고성능, 저지연 트래픽 처리 필요 시	여러 VPC 간 트래픽 라우팅 필요 시

 

 

1. Classic Load Balancer (CLB)

• 출시 연도: 2009년 (가장 오래된 버전)
• 지원 프로토콜: HTTP, HTTPS, TCP, SSL (secure TCP)
• 특징: 제한적인 기능, 지금은 지원 종료됨. (=> 즉, 시험에 안나오니까 안봐도 된다.)

2. Application Load Balancer (ALB)

• 출시 연도: 2016년 (새로운 세대)
• 지원 프로토콜: HTTP, HTTPS, WebSocket -> 즉, 웹 트래픽 처리하도록 설계
• 특징:
  • 7계층(Application layer) 로드 밸런싱 기능 제공 (더욱 유연한 트래픽 분산)
  • targer group에 있는 여러 HTTP 애플리케이션으로 로드 밸런싱
  • 동일 머신(예: 컨테이너)에서 실행되는 여러 애플리케이션으로 로드 밸런싱
  • 리다이렉트 지원 (예: HTTP에서 HTTPS로)
  • MSA나 컨테이너 기반 애플리케이션 (Docker, Amazon ECS)에 적합
  • CLB와 비교하여, ALB는 애플리케이션 당 하나의 로드 밸런스만 필요 (goood!) 
  • 포트 매핑 기능 : 로드밸런서로 들어오는 트래픽을 ECS 컨테이너에 지정된 동적 포트로 리다이렉션 -> 각 컨테이너에 고정포트 할당할 필요 없어짐.
• ALB의 트래픽 라우팅 방식
  • 1. URL 경로 기반 라우팅 (.com/users & .com/posts)
  • 2. URL 호스트 이름을 기반 라우팅 (one.example.com & other.example.com)
  • 3. 쿼리 스트링, 헤더 기반 라우팅 (example.com/users?id=123&order=false)
•  ALB가 가질 수 있는 Target Group
  • EC2 인스턴스 (ASG에서 관리될 수 있다.) - HTTP
  • ECS - HTTP
  • Lambda function - HTTP 요청은 JSON 이벤트로 변환
  • IP 주소 - 반드시 사설 IP여야 한다. 
  • -> ALB는 위와 같이 다양한 타겟 그룹을 가질 수 있으며, 헬스 체크는 타겟 그룹에서 수행된다.

URL 기반으로 라우팅

쿼리 스트링/파라미터 기반 라우팅

 

더 알아두기 

• ALB 도메인 이름은 고정적이다 (XXX.region.elb.amazonaws.com).
• 애플리케이션 서버는 클라이언트의 실제 IP를 직접 볼 수 없다.
  • 클라이언트의 실제 IP, 포트는 각각 X-Forwarded-For 헤더를 통해 알 수 있다. (-> 즉, ALB에서 X-Forwarded-For 헤더에 클라이언트 IP를 담아서 인스턴스에 전달)
• 그리고 클라이언트가 EC2 인스턴스에 직접 접근하는 것보다 ALB를 통해 접근하는 것을 권장한다. (-> 보안그룹을 통해 ALB에서 오는 트래픽이 아니면 타임아웃나도록 막아둘 수 있다. )
• ALB에 들어오는 트래픽을 특정한 조건을 정해서 특정한 액션을 취하도록 설정할 수 있다. 

 

 

 

 

3. Network Load Balancer (NLB)

• 출시 연도: 2017년 (새로운 세대)
• 지원 프로토콜: TCP, TLS (secure TCP), UDP
• 특징:
  • 고속, 저지연 네트워크 트래픽 처리에 최적화
  • 4계층(Transport layer) 로드 밸런싱만 제공
    • TCP 및 UDP 트래픽을 인스턴스로 전달
    • 초당 수백만 건의 요청 처리 가능 (-> 성능이 좋다!) 
    • ALB보다 낮은 지연 (ALB: 400ms vs NLB: 100ms)
  • NLB는 AZ당 하나의 정적 IP를 가지고 있으며, 탄력적 IP 할당도 가능하다. (특정 IP를 whitelist에 등록하기에 유용)
  • NLB는 극한의 성능, TCP 또는 UDP 트래픽에 사용
  • Free tier 제공x
• Target Group
  • EC2 인스턴스
  • IP 주소 (반드시 private IP)
  • ALB
  • -> health check : TCP, HTTP, HTTPS의 프로토콜을 사용하여 헬스체크를 한다. 

Target Group

 

 

4. Gateway Load Balancer (GLB)

• 출시 연도: 2020년
• 지원 프로토콜: 3계층(Network Layer) - IP 프로토콜
• 특징:
  
  • 3rd party 네트워크 가상 장치 (NVAs): 다양한 NVAs를 AWS에서 실행할 수 있다. 
    • NVA: 방화벽, 침입 감지 및 차단 시스템 (IDS/IPS), 심층 패킷 검사 (DPI), 페이로드 조작 등 다양한 기능을 제공하는 소프트웨어 기반 네트워크 보안 솔루션
  • 단일 진입/퇴출 지점: 게이트웨이 로드 밸런서는 네트워크 트래픽의 단일 진입/퇴출 지점으로 작동하여 네트워크 관리를 간소화한다. 모든 트래픽은 게이트웨이 로드 밸런서를 통과해야 한다.
  • 로드 밸런싱 : 트래픽을 여러 virtual appliances로 분산한다.
  • 게이트웨이 로드 밸런서는 GENEVE 프로토콜을 사용하여 포트 6081에서 작동
• Target Group
  • EC2 인스턴스
  • IP (반드시 private IP)

GLB: 이 그림을 이해하면 된다(고 했다).

 

target group

 

 

로드밸런서 보안 그룹 설정

보안그룹 예시

위의 그림을 보면 로드 밸런서는 모든 트래픽을 허용하고, EC2 인스턴스는 로드 밸런서를 통해 들어오는 트래픽만 허용한다. 이를 보안 그룹을 설정하여 구현할 수 있다. 

그림을 보면 로드 밸런서의 보안 그룹은 모든 트래픽을 허용하도록 되어 있고, EC2 인스턴스의 보안그룹은 LB의 보안그룹을 source로 두고 있다. 

 

 

Sticky Sessions (고정 세션)

• 로드 밸런서 뒤에서 동일한 클라이언트가 항상 같은 인스턴스로 리디렉션되도록 한다.
• CLB, ALB, NLB 에서 작동한다. (GLB에서는 x)
• CLB와 ALB의 경우, 쿠키의 만료 날짜 설정 가능
• sticky session을 사용할 경우, 백엔드 EC2 인스턴스 간의 부하 불균형을 초래할 수 있음.

클라이언트가 각각 같은 인스턴스로 리디렉션 된다.

위의 그림처럼, 고정 세션을 유지하기 위해서는 쿠키를 사용한다. 쉽게 말해서, 접속할 인스턴스에 대한 정보를 클라이언트의 쿠키에 담아서 세션을 유지하도록 하는 것이다. 쿠키도 종류를 나눌 수 있다. 

• Application-based Cookies
  • Custom cookie : 대상(서버)에서 생성하며, 애플리케이션에 필요한 속성을 포함
  • Application cookie : 로드 밸런서가 생성하며, 이름은 AWSALBAPP

 

• Duration-based Cookies
  • 로드 밸런서가 생성하며, 이름은 AWSALB, AWSELB

 

Cross-Zone Load Balancing

• 활성화 시: 각 로드 밸런서 인스턴스가 모든 AZ의 등록된 인스턴스에 균등하게 분배
• 비활성화 시: 요청이 해당 노드의 Elastic Load Balancer 인스턴스로만 분배
• AWS에서 제공하는 LB에서 이 기능을 사용할 수 있지만, 각각 비용이 드는지에 대한 내용이 다름.
  • ALB: 활성화(default), AZ간 데이터 이동에 비용 x 
  • NLB & GLB : 비활성화(default), AZ 간 데이터 이동에 비용 o (비용 드니까 비활성화가 default)
  • CLA: 비활성화(default), AZ간 데이터 이동에 비용 x 

Cross-Zone 활성화/비활성화

 

SSL/TLS

• SSL 인증서를 통해 클라이언트와 로드 밸런서 간 트래픽을 암호화한다.
• 공개 SSL 인증서는 인증 기관(CA)에서 발급
• 지금은 TLS를 대부분 사용하지만, 그냥 SSL이라고 부름
• SSL 인증서는 만료기간이 있기 때문에 주기적으로 갱신해야함. 

그렇다면 Load Balancer에서 SSL 인증서는 어떻게 쓰일까? 

• X.509 인증서 사용
• 인증서 관리 방법
  • AWS Certificate Manager(ACM)를 사용하여 인증서를 관리
  • 또는 자체적으로 인증서를 생성하여 업로드

 

• HTTPS 리스너 설정
  • 기본 인증서를 반드시 지정해야 한다.
  • 여러 도메인을 지원하기 위해 선택적으로 추가 인증서 목록을 추가할 수 있다.
• 클라이언트는 SNI(Server Name Indication)를 사용하여 접속하고자 하는 호스트명을 지정할 수 있다.
• 이전 버전의 SSL/TLS를 지원하기 위해 보안 정책을 지정할 수 있다. (-> 레거시 클라이언트를 위한 기능)

 

SSL/TLS

SSL - SNI (Server Name Indication)

• SNI는 하나의 웹 서버에 여러 SSL 인증서를 로드할 수 있게 한다.(->  SNI 통해 하나의 서버에서 여러 웹사이트를 서비스함 = 여러 IP 주소 사용하지 않고도 다수의 SSL 인증서를 관리할 수 있게 되었다. )
• 클라이언트가 초기 SSL 핸드셰이크 과정에서 대상 서버의 호스트명을 지정해야 한다.
  • 클라이언트가 지정한 호스트명을 바탕으로 서버는 올바른 인증서를 찾아 제공
  • 해당하는 인증서가 없으면 기본 인증서를 반환

• ALB, NLB, CloudFront에서 작동하지만 CLB에서는 작동 X

SNI 작동 원리

 

Connection Draining

• CLB에서는 Connection Draining, ALB와 NLB에서는 Deregistration Delay 라고 말한다.
• 인스턴스가 등록 취소 중이거나 비정상 상태일 때 "진행 중인 요청"을 완료하기 위한 시간을 제공 (-> 즉, 서버에서 진행 중인 작업을 안전하게 완료할 수 있도록 한다. )
• 등록 취소(de-register) 중인 EC2 인스턴스로 새로운 요청을 보내지 않도록 하되, 이미 처리 중인 요청은 완료될 때까지 기다린다.  
  • 등록 취소란 : 로드밸런서에서 EC2 인스턴스를 제거하는 것. 
• 기본 값은 5분이며, 1초 ~ 1시간 사이로 설정 가능. 값을 0으로 하면 기능 비활성화.
• ex) 사용자가 결제 중일 때, 해당 서버가 등록 취소될 경우, 결제 과정이 완료될 때까지 기다림으로써 사용자의 트랜잭션이 안전하게 완료되도록 한다. 

 

Auto Scaling Group(ASG)

웹사이트와 애플리케이션의 부하는 계속 바뀌고, 클라우드 환경에서는 서버를 쉽게 생성/제거할 수 있다. 클라우드를 사용하여 부하 변화에 대응하기 위해 ASG를 사용할 수 있다.

 

ASG의 목적은 아래와 같다.

• 증가하는 부하에 맞춰 scale out : EC2 인스턴스 추가
• 감소하는 부하에 맞춰 scale in : EC2 인스턴스 제거
• 최소,최대 EC2 인스턴스 수를 설정할 가능
• 새 인스턴스를 로드 밸런서에 자동으로 등록
• 이전 인스턴스가 종료된 경우, 새 EC2 인스턴스를 재생성

ASG는 무료로 사용할 수 있으며, 실제로 사용한 인스턴스에 대한 비용만 지불하면 된다. 

ASG, ELB

ASG Attributes 설정

• Launch Template에 속성들이 포함되어 있다.
  • AMI + 인스턴스 유형
  • EC2 User Data
  • EBS 볼륨
  • 보안 그룹
  • SSH 키 페어
  • EC2 인스턴스를 위한 IAM role
  • 네트워크 + 서브넷 정보
  • 로드 밸런서 정보
  • 최소 크기 / 최대 크기 / 초기 용량
  • Scaling 정책

Auto Scaling - CloudWatch  Alarms & Scaling

• CloudWatch alarms(경보)를 기반으로 ASG 조정
• alarms(경보)는 metric(지표)를 모니터링한다. (ex. 평균 CPU 사용률, 커스텀 metric)
• alarms 에 따라 확장 또는 축소 정책을 생성

CloudWatch에서 경보 발생 시 EC2 확장 or 축소

 

ASG - Scaling Policy

스케일링 정책은 크게 3가지로 나뉜다. 

 

1. Dynamic Scaling (동적 스케일링)
   1. Target Tracking Scaling
      • 설정 쉬움.
      • ex) ASG의 CPU 사용률 평균이 대략 40% 되도록 하자
   2. Simple / Step Scaling
      • 클라우드워치 경보가 울렸을 때 (CPU 사용률이 70% 이상) -> 2개 유닛 추가하자
      • 클라우드워치 경보가 울렸을 때 (CPU 사용률이 30% 이하) -> 1개 지우자
2. Scheduled Scaling (스케줄 스케일링)
   • 사용 패턴을 알고 있으면 스케줄에 맞춰서 스케일링 한다.
   • ex) 금요일 10-5시에 인스턴스를 더 늘린다.
3. Predictive scaling (예측 스케일링)
   • 사용량 미리 예측해서 스케일링한다. 

Predictive scaling (예측 스케일링)

 

스케일링할 때 좋은 metric들

• CPU 사용량
• 평균 네트워크 입출력
• 타겟당 request수
• 그 외에도 cloudwatch 사용해서 custom metric 만들 수 있다. 

Auto Scaling Groups - Scaling Cooldowns

스케일링을 하면 일정 기간의 cooldown (=휴지) 기간을 갖는다. (default : 300초)

이 기간동안은 인스턴스를 추가할수도, 종료할 수도 없다. 

 

cooldown을 갖는 이유는 아래와 같다.

• 새로운 인스턴스 안정화 위함
• 바뀐 이후에 metric 추적 하기 위함

cooldown 기간을 줄이고 싶으면 AMI를 미리 만들어둬서 인스턴스 구성 시간을 줄일 수도 있다. 

 

 

사용 예시)

https://yejin-code.tistory.com/52

 

AWS 서비스로 모니터링 환경 구축하기