왜 쓰는가?
- 코드의 배포, 프로비저닝, 관리가 복잡하여
- 서버, DB, 로드밸런서, 방화벽, 복잡한 네트워크를 구성하고 관리하는데 시간 걸림
- 애플리케이션 스케일 인/아웃을 어케해야하는지?
온프레미스보다 클라우드가 간단한건 맞지만, 더 간단화해보자!
서비스 코드에만 집중하자!!
장점
- 빠르고 간단
- 개발자 생산성 증가
- 완전한 자원 제어
- 사용에 따른 추가 요금이 없음 ( 사용한 만큼만 지불 )
AWS Elastic Beanstalk
- 정의: 웹 서비스를 배포하고, 확장하고, 관리하는데 있어 쉽고 빠르게 할 수 있도록 돕는 완전 관리형 서비스
- 사용자는 서비스 코드에만 집중
인프라스트럭쳐 스택 구성 과정
- 로드밸런서 구성
- 로드밸런서에 퍼블릭IP를 할당해서 여기서 접근
- 따라서 우리는 로드밸런서에 접근하여 로드밸런서가 연결해주는 EC2에 연결하는 것
- Beanstalk의 퍼블릭 주소는 로드밸런서 주소임
- 오토 스케일링 그룹 설정
- 오토 스케일링 그룹에서 인스턴스들을 시작
- 모든 구성 요소들을 하나로 엮음
- DNS설정을 통해 외부에 publish
- 로그와 앱 버전들에 대한 설정을 모두 S3에 저장
- 블록 스토리지는 한개의 인스턴스에 종속적이니까 전체에 대한 로그를 저장하는데는 무리
- 파일 스토리지는 비용이 너무 비쌈
- 따라서 객체 스토리지에 저장 ( 컴퓨터랑 관련 없이 그냥 파일만 올리면 되기 떄문에 )
- 주의!: 여러 버전을 올리면 그 용량만큼 비용이 지불됨 -> 필요없는 버전은 주기적으로 삭제해줘야함
서비스 배포에 필요한 정보들
서비스 배포 과정
- eb deploy를 입력하면 현재 폴더의 모든 것을 압축해서 올림
- 하위 폴더에 .git이 존재한다면 git integration작업을 또 진행
eb deploy를 하면 버전별로 S3 환경에 올라감
애플리케이션 업데이트 배포 정책
All at once
- 모든 인스턴스에 동시에 새 버전 배포
- 하지만, 이러면 모든 인스턴스가 사용 불가가 되어 추천하지 않음
Rolling
- 배치 단위로 새 버전 배포
- 하지만, 이러먼 어떤 사용자는 v2를 보게되고 어떤 사용자는 v1을 볼 수 있음
- 이러면 케파가 50% 정도로 나옴 ( 배치 크기 만큼 인스턴스 접근을 못함 )
Rolling with additional batch
- 배치 단위로 새 버전 배포, +1 추가 배치
- 배치 크기만큼 새로운 인스턴스를 생성하여 케파 100%를 유지
Immutable
새로운 인스턴스 그룹에 배포
Blue/Green
- 새로운 환경에서 테스트해보고 잘 되면, url을 바꾸는 형태로 배포
- 장점
- 이전 환경이 여전히 실행중이므로 빠른 롤백 가능
- 다운타임 없이 배포
- 단점
- 새로운 환경 생성으로 인한 느린 배치
- RDS까지 구축되어 있다면 RDS까지 복제해야할 필요 있음
