Section 17. AWS Elastic Beanstalk

지금까지 우리는 아래와 같은 아키텍쳐를 통해 어플리케이션을 배포해왔다.

 로드밸런서는 사용자의 모든 요청을 처리하고, 여러 가용 영역을 가진 오토 스케일링 그룹이 있고, 각 AZ에는 일부 EC2 인스턴스가 배포된다.

 백엔드에는 데이터 서브네이 있을 수도 있다. 그래서 RDS와 읽기 전용 복제본 등이 있을 수 있다.

 또한 캐싱 레이어가 필요하다면 ElastiCache를 살펴보아야 한다.

 

배포할 애플리케이션이 많고, 이들이 동일한 아키텍쳐를 따를 경우 반복적인 작업이 번거로울 수 있다.

따라서 개발자로서 코드를 배포하기 위해 인프라를 관리하는 것은 복잡하다.
또한 모든 데이터베이스, 로드 밸런서 등을 일일이 구성하고 싶지 않고, 모든 것이 확장되기를 원한다.

지금까지의 학습을 통해 보면 대부분의 웹 어플리케이션들은 로드 밸런서와 오토 스케일링 그룹을 갖는 동일한 아키텍쳐를 갖는 다는 것을 알 수 있다.

따라서 다양한 프로그래밍 언어로 개발하고 다양한 어플리케이션과 환경을 사용하는 경우 어플리케이션을 배포하는 단일 방법을 원할 수 있는데 이 때 Beanstalk가 작동한다.

 

Beanstalk는 AWS에 애플리케이션을 배포하는 데에 있어 개발자 중심의 관점을 제공한다.

Elastic Beanstalk의 아이디어는 하나의 인터페이스에서 EC2, ASG, ELB, RDS와 같이 이전에 본 모든 구성 요소를 재사용하는 것으로 이러한 모든 것을 자동으로 배포해 주는 관리형 서비스가 될 것이다.

Beanstalk는 그 자체로는 무료이지만 Beanstalk가 사용하는 기본 인스턴스나 ASG 등에 대한 비용은 지불해야 한다.

 

1. Components

• Beanstalk는 애플리케이션으로 구성되며 이는 환경, 버전 등과 같은 Beanstalk 구성 요소의 모음이다.
• 버전 자체는 애플리케이션 코드의 반복이기 때문에 버전1, 버전2 등으로 나눌 수 있다.
• 환경은 특정 애플리케이션 버전을 실행하는 리소스의 모음이므로 환경 내에서는 한 번에 하나의 애플리케이션 버전만 사용할 수 있다.
  • Beanstalk에서는 티어가 있기에 두 가지 다른 티어를 설정할 수 있다.
  • 또한 Beanstalk에서 개발, 테스트, 프로덕션 등 여러 환경을 생성할 수 있고 원하는 모든 환경을 만들 수 있다.

2. Supported Platforms

Beanstalk에서는 여러 언어를 제공하는데 Go, Java SE, Java with Tomcat, .Net Core on Linux, .NET on Windows Server, Node.js, PHP, Python 등의 언어를 제공한다.

- 언어가 없으면 EC2 사용자 데이터 스크립트를 사용하여 스크립트 및 보안 소프트웨어를 설치하자!

 

3. Web Server Tier vs. Worker Tier

위에서 알아보았던 Beanstalk의 티어 두 가지를 알아보도록 하겠다.

1. Web Tier
   1. 우리가 로드 밸런서가 있는 위치를 알고 있는 전통적 아키텍쳐로 로드 밸런서가 트래픽을 ASG로 보내고 여기에 여러 EC2 인스턴스가 포함되어 있어 웹 서버 역할을 한다.
2. Worker Tier
   1. 작업자 환경을 중심으로 이루어지는 아키텍쳐이다.
   2. EC2 인스턴스에 직접 액세스하는 클라이언트가 없고, 메시지 대기열인 SQS 대기열을 사용하여 메시지를 전송한다.
   3. EC2 인스턴스는 작업자 역할을 할 것인데, SQS 대기열에서 메시지를 가져와 처리하기 때문이다.
   4. 이 경우 작업자 환경은 SQS 메시지 수에 따라 확장된다.

Web Tier(왼)과 Worker Tier(우)

4. Elastic Beanstalk Deployment Modes

Beanstalk에 대한 두 가지 배포 모드에 대해 알아보자.

1. 개발 목적에 적합한 단일 인스턴스
   1. 탄력적 IP를 가진 EC2 인스턴스가 하나 있고, RDS 데이터베이스 등을 생성할 수도 있지만 이는 모두 하나의 인스턴스와 탄력적 IP를 기반으로 한다.
2. 생산 환경에 적합한 로드밸런서를 가진 고가용성
   • 로드 밸런서가 ASG 및 여러 AZ에서 관리되는 EC2 인스턴스들에 로드를 분산시킬 수 있다.
   • 또한 마스터와 스탠바이 인스턴스를 가진 Multi-AZ RDS 데이터베이스를 가질 수도 있다.

단일 인스턴스(좌)와 고가용성 로드 밸런서(우)

---

Beanstalk Deployment Options for Updates

• 첫 번째 옵션 | 한 번에 다 배포
  • 한 번에 모든 인스턴스를 배포한다. 가장 빠르지만 인스턴스가 업데이트되는 동안 서비스가 잠시 중지되어 다운타임이 발생한다.
• 두 번째 옵션 | 롤링(Rolling)
  • 버킷이라는 인스턴스 묶음을 동시에 업데이트하고 첫 번째 버킷의 상태가 괜찮으면 다음 버킷으로 이동한다. 
• 세 번째 옵션 | 추가 배치를 사용한 롤링
  • 롤링 옵션과 같지만 새 인스턴스를 생성하여 시간에 걸쳐 인스턴스를 업데이트하기 때문에 배포 중에 용량을 유지한 채 이전 애플리케이션을 이용할 수 있다.
• 네 번째 옵션 | 변경 불가능
  • ASG에 인스턴스가 있을 때 새 인스턴스를 다 같이 배포한다.
  • 인스턴스에 버전을 배포한 다음 다음 상태가 모두 괜찮으면 모든 인스턴스를 교환한다.
• 다섯 번째 옵션 | 블루 그린 옵션
  • 완전히 새로운 환경을 다같이 생성한 다음 준비가 되면 교환한다.
• 여섯 번째 옵션 | 트래픽 분할 옵션
  • 카나리아 테스트용 옵션, 애플리케이션 트래픽의 일부를 완전히 새로운 배포로 전송하여 수행한다.

1. All at Once

• 가장 빠른 배포 옵션
• 애플리케이션 다운타임이 발생한다.(서비스를 사용할 수 없음을 의미)
• 빠른 이터레이션 및 개발 환경에 좋다.
• 추가 요금이 없다.

All at Once

2. Rolling

• 기본적으로 용량 이하로 실행
• 버킷 사이즈를 조정할 수 있다.
• 버전이 동시적으로 실행된다.
• 추가 요금 없음.

3. Rolling with additional batches

• 용량 이하로 실행
• 버킷 사이즈 조정이 가능
• 두 버전이 동시에 실행된다.
• 약간의 추가 요금 발생
• 배포가 오래 걸리지만 prod 환경에 유용하다.

4. Immutable

• 다운타임이 0이다.
• 새 코드가 새 인스턴스에 배포된다.
• 이 새로운 인스턴스는 임시로 ASG에 연결된다.
• 비용이 세고, 용량이 2배가 필요하다.
• 배포 시간이 가장 길다.
• 실패 시 빠른 롤백이 가능하다.(새 ASG를 제거만 하면 되기 때문!)

5. Blue / Green

• Elastic Beanstalk가 직접 제공하는 기능은 아니다.
• 다운타임이 0이다.
• 새로운 스테이징 환경을 배포하려는 경우 다른 Elastic Beanstalk 환경을 생성하고 v2를 그곳에 배포한다.
• 새 스테이징, 그린 환경이 독립적으로 검증되고 문제가 발생 시 롤백된다.
• Route53 등을 사용해 트래픽이 두 방향으로 흐르는 것을 방지할 수 있다. 가중치 기반 정책을 설정하고 약간의 트래픽을 스테이징 환경으로 보내 모든 것을 테스트 할 수 있다.

6. Traffic Splitting

• 카나리아 테스트를 꼭 기억할 것
  
  • 이 테스트에서는 새 애플리케이션 버전이 같은 용량의 임시 ASG에 배포된다.
  • 이때 작은 비율의 트래픽이 구성 가능한 시간 동안 임시 ASG로 보내진다.
• 배포가 실패하거나 메트릭이 잘못되면 자동화된 롤백이 빠르게 트리거된다.
• 다운타임이 없다.
• 옛 버전은 모두 삭제된다.

---

Beanstalk Lifecycle Policy

Elastic Beanstalk는 최대 1000개의 애플리케이션 버전을 저장할 수 있다.

옛 버전을 지우지 않으면 Beanstalk를 더이상 배포를 진행할 수가 없게 된다. 그렇다면 오래된 버전을 단계적으로 폐기해야함을 나타낸다.

이때 Beanstalk 수명주기 정책을 사용하면 된다!

 

• 수명주기 정책으로는 시간을 기준으로 하여 오래된 버전을 삭제할 수도 있고, 공간을 기반으로도 삭제할 수 있다.
• 현재 환경에서 사용하는 버전은 삭제되지 않는다! 어떤 경우에도!
• Amazon S3에서 애플리케이션의 소스 번들을 삭제하지 않도록 하는 옵션도 존재한다.
• 현 수명주기 정책은 Beanstalk 인터페이스에서 삭제할 수 있다.

---

Elastic Beanstalk Extensions

• zip 파일을 생성 시, Elastic Beanstalk에 배포하는 코드가 포함된다. 하지만 Elastic Beanstalk 확장을 추가할 수도 있다.
• UI에 있는 모든 파라미터는 파일을 사용하여 코드로 구성할 수 있다!(=EB 확장)
• 모든 설정 파일은 소스코드 루트 디렉터리의 .ebextensions/라는 폴더에 들어가야만 한다.
  • 이 형식은 YAML이나 JSON형식이어야 하는데 이때 파일의 확장자는 .config여야한다.(ex. logging.config)
  • option_settings를 사용하여 기본값을 수정하는 것이 가능하다.
• EB 확장으로 리소스를 추가할 수도 있다.(RDS, EalstiCache 등등)
• EB 확장에서 관리되는 모든 것들은 환경이 삭제되면 같이 삭제된다.

---

Elastic Beanstalk Under the Hood

• Beanstalk는 이면에서 CloudFormation을 기반으로 한다.
  • CloudFormation은 다른 AWS 서비스를 프로비저닝하는 코드형 인프라 서비스이다.
• .ebextensions 폴더의 CloudFormation 리소스를 사용하면 모든 것을 프로비저닝 할 수 있다!
• AWS 상에서는 원하는 모든 것을 구성할 수 있다.

---

Elastic Beanstalk Cloning

• Cloning의 장점은 기존 환경을 새로운 환경으로 복제할 수 있다!
• 애플리케이션의 배포 버전이 있는 경우 매우 유용하다.
• 배포용 환경을 새로운 환경으로 복제해서 테스트 하는 용도로 쓰일 수 있다.
• 모든 리소스와 설정은 보존된다.
  • 로드밸런서 유형과 설정
  • RDS 데이터베이스 유형(이때 데이터는 보존되지 않음..)

---

Elastic Beanstalk Migration

1. Load Balancer

• Beanstalk 환경을 생성하고 나면, ELB 유형은 변경이 불가능하고, 설정만 변경할 수 있다.
• CLB를 ALB, ALB를 NLB로 업그레이드 하려면 다음 단계에 따라 Migration을 수행해야 한다.
  1. 동일한 구성으로 새로운 환경을 생성한다. 로드 밸런서만 제외하고 말이다. 수동으로 생성할 것(Cloning은 로드 밸런서 유형까지 복제한다.)
  2. 애플리케이션을 새 환경에 배포한다.
  3. CNAME 교체나 Route 53을 통해 DNS 업데이트를 수행한다.

2. RDS with Elastic Beanstalk

• RDS는 Beanstalk 애플리케이션을 이용해서 프로비저닝이 가능하다.(개발이나 테스트에 유용)
• 데이터베이스 수명 주기가 Beanstalk 환경 생명주기에 묶여 있어서 배포에는 적합하지 않다.
• 최선의 방안은 RDS 데이터베이스를 Beanstalk 환경에서 분리한 다음 환경 변수 등을 이용하여 이를 연결 문자열로 참조하는 것이다.

3. Decouple RDS(Beanstalk 환경이 아닐 때에 RDS를 생성하는 방법)

1. 문제가 발생할 경우에 대비하여 RDS 데이터베이스에 대한 스냅샷을 생성한다.(백업 용도)
2. RDS 콘솔로 이동하여 RDS 데이터베이스가 삭제되지 않도록 보호한다.
3. 새로운 Elastic Beanstalk 환경을 생성하는데 RDS를 제외하고 환경 변수 등을 사용해서 애플리케이션을 기존의 RDS 데이터베이스로 지정한다.
4. CNAME 교체나 Route 53 업데이트를 수행한다.
5. 기존 환경을 삭제한다. 이때 RDS는 삭제 보호를 수행했으므로 그대로 유지된다.
6. CloudFormation 스택을 수동으로 삭제한다.

옛 버전은 삭제되는 과정

 

---

참고사항

1. Elastic Beanstalk 배포 속도가 느린 경우, 로그를 확인하였을 때 배포할 때마다 각 인스턴스에서 애플리케이션 종속성이 해결되기 때문이라는 것을 알게 되었다.

이때, 최소한의 영향으로 배포 프로세스의 속도를 높이려면 사전에 종속성을 해결하고 Elastic Beanstalk에 업로드된 zip 파일로 패키징을 해야 한다.

 

2. Elastic Beanstalk의 이전 애플리케이션의 버전 삭제를 자동화하여 새 애플리케이션 버전을 만드는 것은 '수명 주기 정책'이다.