수동 배포와 Amazon Elastic Beanstalk


114

일반적인 Java 웹 애플리케이션을 위해 수동으로 EC2 인스턴스를 생성하고 tomcat 서버를 설정하고 배포하는 것보다 Elastic Beanstalk를 사용하여 얻을 수있는 이점은 무엇입니까? 부하 분산, 모니터링 및 자동 확장이 유일한 장점인가요?

데이터베이스를 사용하는 웹 애플리케이션의 경우 EC2 인스턴스 자체에 데이터베이스를 설치했다고 가정합니다. 자동 호출이 발생하면 새로 생성 된 인스턴스에서 데이터베이스가 생성되거나 마스터 인스턴스에서 생성 된 데이터베이스에 액세스합니다. 자동 확장이 발생할 때 복제본 만 생성하면 인스턴스간에 데이터 동기화가 어떻게 발생합니까?

답변:


144

로드 밸런싱, 모니터링 및 자동 확장과 같이 언급 한 모든 것이 확실히 이점입니다.

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

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

Elastic Beanstalk는 PAAS 시스템입니다. 그래서있는 앱 엔진하늘빛은 많은 다른 사람의 사이에서.

진정한 PAAS 시스템에서 DBMS는 웹 응용 프로그램 서버와는 별도의 구성 요소입니다. 그 이유는 분명합니다. 트래픽을 기반으로 인스턴스가 생성 및 파괴되면 DBMS가 손실되기 때문에 애플리케이션 서버에 사용되는 인스턴스에 DBMS를 설치할 수 없습니다! 어쨌든 DBMS와 응용 프로그램 서버를 동일한 시스템 / 인스턴스에 두는 것은 일반적으로 좋은 생각이 아닙니다.

PAAS 시스템에서 DBMS는 별도의 서비스입니다. Amazon의 경우 Amazon RDS 입니다. 애플리케이션 서버에 대해 걱정할 필요가없고 WAR 파일 만 업로드하는 Elastic Beanstalk와 마찬가지로 RDS를 사용하면 DBMS에 대해 걱정할 필요가없고 데이터베이스 만 배포 할 수 있습니다.

Elastic Beanstalk와 RDS는 특히 지연 시간이 매우 낮은 동일한 가용 영역에 배포 된 경우 매우 잘 작동합니다.

마지막으로 Elastic Beanstalk를 사용하면 배포 된 리소스 (EC2 인스턴스 및로드 밸런서)보다 더 많은 비용이 들지 않습니다. 그러나 RDS는 저렴하지 않으며 애플리케이션 서버와 DBMS 모두에 단일 EC2 인스턴스를 사용하는 것보다 확실히 더 비쌉니다.


3
멋지게 넣어. 추가 사항 : 각 인스턴스 생성의 기반으로 사용할 사용자 지정 AMI를 지정할 수 있습니다. 따라서 예를 들어 필요한 모든 구성 및 앱으로 Apache 이미지를 사용자 지정하고 기본 AMI로 사용할 수 있습니다 (Beanstalk 환경 구성에 사용자 지정 AMI ID 필드가 있음). 그래도 런타임 생성 데이터는 모든 인스턴스 종료시 실제로 삭제됩니다. (그리고로드 밸런서는 그렇게 할 것입니다!).
André Felipe

1
저를 당황하게 한 한 가지는 Elastic Beanstalk가 배포 된 각 환경에 대해로드 밸런서를 생성한다는 사실이었습니다. 로드 밸런서는 실행 비용이 많이 들지는 않지만 마이크로 인스턴스와 거의 같은 비용입니다.
켄 리우

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

7
@BigSack-제가하려는 요점은 Elastic Beanstalk가 무료로 제공되어야한다는 점이지만 AWS는 각 환경이 한 달에 약 15 달러의 비용이 드는로드 밸런서를 할당 할 것이라는 점을 분명히 밝히지 않았습니다. 나는 마이크로 인스턴스와 비교하지 않았습니다.
Ken Liu

내가 아는 한 RDS는 가격면에서 요즘 EC2와 거의 동일하지만 훨씬 더 큰 유틸리티, 유지 관리 및 안정성을 제공합니다.
Justin Schier

38

Elastic Beanstalk는 단순한로드 밸런싱, 모니터링 및 자동 확장 이상의 기능을 수행합니다.

1) 서로 다른 버전의 애플리케이션을 저장하고 관리하여 애플리케이션 버전을 관리하므로 서로 다른 버전의 애플리케이션간에 쉽게 전환 할 수 있습니다.

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

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

4) 콘솔을 통해 애플리케이션 로그 파일을보고 로그 파일을 S3에 자동으로 롤 및 보관합니다. (확실히이 기능은 현재 약간 약합니다.)


어쨌든 내 콘셉트에서 그는 내가 콩나무에서 싫어하는 성능, 배포시 오작동 및 재난 사례에 대해 이해하고 싶어한다고 생각하며 LAMBDA를 사용하면 모든 것이 동일하거나 더 나을 수 있습니다. 어렵지만 고 가용성은 은색 총알입니다.
Lucas Rodrigues Sena

마지막 요점에 추가하면 모든 애플리케이션 로그를 CloudWatch로 멋지게 전송할 수 있습니다.
SebaGra

6

EC2 전용 (Nginx 및 Gunicorn)과 Beanstalk 환경 (CentOS 및 Apache2) 모두에 앱을 배포했습니다.

내 관찰 :

  • BeanStalk는 Paas입니다. EC2 인스턴스 (IAAS)를 수동으로 생성하는 것은 모든 것을 처음부터 수행하는 것과 같지만 확실한 제어 권한이 있습니다.

  • BeanStalk는 기본적으로 CentOS 및 Apache (Httpd)와 함께 제공됩니다. 전용 인스턴스에서 OS를 선택할 수 있습니다.

  • 나에게 중요한 것들은

    • Beanstalk 환경에서 504 개의 오류가 많이 나타났습니다.
    • BeanStalk 서버가 충돌했을 때 로그도 표시되지 않고 시스템에 ssh 할 수 없기 때문에 디버그하기가 어려웠습니다. 이건 매우 중요합니다.
    • Celery, Redis (다른 포트를 실행해야 함) 등과 같은 도구를 설치 / 구성합니다. 전용 인스턴스에서 훨씬 더 쉽습니다.
  • 제 경우에는 일부 패키지 (예 : pandoc)의 설치를 실행하기 위해 (Beanstalk) 서버를 확장해야했습니다. 이러한 것들은 우분투에서 더 간단합니다.

  • 확장은 BeanStalk에서 훨씬 더 쉽습니다. 복제 서버는 BeanStalk에서 간단합니다.

  • 두 경우 모두 마이크로 촬영했습니다 (전용 및 Beanstalk). 전용 마이크로 인스턴스가 더 좋다고 느꼈습니다.

  • Beanstalk에서 자동 배포. 나는 똑같은 것을 자동화하기 위해 스크립트를 작성해야했는데, 그것은 단 한 번이기 때문에 괜찮습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.