AWSOpsWorksとAWSBeanstalkおよびAWSCloudFormationを使用することの長所と短所は何ですか？
自動スケーラブルも可能なデータベースレイヤーを含め、多数の同時Webリクエスト（1分あたり1000リクエストから1,000万rpmまで）を処理するために自動スケーリングできるシステムに興味があります。
アプリごとに個別のインスタンスを用意する代わりに、理想的には、いくつかのハードウェアリソースを効率的に共有したいと思います。過去には、主にEC2インスタンス+ RDS + Cloudfront + S3を使用していました
スタックシステムは、Herokuから移行するトラフィックの多いRuby on Railsアプリ、Python / djangoアプリ、PHPアプリをホストします。
前もって感謝します。
回答:
AWSOpsWorksとAWSBeanstalkおよびAWSCLoudFormationを使用することの長所と短所は何ですか？
答えは：それは異なります。
AWSOpsWorksとAWSBeanstalkは（聞いたことがありますが）インフラストラクチャを管理する方法が、考え方によって異なります。CloudFormationは、単にインフラストラクチャをテンプレート化する方法です。
個人的には、Elastic Beanstalkに精通していますが、それぞれに精通しています。Gitを介してデプロイできるので、私はそれを好みます。ElasticBeanstalkが内部でCloudFormationを使用して環境を起動することは公開情報です。
私のプロジェクトでは、両方を組み合わせて使用しています。CloudFormationを使用して、アプリに使用するカスタム構成のVPC環境、S3バケット、DynamoDBテーブルを構築しています。次に、S3 / DynamoDBリソースと通信する方法を知っているカスタムVPC内でElasticBeanstalk環境を起動します。
自動スケーラブルも可能なデータベースレイヤーを含め、多数の同時Webリクエスト（1分あたり1000リクエストから1,000万rpmまで）を処理するために自動スケーリングできるシステムに興味があります。
内部的には、OpsWorksとElasticBeanstalkはEC2 + CloudWatch + Auto Scalingを使用しており、これはあなたが話している負荷を処理することができます。RDSは、スケーラブルなSQLベースのデータベースのサポートを提供します。
アプリごとに個別のインスタンスを用意する代わりに、理想的には、いくつかのハードウェアリソースを効率的に共有したいと思います。過去には、主にEC2インスタンス+ RDS + Cloudfront + S3を使用していました
「一部のハードウェアリソース」の意味に応じて、OpsWorksまたはElasticBeanstalk環境と一緒にスタンドアロンEC2インスタンスをいつでも起動できます。現在、ElasticBeanstalkは環境ごとに1つのWebアプリをサポートしています。OpsWorksが何をサポートしているか思い出せません。
スタックシステムは、Herokuから移行するトラフィックの多いRuby on Railsアプリ、Python / djangoアプリ、PHPアプリをホストします。
これらはすべてAWSによって完全にサポートされています。OpsWorksとElasticBeanstalkは、さまざまな開発環境向けに最適化されています（Ruby、Python、PHPはすべてリストに含まれています）が、EC2は、必要なものをインストールできるrawサーバーを提供します。
OpsWorksは、Chefのようなオーケストレーションツールです。実際、Chefから派生しています。Puppet、Ansible、Saltstalkです。Opsworksを使用して、各リソース（サーバーインスタンス、アプリケーション、ストレージ）の状態を指定することにより、ネットワークの状態を指定します。また、各リソースの状態を指定します。その状態の各属性に必要な値を指定します。たとえば、Apacheサービスを常に稼働させ、起動時にApacheをユーザーとしてApacheをLinuxグループとして開始したい場合があります。
CloudFormationは、デプロイするリソースの状態を指定するjsonテンプレート（**）です。つまり、VPC 192.168.1.0/24の一部としてus-east-1にAWSEC2 microt2インスタンスをデプロイします。 。EC2インスタンスの場合、EC2リソースのuser-dataセクションにあるカスタムbashスクリプトを使用して、そのリソースで何を実行するかを指定できます。CloudFormationは単なるテンプレートです。テンプレートは、CloudFormationのAWSマネジメントコンソールから実行するか、Cloudformationのaws cliコマンド（aws cloudformation ...）を実行した場合にのみ、実行中のリソースとして肉付けされます。
ElasticBeanstalkはPAASです。具体的にはRuby / Rails、node.js、Python / django、Python / Flaskアプリをアップロードできます。Scala、Haskellなどを実行している場合は、そのためのDockerイメージを作成し、そのDockerイメージをElastic Beanstalk（*）にアップロードします。
CloudFormationのawscliを実行するか、Opsworksのレシピを作成してアプリをElastic Beanstalkにアップロードすることで、ElasticBeanstalkにアプリをアップロードできます。Opsworksを介してCloudformationのawscliを実行することもできます。
（*）実際、Rubyアプリの例に関するAWSのドキュメントは非常に貧弱だったため、忍耐力を失い、サンプルアプリをDockerイメージに埋め込み、DockerイメージをElasticBeanstalkにアップロードしました。
（**）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ユーザーがアプリケーション全体を簡単にモデル化および管理できるようにするアプリケーション管理サービスに他なりません。
AWSCloudFormation-環境を作成および更新します。
AWS Opsworks-ChefやPuppetの場合と同様に、その環境内でシステムを管理します
AWS Beanstalk-作成、管理、デプロイ。
しかし、個人的には、CloudFormationとOpsWorksの両方が、その目的のためにフルパワーを使用することで気に入っています。
CloudFormationを使用して環境を作成すると、クラウド形成スクリプトからOpsworksを呼び出してマシンを起動できます。次に、それを管理するためのOpsworksスタックがあります。たとえば、Opsworksを使用してLinuxボックスにユーザーを追加したり、シェフのレシピを使用してボックスにパッチを適用したりします。デプロイ用のシェフのレシピを書き留めることもできます。それ以外の場合は、デプロイメント用に特別にビルドされたCodeDeployを使用できます。
AWSOpsWorks-これはAWS管理サービスの一部です。スクリプトを使用してアプリケーションを構成するのに役立ちます。このアプリケーションの管理と操作のためのdevopsフレームワークとしてChefを使用します。サーバー、データベース、ストレージの構成に使用できるテンプレートがあります。テンプレートは、他のタスクを実行するようにカスタマイズすることもできます。DevOpsエンジニアは、アプリケーションの依存関係とインフラストラクチャを制御できます。
AWS Beanstalk -Java、Node Js、Python、RubyGoなどの言語の環境を提供します。Elastic Beanの茎は、アプリケーションを実行するためのリソースを提供します。開発者はインフラストラクチャについて心配する必要はなく、インフラストラクチャを制御することもできません。
AWS CloudFormation -CloudFormationには、AWSリソースを順番に管理するためのサンプルテンプレートがあります。
他の多くの人がAWSBeanstalkにコメントしているように、AWSOpsWorksとAWSCloudFormationはさまざまな問題に対してさまざまなソリューションを提供します。
を達成するために
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.
また、移行プロセスにあることを考慮して、AWSLambdaおよびAWSDynamoDBソリューション（またはハイブリッドソリューション）を検討することを強くお勧めします。
どちらも簡単な方法で自動スケーリング用に設計されており、非常に安価なソリューションになる可能性があります。