Elastic Beanstalk
배포할 애플리케이션이 너무 많고 이들이 동일한 아키텍처를 따를 경우
매번 이를 다시 생성하는 것은 복잡할 수 있다.
인프라를 다 설정해야 하고
코드를 넣어야 하며, 데이터베이스를 구축하고 로드밸런서를 연결 시키며
오토 스케일링을 설정하는 모든 과정이 복잡하다.
대부분의 웹, 앱은 동일한 아키텍쳐를 가진다 (ALB + ASG)
다양한 프로그래밍 언어로 개발하고 다양한 환경을 사용하는 경우
환경에 맞게 배포를 여러번 진행해야 한다.
여기서 앨라스틱 빈스톡을 사용할 수 있다.
- 빈스톡은 애플리케이션을 배포하는데 있어 개발자 중심의 관점을 제공한다.
- 빈스톡은 하나의 인터페이스에서 EC2, ASG, ELB, RDS와 같이
모든 구성 요소를 다룰 수 있는 것이다. - 위의 모든 요소를 자동으로 배포해주는 관리형 서비스이다.
- 자동으로 용량 예약, 로드 밸런서 구성, 자동 확장, 모니터링,
인스턴스 구성 등을 처리한다. - 우리가 신경 쓸 것은 코드밖에 없다.
- 자동으로 용량 예약, 로드 밸런서 구성, 자동 확장, 모니터링,
- 각 구성 요소의 설정에 대한 제어는 여전히 가능하다.
- 빈스톡은 무료이나, 내부에서 사용되는 EC2, ELB 등의 가격은 지불된다.
빈스톡 구성요소
- 애플리케이션
- 여러 구성 요소로 이뤄진 하나의 프로젝트 또는 시스템을 의미한다.
- 애플리케이션 버전
- 애플리케이션의 버전을 의미한다.
- 환경: 애플리케이션이 실제로 실행되는 곳이다. 서버와 리소스들이 모여있는 환경을 의미한다.
환경 내에서는 한 번에 하나의 애플리케이션 버전만 사용할 수 있다.- environment 내에서 애플리케이션 버전을 업데이트할 수 있다.
- 개발 환경, 테스트 환경, 배포 환경 등 여러 환경을 생성할 수 있다.
- 빈스톡에서 제공하는 환경은 크게 두 종류로 나뉜다.
- 웹 서버 environment tier와 worker environment tier가 존재한다.
- 만약 빈스톡에서 데이터베이스를 사용하기로 했다면
데이터베이스의 생명주기는 환경과 연결된다.
환경이 삭제되면 데이터베이스도 삭제된다.
빈스톡에서 지원 언어
Web Server Tier란?
- 로드 밸런서가 있는 위치를 알고 있는 전통적인 아키텍쳐로
로드 밸런서가 트래픽을 오토 스케일링 그룹으로 보내고
여기에 여러 EC2 인스턴스가 포함되어 웹 서버 역할을 하는 구조다
Worker Tier
- EC2 인스턴스에 직접 액세스하는 클라이언트가 없는 구조다.
- 큐를 사용하며, 큐에 들어온 요청이 SQS message에 들어가고
SQS message의 메세지를 EC2에서 가져가 처리한다. - 큐의 메세지 수에 따라 자동으로 스케일링 된다.
웹 환경과 작업자 환경을 함께 배치해서 사용할 수도 있다.
빈스톡 배포 모드
두 가지의 배포 모드가 있다
- 개발 목적에 적합한 싱글 인스턴스
- elastic ip를 가진 EC2 인스턴스가 하나 존재한다.
- RDS 데이터 베이스를 생성할수도 있지만
이는 모두 하나의 인스턴스를 기반으로 한다.
- 로드 밸런서를 사용하는 고 가용성 모드
- 실제 운영 환경에 적합하다.
- ALB를 통해 부하 분산이 이뤄지며
- 마스터와 스탠바이 인스턴스를 가진 다중 AZ 데이터베이스를 가질 수도 있다.
빈스톡에서 애플리케이션을 업데이트할 때 사용할 수 있는 배포 옵션
- All at once - 모든 인스턴스를 한 번에 배포한다. 가장 빠르지만 인스턴스가 업데이트 되는 동안
서비스가 잠시 중지되어 다운타임이 발생한다. - Rolling - 버킷이라는 인스턴스 묶음 단위로 동시에 업데이트하고, 첫 번째 버킷의 상태가 괜찮으면
다음 버킷을 업데이트한다. - Rolling with additional batches: 롤링 옵션과 같지만 새 인스턴스를 생성하여
새 인스턴스들에 대해서 업데이트를 하는 것이다. (old 인스턴스는 건드리지 않으므로 같은 서비스 상태를 유지할 수 있다.) - immutable: 새로운 인스턴스에 애플리케이션을 배포한 후, 문제가 없으면 기존 인스턴스와 교체한다.
안전하지만 시간이 오래걸릴 수 있다. - Blue Green: 새로운 버전의 애플리케이션을 별도의 환경 (그린)에 배포한 후 분제가 없으면 전환한다.
- Traffic Splitting: 트래픽을 새 버전과 기존 버전으로 분할하여 약간의 트래픽을 새 버전에 보낸 후
문제가 없다면 교체한다.
All At Once
- 모든 인스턴스를 실행 중지한다.
- 그리고 새로운 버전2 를 실행한다.
- 가장 빠르다.
- 다운타임이 발생한다.
- 개발 환경에 적합하다.
- 추가 요금이 없다.
Rolling
- 다른 버전이 동시에 실행된다.
- 애플리케이션이 전체 용량을 다 사용하지 못한다.
- 추가 요금이 없다.
- 인스턴스를 업그레이드 하는데 시간이 오래 걸린다.
Rolling with additional batches
- 애플리케이션이 전체 용량을 다 사용한다.
- 약간의 추가 요금이 있다.
- 추가된 배치는 배포의 마지막 단계에서 제거된다.
- 배포가 오래 걸린다.
- 두 가지 버전이 동시에 실행된다.
- prod 환경을 다루는데 적합하다.
Immutable
- 다운타임이 없다.
- 새 버전의 코드가 새 인스턴스에 배포된다.
- 해당 인스턴스는 임시 ASG에 연결된다.
- 비용이 많이 들고 용량을 두 배로 쓰게 된다.
- 배포시간이 가장 긴 옵션이다.
- 실패 시 빠른 롤백을 제공한다.
- 실패 시 그냥 ASG를 종료하기만 하면 되기 때문이다.
- 조금 더 많은 비용을 부담할 수 있다면 prod 환경에서 훌륭한 선택이다.
Blue / Green
- 앨라스틱 빈스톡이 직접 제공하는 기능은 아니다.
- 다운타임이 없고 더 많은 테스트를 가능하게 한다.
- 빈스톡을 하나 더 만들고 그곳에 새 버전을 배포하는 방식이다.
- 이전의 모든 배포 전략은 같은 환경에서 이뤄지는 반면
이 전략은 새 환경을 생성한다. - 새 그린 환경이 테스트 되고 문제 발생 시 롤백된다.
- route53 등을 사용해 트래픽이 두 방향으로 흐르는 것을 제어할 수 있다.
- 가중치 기반 정책을 설정하고 약간의 트래픽을 스테이징 환경으로 보내
테스트를 할 수도 있다.
- 가중치 기반 정책을 설정하고 약간의 트래픽을 스테이징 환경으로 보내
- 테스트가 끝나면 콘솔에서 swqp url을 통해 간단하게 url 변경이 가능하다.
- 기존의 블루 버전은 종료한다.
빈스톡에서 제공하는 기능이 아니기 때문에 수작업이 많이 필요하다.
Traffic Splitting
- 카나리아 테스트에 사용된다.
- 새 버전의 애플리케이션이 같은 용량의 임시 ASG에 배포된다.
- 적은 양의 트래픽이 임시 ASG에 보내진다.
- 임시 ASG의 상태가 모니터링 된다.
- 뭔가 잘못되면 롤백시킨다.
- 다운타임이 없다.
- 잘못된게 없으면 새 인스턴스가 임시 ASG에서 메인 ASG로 이동한다
- 모든 과정이 자동화 돼있고, 블루 그린의 업그레이드 버전이다.
Elastic Beanstalk CLI
- CLI로 빈스톡이 훨씬 쉽게 실행되도록 도와준다.
- 다양한 커맨드가 있다
- 개발 파이프라인을 자동화 하려면 EB CLI 사용이 적합하다.
Beanstalk Deployment process
- 종속성을 설명해야 한다.
- requirements.txt
- 모든 코드를 zip 파일로 패키징한다.
- 콘솔에 zip 파일을 업로드한다.
- 새 버전이 업로드 되면 콘솔이나 CLI를 통해 배포할 수 있다.
- zip 파일을 빈스톡에 업로드하면 S3에 업로드 되고 빈스톡 인터페이스에서 S3를 참조하여 가져오게 된다.
- zip 파일을 각 EC2 인스턴스에 배포하고 종속성을 해결하면 애플리케이션이 실행된다.
- 시험에 안 나오니까 이런게 있다 정도만 알아둬라
Beanstalk Lifecycle Policy
- 빈스톡에는 최대 1000개의 애플리케이션 버전을 저장할 수 있다.
- 옛날 버전을 지우지 않는다면 더 이상 새 버전을 배포할 수 없다.
- 수명주기 정책을 통해 오래된 버전을 삭제하자
- 시간을 기준으로할 수도 있고
- 공간을 기반으로도 할 수 있다.
- 현재 환경에서 사용하는 버전은 삭제되지 않는다.
- S3에서는 소스가 삭제되지 않도록 설정할 수도 있다.
- 나중에 다시 사용할 수도 있으므로
Elastic Beanstalk Extensions
- 애플리케이션의 배포 및 실행을 더 세밀하게 제어하기 위해 사용하는 기능으로
설정 파일을 포함시켜 설정을 정의할 수 있다. - zip 파일을 생성할 때 설정 파일을 포함시켜야 한다.
- 확장 파일의 모든 매개변수는 UI에서 구성하거나 파일에 코드로 작성할 수 있다.
- requirements
- 모든 설정파일이 ,ebextensions/라는 폴더에 들어가야 한다.
- yaml이나 json 형식이어야 한다.
- 파일의 확장자는 .config 여야 한다.
- option_settings를 사용해 기본값을 수정할 수 있다.
- 리소스를 추가할 수도 있다. RDS, 캐시, DynamoDb 등등 ,,
이들은 빈스톡 콘솔에서 설정할 수 없는 것들이다.
- EB 확장에서 관리되는 모든 것 들은 환경이 삭제되면 다 같이 사라진다.
이렇게 ebextensions 안에 .config 파일로 구성해야 한다.
이와 같이 DB와 관련된 매개변수를 설정하여 DB를 사용할 수도 있다.
Beanstalk Under the Hood
- 빈스톡의 여러 기능은 Cloudformation을 기반으로 하고 있다.
- 클라우드 포메이션은 다른 AWS 서비스를 공급해주는 서비스다.
- 앞서 살펴본 .ebextesntion 폴더에서 클라우드포메이션 리소스를 정의하면
AWS의 여러가지 서비스를 사용할 수 있다.- 캐시, 버킷, 등등
Beanstalk Cloning
- 기존에 만들어둔 환경을 똑같이 복제할 수 있는 기능이다.
- 배포 버전이 있는 경우에 유용하다
- 동일한 설정으로 테스트 버전을 배포할 수도 있다.
- 원래 환경의 모든 리소스와 설정은 그대로 이전된다
- 로드밸런서 타입
- RDS 데이터베이스 타입 (내부의 데이터는 보존되지 않는다)
- 한경변수
- 복제 이후 설정을 변경할 수도 있다.
Beanstalk Migration: loadBalancer
- 빈스톡 환경을 한 번 만들고 나면
ELB 유형은 변경이 불가능하고, 구성만 바꿀 수 있다.- ALB에서 NLB로 변경 불가
- 따라서 로드밸런서를 변경하고 싶으면 다음과 같은 단계를 밟아야 한다.
- 동일한 구성으로 새 환경을 생성한다. (로드밸런서만 제외하고)
당연히 로드밸런서를 제외하고 동일한 구성을 만들어야하기 때문에 복제는 사용 못 한다. - 새 환경의 애플리케이션을 배포한다.
- 이전 환경으로 가던 트래픽을 새 환경으로 변경한다.
CNAME swap 혹은 route53 업데이트
- 동일한 구성으로 새 환경을 생성한다. (로드밸런서만 제외하고)
- 그냥 동일한 구성으로 새로 만들어서 로드밸런서만 바꾸라는 얘기다
RDS with Beanstalk
- RDS는 빈스톡을 이용해서 프로비저닝 가능하다.
- dev/ test 환경에서 유용하다
- 그러나 prod 환경에서는 유용하지 못 하다
- 이유는 데이터베이스의 수명 주기가 빈스톡환경의 수명 주기 와 연결돼 있기 때문이다.
- prod 환경에서는 RDS를 빈스톡 환경과 분리하고 환경 변수 등을 이용하여
참조하는게 제일 좋다.
그렇다면 이미 빈스톡 스택에 존재하는 RDS를 분리할 수 있을까?
- 먼저 문제가 발생할 경우에 대비해 스냅샷을 만들어 둔다.
- RDS 콘솔로 이동하여 데이터베이스가 삭제되지 않도록 보호한다.
- 새로운 빈스톡 환경을 생성하는데 이번에는 RDS를 제외하고 만든다.
- 환경변수 등을 활용하여 기존의 환경에 존재하던 RDS와 새로운 빈스톡 환경을 연결시킨다.
- Cname swqp이나 route53을 활용해 트래픽을 새 환경으로 변경한다.
- 이제 오래된 빈스톡 환경을 삭제한다. (RDS 삭제 보호를 했으니 RDS는 그대로 유지된다.)
- 아마 RDS 때문에 기존의 빈스톡 환경 삭제에 실패할 것이다.
이 때는 클라우드 포메이션으로 이동해 스택을 삭제하여 환경을 삭제한다.
