◇ 공부 기록용으로 작성하였으니 틀린점, 피드백 주시면 감사하겠습니다 ◇
AWS Elastic Beanstalk
AWS Elastic Beanstalk는 개발자가 인프라에 대한 고민 없이 애플리케이션의 개발에만 집중하여, 쉽게 배포하고 할 수 있게 해주는 AWS 서비스이다. (AWS 측에서 인프라 측에 설정을 해준다.)
몇 번의 클릭만으로 인프라 환경을 생성할 수 있다. (빠른 Deploy 가능)
⭐ 특징
- 인프라 설정의 준비나 부하 분산, 모니터링 등을 개발자 대신 처리해준다.
- EC2 인스턴스는 운영체제(OS)는 물론, 웹 서버 소프트웨어와 애플리케이션 실행 환경 등이 설치된 상태로 제공
- 단일 인스턴스 또는 Multi-AZ 구성을 선택할 수 있다.
- 관련된 AWS 서비스(ELB, S3, Auto Scaling 그룹 등)도 설정이 완료된 상태로 제공한다.
- 어플리케이션을 실행하기 위한 인프라/서버를 준비할 필요없다.
- → 개발자는 애플리케이션을 업로드하기만 된다. 개발자의 생산성 상승
- 지원되는 언어 및 플랫폼:
- Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker(컨테이너)
- Amazon Linux AMI、Windows Server AMI
- 환경이 구축된 후에도 운영 관리 등은 AWS에 의해 수행된다.
- 예를 들어, 운영 체제(OS)의 업데이트는 자동으로 이루어지며, 항상 최신 버전으로 유지할 수 있다.
Workflow:
기본적으로 인프라 관리가 필요없이 쉽게 새로운 버전을 배포 할 수 있다.
일반적으로 Elastic Beanstalk가 담당하는 부분
인프라의 프로비저닝, 버전 관리, 부하 분산 등.
아래와 같이 AWS 리소스의 특정 세부 사항을 선택한다.
- EC2 (서버): 애플리케이션을 실행하기 위해 필요한 EC2 인스턴스를 자동으로 생성하고 관리한다.
- ELB (로드 밸런싱): 애플리케이션 트래픽을 여러 인스턴스에 분산하기 위해 로드 밸런서를 설정하고 관리한다.
- Auto Scaling: 애플리케이션의 트래픽 변화에 따라 인스턴스 수를 자동으로 조정한다. 트래픽이 증가하면 인스턴스를 추가하고, 감소하면 인스턴스를 줄인다.
- 모니터링: Amazon CloudWatch와 통합하여 로그 관리
단점:
- 제한된 커스터마이징: 자동화된 설정으로 인해 세부적인 인프라 설정이 제한될 수 있다.
- 복잡한 요구 사항 처리: 매우 복잡한 배포 요구 사항이 있을 경우, 직접 인프라를 관리하는 것이 더 나을 수 있다.
CloudFormation와 관련성
사실 Elastic Beanstalk는 CloudFormation으로 구축되어 있다.
Elastic Beanstalk는 실제 배포 시 CloudFormation과 연동하여 환경을 배포하고 있다.
Deploy Policy
Deploy Policy는 애플리케이션을 새로 배포할 때(버전을 바꿀 때) 사용한다.
📌 All at One (모두 한 번에)
애플리케이션의 모든 인스턴스를 동시에 새로운 버전으로 배포(Deploy)한다.
🎈예시)
4개의 인스턴스 있을 경우 → 4개 한꺼번에 배포
- 배포 속도가 가장 빠르다.
- 서비스의 중단 시간이 있다. (인스턴스들이 모두 동시에 업데이트되면서 기존 버전이 없어지기 때문에)
📌 Rolling (순차적으로)
Rolling은 인스턴스를 한꺼번에 업데이트하지 않고, 여러 Batch로 나누어 순차적으로 배포(Deploy)하는 방법이다.
🎈예시)
4개의 인스턴스 있을 경우 → 먼저 2개 배포 → 문제 없으면 나머지 2개 배포
- 사전에 설정한 batch 사이즈에 해당하는 인스턴스에게 새로운 버전을 먼저 배포한다.
- 배포한 것에 문제가 없으면 다른 인스턴스에도 배포한다.
- (이런 방식으로 배포하기 때문에 인스턴스들에 새로운 버전과 이전 버전이 함께 공존하는 시간이 존재한다)
- Batch 사이즈를 지정할 수 있다.
- 배포 중인 인스턴스는 일시적으로 서비스 중단 상태가 된다
📌 Rolling with Additional Batch (추가 Batch를 활용하여, 순차적으로..)
Rolling에 추가 Batch를 더한 방법으로, 서비스 중단을 최소화하고 성능 저하도 줄이기 위해 고안된 방식이다.
추가로 하나의 Batch 만큼 인스턴스를 임시 생성 후에, Rolling과 동일하게 배포한다.
🎈예시)
4개 인스턴스 있을 경우 (Batch size: 2) → 추가로 2개 인스턴스를 임시 생성 → 2개 배포 → 2개 배포 → 임시 생성한 2개 인스턴스 삭제
- 추가로 Batch 사이즈만큼 인스턴스를 임시 생성하여 배포하기 때문에 서비스 중단 시간을 최소화한다.
- Batch 사이즈를 지정할 수 있다.
- Rolling보다 가용성이 높다
📌 Immutable
애플리케이션을 배포할 때 기존 인스턴스를 변경하지 않고, 동인한 수의 새로운 인스턴스를 생성하여 새 버전을 배포한다. 그 후에 기존 인스턴스는 종료한다.
🎈예시)
4개 인스턴스 있을 경우→ 추가로 4개 인스턴스를 생성하여 새 버전 배포 → 기존 4개 인스턴스 삭제
📌 Traffic Splitting
새로운 버전으로의 트래픽 전환을 제어하는 방법으로, 특정 비율의 트래픽을 새로운 버전으로 전환하고, 나머지는 기존 버전으로 유지할 수 있다.
🎈예시)
80%의 트래픽을 기존 버전으로 유지하고, 20%의 트래픽을 새로운 버전으로 보낼 수 있다.
- Canary 배포 방식
- 일부 인스턴스에만 새로운 애플리케이션을 배포하고 업데이트한다.
- 수신 트래픽의 일부를 사용해 새로운 애플리케이션의 상태를 테스트한다.
📌 Blue/Green
Elastic Beanstalk 환경의 클론을 생성한 후, 클론에 새로운 애플리케이션을 배포하고, 환경 URL을 스왑하여 (새로운 환경과 기존 환경을 교체) 전환한다.
