1. Elastic Beanstalk

기존 구조의 한계점

지난주에 EC2, ALB, ASG를 배우며 기본적인 Web 3-tier architecture를 배웠다.
이 구조를 이용하여 웹 서버를 구축하면서 몇가지 아쉬운점이 있었다.

• 서버가 업데이트 된다면 ASG의 인스턴스에 반영하기 위해선 AMI를 다시 따서 교체해야한다.
• 동일한 구조의 또 다른 서버를 구축하려면 똑같은 구조 구축을 반복해야한다. (ALB Group, ASG Group 덕분에 좀 더 편하게 구축할 순 있긴 한것 같다)
• 로그를 만들기 위해 각 리소스별로 CloudWatch를 달아줘야 한다.
• 업데이트 후 이상이 생길 시 롤백을 어떻게 해야할지 모르겠다. (CodeDeploy를 통해 새 배포가 가능하다고 한다)
• 나와 같은 1인 개발자(초보)같은 경우 적용하는데 꽤 오랜시간이 필요하다

Elastic Beanstalk을 이용하면 위의 문제들을 손쉽게 해결할 수 있다.
(더 많은 문제점이 있을 수 있고, 내가 모르는 간단한 해결책들이 있을 순 있겠지만...)

Elastic Beanstalk란?

EC2, ASG, RDS등 AWS 리소스들을 조합하여 완성된 어플리케이션 플랫폼으로, PaaS(Platform as a Service)의 일종이다.
때문에, 복잡한 설정을 하지 않아도 오토 스케일링과 로드 밸런싱 기능, 버전 관리 등 콘솔에서 몇번의 클릭으로 처리가 가능하여 개발자들의 시간을 절약하고 불필요한 자원낭비가 줄어들게 된다.
또한, 실제 서비스를 제공하는 리소스가 아니기 때문에 사용 요금이 없다.

장점으로,

• 배포할 코드만 있으면 콘솔이나 CLI를 통해 빠르고 간단하게 필요한 기능들을 추가하여 배포가 가능하기 때문에, 개발자의 생산성을 높일 수 있다.
• 대부분의 자동화 플랫폼 툴들은 자원들을 직접 컨트롤 할 수 없지만, EB는 직접 컨트롤이 가능하다.
• S3에 로그들과 앱 버전을 기록하여 간편하게 롤백할 수 있다(!!)
• 다양한 어플리케이션 버전을 다양한 환경에서 배포 가능하다. (dev test, prod 등)

가 있다.

학습하면서 우리 서비스에 적용해볼만 하겠다라고 생각했던 가장 핵심은 코드레벨에만 집중할 수 있는 것과 로그들을 쉽게 저장할 수 있다는 두가지였다.
서비스가 크지 않고, 사용자도 많지 않다보니 많은 부분에서 공감할 순 없었지만, 위 두가지는 직접 체험해본 어려움이였던지라 더욱 공감 할 수 있었다.

(출처: https://www.slideshare.net/awskorea/aws-elastic-beanstalk-aws-aws-devday2018)

어플리케이션 배포

배포 모델

Elastic Beanstalk에서는 어플리케이션을 업로드하는 공간을 Application(이름이 같다)이라고 하고, 어플리케이션을 실행하는 플렛폼을 Enviroment라고 한다.

Application에서는 당연히 여러 버전을 가지고 관리할 수 있고, Enviroment도 역시 dev, prod, alpha등 여러 환경을 가지고 있을 수 있다.

여러 환경에서 내가 필요한 어플리케이션 버전을 다양하게 실행할 수 있으므로,
테스트 및 배포 등 환경 설정역시 편리하게 적용할 수 있다.

배포 정보

배포를 위해선
1. 어플리케이션 코드
2. 리전
3. 스택 타입(Node, Java, PHP 등.. + 커스텀도 가능)
4. 인스턴스 타입
5. ASG, ALB 설정여부
6. RDS 설정여부

가 필요하다.

위 정보들을 이용해서 콘솔, CLI, GIT을 이용하여 배포가 가능하다.

어플리케이션 업데이트

어플리케이션이 업데이트 될때, 인스턴스들이 한꺼번에 업데이트가 된다면 업데이트 진행중에 생기는 딜레이와 오류가 발생했을때에 대응하여 업데이트시 사용할 여러 전략들이 있고, 이를 배포 정책이라고 부른다.
(https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html)

1. All at Once
   단일 및 다중 인스턴스 업데이트시 한꺼번에 업데이트를 진행한다.
   다운타임이 생기므로 사용자가 없는 시간에 업데이트를 해야하는 단점이 있다.

2. Rolling
   사용자가 지정한 업데이트율에 따라 일부 인스턴스가 먼저 업데이트 된 후,
   업데이트가 끝난후에 나머지 인스턴스 업데이트가 실행된다.
   부분적인 업데이트로 진행되므로 다운타임이 없다.
   다만, 로드밸런서는 인스턴스를 구분하여 배분하지 않기 때문에 업데이트 중간에 사용자들이 서로 다른 버전의 어플리케이션을 경험할 수 있는 문제가 있다.

3. Rolling with additional batch
   Rolling과 유사하게 배포율을 설정하는데, 초기 업데이트가 기존의 인스턴스를 활용하지 않고 추가 인스턴스를 생성하여 테스팅 후 나머지 인스턴스를 업데이트하여 추가된 인스턴스와 합쳐지게 된다.

4. Immutable
   기존의 인스턴스를 업데이트하지 않고 완전히 새로운 인스턴스를 생성한다.
   롤백이 실행될시 새 인스턴스들만 종료하게 된다. (좀 더 학습이 필요..)

5. Blue/Green
   Immutable과 새로운 인스턴스를 생성한다는 점에선 유사하지만, Blue/Green은 아예 새로운 환경을 만들어 직접 기존 환경과 URL 스와이핑을 통해 수동으로 업데이트해준다.
   따라서, 이전 환경과 업데이트된 환경 두개가 실행중이고 이 덕분에 빠른 롤백 및 다운타임 없는 배포가 가능하다.

   각 정책들은 서로 장단점이 있기 때문에 각 서비스 성격에 맞춰서 업데이트 전략을 새울 필요가 있다.

   구축

   아직 학습중인지라 내일 직접 구현해보면서 느껴봐야겠다.
   구현할때는 샘플코드 테스트 -> 서버코드 단일 인스턴스 dev 환경 구축 -> 서버코드 prod 환경구축 순으로 진행해 볼것이다.