9. Elastic Beanstalk

1. Overview

 

개요 및 배경

• 복잡한 인프라(EC2, ASG, ELB, RDS 등)를 매번 수동으로 구성하는 번거로움을 해결하기 위해 도입된 개발자 중심의 애플리케이션 배포 및 관리형 서비스(PaaS)임
• 용량 프로비저닝, 로드 밸런서 구성, 오토 스케일링, 상태 모니터링 등을 AWS가 자동 처리하므로 개발자는 코드(Code) 작성 및 배포에만 집중할 수 있음
• Elastic Beanstalk 서비스 자체는 무료이며, 내부적으로 프로비저닝된 기반 AWS 리소스(EC2, ELB 등)에 대해서만 과금됨

주요 리소스 및 기능

1. 핵심 구성 요소
   • 애플리케이션(Application): 환경, 버전, 구성을 포함하는 최상위 논리적 집합체임
   • 애플리케이션 버전(Application Version): 개발자가 업로드한 코드의 특정 반복(Iteration) 빌드 버전임
   • 환경(Environment): 특정 애플리케이션 버전을 실행하는 실제 AWS 인프라 리소스의 집합이며, 한 환경에서는 한 번에 하나의 버전만 실행 가능함
2. 환경 티어 (Environment Tiers)
   • 웹 서버 티어(Web Server Tier): 클라이언트의 HTTP 요청을 직접 처리하는 전통적인 웹 아키텍처로, 로드 밸런서(ELB)와 Auto Scaling 그룹(ASG) 기반으로 동작함
   • 워커 티어(Worker Tier): 백그라운드 작업을 비동기적으로 처리함. 내장된 Amazon SQS 대기열을 통해 메시지를 수신하며, 대기열의 메시지 양에 비례하여 EC2 인스턴스(워커)가 오토 스케일링됨
3. 배포 모드 (Deployment Modes)
   • 단일 인스턴스(Single Instance): 탄력적 IP(EIP)를 가진 1대의 EC2 인스턴스만 실행하며 로드 밸런서가 없음 (개발 및 테스트 환경용)
   • 고가용성 로드 밸런서(High Availability with Load Balancer): 다중 가용 영역(Multi-AZ)에 걸친 ASG와 로드 밸런서를 프로비저닝함 (프로덕션 운영 환경용)

헷갈리는 포인트 (Tips)

• 사용자 요청 처리에 지연을 유발하는 무거운 백그라운드 작업을 분리하려면, 웹 서버 환경과 워커 환경을 각각 별도로 구축하고 웹 서버에서 워커 환경의 SQS 대기열로 메시지를 전송하도록 아키텍처를 분리(Decoupling)하는 것이 모범 사례임
• 워커 티어(Worker Tier)의 오토 스케일링 기준은 EC2의 CPU 사용량 등이 아니라 SQS 대기열에 쌓인 메시지 수(Message Count)를 기반으로 작동한다는 점을 명확히 인지해야 함

---

2. High Availability Environment

 

개요 및 배경

• 프로덕션 수준의 안정성을 요구하는 웹 애플리케이션을 배포하기 위해, 단일 인스턴스(Single Instance) 모드 대신 고가용성(High Availability, HA) 모드로 Elastic Beanstalk 환경을 프로비저닝함
• 고가용성 모드를 선택하면 백그라운드에서 자동으로 로드 밸런서(ALB)와 다중 가용 영역(Multi-AZ)에 배포되는 Auto Scaling 그룹(ASG)이 구성되어 트래픽 분산과 오토 스케일링을 수행함

주요 리소스 및 구성 요소 설정

1. 인스턴스 및 네트워크 설정 (Instance & Networking)
   • 고가용성 환경에서는 로드 밸런서가 인터넷 게이트웨이를 통해 외부 트래픽을 처리하므로, 보안 강화를 위해 EC2 인스턴스에 퍼블릭 IP(Public IP)를 할당하지 않고 프라이빗 서브넷(Private Subnets)에 배치하는 것이 모범 사례임
   • 데이터베이스(RDS)를 Beanstalk 환경에 직접 포함하여 생성할 수 있으나, 이 경우 데이터베이스의 생명 주기가 환경과 동일하게 묶여 환경 삭제 시 DB도 함께 삭제(Terminate)되는 위험이 있음 (프로덕션 환경에서는 DB를 외부에 별도로 분리 구성하는 것을 권장함)
2. Auto Scaling 그룹 (ASG) 및 로드 밸런서 (Load Balancer)
   • 용량 설정: 트래픽 변동에 대응하기 위해 ASG의 최소(Min) 및 최대(Max) 인스턴스 용량(예: 1~4대)을 정의함
   • 동적 스케일링 정책: 네트워크 트래픽(Network Out 평균치)이나 CPU 사용률 등 특정 임계값(Threshold)을 기준으로 스케일 아웃/인 정책을 Beanstalk 콘솔에서 직접 설정할 수 있음
   • ALB 공유: 비용 절감을 위해 여러 Beanstalk 환경이 하나의 Application Load Balancer(공유 로드 밸런서)를 함께 사용하도록 구성할 수 있음
3. 보안 그룹 (Security Groups) 자동 구성
   • Beanstalk이 로드 밸런서용 보안 그룹(외부 80번 포트 허용)과 EC2 인스턴스용 보안 그룹(로드 밸런서 보안 그룹으로부터의 트래픽만 허용)을 자동으로 생성하고 상호 연결하여 3계층 보안 아키텍처를 구현함

헷갈리는 포인트 (Tips)

• Elastic Beanstalk 콘솔에서 "High Availability" 프리셋을 선택하고 세부 설정을 변경하지 않고 그대로 배포(Skip to review)하더라도, 기본적으로 로드 밸런서, ASG, 타겟 그룹(Target Group), 보안 그룹 등 프로덕션에 필요한 모든 기반 인프라가 자동으로 완벽하게 프로비저닝됨
• 시험 문제에서 "데이터베이스가 Elastic Beanstalk 환경 내부에 생성되었을 때 환경 삭제 시 데이터 보존 방법"을 묻는다면, "환경 삭제 전 스냅샷(Snapshot) 생성" 또는 최초 아키텍처 설계 시 RDS를 Beanstalk 외부 환경으로 분리(Decoupling)하는 옵션을 선택해야 함

---

3. Deployment Modes

 

개요 및 배경

• Elastic Beanstalk 환경에 새로운 애플리케이션 버전(v2)을 배포할 때, 서비스 가용성, 배포 속도, 비용, 롤백 용이성 등의 요구사항에 맞춰 선택할 수 있는 6가지 배포 전략(Deployment Policies)을 이해해야 함
• 시험에서는 주어진 시나리오(예: "다운타임 허용 불가", "비용 최소화", "카나리 테스트 필요" 등)에 가장 적합한 배포 방식을 선택하는 문제가 자주 출제됨

주요 배포 모드 비교

1. All at Once (한 번에 모두)
   • 방식: 기존 인스턴스 전체의 애플리케이션(v1)을 동시에 중지하고 새 버전(v2)을 배포함
   • 특징: 배포 속도가 가장 빠름. 추가 인프라 프로비저닝이 없어 추가 비용 없음.
   • 단점: 배포가 진행되는 동안 모든 인스턴스가 오프라인 상태가 되므로 다운타임(Downtime)이 발생함. (개발/테스트 환경에 적합)
2. Rolling (롤링)
   • 방식: 지정된 배치 크기(Bucket Size, 예: 전체의 30% 또는 2대)만큼 순차적으로 기존 인스턴스를 중지하고 새 버전을 배포함
   • 특징: 다운타임 없음. 추가 인스턴스를 생성하지 않으므로 추가 비용 없음. 일시적으로 v1과 v2가 혼재되어 서비스됨
   • 단점: 배포 중에는 전체 인스턴스 수가 감소하므로 용량 부족(Under capacity) 상태로 운영됨. 배포 속도가 느림
3. Rolling with Additional Batch (추가 배치를 사용한 롤링)
   • 방식: 롤링 방식의 단점을 보완하기 위해, 먼저 새로운 인스턴스(추가 배치)를 프로비저닝하여 v2를 배포한 뒤 기존 인스턴스를 순차적으로 교체함
   • 특징: 다운타임 없음. 배포 과정 내내 100% 용량(Full capacity)을 유지함. (프로덕션 환경에 적합)
   • 단점: 배포 완료 시 제거될 임시 인스턴스를 잠시 실행하므로 소규모 추가 비용이 발생함. 배포 속도가 느림
4. Immutable (불변)
   • 방식: 기존 ASG를 건드리지 않고, 새 버전을 구동하는 임시 ASG(Temporary ASG)를 생성하여 전체 용량만큼 새 인스턴스를 프로비저닝함. 헬스 체크 통과 후 새 인스턴스들을 기존 ASG로 이동시키고 기존 인스턴스(v1)를 모두 종료함
   • 특징: 다운타임 없음. 롤백이 매우 빠르고 안전함(임시 ASG만 삭제하면 됨). 이전 버전의 인스턴스가 오염되는 것을 원천 차단함
   • 단점: 배포 시점에 인프라 용량이 정확히 2배(Double capacity)가 되므로 가장 높은 추가 비용이 발생하고 배포 시간이 김
5. Blue/Green (블루/그린)
   • 방식: 기존 환경(Blue, v1)과 완전히 동일한 새로운 독립된 환경(Green, v2)을 아예 새로 구축함. 이후 Route 53 가중치 라우팅(Weighted Routing)이나 Beanstalk의 Swap Environment URLs 기능을 사용하여 트래픽을 전환함
   • 특징: 다운타임 없음. 새 환경에서 완벽한 사전 테스트가 가능하며, 즉각적인 롤백이 가능함
   • 단점: Beanstalk의 내장된 자동화 배포 옵션이 아니며, 인프라 비용이 2배로 들고 수동(Manual) 작업 요소가 강함
6. Traffic Splitting (트래픽 분할 / Canary Testing)
   • 방식: 임시 ASG를 생성하고 ALB(Application Load Balancer)를 제어하여 소규모 비율(예: 10%)의 트래픽만 새 버전(v2)으로 라우팅하는 카나리 테스트(Canary Testing)를 자동 수행함. 일정 시간 후 상태가 정상이면 나머지 90% 트래픽도 모두 전환함
   • 특징: 소수의 사용자 트래픽만으로 새 버전을 안전하게 검증할 수 있음. 실패 시 즉각적이고 자동화된 롤백을 지원함

헷갈리는 포인트 (Tips)

• "배포 중에도 가용성(Capacity)이 100% 유지되어야 하며, 비용 증가를 최소화해야 한다"는 요구사항에는 Rolling with Additional Batch가 정답임 (Immutable은 비용이 너무 큼)
• "새 코드 배포 시 실패율을 최소화하기 위해 일부 사용자에게만 먼저 노출하고 싶다"는 요구사항(카나리 배포)에는 Traffic Splitting이 정답임
• "기존 인스턴스의 구성 변경(돌연변이)을 허용하지 않고, 문제가 생겼을 때 가장 빠르고 안전하게 롤백해야 한다"면 Immutable 배포 방식이 가장 적합함