Elastic Beanstalk(EB)를 통한 배포 인프라 자동화

 

 

알아서 EC2 인스턴스 유형을 변경하고, Auto Scaling으로 EC2 인스턴스를 늘리고, ELB로 부하를 분산하며 애플리케이션 배포까지 자동으로 해주는 Paas(Platform as a Service)이다. AWS 리소스를 이용하고, 이를 구성하는 곳에만 관여하기 때문에 Beanstalks를 이용한다고 해서 비용이 더 발생하는 등의 문제는 발생하지 않는다.

 

간단한 웹 애플리케이션을 구성하려고 할 때, 인프라 구축에 많은 공을 들이지 않아도 간단하게 배포할 수 있으며, 세부 사항을 조정할 수 있어서 편리하다. (앞으로 서비스 배포는 웬만해서는 Beanstalk를 사용하게 될 것 같다)

 

웹 사이트, 모바일 백엔드 등 다양한 분야에서 활용될 수 있다. BMW 차량 컴퓨터 처리 서버가 빈스톡으로 만들어졌다는 카더라 소문도 있다.

 

Elastic Beanstalk은 Elasitc Load Balacer + EC2를 만들고 Auto Scaling 그룹 설정 + 앱 버전과 로그들은 S3에 자동 저장

 

여타 다른 aws 서비스와 같이 AWS 콘솔에서 업로드할 수도 있고, AWS 툴킷, git, docker, AWS CLI 등을 이용해서도 올릴 수 있다. 콘솔에서 진행해보자.

 

 

Elastic Beanstalk 용어

• 애플리케이션

  • 복수의 환경으로 구성된 작업 공간.

• 환경

  • 앱이 실행되는 배포 환경. 각각의 환경은 서로 다른 ID와 접속 URL을 가진다. 개발, 릴리즈, 프로덕션 등 목적에 맞게 추가해서 사용할 수 있다.

• 인스턴스

  • 1개의 환경은 복수의 AWS EC2 인스턴스를 가질 수 있다. 인스턴스 유형은 필요한 성능에 맞춰 선택할 수 있다.

• 플랫폼

  • 운영체제, 웹 서버, 애플리케이션 서버 등 웹 애플리케이션 실행을 위한 구성 요소를 포함한다.

• 용량

  • 환경의 인스턴스가 1개 이상이면 자동으로 로드 밸런싱이 작동한다. 환경은 최소 1개에서 최대 10000개의 인스턴스를 가질 수 있다. 실제로 사용되는 인스턴스의 수는 사용자가 설정한 최소, 최대 인스턴스 수와 트리거에 기반을 둬서 자동으로 조절된다.

• 롤링 업데이트

  • 배포를 하면 기본적으로 모든 인스턴스를 한 번에 업데이트한다. 그런데 Elastic Beanstalk는 드롭인(drop-in) 업그레이드 프로세스를 사용하기 때문에 애플리케이션이 몇 초 정도 가동이 중지될 수 있다. 그래서 프로덕션 환경에서는 인스턴스를 나눠서 업데이트하는 방법이 권장된다. 한 번에 업데이트할 인스턴스의 수와 비율을 사용자가 직접 지정할 수 있다.

 

 

Beanstalk 환경 / 애플리케이션 생성

 

 

이름을 지정하고, 플랫폼을 지정하면 됩니다. 애플리케이션 코드는 그냥 기본값인 샘플 애플리케이션을 적용하겠습니다.

사용할 수 있는 플랫폼은 아래 같습니다.

 

 

 

이제 beanstalk에서 자동으로 환경을 구성해봅시다.

beanstalk에서는 환경 / 애플리케이션 / 애플리케이션 버전을 구분할 줄 알아야 합니다.

 

 

대략적으로 진행되는 방식을 보면

environment data 저장을 위한 S3 버킷 생성, EIP생성, EC2 생성 등이 이루어진 것을 볼 수 있습니다.

 

10: 30오후Added instance [i-06ed9a1f227dd5ce7] to your environment.

10: 30오후Environment health has transitioned from Pending to Ok. Initialization completed 44 seconds ago and took 2 minutes.

10: 30오후Successfully launched environment: Beanstalktesting-env

10: 30오후Application available at Beanstalktesting-env.eba-znsgeavm.ap-northeast-2.elasticbeanstalk.com.

10: 29오후Instance deployment completed successfully.

10: 29오후Instance deployment: You didn't specify a Node.js version in the 'package.json' file in your source bundle. The deployment didn't install a specific Node.js version.

10: 29오후Waiting for EC2 instances to launch. This may take a few minutes.

10: 28오후Environment health has transitioned to Pending. Initialization in progress (running for 21 seconds). There are no instances.

10: 28오후Created EIP: 3.34.241.53

10: 27오후Created security group named: awseb-e-ex5ukfxq2m-stack-AWSEBSecurityGroup-1V8NYZGK38GUM

10: 27오후Using elasticbeanstalk-ap-northeast-2-242966273429 as Amazon S3 storage bucket for environment data.

10: 27오후createEnvironment is starting.

 

공식문서에 따르면 beanstalk가 생성하는 리소스는 다음과 같습니다.

 

• EC2 인스턴스 – 선택한 플랫폼에서 웹 앱을 실행하도록 구성된 Amazon EC2 가상 머신입니다.

  특정 언어 버전, 프레임워크, 웹 컨테이너 또는 조합을 지원하도록 각 플랫폼마다 실행하는 소프트웨어, 구성 파일 및 스크립트 세트가 다릅니다. 대부분의 플랫폼에서는 웹 앱 앞의 웹 트래픽을 처리하고, 웹 앱으로 요청을 전달하고, 정적 자산을 제공하고, 액세스 및 오류 로그를 생성하는 역방향 프록시(리버스 프록시)로 Apache 또는 nginx를 사용합니다.

• 인스턴스 보안 그룹 – 포트 80에서 수신 트래픽을 허용하도록 구성된 Amazon EC2 보안 그룹입니다. 이 리소스를 통해 로드 밸런서의 HTTP 트래픽이 웹 앱을 실행하는 EC2 인스턴스에 도달할 수 있습니다. 기본적으로 다른 포트에서는 트래픽이 허용되지 않습니다.

• Amazon S3 버킷 – Elastic Beanstalk 사용 시 생성된 소스 코드, 로그 및 기타 결과물의 스토리지 위치입니다.

• Amazon CloudWatch 경보 – 환경의 인스턴스에 대한 로드를 모니터링하는 두 개의 CloudWatch 경보로, 로드가 너무 높거나 너무 낮은 경우 트리거됩니다. 경보가 트리거되면 이에 대한 응답으로 Auto Scaling 그룹이 확장 또는 축소됩니다.

• AWS CloudFormation 스택 – Elastic Beanstalk에서는 AWS CloudFormation을 사용하여 사용자 환경의 리소스를 시작하고 구성 변경 사항을 전파합니다. 리소스는 AWS CloudFormation 콘솔에서 볼 수 있는 템플릿에서 정의됩니다.

• 도메인 이름 – subdomain.region.elasticbeanstalk.com 형식으로 웹 앱으로 라우팅되는 도메인 이름입니다.

 

 

환경 설정이 끝난 후 배포된 주소를 확인할 수 있습니다.

 

 

여기서 안내된 위 주소로 접속해보면 다음 페이지와 같은 곳으로 접속할 수 있습니다.

(Beanstalktesting-env.eba-znsgeavm.ap-northeast-2.elasticbeanstalk.com.)

 

 

 

Beanstalk의 결과로 EC2에 인스턴스가 새로 생겼고 이 인스턴스는 생성된 EIP와 연결되어 있습니다. 설정에 따라 다른 리소스도 생성됩니다.

애플리케이션 버전과 로그 기록을 위한 S3 버킷도 생겼습니다.

 

 

 

Beanstalk 환경, 애플리케이션, 애플리케이션 버젼(S3) 삭제

 

위에서 생성된 EC2를 수동으로 지운다고 해도 Beanstalk에서 재생성합니다.

beanstalk로 생성된 내용을 삭제하기 위해서는 약간의 절차를 밟아야 합니다. (그래도 실제 서비스 인프라를 구축한 경우보다는 훨씬 빠릅니다.) 환경을 삭제한다고 해서 해당 환경에 의존하고 있는 애플리케이션과 버젼(S3)에 삭제되지는 않습니다.

 

EB 환경 종료 => EB 애플리케이션 버전(S3) 삭제 => EB 애플리케이션 삭제

 

이 순서로 삭제하는 게 품을 줄이는 일입니다.

 

환경 종료 => EIP 자동 삭제, EC2 삭제 등 기반 리소스는 자동 삭제됩니다.

 

 

 

애플리케이션 버전(S3) 삭제

 

 

🚨 주의 : 애플리케이션을 삭제하기 전에 애플리케이션 버전(S3)을 먼저 삭제해야 합니다. 그렇지 않으면 애플리케이션이 저장된 S3 버킷이 계속 남아있게 됩니다.

만약 애플리케이션 버전보다 애플리케이션을 먼저 삭제했다면 해당 버켓의 내용물을 전부 제거하고, 버켓 정책을 삭제한 다음데 S3를 삭제해주면 됩니다.

 

 

애플리케이션 삭제 => 위와 비슷하게, 종료를 해주면 됩니다.

 

 

 

 

 

 

참고한 글)

 

https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/GettingStarted.html

Elastic Beanstalk 사용 시작하기 - AWS Elastic Beanstalk

https://www.slideshare.net/awskorea/aws-elastic-beanstalk-aws-aws-devday2018

https://blog.rhostem.com/posts/2019-09-01-deploy-next-app-to-eb