aws Beanstalk

 

이 아키텍처에 로드 밸런서가 있고 그게 사용자의 모든 요청을 받았습니다. 그런 다음에 다수의 가용성 영역과 오토 스케일링 그룹이 있습니다. 각각의 AZ에 EC2 인스턴스들이 배포되었어요 그리고 백엔드에는 예를 들어 데이터 서브넷이 있습니다. 읽기와 쓰기를 받는 RDS 데이터베이스가 있습니다. 읽기 레플리카 등등도 있습니다. 케싱 레이어가 필요하면 우린 ELastiCache를 써야 합니다. 이렇게 배포할 애플리케이션이 많고 그것들이 동일한 아키텍처를 따른다면 그것을 매번 다시 생성하려면 힘들 수 있습니다. 그럼 개발자로서 인프라를 인프라를 관리하고 코드를 배포하기가 어려워집니다.

 

 AWS Beanstalk 

- Beanstalk는 개발자 입장에서 애플리케이션을 AWS에 배포합니다.

- 하나의 인스페이스에서 우리가 앞에서 본 EC2, ASG, ELB, RDS 등 모든 컴포넌트를 재사용한다는 개념입니다.

- 모든 걸 배포하는 관리형 서비스입니다.

- Beanstalk가 용량 프로비저닝, 로드 밸런서 설정 스케일링, 애플리케이션 상태 모니터링, 인스턴스 설정 등을 처리하게 됩니다. 

- 그럼 개발자는 코드 자체만 담당하면 됩니다.

- Beanstalk는 서비스 자체는 무료이지만 Beanstalk가 활용하는 인스턴스나 ASG, ELB등에 대해서는 비용을 지불해야합니다.

- Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker 등 다양한 언어와 플랫폼을 지원하여 다양한 애플리케이션을 호스팅할 수 있습니다.

 

Beanstalk 웹 티어 

 

로드 밸런서가 있고 그게 트래픽을 오토 스케일링 그룹에 전송하고 거기엔 웹 서버가 될 다수가 EC2 인스턴스가 있는 전통적인 아키텍처입니다. 이게 Beanstalk 1번 아키텍처입니다.

 

 

Beanstalk을 사용하는 2번 아키텍처는 워커 환경을 중심으로 이루어져 있습니다. 즉 여기서는 EC2 인스턴스에 직접적으로 액세스하는 클라이언트가 없어요. 우리는 메시지 대기열인 SQS Queue를 사용할 거고요, 메시지는 SQS Queue로 전송되고 EC2 인스턴스는 워커가 될 겁니다. 왜냐면 그것들이 메시지를 SQS Queue에서 가져와서 처리하게 되기 때문입니다.

그리고 이 경우에 워커 환경은 SQS 메시지의 개수에 따라 스케일링이 됩니다. 그래서 메시지가 많으면 EC2 인스턴스가 많아집니다. 웹 환경이 메시지를 워커 환경의 SQS Queue에 푸시하게 함으로써 웹 환경과 워커 환경을 하나로 모을 수 있다는 점입니다.

 

Beanstalk 배포 모드

 

 

싱글 인스턴스 입니다. 개발용으로 아주 좋습니다. 이 경우에 하나의 EC2 인스턴스를 가질 겁니다. 그게 탄력적 IP를 가집니다. 그리고 RDS 데이터베이스 등을 시작할 수도 있습니다. 하지만 모두 탄력적 IP를 가진 하나의 인스턴스를 기반으로 합니다. 

 

 

하지만 실제 Elastic Beanstalk 모드로 스케일링을 하고 싶은면 로드 밸런서를 사용하는 고가용성을 선택할 겁니다. 프로덕션 환경에 적합합니다. 그 경우엔 로드 밸런서가 있어서 로드를 다수의 EC2 인스턴스에 걸쳐 분산시킬 수 있습니다. 그것 들이 오토 스케일링 그룹과 다수의 가용성 영역에 맞춰 관리됩니다. 그리고 마지막으로 역시 멀티 AZ이고 마스터와 스탠바이가 있는 RDS 데이터베이스를 가질 수도 있습니다.