DockerコンテナをスケーリングするためにAWSElasticBeanstalkまたはAmazonEC2 Container Service（ECS）を使用する必要がありますか？
複数のマイクロサービスで構成されるDockerベースのアプリケーションを開発しました。Amazon SQSメッセージを消費し、それらを処理する必要があります。最初はAWSElastic Beanstalkを使用したかったのですが、その後EC2 ContainerServiceに転倒しました。今、私はどちらを選ぶべきかわかりません。 現在のところ、ElasticBeanstalkはMulti-Container-Environmentsをサポートしています。すべてのマイクロサービスがDockerコンテナ内に独自のアプリケーションサーバーを持っているので、これは素晴らしいことです。次の問題はスケーリングです。 スケーリングメカニズムがどのように機能するのかわかりません。例：ElasticBeanstalk環境に5つのDockerコンテナーがあります。現在、処理するSQSメッセージが大量にあるため、5番目のDockerコンテナのみが高負荷になっています。他の4つは、CPUをあまり必要としないか、SQSメッセージが少ないため、ほとんどアイドル状態です。5番目のコンテナがJBossアプリケーションサーバーを実行するとします。私の知る限り、使用可能なCPU /メモリが十分にある場合でも、サーバーは限られた量の並列要求しか消費できません。 JBoss Dockerコンテナがリクエストの量を処理できないが、使用可能なCPU /メモリが十分にある場合は、もちろん、同じインスタンスで2番目のDocker / JBossコンテナを自動的に起動したいと思います。しかし、十分なCPU /メモリがない場合はどうなりますか？もちろん、EBの自動スケーリンググループを介して構成可能な2番目のインスタンスでスピンしたいと思います。これで2番目のインスタンスが起動しますが、5番目を除くすべてのコンテナはほぼアイドル状態です。もちろん、2番目のインスタンスでも不要な4を生成しないようにします。これは、リソースの浪費になります。5番目のみが生成され、他はCPU /メモリ/ SQSなどの構成可能なパラメーターに基づいて5番目のスケールのようにスケーリングする必要があります。 Amazon ECSがそれを行っているかどうか、またはそれが可能かどうかは正確にはわかりませんが、このトピックに関する情報源はインターネット上で実際には見つかりません。一般的に言われているように、インスタンス/コンテナーに基づいてスケーリングします。