◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇
AWS Elastic Beanstalk
AWS Elastic Beanstalk는 개발자가 인프라에 대한 고민 없이 애플리케이션의 개발에만 집중하여, 쉽게 배포하고 할 수 있게 해주는 AWS 서비스이다. (AWS 측에서 인프라 측에 설정을 해준다.)
몇 번의 클릭만으로 인프라 환경을 생성할 수 있다.
⭐ 특징
- 애플리케이션을 위한 인프라(서버)을 따로 생각해서 준비할 필요 없다. → 개발자의 생산성 상승
- Elastic Beanstalk가 인프라를 위한 부하 분산, 모니터링 등을 개발자 대신 해준다.
- EC2 인스턴스는 운영체제(OS)는 물론, 웹 서버 소프트웨어와 애플리케이션 실행 환경 등이 설치된 상태로 제공
- 관련된 AWS 서비스(ELB, S3, Auto Scaling 그룹 등)도 설정이 완료된 상태로 제공한다.
- 단일(single) 인스턴스 또는 Multi-AZ 구성을 선택할 수 있다.
- 지원되는 언어: Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker (컨테이너)
- 지원되는 AMI: Amazon Linux AMI、Windows Server AMI
- 단일(single) 인스턴스 또는 Multi-AZ 구성을 선택할 수 있다.
- 환경이 구축된 후에도 운영 관리 등은 AWS에 의해 수행된다. 예를 들어, 운영 체제(OS)의 업데이트는 자동으로 이루어지며, 항상 최신 버전으로 유지할 수 있다.
Elastic Beanstalk의 Workflow:
기본적으로 인프라 관리가 필요없이 쉽게 새로운 버전을 배포 할 수 있다.
Elastic Beanstalk의 설정 방식
🤝 CloudFormation와 관련성
사실 Elastic Beanstalk는 CloudFormation으로 구축되어 있다.
Elastic Beanstalk는 실제 배포 시 CloudFormation과 연동하여 개발 환경을 배포하고 있다.
📁 .ebextensions 파일
(.ebextensions)는 Elastic Beanstalk 애플리케이션 환경을 설정할 때 사용하는 폴더이다.
애플리케이션의 소스 코드에 (.ebextensions) 폴더를 추가하여 파일 확장자를 .config를 가진 YAML 또는 JSON 형식의 파일을 이 폴더에 배치하여 Deploy(배포)한다.
.ebextensions폴더에는 Elastic Beanstalk 환경을 설정하고 관리하기 위한 설정 파일을 넣는다.
- 필요한 프로그램 설치 파일 (예: Apache, Git, Node.js)
- 명령어 실행 파일
- 환경 변수 설정 파일 (예: 애플리케이션에 사용되는 DB에 접근하기 위한 변수)
- 네트워크 설정 파일 (예: Load Balancer나 X-Ray 등의 환경 설정 파일)
.ebextensions 폴더 구조 예시
elasticBeanstalk_application/
├── .ebextensions/
│ ├── 01_packages.config
│ ├── 02_environment.config
│ ├── 03_scripts.config
│ └── 04_custom_files.config
├── application.py
└── requirements.txt
Deploy Policy (배포 정책)
Deploy Policy는 애플리케이션을 새로 배포할 때(버전을 바꿀 때) 사용한다.
📌 All at One (모두 한꺼번에 배포)
애플리케이션의 모든 인스턴스를 동시에 새로운 버전으로 배포(Deploy)한다.
- 배포 속도가 다른 방법에 비교하여 가장 빠르다.
- 서비스가 중단되는 시간이 있다. (인스턴스들이 모두 동시에 업데이트하기 때문에 배포 도중에 서비스가 중단된다)
🎈예시) 4개의 인스턴스 있을 경우 → 4개 한꺼번에 배포
📌 Rolling (순차적으로 배포)
Rolling은 인스턴스를 한꺼번에 업데이트하지 않고, 여러 Batch로 나누어 순차적으로 배포(Deploy)하는 방법이다.
배포할 인스턴스 집합의 크기. ("Rolling"과 "Rolling with Additional Batch"에서 사용한다)
- 사전에 Batch Size를 지정하여 새로운 버전을 배포한다.
- 배포한 것에 문제가 없으면 다른 인스턴스에도 배포한다.
- (이런 방식으로 배포하기 때문에 인스턴스들에 새로운 버전과 이전 버전이 함께 공존하는 시간이 존재한다)
- 배포 중인 인스턴스는 일시적으로 서비스 중단 상태가 될 수도 있다.
🎈예시) 4개의 인스턴스 있을 경우 → 먼저 2개 배포 → 문제 없으면 나머지 2개 배포
📌 Rolling with Additional Batch (추가 Batch를 활용하여, 순차적으로..)
Rolling에 추가 Batch를 더한 방법으로, 서비스 중단을 최소화하고 성능 저하도 줄이기 위해 고안된 방식이다.
추가로 하나의 Batch 만큼 인스턴스를 임시 생성 후에, Rolling과 동일하게 배포한다.
- 추가로 Batch 사이즈만큼 인스턴스를 임시 생성하여 배포하기 때문에 서비스 중단 시간을 최소화한다.
- Rolling의 방법보다 가용성이 높다
🎈예시) 4개 인스턴스 있을 경우(Batch size: 2) → 추가로 2개 인스턴스를 임시 생성 → 2개 배포
→ 2개 배포 → 임시 생성한 2개 인스턴스 삭제
📌 Immutable
애플리케이션을 배포할 때 기존 인스턴스를 변경하지 않고, 동인한 수의 새로운 인스턴스를 생성하여 새 버전을 배포한다. 그 후에 기존 인스턴스는 종료한다.
🎈예시) 4개 인스턴스 있을 경우→ 추가로 4개 인스턴스를 생성하여 새 버전 배포 → 기존 4개 인스턴스 삭제
📌 Traffic Splitting (Canary Release 방식)
새로운 버전으로의 트래픽 전환을 제어하는 방법으로, 특정 비율의 트래픽을 새로운 버전으로 전환하고, 나머지는 기존 버전으로 유지할 수 있다. 이는 Canary Release라고도 한다.
- Canary Release 방식
- 일부 인스턴스에만 새로운 애플리케이션을 배포하고 업데이트한다.
- 수신 트래픽의 일부를 사용해 새로운 애플리케이션의 상태를 테스트한다.
🎈예시) 80%의 트래픽을 기존 버전으로 유지하고, 20%의 트래픽을 새로운 버전으로 보낼 수 있다.
📌 Blue/Green
Elastic Beanstalk 환경의 클론을 생성한 후, 클론에 새로운 애플리케이션을 배포하고, 환경 URL을 스왑하여 (새로운 환경과 기존 환경을 교체) 전환한다.
🤔 문제 1
한 회사가 AWS Elastic Beanstalk에 애플리케이션을 배포했습니다. 회사는 Elastic Beanstalk 환경에 연결된 Auto Scaling 그룹을 Amazon EC2 인스턴스 5개로 구성했습니다. 배포 중 EC2 인스턴스의 수가 4개 미만이 되면 애플리케이션 성능이 저하됩니다. 현재 all-at-once 배포 정책을 사용하고 있습니다.
배포 문제를 가장 비용 효율적으로 해결하는 방법은 무엇입니까?
- Auto Scaling 그룹을 6개의 원하는 인스턴스로 변경합니다.
- 배포 정책을 Traffic Splitting로 변경합니다. 평가 시간을 1시간으로 지정합니다.
- 배포 정책을 Rolling with addtional batch으로 변경합니다. 배치 크기를 1로 지정합니다.
- 배포 정책을 Rolling으로 변경합니다. 배치 크기를 2로 지정합니다.
정답
정답. 3번
🤔 문제 2
AWS Elastic Beanstalk에 배포된 애플리케이션이 새로운 애플리케이션 버전 배포 중 오류율이 증가하여 사용자 서비스가 저하되고 있습니다. 개발팀은 배포 단계에서 용량이 줄어드는 것이 원인이라고 생각합니다. 팀은 배포 중 기존 인스턴스를 사용하면서 전체 용량을 유지할 수 있는 환경의 배포 정책 구성을 변경하고자 합니다. 이 요구사항을 충족하는 배포 정책은 무엇인가요?
- All at once
- Rolling
- Rolling with additional batch
- Immutable
정답
정답. 3번
