Typical architecture: Web App 3-tier
- 유저로부터 모든 요청을 접수하는 로드 밸런서,
다수의 AZ를 가진 자동 확장 그룹,
각각의 AZ에서 실행되는 EC2 인스턴스,
백엔드에는 RDS 데이터베이스를 위한 데이터 서브넷있어 읽기와 쓰기를 받아들임,
읽기 전용 복제본이 있음,
캐싱 계층을 위한 ElastiCache
를 가진 아키텍처
Developer problems on AWS
- 이 아키텍처를 매번 다시 생성하는 것은 힘드며 개발자로부터 인프라를 관리하고 코드를 배포하는 것은 복잡함
- 데이터베이스와 로드밸런서 등의 모든 구성을 하고 싶지 않음
- 모든 것을 확장하도록 해야 함
대부분의 웹 애플리케이션은 로드 밸런서와 자동 확장 그룹이 있는 동일한 아키텍처를 가짐 - 개발자는 단지 코드가 잘 실행되는지만 알고 싶고 다른 것들에 대해서는 걱정하고 싶지 않음
- 여러 프로그래밍 언어로 개발할 때 여러 다른 애플리케이션 환경이 있다면 애플리케이션은 단 하나의 방법으로만 배포하길 원함
- 이 때 필요한 것이 Beanstalk
Elastic Beanstalk – Overview
- Beanstalk는 AWS에서 애플리케이션을 배포하는 개발자 중심의 관점으로
단 하나의 인터페이스로 EC2, ASG, ELB, RDS 등의 모든 구성 요소를 재사용하는 것 - 즉, 모든 것을 배포하는 관리 서비스로 용량 프로비저닝, 로드 밸런서의 구성, 확장, 애플리케이션 상태 모니터링, 인스턴스 구성
등을 처리해 주므로 개발자는 단지 코드 자체에만 신경을 쓰면 됨 - 각각의 구성요소를 Beanstalk에서는 하나의 인터페이스로 통합되어 있음
- Beanstalk는 애플리케이션 업데이트 방법 또한 가지고 있음
- Beanstalk 서비스 자체는 무료지만 Beanstalk가 활용할 기본 인스턴스나 ASG, ELB 등에 대한 비용을 지불해야 함
Elastic Beanstalk – Components
- 애플리케이션
Beanstalk의 구성 요소로 이루어져 있으며 이는 환경, 버전, 구성을 가진 Beanstalk 구성 요소들의 묶음으로 구성되어 있음 - 애플리케이션 버전
애플리케이션 버전은 애플리케이션 코드의 반복으로 버전 1, 2, 3 등이 존재 - 환경
특정 애플리케이션 버전을 실행하는 리소스의 모음으로 환경은 오직 하나의 버전만 존재하며
환경 내에서 애플리케이션 버전을 업데이트할 수 있음 (버전1 → 버전2)
Beanstalk에서는 서로 다른 두 개의 티어를 가질 수 있으며 웹 서버 환경 티어와 작업자 환경 티어가 있음
또한 dev, test, prod 등 어떤 환경이든 다수의 환경을 생성할 수 있음
- Beanstalk 프로세스
1) 애플리케이션 생성
2) 버전 업로드
3) 환경 실행
4) 환경 수명 주기를 관리
5) 새로운 버전을 업로드하여 버전을 업데이트하고 환경 내에서 새로운 버전을 다시 실행하여 애플리케이션 스택을 업데이트
Elastic Beanstalk – Supported Platforms
- Beanstalk는 여러 프로그래밍 언어를 지원
Go, Java SE, Java with Tomcat, .NET Core on Linux , .NET on Windows Server, Node.js, PHP, Python, Ruby,
Packer Builder, Single Container Docker, Multi-container Docker, Preconfigured Docker 등 - 원하는 프로그래밍 언어가 없다면 사용자 지정 플랫폼을 만들 수 있는 고급 기능이 존재하므로
Beanstalk에서는 거의 모든 것을 배포할 수 있음
Web Server Tier vs. Worker Tier
- 웹 환경 (웹 서버 티어)
전통적인 방식의 아키텍처로 로드밸런서가 있고
웹 서버가 될 다수의 EC2 인스턴스가 있는 자동 확장 그룹으로 트래픽을 전송하는 Beanstalk의 1번 아키텍처
- 작업자 환경 (작업자 티어)
클라이언트가 직접 EC2 인스턴스에 접근하지 않고 메시지 대기열인 SQS 대기열을 사용하여 메시지를 전송하며
EC2 인스턴스가 작업자가 되어 SQS 대기열로부터 메시지를 가져와서 처리하는 Beanstalk의 2번 아키텍처
이 경우 작업자 환경이 SQS 메시지 숫자에 따라 확장되며 메시지가 많을수록 EC2 인스턴스가 많아짐
이로인해 웹 환경이 작업자 환경의 SQS 대기열로 메시지를 푸시함으로써 웹 환경과 작업자 환경이 함께 할 수 있게 됨
<Beanstalk 실습>
- Elastic Beanstalk로 애플리케이션 배포
다양한 플랫폼 중 Node.js를 사용하며 내 코드를 업로드해도 되지만 Sample application을 선택하여 DemoBeanstalk 생성
Elastic Beanstalk에서 설정할 수 있는 옵션의 종류를 보기 위해 Configure more opions를 클릭
프리셋을 통해 Elastic Beanstalk에서 몇몇 형식의 솔루션 아키텍처를 실행할 수 있음
예를 들어 프리 티어에 적합한 단일 인스턴스를 사용할 수 있으며 스팟 인스턴스를 사용하는 단일 인스턴스도 존재
또한 애플리케이션과 로드 밸런서를 사용하는 고가용성, 스팟 및 온디맨드 인스턴스를 사용하는 고가용성, 커스텀 구성이 존재
프리 티어에 적합한 단일 인스턴스를 사용하며 플랫폼은 Node.js 12로 하면 Software에서 이 모든 것을 설정할 수 있고
Instances에서 원하는 인스턴스 유형을 정할 수 있으며, Capacity에는 온디맨드 인스턴스인 t2.micro가 존재
단일 인스턴스를 사용 중이기 때문에 로드 밸런서는 존재하지 않음
- 애플리케이션 확인
애플리케이션이 녹색으로 실행 중이면 URL을 클릭하여 실행된 애플리케이션을 볼 수 있음
그러므로 첫 번째 Beanstalk Node.js 애플리케이션이 클라우드에 실행되게 됨
- Elastic Beanstalk에 의해 무엇이 실행되었는지 확인
EC2 서비스에 들어가면 Beanstalk에 의해 하나의 인스턴스가 실행된 것을 볼 수 있으며
태그 항목으로 가면 CloudFormation 태그와 Elastic Beanstalk 태그를 볼 수 있음
또한 오토 스케일링 그룹에 의해 관리되고 있음을 알 수 있으므로
오토 스케일링 그룹에 가면 ASG가 생성되어 희망 용량, 최소 용량, 최대 용량이 1인 것을 볼 수 있으며
오토 스케일링 그룹의 인스턴스 관리에서도 EC2 인스턴스를 볼 수 있음
또한 프리 티어에 적합한 단일 인스턴스를 선택했기 때문에 Elastic IPs에 들어가면 이를 위해 생성된 탄력적 IP를 찾을 수 있음
그리고 보안 그룹으로 가면 보안 그룹이 생성된 것도 볼 수 있으며 인바운드 규칙이 80번 포트의 HTTP를 허용하므로
이를 통해 Elastic Beanstalk의 애플리케이션에 접근할 수 있는 것임
만약 로드 밸런서를 생성했다면 로드 밸런서 서비스에서 이를 발견할 수 있음
'Cloud > AWS' 카테고리의 다른 글
[SAA] S3 버전 관리 (0) | 2022.03.21 |
---|---|
[SAA] S3 버킷 및 객체 (0) | 2022.03.21 |
[SAA] 애플리케이션을 빠르게 인스턴스화 하기 (0) | 2022.03.21 |
[SAA] MyWordPress.com (0) | 2022.03.20 |
[SAA] MyClothes.com (0) | 2022.03.20 |