고가용성과 확장성

ELB 요청 분산과 Auto Scaling 용량 조정, CloudFront 엣지 캐시로 이어지는 구성

고가용성과 확장성은 서로 연결되어 있지만 같은 문제는 아니다. 로드 밸런서는 요청을 분산하고, Auto Scaling은 용량을 조정하며, CloudFront는 사용자와 오리진 사이에서 콘텐츠를 캐시한다. 먼저 장애 대응 범위와 트래픽 변화 양상을 구분한 뒤 각 구성 요소를 맞춘다.

1. 확장 방식: 수직 vs 수평

구분	수직 확장 (Scale Up)	수평 확장 (Scale Out)
방법	인스턴스 크기를 키움	인스턴스 수를 늘림
한계	하드웨어 한계 존재	이론상 무제한
다운타임	재시작 필요	무중단 가능
SAP 선호	단기 임시 방편	장기 권장 설계

선택 근거: "무중단으로 확장해야 한다"는 조건 → 수평 확장 + Auto Scaling + ELB 조합이 정답이다.

2. ELB (Elastic Load Balancer)

ELB는 들어오는 트래픽을 여러 EC2에 분산하는 서비스다. AWS가 완전 관리하므로 로드 밸런서 자체의 고가용성은 신경 쓸 필요 없다.

3종류 비교

구분	ALB	NLB	GLB
계층	L7 (애플리케이션)	L4 (전송)	L3 (네트워크)
프로토콜	HTTP, HTTPS, WebSocket	TCP, UDP, TLS	IP
라우팅 기준	URL, 헤더, 쿼리 파라미터	IP + 포트	-
고정 IP	불가 (DNS만)	가능 (Elastic IP)	-
주요 용도	웹 앱, 마이크로서비스	게임, IoT, 금융 TCP	방화벽·IDS 트래픽 검사

ALB (Application Load Balancer)

가장 많이 쓰이는 로드 밸런서. URL 경로 기반 라우팅이 핵심 기능이다.

클라이언트 요청
  /api/*     → Target Group A (API 서버)
  /images/*  → Target Group B (이미지 서버)
  /admin/*   → Target Group C (관리 서버)

추가 기능:

호스트 기반 라우팅: api.example.com → 서버 A, www.example.com → 서버 B
헤더·쿼리 파라미터 기반 라우팅: A/B 테스트에 활용
고정 세션 (Sticky Session): 같은 사용자를 항상 같은 EC2로 연결
Lambda를 타겟으로 등록 가능

NLB (Network Load Balancer)

초저지연, 고성능이 필요할 때 사용. L4에서 동작하므로 HTTP 내용을 보지 않는다.

고정 IP 제공 (Elastic IP 연결 가능) — 방화벽 화이트리스트에 IP 등록해야 하는 경우 필수
초당 수백만 요청 처리 가능
TLS 종료 가능

선택 근거: "고객사 방화벽에 로드 밸런서 IP를 등록해야 한다" → ALB는 고정 IP 불가, NLB가 정답. "WebSocket, 실시간 게임 서버" → NLB.

GLB (Gateway Load Balancer)

트래픽을 방화벽·침입 탐지 시스템(IDS/IPS) 같은 보안 어플라이언스로 통과시킬 때 사용. SAP에서 "모든 트래픽을 보안 검사 후 전달해야 한다"는 요구사항에 등장한다.

Target Group (대상 그룹)

ELB가 트래픽을 보내는 대상의 묶음.

EC2 인스턴스
IP 주소 (온프레미스 서버 포함 가능)
Lambda 함수 (ALB만)
ALB (GLB에서 ALB로 연결 시)

헬스 체크: Target Group 내 각 대상의 상태를 주기적으로 확인. 비정상 대상에는 트래픽 전송 안 함.

3. Auto Scaling

수요에 따라 EC2 인스턴스 수를 자동으로 조절하는 서비스.

핵심 구성 요소

Launch Template: 인스턴스를 어떻게 만들지 정의 (AMI, 인스턴스 타입, 보안 그룹, User Data 등)

Auto Scaling Group (ASG): 인스턴스의 묶음. 최소·최대·원하는 수를 설정.

ASG 설정 예시:
  Min: 2   (항상 최소 2대 유지 — 고가용성)
  Desired: 4 (현재 원하는 수)
  Max: 10  (최대 10대까지 확장 가능)

스케일링 정책 종류

정책	동작 방식	언제 쓰나
Target Tracking	지표를 목표값으로 유지	CPU 60% 유지 등 단순 목표
Step Scaling	지표 범위별 단계적 조정	CPU 70~80%면 2대, 80~90%면 4대 추가
Scheduled	특정 시간에 수 변경	매일 오전 9시 10대로, 오후 6시 2대로
Predictive	ML로 미래 트래픽 예측 후 선제 확장	패턴이 규칙적인 워크로드

선택 근거:

"CPU 사용률 70% 유지" → Target Tracking (가장 단순, 권장)
"트래픽이 급격히 변동한다" → Step Scaling (단계별 대응)
"매주 월요일 오전 트래픽이 많다" → Scheduled + Predictive 병행

Cooldown Period (쿨다운)

스케일링 후 다음 스케일링 전 대기 시간. 기본 300초. 인스턴스가 뜨는 데 시간이 걸리므로, 과도한 스케일링을 방지한다.

스케일 인(감소) 방지: 특정 인스턴스를 스케일 인 대상에서 제외하는 Standby 또는 Instance Protection 설정 가능.

ASG + ELB 조합

사용자 요청
  → ELB (트래픽 분산)
    → ASG 내 EC2 인스턴스들
      (트래픽 증가 시 ASG가 자동으로 인스턴스 추가)
      (ELB가 새 인스턴스를 자동으로 Target Group에 등록)

ELB 헬스 체크 실패한 인스턴스 → ASG가 자동으로 교체.

4. CloudFront

CloudFront는 AWS의 CDN(Content Delivery Network) 서비스다. 전 세계 엣지 로케이션에서 콘텐츠를 캐싱해 지연 시간 최소화 + 오리진 서버 부하 감소를 동시에 달성한다.

동작 방식

사용자 (도쿄)
  ↓ 1. 가장 가까운 엣지 로케이션 요청
엣지 로케이션 (도쿄 PoP)
  ↓ 2. 캐시 있으면 바로 응답 (Cache Hit)
  ↓ 캐시 없으면 오리진으로 요청 (Cache Miss)
오리진 (서울 ALB 또는 S3)
  ↓ 3. 응답 + 엣지에 캐시 저장
사용자에게 전달

오리진 종류

S3 버킷 (정적 파일 배포에 최적)
ALB / EC2 (동적 콘텐츠)
API Gateway
모든 HTTP 서버 (온프레미스 포함)

캐시 제어

TTL (Time To Live): 엣지에서 콘텐츠를 얼마나 보관할지.

오리진의 Cache-Control 헤더로 제어
CloudFront에서 최소·최대·기본 TTL 직접 설정 가능

캐시 무효화 (Invalidation):

오리진의 파일이 바뀌었을 때 엣지 캐시를 강제로 지우는 작업
경로 패턴으로 지정 가능 (/images/*)
비용 발생 (월 1,000건 무료)

캐시 키: 기본은 URL. 헤더·쿠키·쿼리 파라미터를 캐시 키에 추가하면 더 세밀한 캐싱 가능 (하지만 캐시 히트율 감소).

CloudFront + S3 조합 (SAP 단골)

S3 버킷을 직접 공개하지 않고 CloudFront를 통해서만 접근하도록 설정.

사용자 → CloudFront → S3 (비공개 버킷)
                       ↑
               OAC (Origin Access Control)로만 접근 허용
               S3 버킷 정책: CloudFront만 GetObject 허용

선택 근거: "S3의 파일을 전 세계에 빠르게 배포하되 S3 URL을 직접 노출하고 싶지 않다" → CloudFront + OAC 조합.

Lambda@Edge / CloudFront Functions

엣지 로케이션에서 코드를 실행해 요청/응답을 가공하는 기능.

구분	CloudFront Functions	Lambda@Edge
실행 위치	엣지 (200개 이상)	리전 엣지 (13개)
언어	JavaScript만	Node.js, Python
실행 시간	1ms 이하	최대 30초
메모리	2MB	최대 10GB
용도	URL 리다이렉트, 헤더 조작	인증, 이미지 변환, A/B 테스트

선택 근거: "CloudFront 엣지에서 사용자 인증을 처리해야 한다" → Lambda@Edge. "단순 URL 리라이트, 헤더 추가" → CloudFront Functions (더 빠르고 저렴).

CloudFront 보안

WAF 연동: CloudFront 앞에 AWS WAF를 붙여 SQL Injection, XSS 등 차단.

Geo Restriction: 특정 국가에서의 접근 차단 또는 허용.

Signed URL / Signed Cookie: 특정 사용자만 콘텐츠에 접근하도록 제한 (유료 콘텐츠, 프리미엄 서비스).

5. 전형적인 고가용성 아키텍처

SAP 시험에서 "다음 요구사항을 만족하는 아키텍처를 설계하라"는 문제의 정답 구조다.

전 세계 사용자
      ↓
  Route 53 (DNS, 헬스 체크·장애 조치)
      ↓
  CloudFront (정적 캐싱, 엣지 배포)
      ↓
  ALB (Multi-AZ, 트래픽 분산)
      ↓
  Auto Scaling Group
  ├── EC2 (AZ-a, 프라이빗 서브넷)
  └── EC2 (AZ-b, 프라이빗 서브넷)
      ↓
  RDS Multi-AZ (AZ-a Primary, AZ-b Standby)

각 계층이 Multi-AZ로 구성되어 어느 AZ가 죽어도 서비스가 유지된다.

6. SAP 시험 출제 유형

유형 1 — 로드 밸런서 선택

"보안 팀이 로드 밸런서의 IP를 방화벽에 등록해야 한다. 어떤 로드 밸런서를 써야 하는가?"

→ NLB (Elastic IP로 고정 IP 제공. ALB는 DNS만 제공, IP 변동)

유형 2 — 스케일링 정책 선택

"쇼핑몰이 매년 블랙프라이데이에 트래픽이 10배 급증한다. 평소에는 2대면 충분하다."

→ Scheduled Scaling (날짜·시간 예측 가능) + Target Tracking (평시 자동 조절) 병행

유형 3 — 글로벌 배포

"정적 웹사이트를 전 세계 사용자에게 빠르게 제공해야 한다. 비용도 최소화한다."

→ S3 정적 웹 호스팅 + CloudFront (서버 없음, 글로벌 엣지 캐싱, 저비용)

유형 4 — 오리진 보호

"EC2 앱 서버에 DDoS 공격이 우려된다. CloudFront 경유 트래픽만 허용하고 싶다."

→ CloudFront → ALB 구성 + ALB 보안 그룹에 CloudFront 관리형 접두사 목록만 허용

7. 요구사항을 서비스 조합으로 바꾸는 순서

고가용성과 확장성 문제는 서비스 이름을 먼저 떠올리기보다 요구사항을 수치로 바꾸는 것이 출발점이다.

요구사항	확인할 지표	기본 설계 방향
장애 중에도 요청을 처리해야 함	RTO, RPO, 허용 오류율	여러 AZ의 대상 + ELB 헬스 체크
트래픽이 예측 가능하게 증가함	시간대·요일별 요청량	Scheduled 또는 Predictive Scaling
트래픽이 갑자기 변함	요청 수, 지연 시간, CPU	Target Tracking + Step Scaling
정적 응답이 많고 사용자가 전 세계에 있음	Cache Hit Ratio, 오리진 지연	CloudFront 캐시 정책과 적절한 TTL
오리진을 직접 노출하면 안 됨	오리진 접근 경로	CloudFront OAC·보안 그룹·WAF 조합

상태를 어디에 둘 것인가

ASG의 인스턴스는 교체될 수 있으므로 세션·업로드 파일·작업 큐를 로컬 디스크나 메모리에만 두면 스케일 아웃 후 사용자가 다른 인스턴스로 이동할 때 문제가 생긴다. 세션은 ElastiCache 또는 애플리케이션의 무상태 토큰 방식으로, 파일은 S3 또는 EFS로 분리하는 식으로 컴퓨팅 계층을 교체 가능하게 만들어야 한다.

캐시를 길게 잡을수록 비용과 지연은 줄지만 변경 사항 반영이 늦어진다. HTML·API·버전이 붙은 정적 파일을 같은 캐시 정책으로 묶지 말고, 콘텐츠 변경 주기와 무효화 비용을 기준으로 TTL을 나눈다.

8. 공식 문서로 다시 확인하기

Elastic Load Balancing 개요 — 대상 헬스 체크와 다중 AZ 분산
EC2 Auto Scaling 동적 스케일링 — Target Tracking·Step Scaling
CloudFront 캐시 동작 — 엣지 캐시·오리진 요청 흐름

이 시리즈에서 이어 읽기

03. VPC와 3-Tier 네트워크 — ALB·앱 서버·데이터 계층의 배치
04. EC2와 스토리지 — ASG에서 사용할 컴퓨팅·파일·객체 저장소
06. 데이터베이스 선택 — Multi-AZ와 읽기 확장 대상 선택

정리

개념	핵심 한 줄
ALB	L7, URL·헤더 기반 라우팅, 웹 앱의 표준 선택
NLB	L4, 고정 IP, 초저지연, 방화벽 IP 등록 필요 시
GLB	보안 어플라이언스 트래픽 검사용
Target Tracking	CPU·요청 수 목표값 유지, 가장 단순한 정책
Step Scaling	지표 범위별 단계적 대응, 급격한 변동에 적합
Scheduled	시간 예측 가능한 트래픽에 선제 확장
CloudFront + S3	정적 파일 글로벌 배포, OAC로 S3 직접 노출 차단
Lambda@Edge	엣지에서 인증·이미지 변환 등 복잡한 로직 처리
CloudFront Functions	엣지에서 단순 URL 조작·헤더 변경

RDS·Aurora·DynamoDB·ElastiCache·Redshift를 비교하고, SAP에서 자주 출제되는 "어떤 DB를 선택해야 하는가" 시나리오를 집중 정리한다.