AWS OpsWorks와 AWS Beanstalk 및 AWS CloudFormation을 사용할 때의 장단점을 알고 싶습니다.
자동 확장이 가능한 데이터베이스 계층을 포함하여 많은 수의 동시 웹 요청 (분당 1,000 건에서 1,000 만 rpm까지)을 처리하도록 자동 확장 할 수있는 시스템에 관심이 있습니다.
각 앱에 대해 별도의 인스턴스를 갖는 대신, 이상적으로는 일부 하드웨어 리소스를 효율적으로 공유하고 싶습니다. 과거에는 주로 EC2 인스턴스 + RDS + Cloudfront + S3를 사용했습니다.
스택 시스템은 Heroku에서 마이그레이션하는 Rails 앱, 일부 python / django 앱 및 일부 PHP 앱에 트래픽이 많은 루비를 호스팅합니다.
미리 감사드립니다.
답변:
AWS OpsWorks와 AWS Beanstalk 및 AWS CLoudFormation을 사용할 때의 장점과 단점은 무엇인지 알고 싶습니다.
답은 상황에 따라 다릅니다.
AWS OpsWorks와 AWS Beanstalk는 생각하는 방식에 따라 단순히 인프라를 관리하는 방법이 다릅니다. CloudFormation은 단순히 인프라를 템플릿 화하는 방법입니다.
개인적으로 저는 Elastic Beanstalk에 더 익숙하지만 각각에 대해 잘 알고 있습니다. Git을 통해 배포 할 수 있기 때문에 선호합니다. Elastic Beanstalk가 환경을 시작하기 위해 내부적으로 CloudFormation을 사용하는 것은 공개 정보입니다.
내 프로젝트에서는 두 가지를 동시에 사용합니다. CloudFormation을 사용하여 앱에 사용하는 사용자 지정 구성 VPC 환경, S3 버킷 및 DynamoDB 테이블을 구성합니다. 그런 다음 S3 / DynamoDB 리소스와 대화하는 방법을 알고있는 사용자 지정 VPC 내에서 Elastic Beanstalk 환경을 시작합니다.
자동 확장이 가능한 데이터베이스 계층을 포함하여 많은 수의 동시 웹 요청 (분당 1,000 건에서 1,000 만 rpm까지)을 처리하도록 자동 확장 할 수있는 시스템에 관심이 있습니다.
내부적으로 OpsWorks 및 Elastic Beanstalk는 사용자가 말하는로드를 처리 할 수있는 EC2 + CloudWatch + Auto Scaling을 사용합니다. RDS는 확장 가능한 SQL 기반 데이터베이스를 지원합니다.
각 앱에 대해 별도의 인스턴스를 갖는 대신, 이상적으로는 일부 하드웨어 리소스를 효율적으로 공유하고 싶습니다. 과거에는 주로 EC2 인스턴스 + RDS + Cloudfront + S3를 사용했습니다.
" 일부 하드웨어 리소스"의 의미에 따라 OpsWorks 또는 Elastic Beanstalk 환경과 함께 항상 독립형 EC2 인스턴스를 시작할 수 있습니다. 현재 Elastic Beanstalk는 환경 당 하나의 웹앱을 지원합니다. OpsWorks가 무엇을 지원하는지 기억이 나지 않습니다.
스택 시스템은 Heroku에서 마이그레이션하는 Rails 앱, 일부 python / django 앱 및 일부 PHP 앱에 트래픽이 많은 루비를 호스팅합니다.
이 모든 것이 AWS에서 완벽하게 지원됩니다. OpsWorks 및 Elastic Beanstalk는 다양한 개발 환경 (Ruby, Python 및 PHP가 모두 목록에 있음)에 맞게 최적화 되었으며 EC2는 원하는 모든 것을 설치할 수있는 원시 서버를 제공합니다.
OpsWorks는 Chef와 같은 오케스트레이션 도구입니다. 사실 Chef-Puppet, Ansible 또는 Saltstalk에서 파생되었습니다. Opsworks를 사용하여 각 리소스 (서버 인스턴스, 애플리케이션, 스토리지)가있을 상태를 지정하여 네트워크가있는 상태를 지정합니다. 그리고 각 리소스가있을 상태를 지정합니다. 해당 상태의 각 속성에 대해 원하는 값을 지정합니다. 예를 들어 Apache 서비스가 항상 실행되고 실행되고 사용자가 Apache이고 Linux 그룹이 Apache 인 부팅시 시작되도록 할 수 있습니다.
CloudFormation은 배포하려는 리소스의 상태를 지정하는 json 템플릿 (**)입니다. 즉, VPC 192.168.1.0/24의 일부로 us-east-1에 AWS EC2 micro t2 인스턴스를 배포하려고합니다. . EC2 인스턴스의 경우 EC2 리소스의 사용자 데이터 섹션에있는 사용자 지정 bash 스크립트를 통해 해당 리소스에서 실행할 항목을 지정할 수 있습니다. CloudFormation은 단순한 템플릿입니다. 템플릿은 CloudFormation 용 AWS Management Console을 통해 실행하거나 Cloudformation 용 aws cli 명령 (예 : aws cloudformation ...)을 실행하는 경우에만 실행 리소스로 구체화됩니다.
ElasticBeanstalk는 PAAS입니다. 특히 Ruby / Rails, node.js 또는 Python / django 또는 Python / Flask 앱을 업로드 할 수 있습니다. Scala, Haskell 또는 다른 것을 실행하는 경우 Docker 이미지를 생성하고 해당 Docker 이미지를 Elastic Beanstalk (*)에 업로드합니다.
CloudFormation 용 aws cli를 실행하여 앱을 Elastic Beanstalk에 업로드하거나 Opsworks에 대한 레시피를 생성하여 앱을 Elastic Beanstalk에 업로드 할 수 있습니다. Opsworks를 통해 Cloudformation 용 aws cli를 실행할 수도 있습니다.
(*) 실제로 Ruby 앱 예제에 대한 AWS의 문서가 너무 열악하여 인내심을 잃고 예제 앱을 Docker 이미지에 내장하고 Docker 이미지를 Elastic Beanstalk에 업로드했습니다.
(**) 2016 년 9 월부터 Cloudformation은 YAML 템플릿도 지원합니다.
Opsworks에서는 기본 인스턴스가 수행 할 수있는 특정 작업을 결합하여 더 적은 리소스를 사용하기 위해 스택에 걸쳐 계층의 "역할"을 공유 할 수 있습니다.
레이어 호환성 목록 (보안 그룹이 올바르게 설정된 경우) :
HA Proxy : custom, db-master, and memcached.
MySQL : custom, lb, memcached, monitoring-master, nodejs-app, php-app, rails-app, and web.
Java : custom, db-master, and memcached.
Node.js : custom, db-master, memcached, and monitoring-master
PHP : custom, db-master, memcached, monitoring-master, and rails-app.
Rails : custom, db-master, memcached, monitoring-master, php-app.
Static : custom, db-master, memcached.
Custom : custom, db-master, lb, memcached, monitoring-master, nodejs-app, php-app, rails-app, and web
Ganglia : custom, db-master, memcached, php-app, rails-app.
Memcached : custom, db-master, lb, monitoring-master, nodejs-app, php-app, rails-app, and web.
참조 : http://docs.aws.amazon.com/opsworks/latest/userguide/layers.html
AWS Beanstalk : Elastic Beanstalk로 웹 애플리케이션을 실행하는 인프라에 대해 걱정하지 않고 AWS 클라우드에서 애플리케이션을 배포하고 관리합니다. EC2 또는 기타 설치에 대해 걱정할 필요가 없습니다.
AWS OpsWorks AWS OpsWorks는 새로운 DevOps 사용자가 전체 애플리케이션을 쉽게 모델링하고 관리 할 수있게 해주는 애플리케이션 관리 서비스에 불과합니다.
AWS CloudFormation-환경을 생성하고 업데이트합니다.
AWS Opsworks-Chef 또는 Puppet과 마찬가지로 해당 환경 내에서 시스템을 관리합니다.
AWS Beanstalk-생성, 관리 및 배포.
그러나 개인적으로 저는 CloudFormation과 OpsWorks가 의미하는 바에 대한 모든 기능을 사용하는 것을 좋아합니다.
CloudFormation을 사용하여 환경을 생성 한 다음 클라우드 형성 스크립트에서 Opsworks를 호출하여 머신을 시작할 수 있습니다. 그런 다음 Opsworks 스택을 사용하여 관리 할 수 있습니다. 예를 들어 Opsworks를 사용하여 Linux 상자에 사용자를 추가하거나 요리사 레시피를 사용하여 상자를 패치합니다. 배포를위한 셰프 레시피를 기록 할 수도 있습니다. 그렇지 않으면 배포 용으로 특별히 빌드 된 CodeDeploy를 사용할 수 있습니다.
AWS OpsWorks- 이것은 AWS 관리 서비스의 일부입니다. 스크립팅을 사용하여 애플리케이션을 구성하는 데 도움이됩니다. 이 애플리케이션 관리 및 운영을위한 devops 프레임 워크로 Chef를 사용합니다. 서버, 데이터베이스, 스토리지 구성에 사용할 수있는 템플릿이 있습니다. 다른 작업을 수행하도록 템플릿을 사용자 지정할 수도 있습니다. DevOps 엔지니어는 애플리케이션의 종속성 및 인프라를 제어합니다.
AWS Beanstalk -Java, Node Js, Python, Ruby Go와 같은 언어를위한 환경을 제공합니다. Elastic Bean stalk는 애플리케이션을 실행하기위한 리소스를 제공합니다. 개발자는 인프라에 대해 걱정할 필요가 없으며 인프라를 제어 할 수 없습니다.
AWS CloudFormation -CloudFormation에는 AWS 리소스를 순서대로 관리하기위한 샘플 템플릿이 있습니다.
다른 많은 사람들이 AWS Beanstalk에 대해 언급했듯이 AWS OpsWorks 및 AWS Cloud Formation은 다양한 문제에 대해 서로 다른 솔루션을 제공합니다.
달성하기 위해
I am interested in a system that can be auto scaled to handle any high number of simultaneous web requests (From 1000 requests per minute to 10 million rpm.), including a database layer that can be auto scalable as well.
마이그레이션 프로세스에 있다는 점을 고려하여 AWS Lambda 및 AWS DynamoDB 솔루션 (또는 하이브리드 솔루션)을 살펴 보는 것이 좋습니다.
두 가지 모두 간단한 방식으로 자동 확장을 위해 설계되었으며 매우 저렴한 솔루션 일 수 있습니다.