1. 개발자의 AWS 고민
일반적인 3-Tier 웹 앱 아키텍처
┌─────────────────────────────────────────────────────────────┐
│ Route 53 │
└──────────────────────────────┬──────────────────────────────┘
│
┌──────────────────────────────▼──────────────────────────────┐
│ PUBLIC SUBNET │
│ ELB │
└──────────────────────────────┬──────────────────────────────┘
│
┌──────────────────────────────▼──────────────────────────────┐
│ PRIVATE SUBNET │
│ Auto Scaling Group (Multi-AZ) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ EC2 │ │ EC2 │ │ EC2 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
└──────────────────────────────┬──────────────────────────────┘
│
┌──────────────────────────────▼──────────────────────────────┐
│ DATA SUBNET │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Amazon RDS │ │ ElastiCache │ │
│ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘쉽게 이해하기: 서브넷(Subnet)이란?
서브넷 = VPC 안에서 네트워크를 나눈 작은 구역
VPC가 회사 건물 전체라면, 서브넷은 건물 안의 **각 층(구역)**입니다.
서브넷 비유 설명 Public Subnet 1층 로비 외부 손님(인터넷)이 들어올 수 있는 공간 Private Subnet 사무실 층 직원(내부 서버)만 있는 공간, 외부 직접 접근 불가 Data Subnet 금고/서버실 가장 중요한 데이터 보관, 철저히 보호 왜 나누는가?
- 보안: 외부에서 DB에 직접 접근 못하게
- 관리: 역할별로 네트워크 규칙 분리
개발자의 고민
| 고민 | 설명 |
|---|---|
| 인프라 관리 | EC2, VPC, 보안 그룹 등 |
| 코드 배포 | 배포 프로세스 구성 |
| 설정 | DB, 로드밸런서 등 구성 |
| 스케일링 | Auto Scaling 설정 |
💡 대부분의 웹 앱은 같은 아키텍처 (ALB + ASG)
개발자가 원하는 건 코드만 실행되는 것!
2. Elastic Beanstalk 개요
Elastic Beanstalk이란?
- 개발자 중심의 애플리케이션 배포 서비스
- EC2, ASG, ELB, RDS 등 기존 AWS 서비스를 활용
- 관리형 서비스
자동 관리 항목
- 용량 프로비저닝
- 로드 밸런싱
- 스케일링
- 애플리케이션 헬스 모니터링
- 인스턴스 구성
개발자 책임
- 애플리케이션 코드만!
비용
- Beanstalk 자체는 무료
- 사용하는 AWS 리소스(EC2, RDS 등)에 대해서만 과금
3. Elastic Beanstalk 구성 요소
핵심 개념
| 구성 요소 | 설명 |
|---|---|
| Application | Beanstalk 구성 요소 모음 (환경, 버전, 설정) |
| Application Version | 애플리케이션 코드의 버전 |
| Environment | AWS 리소스 모음 (한 번에 하나의 버전만 실행) |
워크플로우
Create Application → Upload Version → Launch Environment → Manage Environment
↑ │
│ │
└── deploy new version ──┘Environment Tier
| Tier | 용도 | 구성 |
|---|---|---|
| Web Server Tier | HTTP 요청 처리 | ELB + EC2 (Auto Scaling) |
| Worker Tier | 백그라운드 작업 처리 | SQS + EC2 (Auto Scaling) |
Web Server vs Worker Tier
┌─── Web Server Tier ───┐ ┌─── Worker Tier ───┐
│ │ │ │
│ ELB → EC2 (ASG) │ │ SQS → EC2 (ASG) │
│ │ │ │
│ HTTP 요청 처리 │ │ 메시지 처리 │
│ │ → │ │
│ URL 엔드포인트 제공 │ Push │ SQS 메시지 기반 │
│ │ to │ 스케일링 │
│ │ SQS │ │
└───────────────────────┘ └────────────────────┘4. 지원 플랫폼
언어/프레임워크
| 카테고리 | 지원 플랫폼 |
|---|---|
| Languages | Go, Java SE, Java with Tomcat, Node.js, PHP, Python, Ruby |
| .NET | .NET Core on Linux, .NET on Windows Server |
| Docker | Single Container, Multi-container, Preconfigured |
| 기타 | Packer Builder |
5. Deployment Modes (배포 모드)
Single Instance vs High Availability
| 모드 | 구성 | 용도 |
|---|---|---|
| Single Instance | EC2 1개 + Elastic IP + RDS | 개발 환경 |
| High Availability | ALB + ASG (Multi-AZ) + RDS (Multi-AZ) | 프로덕션 |
┌─── Single Instance ───┐ ┌─── High Availability ───┐
│ │ │ │
│ ┌───────────┐ │ │ ALB │
│ │ Elastic IP│ │ │ │ │
│ └─────┬─────┘ │ │ ┌─────┴─────┐ │
│ │ │ │ │ │ │
│ ┌─────▼─────┐ │ │ ┌──▼──┐ ┌──▼──┐ │
│ │ EC2 │ │ │ │ EC2 │ │ EC2 │ │
│ └─────┬─────┘ │ │ │(AZ1)│ │(AZ2)│ │
│ │ │ │ └─────┘ └─────┘ │
│ ┌─────▼─────┐ │ │ ASG │
│ │ RDS Master│ │ │ ┌─────┴─────┐ │
│ └───────────┘ │ │ │ │ │
│ │ │ ┌──▼──┐ ┌──▼──┐ │
│ AZ 1 │ │ │ RDS │ │ RDS │ │
│ │ │ │Master│ │Standby│ │
└───────────────────────┘ └──────────────────────────┘6. Deployment Options (배포 옵션)
배포 방식 비교
| 방식 | 다운타임 | 속도 | 비용 | 용도 |
|---|---|---|---|---|
| All at once | ✅ 있음 | 가장 빠름 | 없음 | 개발 |
| Rolling | ❌ 없음 | 느림 | 없음 | - |
| Rolling with additional batches | ❌ 없음 | 느림 | 약간 | 프로덕션 |
| Immutable | ❌ 없음 | 가장 느림 | 높음 (2배) | 프로덕션 |
| Blue/Green | ❌ 없음 | 느림 | 높음 | 프로덕션 |
| Traffic Splitting | ❌ 없음 | 느림 | 높음 | 카나리 테스트 |
6.1 All at once
Before: [v1] [v1] [v1] [v1]
↓ 모두 동시에 배포
After: [v2] [v2] [v2] [v2]| 특징 | 설명 |
|---|---|
| 속도 | 가장 빠름 |
| 다운타임 | 있음 ⚠️ |
| 비용 | 추가 비용 없음 |
| 용도 | 개발 환경 |
6.2 Rolling
Step 1: [v1] [v1] [v2] [v2] ← Bucket 1 배포
↓
Step 2: [v2] [v2] [v2] [v2] ← Bucket 2 배포| 특징 | 설명 |
|---|---|
| 용량 | 배포 중 감소 |
| 버전 공존 | v1, v2 동시 실행 |
| 비용 | 추가 비용 없음 |
| 속도 | 느림 |
| Bucket 크기 | 설정 가능 |
6.3 Rolling with additional batches
Step 1: [v1] [v1] [v1] [v1] + [v2] [v2] (new) ← 추가 인스턴스 생성
↓
Step 2: [v2] [v2] [v1] [v1] + [v2] [v2] ← Bucket 1 교체
↓
Step 3: [v2] [v2] [v2] [v2] ← 완료, 추가분 제거| 특징 | 설명 |
|---|---|
| 용량 | 유지됨 |
| 버전 공존 | v1, v2 동시 실행 |
| 비용 | 약간 추가 (추가 인스턴스) |
| 용도 | 프로덕션 권장 |
6.4 Immutable
Step 1: Current ASG [v1] [v1] [v1] [v1]
Temp ASG [v2] [v2] ← 새 ASG에 배포
↓
Step 2: Current ASG [v1] [v1] [v1] [v1] [v2] [v2] ← Temp ASG 병합
↓
Step 3: Current ASG [v2] [v2] [v2] [v2] ← v1 종료| 특징 | 설명 |
|---|---|
| 다운타임 | 없음 |
| 비용 | 높음 (용량 2배) |
| 속도 | 가장 느림 |
| 롤백 | 빠름 (새 ASG 종료만 하면 됨) |
| 용도 | 프로덕션 권장 |
6.5 Blue/Green
┌─────────────────────────────────────────────┐
│ Route 53 │
│ (Weighted Policy) │
│ 90% 10% │
└───────────────────┬──────────┬──────────────┘
│ │
┌──────────▼──┐ ┌────▼──────────┐
│ Environment │ │ Environment │
│ "Blue" │ │ "Green" │
│ [v1][v1] │ │ [v2][v2] │
└─────────────┘ └───────────────┘
↑
테스트 완료 후
"Swap URLs" 실행| 특징 | 설명 |
|---|---|
| Beanstalk 기능 | 직접 기능 아님 (수동 구성) |
| 다운타임 | 없음 |
| 검증 | 새 환경 독립적 검증 가능 |
| 전환 | Route 53 가중치 또는 URL Swap |
| 롤백 | 쉬움 (URL 다시 Swap) |
6.6 Traffic Splitting (Canary)
ALB
90% 10%
│ │
┌──────────▼──┐ │
│ Main ASG │ │
│ [v1][v1] │ │
└─────────────┘ │
┌────▼────────┐
│ Temp ASG │
│ [v2][v2] │
└─────────────┘
↓
헬스 체크 후
인스턴스 마이그레이션| 특징 | 설명 |
|---|---|
| 목적 | 카나리 테스트 |
| 트래픽 | 일부(%)만 새 버전으로 |
| 모니터링 | 배포 헬스 모니터링 |
| 롤백 | 자동 (실패 시) |
| 다운타임 | 없음 |
7. Elastic Beanstalk CLI
EB CLI 명령어
| 명령어 | 설명 |
|---|---|
eb create | 환경 생성 |
eb status | 환경 상태 확인 |
eb health | 헬스 상태 확인 |
eb events | 이벤트 로그 |
eb logs | 로그 확인 |
eb open | 애플리케이션 URL 열기 |
eb deploy | 배포 |
eb config | 설정 변경 |
eb terminate | 환경 종료 |
💡 자동화된 배포 파이프라인에 유용!
8. 배포 프로세스
의존성 파일
| 언어 | 의존성 파일 |
|---|---|
| Python | requirements.txt |
| Node.js | package.json |
배포 단계
1. 의존성 파일 작성
↓
2. 코드를 ZIP으로 패키징
↓
3. Console: ZIP 업로드 → 새 버전 생성 → 배포
CLI: eb deploy → ZIP 업로드 → 배포
↓
4. Beanstalk이 각 EC2에:
- ZIP 배포
- 의존성 설치
- 애플리케이션 시작9. Lifecycle Policy (수명 주기 정책)
필요성
- Beanstalk은 최대 1,000개 버전 저장 가능
- 오래된 버전 미삭제 시 배포 불가
정책 기준
| 기준 | 설명 |
|---|---|
| 시간 기반 | 오래된 버전 자동 삭제 |
| 공간 기반 | 버전 수 초과 시 삭제 |
주의사항
- 현재 사용 중인 버전은 삭제 안 됨
- 소스 번들(S3)은 삭제하지 않도록 옵션 설정 가능
10. Elastic Beanstalk Extensions
.ebextensions 디렉토리
| 항목 | 설명 |
|---|---|
| 위치 | 소스 코드 루트의 .ebextensions/ |
| 형식 | YAML 또는 JSON |
| 확장자 | .config (예: logging.config) |
기능
- UI 설정을 코드로 관리 (IaC)
option_settings로 기본 설정 변경- 추가 리소스 생성 (RDS, ElastiCache, DynamoDB 등)
예시: .ebextensions/01_options.config
option_settings:
aws:elasticbeanstalk:application:environment:
DB_HOST: mydb.xxxxx.rds.amazonaws.com
NODE_ENV: production⚠️
.ebextensions로 생성한 리소스는 환경 삭제 시 함께 삭제됨
11. Elastic Beanstalk 내부 구조
CloudFormation 기반
Elastic Beanstalk ──❤── CloudFormation
│
└─→ .ebextensions에서 CloudFormation 리소스 정의 가능
(ElastiCache, S3 버킷 등)- Beanstalk은 내부적으로 CloudFormation 사용
- CloudFormation 스택으로 리소스 프로비저닝
12. Environment Cloning (환경 복제)
개요
- 기존 환경과 동일한 설정으로 새 환경 생성
보존되는 항목
- Load Balancer 타입 및 설정
- RDS 데이터베이스 타입 (데이터는 복사 안 됨)
- 환경 변수
사용 사례
- 테스트 환경 배포
13. 마이그레이션 시나리오
13.1 Load Balancer 타입 변경
⚠️ 환경 생성 후 Load Balancer 타입 변경 불가 (설정만 변경 가능)
마이그레이션 방법:
1. 새 환경 생성 (원하는 LB 타입으로, Clone 불가)
↓
2. 새 환경에 애플리케이션 배포
↓
3. Route 53 업데이트 또는 CNAME Swap┌─────────────────┐ ┌─────────────────┐
│ Beanstalk old │ │ Beanstalk new │
│ (CLB) │ │ (ALB) │
└────────┬────────┘ └────────┬────────┘
│ │
└──────────┬───────────────┘
│
┌──────▼──────┐
│ Route 53 │
│ 또는 CNAME │
│ Swap │
└─────────────┘13.2 RDS 분리 (Decouple)
문제점
- Beanstalk으로 RDS 프로비저닝 시: 환경 수명 = DB 수명
- 프로덕션에 부적합
권장 방식
- 프로덕션: RDS를 별도 생성하고 연결 문자열만 제공
RDS 분리 마이그레이션
1. RDS DB 스냅샷 생성 (안전장치)
↓
2. RDS 콘솔에서 삭제 방지 설정
↓
3. RDS 없이 새 Beanstalk 환경 생성
→ 기존 RDS 연결 문자열 설정
↓
4. CNAME Swap 또는 Route 53 업데이트
↓
5. 기존 환경 종료 (RDS는 삭제 안 됨)
↓
6. DELETE_FAILED 상태의 CloudFormation 스택 삭제배포 옵션 선택 가이드
개발 환경?
│
├─ Yes → All at once (빠름)
│
└─ No (프로덕션) → 다운타임 허용?
│
├─ Yes → All at once
│
└─ No → 빠른 롤백 필요?
│
├─ Yes → Immutable / Blue-Green
│
└─ No → Rolling with additional batches핵심 요약
| 항목 | 설명 |
|---|---|
| Elastic Beanstalk | 개발자 중심 배포 서비스, 인프라 자동 관리 |
| Web Server Tier | HTTP 요청 처리 (ELB + ASG) |
| Worker Tier | 백그라운드 작업 (SQS + ASG) |
| All at once | 빠름, 다운타임 있음 → 개발용 |
| Rolling | 용량 감소, 추가 비용 없음 |
| Rolling + batches | 용량 유지, 약간 추가 비용 → 프로덕션 |
| Immutable | 새 ASG, 빠른 롤백 → 프로덕션 |
| Blue/Green | 별도 환경, URL Swap |
| Traffic Splitting | 카나리 테스트, 자동 롤백 |
| .ebextensions | 설정/리소스를 코드로 관리 |
| RDS 분리 | 프로덕션에서는 별도 RDS 권장 |