[AWS-SAA] 05. High Availability & Scalability 요약

1강. Scalability & High Availability 개요

• Vertical Scaling (Scale Up / Scale Down) : 개별 서버의 성능을 향상 시키는 것
  • 예시) EC2 인스턴스 성능 향상
• Horizontal Scaling (Scale Out / Scale In) : 서버의 수를 늘리는 것
  • 예시) Auto Scaling Group, Load Balancer
• High Availability : 장애 대비 서버가 끊김 없이 가용될 수 있도록 하는 것
  • 즉, 인스턴스들이 동일한 애플리케이션을 여러 개의 AZ에서 동작 시키고 있는 것
  • 예시) Auto Scaling Group multi AZ, Load Balancer multi AZ

 

2강. Elastic Load Balancer (ELB) 개요

• 로드 밸런서(Load Balancer) : 여러 개의 서버로 트래픽을 분산해 주는 시스템
• 기능
  • 다수의 인스턴스로 트래픽 분산
  • 하나의 DNS 접근 지점으로 사용자들이 접근 가능
  • 유연한 인스턴스 장애 조치
  • 인스턴스들에 대한 상태 확인(Health Check)
  • HTTPS 보안 제공
  • 고가용성 제공
  • 쿠키를 활용해 세션 지속성 보장 가능
    • 클라이언트의 요청을 활용해 쿠키를 생성 후 특정 서버와 통신하도록 세션 고정
  • Public 트래픽 및 Private 트래픽 분리
• 왜 ELB를 사용해야 하는가?
  • ELB는 AWS에서 관리하는 로드 밸런서이다.
    • AWS가 중단되지 않도록 관리해 주며 업그레이드, 고가용성 등을 제공한다.
  • 더 이상 자체 구축하지 않으므로 로드밸런서의 확장성을 고려할 필요가 없다.
  • 다른 AWS 서비스와 쉽게 통합이 가능하다.
• Health Check(상태 확인) 기능
  • 로드 밸런서는 HTTP 프로토콜을 사용해 인스턴스의 상태를 확인한다.
    • 200 응답이 오지 않으면 문제가 발생했다고 판단하고, 더 이상 트래픽을 해당 인스턴스로 전달하지 않는다.
• AWS의 LB 종류는 크게 4가지로 구분할 수 있다.
  • Classic Load Balancer (v1 - old generation) – 2009 – CLB (Deprecated)
    • HTTP, HTTPS, TCP, SSL (secure TCP)
  • Application Load Balancer (v2 - new generation) – 2016 – ALB
    • HTTP, HTTPS, WebSocket
  • Network Load Balancer (v2 - new generation) – 2017 – NLB
    • TCP, TLS (secure TCP), UDP
  • Gateway Load Balancer – 2020 – GWLB
    • Operates at layer 3 (Network layer) – IP Protocol
  • 가급적이면 CLB는 사용하지 않는 것을 권장한다.
• 로드 밸런서는 필요에 따라 내부 트래픽을 분산하는 데 사용할 수도 있고, 외부 트래픽을 내부로 분산해 줄 때도 사용할 수 있다.
• Security Group 에서 IP 범위가 아니라 로드 밸런서를 통해 유입되는 트래픽만 허용되도록 규칙을 구성할 수 있다.

 

3강. Application Load Balancer (ALB) 개요 - 5강. Application Load Balancer (ALB) 실습 (2)

• ALB는 HTTP 로드 밸런서로 트래픽을 타겟 그룹에 분산한다.
• 라우팅 기능을 통해 타겟 그룹에 트래픽을 분산한다.
  • 라우팅 기능은 Listener Rule 설정을 통해 구현할 수 있다.
  • 호스트 기반 → users.example.com
  • 경로 기반 → users.example.com/users
  • Query String 혹은 Header 기반 → users.example.com/users?id=123&order=false
• ALB는 마이크로 서비스나 컨테이너 기반 앱에 유리하다.
• 사용할 수 있는 타겟 그룹(Target Group)의 유형은 아래와 같다.
  • EC2 인스턴스 (주로 Auto Scaling Group를 활용해 사용한다.)
  • ECS (ECS 서비스를 통해 관리한다.)
  • 람다 함수
  • IP 주소 (사설 IP만 사용할 수 있다.)
• ELB는 여러 타겟 그룹으로 라우팅 할 수 있으며, 상태 확인은 타겟 그룹 레벨에서 수행된다.
• 타겟 그룹의 요소들이 로드밸런서를 통해 전달된 클라이언트의 IP를 확인하기 위해서는 HTTP 추가 헤더를 확인해야 한다.
  • X-Forwarded-For : 클라이언트의 IP를 확인할 수 있다.
  • X-Forwarded-Port / X-Forwarded-Proto : 클라이언트의 Protocol를 확인할 수 있다.

 

6강. Network Load Balancer 개요 - 7강. Network Load Balancer 실습

• NLB는 TCP/UDP 트래픽을 인스턴스로 분산한다.
• 매우 낮은 레이턴시를 제공하므로 고용량 트래픽 설계에 대응하기 좋다.
  • TCP, UDP 트래픽에 대해 성능 극대화 하기 좋다.
• NLB는 AZ당 하나의 정적 IP를 제공한다.
  • 필요에 따라 Elastic IP 할당할 수 있다.
• 사용할 수 있는 타겟 그룹(Target Group)의 유형은 아래와 같다.
  • EC2 인스턴스 (주로 Auto Scaling Group를 활용해 사용한다.)
  • ALB
    • NLB를 통해 정적 IP로 트래픽을 분산할 수 있고, ALB를 통해 HTTP에 대한 상세한 설정(쿠키 활용, 라우팅 기능 등)이 가능하다는 장점이 있다.
  • IP 주소 (사설 IP만 사용할 수 있다.)
• TCP, HTTP, HTTPS 프로토콜을 통한 상태 확인 기능을 지원한다.

 

8강. Gateway Load Balancer (GWLB 개요)

• GWLB는 네트워크 계층에서 IP 패킷 기반으로 동작한다.
• Best Practice : Third-Party 보안 장비들과 함께 사용된다.
  1. 사용자의 트래픽을 GWLB가 라우팅 테이블을 조작해 Third-Party의 보안 솔루션으로 전달한다.
  2. Third-Party의 보안 솔루션(IDS, IPS, FW, WAF 등)은 네트워크 계층의 트래픽을 분석하고 문제가 있는 경우 패킷을 드랍한다.
  3. 문제가 없는 경우 Third-Party 장비들이 GWLB에게 트래픽을 반환한다.
  4. GWLB는 이 트래픽을 애플리케이션 단에 전달한다.
• 사용할 수 있는 타겟 그룹(Target Group)의 유형은 아래와 같다.
  • EC2 인스턴스
  • IP 주소 (사설 IP만 사용할 수 있다.)
• 기능
  • Transparent Network Gateway : 모든 트래픽에 대해 단일 출입구 지점을 제공한다.
  • Load Balancer : 필요에 따라 다른 Third-Party(Virtual Appliances 등)에게 트래픽을 분산한다.
• GWLB는 GENEVE UDP 6081번 포트를 사용해 구현돼 있다.

 

9강. ELB - Sticky Session

• Sticky Session(세션 지속성, Session Affinity)은 특정 클라이언트의 요청을 항상 같은 백엔드 서버로 전달하는 로드 밸런서 기능이다.
  • ALB, CLB 에서만 지원하는 기능이다.
• Sticky Session을 사용하면 특정 서버에 트래픽이 집중될 수 있어 Auto Scaling이나 세션 저장소를 고려하는 대책을 마련해야 한다.
• 원리는 다음과 같다.
  • Application-Based Cookies
    • 특정 서버에 대한 지속적인 연결이 필요할 때 사용한다.
    1. Custom Cookie
       • 백엔드 서버에서 생성하고 로드 밸런서는 이 쿠키를 기반으로 세션을 유지한다.
       • 각 Target Group마다 개별적으로 쿠키 이름을 지정해야 한다.
       • 커스텀 속성을 만들 수 있다. (예: 사용자 ID, 세션 데이터 등)
       • AWS 예약 쿠키 이름(AWSALB, AWSALBAPP, AWSALBTG) 사용 금지
    2. Application Cookie
       • ALB가 자동으로 생성하는 쿠키이다.
       • 쿠키 이름은 AWSALBAPP (자동 설정됨)
       • 백엔드 서버가 아닌, 로드 밸런서가 직접 관리하는 방식
  • Duration-based Cookies (기간 기반 쿠키)
    • 로그인 상태를 유지하거나 세션이 일정 시간 동안만 지속되도록 설정할 때 사용한다.
    • 로드 밸런서가 직접 생성하는 쿠키 (클라이언트 요청 시 자동 부여)
    • 특정 TTL(유효 시간)이 지나면 세션 지속성 해제
    • ALB의 경우 AWSALB, CLB의 경우 AWSELB 쿠키를 사용

 

10강. ELB - Cross Zone Load Balancing

• Cross-Zone Load Balancing은 AWS 로드 밸런서가 여러 가용 영역(AZ)에 있는 백엔드 인스턴스 간에 트래픽을 균등하게 분배하는 기능이다.
• 일반적으로 로드 밸런서는 각 AZ로 균등하게 트래픽을 분할한다.
  • 따라서 한 쪽 AZ에 백엔드 인스턴스가 몰려있는 경우 트래픽이 균등하게 처리되지 않을 수 있다.
• ALB 에서는 항상 활성화 되어있으며, NLB, CLB, GWLB 에서는 별도로 활성화를 진행해야 한다.
  • ALB, CLB는 무료이고 NLB, GWLB는 유료 서비스이다.
  • 다만 ALB의 경우, Target Group의 속성(Attributes)에서 별도로 Cross Zone Load Balancing 를 끌 수 있다.

 

11강. ELB - SSL 인증서 - 12강. ELB - SSL 인증서 실습

• SSL 및 TLS 개요
  • SSL(Secure Sockets Layer): 데이터를 암호화하여 보안된 통신을 제공하는 프로토콜
  • TLS(Transport Layer Security): SSL의 최신 버전 (실제 사용은 TLS이지만, 여전히 "SSL"이라고도 불림)
  • SSL/TLS 인증서: 클라이언트와 로드 밸런서 간 전송 중 데이터(Transit Data)를 암호화
  • 공개 SSL 인증서(Public SSL Certificate): CA(Certificate Authority)에서 발급
    • 주요 CA: Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Let's Encrypt 등
  • 인증서 만료일 존재 → 만료 전에 갱신 필요
• 로드 밸런서와 SSL 인증서 관리
  • X.509 인증서(SSL/TLS 서버 인증서)를 사용
  • AWS Certificate Manager(ACM)에서 관리 가능
  • 자체 인증서(Third-party 인증서) 업로드 가능
  • 사용자의 요청은 로드밸런서가 HTTPS로 처리하고 내부는 Private VPC를 활용해 HTTP로 통신함
• HTTPS 리스너(Listener) 설정
  • 기본적으로 하나의 SSL 인증서를 지정해야 함
  • 다중 도메인 지원 가능 (추가 인증서 등록 가능)
  • SNI(Server Name Indication) 지원 → 여러 도메인을 하나의 로드 밸런서에서 처리 가능
  • 보안 정책(Security Policy) 설정 가능 → 이전 버전의 SSL/TLS 지원 여부 선택 가능
• SNI(Server Name Indication) 개념
  • 하나의 서버(로드 밸런서)에서 여러 개의 SSL 인증서를 사용할 수 있도록 하는 기술
  • 클라이언트가 SSL/TLS 핸드셰이크 시 접속하려는 호스트명(도메인명)을 서버에 전달
  • 서버는 해당 도메인에 맞는 올바른 SSL 인증서를 제공
  • 사용 가능한 서비스 : ALB, NLB, CloudFront
  • 사용 불가능한 서비스: CLB
• Load Balancer 유형
  • CLB: 하나의 SSL 인증서만 지원 → 다중 도메인 운영하려면 여러 CLB 필요
  • ALB & NLB: 여러 개의 SSL 인증서를 사용 가능 → SNI를 사용하여 여러 도메인을 처리 가능

    로드 밸런서 유형	SSL 인증서 지원 방식	다중 도메인 지원	SNI 지원
    CLB	하나의 SSL 인증서만 사용 가능	불가능 (여러 CLB 필요)	미지원
    ALB	여러 SSL 인증서 사용 가능	가능	지원
    NLB	여러 SSL 인증서 사용 가능	가능	지원

• Best Practice : HTTPS를 사용하는 애플리케이션에서는 ALB 또는 NLB를 통해 SNI 기능으로 다중 SSL 인증서를 관리하는 방식

 

13강. ELB - Connection Draining

• Connection Draining (연결 종료 관리) : 로드 밸런서에서 EC2 인스턴스를 제거(Deregister)할 때, 진행 중인 요청을 마무리할 시간을 주는 기능
  • 인스턴스를 즉시 종료하지 않고, 기존 요청을 완료한 후 연결을 끊음
  • 새로운 요청은 더 이상 해당 인스턴스로 보내지지 않음
• ALB과 NLB 에서는 Deregistration Delay 라는 용어를 사용함
• 동작 방식
  1. EC2 인스턴스가 등록 해제(Deregister)되거나 비정상 상태(Unhealthy)로 감지되면 더 이상 로드 밸런서는 새로운 요청을 해당 인스턴스로 보내지 않음
  2. 현재 처리 중인 요청이 설정된 시간 내에 완료되도록 대기
     • 최소 1초 ~ 최대 3600초(1시간) 까지 설정 가능, 기본값(5분)
     • 비활성화 가능 (값을 0으로 설정하면 즉시 연결 해제)
     • 요청 시간이 짧은 애플리케이션이라면 낮은 값으로 설정하는 것이 좋음.
  3. 설정된 시간이 지나거나 요청이 모두 완료되면 정상적으로 연결 해제
• Connection Draining은 EC2 인스턴스 제거로 인해 데이터 요청이 유실되지 않도록 하는 기능이다.
  • 예시) EC2 인스턴스가 배포(Deploy) 또는 Auto Scaling으로 종료될 때, 긴 요청 처리(파일 업로드, DB 트랜잭션 등)를 수행하는 애플리케이션

 

14강. Auto Scaling Group (ASG) 개요 - 17강. Auto Scaling Group (ASG) 스케일링 정책 실습

• ASG는 웹사이트 및 애플리케이션의 부하에 따라 자동으로 EC2 인스턴스를 추가/제거하는 기술이다.
• 주요 기능
  • Scale Out: 부하 증가 시 EC2 인스턴스 추가.
  • Scale In: 부하 감소 시 EC2 인스턴스 제거.
  • 최소/최대 EC2 인스턴스 개수 유지.
  • 신규 인스턴스를 로드 밸런서에 자동 등록.
  • 비정상 인스턴스 종료 시 자동 복구.
    • ELB의 Health Check를 활용해 비정상 인스턴스 확인 가능
• 비용: ASG 자체는 무료, EC2 인스턴스 사용량에 대한 비용만 지불.
• 속성
  • Launch Template (Launch Configuration is Deprecated).
  • 구성 요소 (EC2 인스턴스 생성 시 만들어야 하는 것들이 포함되어 있는 것임.)
    • AMI + 인스턴스 타입
    • EC2 User Data
    • EBS 볼륨
    • 보안 그룹
    • SSH 키 페어
    • IAM 역할
    • 네트워크 및 서브넷 정보
    • 로드 밸런서 정보
    • 최소/최대/초기 용량 설정
    • 스케일링 정책
• CloudWatch 알람을 기반으로 ASG 스케일링이 가능하다.
  • 동작 원리
    1. 특정 메트릭(예: 평균 CPU 사용률) 모니터링.
    2. 알람 트리거 시, Scale Out (증가) 또는 Scale In (감소) 정책 실행.
• Auto Scaling Group 스케일링 정책은 크게 3가지로 구분할 수 있다.
  1. Dynamic Scaling (동적 스케일링)
     • Target Tracking Scaling: 특정 지표 목표 유지 (예: 평균 CPU 40%).
     • Simple / Step Scaling:
       • 예: CPU > 70% → 2개 인스턴스 추가.
       • 예: CPU < 30% → 1개 인스턴스 제거.
  2. Scheduled Scaling (예약 스케일링)
     • 예상되는 사용 패턴을 기반으로 스케일링 예약.
     • 예: 매주 금요일 오후 5시에 최소 인스턴스 개수를 10으로 증가.
  3. Predictive Scaling (예측 스케일링)
     • AI/ML을 활용해 부하를 예측하고 사전에 스케일링 수행.
• 스케일링 지표(Metric) 종류
  • CPUUtilization(평균 CPU 사용률), RequestCountPerTarget(EC2 인스턴스당 요청 수), Network In/Out(네트워크 부하 기반), 사용자 정의
• Scaling Cooldowns (쿨다운)
  • 스케일링 후 일정 시간(기본 300초) 동안 추가 스케일링 방지.
  • 쿨다운 동안 메트릭이 안정화되도록 대기.
  • 최적화 팁: 사전 구성된 AMI 사용 → 인스턴스 부팅 및 구성 시간 단축.
• 요약
  • ASG는 트래픽 변화나 인스턴스 상태에 따라 EC2 인스턴스를 자동으로 조정하는 AWS 서비스
  • CloudWatch 알람을 기반으로 스케일링 정책(동적, 예약, 예측)을 설정해야 함
    • 효율적인 리소스 운영을 위해 CPU 사용률, 네트워크 트래픽, 사용자 정의 메트릭을 활용 가능
  • 쿨다운 시간을 최적화하여 빠른 응답성과 비용 절감을 달성하는 것이 중요함.
    • 사전 구성된 AMI 사용을 통한 인스턴스 부팅 및 구성 시간 단축.