로드 균형 조정, 모니터링 및 자동 크기 조정과 같은 모든 기능은 분명 장점입니다.
그러나 이런 식으로 생각하면됩니다. 진정한 Platform as a Service (PAAS)에서 목표는 애플리케이션을 플랫폼과 분리하는 것입니다. 개발자는 응용 프로그램에 대해서만 걱정할 수 있습니다. 플랫폼이 귀하에게 대여됩니다. 플랫폼 "인스턴스"는 자동으로 업데이트, 관리, 확장, 균형 조정 등을 수행합니다. 방금 WAR 파일을 업로드하면 이론적으로는 작동합니다.
EC2 자체는 PAAS가 아닙니다. IAAS (Infrastructure as a Service)와 같습니다. 여전히 서버 인스턴스를 관리하고 소프트웨어를 설치하고 업데이트를 유지해야합니다.
탄성 Beanstalk는 PAAS 시스템입니다. 따라서 많은 사람들 중에 App Engine과 Azure이 있습니다.
실제 PAAS 시스템에서 DBMS는 웹 응용 프로그램 서버와 별개의 구성 요소입니다. 그 이유는 명백합니다 : 애플리케이션 서버에 사용되는 인스턴스에는 DBMS를 설치할 수 없습니다. 트래픽을 기반으로 인스턴스가 생성되고 파손되므로 DBMS가 손실 될 수 있습니다! DBMS와 응용 프로그램 서버를 동일한 컴퓨터/인스턴스에 두는 것은 일반적으로 좋은 생각이 아닙니다.
PAAS 시스템에서 DBMS는 별도의 서비스입니다. Amazon의 경우 Amazon RDS입니다. Elastic Beanstalk과 마찬가지로 응용 프로그램 서버에 대해 걱정할 필요가없고 RDS를 사용하여 WAR 파일을 업로드하면 DBMS에 대해 걱정할 필요가없고 데이터베이스를 배포하기 만하면됩니다.
Elastic Beanstalk와 RDS는 특히 대기 시간이 매우 짧은 동일한 가용성 영역에 배포 할 때 매우 잘 작동합니다.
마지막으로 Elastic Beanstalk을 사용하면 배치 된 자원 (EC2 인스턴스 및로드 밸런서) 이상의 비용이 들지 않습니다. 그러나 RDS는 저렴하지 않으며 응용 프로그램 서버와 DBMS 모두에 단일 EC2 인스턴스를 사용하는 것보다 훨씬 비쌉니다.
멋지게 넣습니다. 추가 작업 : 사용자 정의 AMI를 지정하여 각 인스턴스 생성의 기준으로 사용할 수 있습니다. 예를 들어 필요한 모든 구성 및 응용 프로그램으로 Apache 이미지를 사용자 정의하고이를 기본 AMI로 사용할 수 있습니다 (Beanstalk 환경 구성에 사용자 정의 AMI ID 필드가 있음) 그래도 런타임 생성 데이터는 실제로 삭제됩니다 모든 인스턴스 종료시 (로드 밸런서가이를 수행합니다!). –
Elastic Beanstalk이 배치 된 각 환경에 대한로드 밸런서를 생성한다는 사실이 경각심을 사로 잡았습니다. 로드 밸런서는 실행에 비용이 많이 들지 않지만 마이크로 인스턴스와 거의 동일한 비용입니다. –
@KenLiu, Load Balancer는 마이크로 인스턴스보다 강력합니다. – BigSack