2012-02-01 6 views
101

일반적인 Java 웹 응용 프로그램에 대해 EC2 인스턴스를 만들고 SQL Server를 설정하고 배포 등을 통해 Elastic Beanstalk을 사용하면 얻을 수있는 이점은 무엇입니까? 로드 밸런싱, 모니터링 및 자동 확장이 유일한 이점입니까?Amazon Elastic Beanstalk 대 수동 배포

데이터베이스를 사용하는 웹 응용 프로그램의 경우 EC2 인스턴스 자체에 데이터베이스를 설치했다고 가정합니다. Autoscalling이 발생하면 새로 생성 된 인스턴스에서 데이터베이스가 생성되거나 마스터 인스턴스에서 생성 한 데이터베이스에 액세스하게됩니다 ... 자동 확장이 수행 될 때 복제본 만 생성하면 인스턴스간에 데이터 동기화가 어떻게 발생합니까?

답변

128

로드 균형 조정, 모니터링 및 자동 크기 조정과 같은 모든 기능은 분명 장점입니다.

그러나 이런 식으로 생각하면됩니다. 진정한 Platform as a Service (PAAS)에서 목표는 애플리케이션을 플랫폼과 분리하는 것입니다. 개발자는 응용 프로그램에 대해서만 걱정할 수 있습니다. 플랫폼이 귀하에게 대여됩니다. 플랫폼 "인스턴스"는 자동으로 업데이트, 관리, 확장, 균형 조정 등을 수행합니다. 방금 WAR 파일을 업로드하면 이론적으로는 작동합니다.

EC2 자체는 PAAS가 아닙니다. IAAS (Infrastructure as a Service)와 같습니다. 여전히 서버 인스턴스를 관리하고 소프트웨어를 설치하고 업데이트를 유지해야합니다.

탄성 Beanstalk는 PAAS 시스템입니다. 따라서 많은 사람들 중에 App EngineAzure이 있습니다.

실제 PAAS 시스템에서 DBMS는 웹 응용 프로그램 서버와 별개의 구성 요소입니다. 그 이유는 명백합니다 : 애플리케이션 서버에 사용되는 인스턴스에는 DBMS를 설치할 수 없습니다. 트래픽을 기반으로 인스턴스가 생성되고 파손되므로 DBMS가 손실 될 수 있습니다! DBMS와 응용 프로그램 서버를 동일한 컴퓨터/인스턴스에 두는 것은 일반적으로 좋은 생각이 아닙니다.

PAAS 시스템에서 DBMS는 별도의 서비스입니다. Amazon의 경우 Amazon RDS입니다. Elastic Beanstalk과 마찬가지로 응용 프로그램 서버에 대해 걱정할 필요가없고 RDS를 사용하여 WAR 파일을 업로드하면 DBMS에 대해 걱정할 필요가없고 데이터베이스를 배포하기 만하면됩니다.

Elastic Beanstalk와 RDS는 특히 대기 시간이 매우 짧은 동일한 가용성 영역에 배포 할 때 매우 잘 작동합니다.

마지막으로 Elastic Beanstalk을 사용하면 배치 된 자원 (EC2 인스턴스 및로드 밸런서) 이상의 비용이 들지 않습니다. 그러나 RDS는 저렴하지 않으며 응용 프로그램 서버와 DBMS 모두에 단일 EC2 인스턴스를 사용하는 것보다 훨씬 비쌉니다.

+3

멋지게 넣습니다. 추가 작업 : 사용자 정의 AMI를 지정하여 각 인스턴스 생성의 기준으로 사용할 수 있습니다. 예를 들어 필요한 모든 구성 및 응용 프로그램으로 Apache 이미지를 사용자 정의하고이를 기본 AMI로 사용할 수 있습니다 (Beanstalk 환경 구성에 사용자 정의 AMI ID 필드가 있음) 그래도 런타임 생성 데이터는 실제로 삭제됩니다 모든 인스턴스 종료시 (로드 밸런서가이를 수행합니다!). –

+1

Elastic Beanstalk이 배치 된 각 환경에 대한로드 밸런서를 생성한다는 사실이 경각심을 사로 잡았습니다. 로드 밸런서는 실행에 비용이 많이 들지 않지만 마이크로 인스턴스와 거의 동일한 비용입니다. –

+0

@KenLiu, Load Balancer는 마이크로 인스턴스보다 강력합니다. – BigSack

34

Elastic Beanstalk은로드 균형 조정, 모니터링 및 자동 확장 그 이상을 수행합니다.

1) 다양한 버전의 응용 프로그램을 저장하고 관리하여 응용 프로그램 버전을 관리하므로 여러 버전의 응용 프로그램 간을 쉽게 전환 할 수 있습니다.

2) 각 환경에 서로 다른 버전의 응용 프로그램을 배포 할 수 있도록 각 응용 프로그램에 대한 "환경"개념을가집니다. 예를 들어 별도의 QA 및 DEV 환경을 설정하고 DEV에 먼저 빌드를 배포 한 다음 QA 팀이 다음 빌드를 준비 할 때 QA에 동일한 버전의 응용 프로그램을 배포하려는 경우에 유용합니다.

3) 중요한 컨테이너 구성 등록 정보 (예 : Tomcat 메모리 설정)를 Elastic Beanstalk 콘솔 및 API에 외부화합니다. 이 때문에 설정을 쉽게 저장하고 환경간에 복사 할 수 있습니다.

4) 콘솔을 통해 응용 프로그램 로그 파일을보고 로그 파일을 S3로 자동 롤 및 보관하십시오. (틀림없이이 기능은 현재 약간 약합니다.)

+0

어쨌든 내 개념으로 볼 때 그는 콩나무에서 싫어하는 성능, 배포 및 재난 사례에서의 오작동에 대해 이해하고 싶어하며 모든 것이 람다를 사용하여 동일하거나 더 좋을 수 있다고 생각합니다. 하드하지만 그것은 당신에게 높은 가용성 실버 총알입니다. –

+0

마지막 지점에 추가하기 만하면 모든 응용 프로그램 로그를 CloudWatch로 잘 발송할 수 있습니다. – sebaGra

관련 문제