수동 배포와 Amazon Elastic Beanstalk
EC2 인스턴스를 수동으로 생성하고 Tomcat 서버를 설정하고 일반적인 Java 웹 애플리케이션을 위해 배포하는 등 Elastic Beanstalk를 사용하면 얻을 수있는 이점은 무엇입니까? 로드 밸런싱, 모니터링 및 자동 확장이 유일한 이점입니까?
데이터베이스를 사용하는 웹 응용 프로그램에서 EC2 인스턴스 자체에 데이터베이스를 설치했다고 가정하십시오. 자동 호출이 수행되면 데이터베이스가 새로 생성 된 인스턴스에서 생성되거나 마스터 인스턴스에서 생성 한 데이터베이스에 액세스하게됩니다 ... 자동 확장이 발생할 때 복제본 만 생성하면 인스턴스간에 데이터 동기화는 어떻게 이루어 집니까?
로드 밸런싱, 모니터링 및 자동 확장과 같이 언급 한 모든 것이 확실히 장점입니다.
그러나 진정한 PAAS ( Platform as a Service )에서 응용 프로그램을 플랫폼과 분리하는 것이 목표입니다. 개발자는 응용 프로그램에 대해서만 걱정합니다. 플랫폼은 "임대"됩니다. 플랫폼 "인스턴스"는 자동으로 업데이트, 관리, 확장, 균형 조정 등입니다. WAR 파일을 업로드하면 (적어도 이론적으로는) 작동합니다.
EC2 자체는 PAAS가 아닙니다. 이는 IAAS ( Infrastructure as a Service ) 와 비슷 합니다. 여전히 서버 인스턴스를 관리하고, 소프트웨어를 설치하고, 업데이트 상태를 유지해야합니다.
Elastic Beanstalk는 PAAS 시스템입니다. App Engine 과 Azure 도 많은 것들 중에서도 마찬가지 입니다.
실제 PAAS 시스템에서 DBMS는 웹 응용 프로그램 서버와는 별도의 구성 요소입니다. 그 이유는 명백합니다. 트래픽에 따라 인스턴스가 작성 및 삭제되면 DBMS가 손실되므로 애플리케이션 서버에 사용중인 인스턴스에 DBMS를 설치할 수 없습니다. DBMS와 애플리케이션 서버를 동일한 머신 / 인스턴스에 두는 것은 일반적으로 좋은 생각이 아닙니다.
PAAS 시스템에서 DBMS는 별도의 서비스입니다. Amazon의 경우 Amazon RDS 입니다. Elastic Beanstalk와 마찬가지로 애플리케이션 서버에 대해 걱정할 필요가없고 WAR 파일을 업로드하기 만하면됩니다. RDS를 사용하면 DBMS에 대해 걱정할 필요가 없으며 데이터베이스 만 배포하면됩니다.
Elastic Beanstalk와 RDS는 특히 지연 시간이 매우 낮은 동일한 가용 영역에 배포 할 때 매우 효과적으로 작동합니다.
마지막으로 Elastic Beanstalk를 사용하면 배포 된 리소스 (EC2 인스턴스 및로드 밸런서) 이상의 비용이 들지 않습니다. 그러나 RDS는 저렴하지 않으며 애플리케이션 서버와 DBMS 모두에 단일 EC2 인스턴스를 사용하는 것보다 확실히 비쌉니다.
Elastic Beanstalk는 단순한로드 밸런싱, 모니터링 및 자동 확장 이상의 기능을 수행합니다.
1) 다른 버전의 응용 프로그램을 저장하고 관리하여 응용 프로그램 버전을 관리하여 다른 버전의 응용 프로그램간에 쉽게 전환 할 수 있습니다.
2) 각 응용 프로그램마다 "환경"이라는 개념이 있으므로 각 환경에 다른 버전의 응용 프로그램을 배포 할 수 있습니다. 예를 들어 별도의 QA 및 DEV 환경을 설정하고 DEV에서 먼저 빌드를 배포 한 다음 QA 팀이 다음 빌드를 준비 할 때 QA에서 동일한 버전의 애플리케이션을 배포하려는 경우에 편리합니다.
3) 중요한 컨테이너 구성 속성 (예 : Tomcat 메모리 설정)을 Elastic Beanstalk 콘솔 및 API로 외부화합니다. 이 때문에 설정을 쉽게 저장하고 환경간에 복사 할 수 있습니다.
4) 콘솔을 통해 응용 프로그램 로그 파일을보고 S3에 로그 파일을 자동으로 롤 및 보관합니다. (이 기능은 현재 약간 약합니다.)
EC2 전용 (Nginx & Gunicorn)과 Beanstalk Environment (CentOS & Apache2) 모두에 앱을 배포했습니다.
내 관찰 :
BeanStalk는 Paas입니다. EC2 인스턴스 (IAAS)를 수동으로 생성하는 것은 처음부터 모든 작업을 수행하는 것과 유사하지만 확실한 제어가 가능합니다.
BeanStalk는 기본적으로 CentOS 및 Apache (Httpd)와 함께 제공됩니다. 전용 인스턴스에서 OS를 선택할 수 있습니다.
나에게 중요한 것들
- Beanstalk 환경에 504 오류가 많이 발생했습니다.
- 로그가 표시되지 않고 머신에 ssh 할 수 없었기 때문에 BeanStalk 서버가 충돌했을 때 디버그하기가 어려웠습니다. 이건 매우 중요합니다.
- Celery, Redis (다른 포트를 실행해야 함) 등과 같은 도구 설치 / 구성 전용 인스턴스에서 훨씬 더 쉽습니다.
필자의 경우 일부 패키지 (pandoc와 같은) 설치를 실행하기 위해 (Beanstalk) 서버를 확장해야했습니다. 우분투에서는 이런 것들이 더 간단합니다.
BeanStalk에서는 확장이 훨씬 더 쉽습니다. BeanStalk에서 서버 복제는 간단합니다.
나는 두 경우 모두에서 마이크로를 취했다 (전용 & 콩 줄기). 전용 마이크로 인스턴스가 더 좋다고 생각했습니다.
Beanstalk에서 자동 배포. 나는 그것을 자동화하기 위해 스크립트를 작성해야했습니다.
참고 URL : https://stackoverflow.com/questions/9093741/manual-deployment-vs-amazon-elastic-beanstalk
'IT story' 카테고리의 다른 글
| 내장 파이썬 함수의 소스 코드를 찾으십니까? (0) | 2020.08.02 |
|---|---|
| Javadoc을 사용하여 @um 값에 연결하는 방법 (0) | 2020.08.02 |
| std :: map에 해당하는 remove_if (0) | 2020.08.02 |
| 가져 오기없이 gpg 키 세부 사항을 표시하는 방법은 무엇입니까? (0) | 2020.08.02 |
| IIS 오류 502.5의 ASP.NET Core 1.0 (0) | 2020.07.30 |