Elastic Beanstalk と ECS と Fargate: どの AWS サービスが最適ですか?

AWSは、アプリケーションを実行するための複数の方法を提供しています。これは、ワークロードによって必要なインフラストラクチャの制御レベル、スケーリング動作、および運用責任が異なるためです。

選択したデプロイメントモデルは、以下の点に影響します。

• 組織が管理するインフラストラクチャの量
• 負荷がかかった状態でのスケーリングの挙動
• どの程度の建築上の制御権を保持するか
• CI/CDパイプラインの統合方法
• 規模拡大時のコスト予測可能性
• システムが移植性をサポートしているか、ベンダーロックインをサポートしているか
• 組織がどれだけの運用上のオーバーヘッドを吸収しているか
  

したがって、Elastic Beanstalk、ECS、Fargateのどれを選ぶかという点において、普遍的に「優れている」選択肢は存在しません。あるのは、特定のワークロードと組織の成熟度レベルに最適な選択肢だけです。

AWS上でアプリケーションを実行するための一般的なコンピューティングモデル

AWSは、さまざまなレベルのインフラストラクチャ制御でアプリケーションを実行できる複数のサービスを提供しています。選択するモデルによって、本番環境におけるアプリケーションのデプロイ、スケーリング、および保守方法が決まります。 

AWSにアプリケーションをデプロイする主な方法は次のとおりです。

• Amazon EC2（サービスとしてのインフラストラクチャ）: OSレベルの完全な制御、手動スケーリング、およびカスタムネットワーク（VPC、セキュリティグループ、EBS、AMI）を備えた仮想マシン。
  
• Elastic Beanstalk（EC2上のマネージドPaaS）EC2、Auto Scaling Groups、Elastic Load Balancing 上でのアプリケーションデプロイメントの抽象化。
  
• Amazon ECS on EC2（コンテナオーケストレーション＋マネージドインスタンス）タスク定義、サービスディスカバリ、IAMロール、およびEC2キャパシティ管理を備えたDockerベースのワークロード。
  
• Amazon ECS on Fargate（サーバーレスコンテナ）EC2プロビジョニングなしでのコンテナ実行。コンピューティング能力はAWSによって管理されます。
  
• Amazon EKS（マネージドKubernetesコントロールプレーン）Kubernetesネイティブのオーケストレーション、クラスタの自動スケーリング、CRD、およびエコシステムツール。
  
• AWS Lambda（イベント駆動型サーバーレス関数）S3、API Gateway、EventBridge、DynamoDB Streamsなどによってトリガーされるステートレスコンピューティング。
  
• ハイブリッドモデル（ECS + EC2 + Fargateの組み合わせ）: ベースラインワークロードはEC2で実行され、バーストトラフィックはFargateで実行される混合容量戦略。

クイック比較：Elastic Beanstalk vs. ECS vs. Fargate

どのAWSコンピューティングオプションがニーズに最適か分からない？Elastic Beanstalk、ECS、Fargateを簡単に比較してみましょう。 各サービスで得られるものと、管理する必要のある事項： 

エラスティックビーンストークとは何ですか？

インフラストラクチャの詳細を気にせずにコードを高速にデプロイしたい場合は、Elastic Beanstalk が AWS 上で最もシンプルな方法です。

コードと設定ファイルをアップロードするだけで、Elastic Beanstalkが残りの作業を処理します。サーバーのプロビジョニング、環境の設定、ネットワークの管理、アプリのデプロイ、トラフィックに基づいたスケーリングなど、すべてElastic Beanstalkが行います。数時間ではなく数分で、動作するウェブアプリが完成します。

Beanstalk は、Java、.NET、Node.js、Python、Go、Ruby、PHP、Docker などの一般的なランタイムとフレームワークをサポートし、Apache、Nginx、Passenger、IIS などの使い慣れたサーバー上で実行されます。

ElasticBeanstalkアーキテクチャ

Beanstalk にデプロイすると、AWS によって以下が自動的に作成されます。

1. EC2インスタンス: アプリはこれらの仮想マシン上で実行されます。
2. エラスティック ロード バランサー (ELB): トラフィックをインスタンス全体に分散します。
3. 自動スケーリンググループ: 負荷に基づいてインスタンスを追加または削除します。
4. セキュリティグループ: アプリに到達できるトラフィックを制御します。
5. ホストマネージャー: 各インスタンスのログ、パッチ、ヘルスチェックを処理する監視エージェント。
6. ElasticBeanstalk環境: アプリが存在する、パブリック URL と CNAME を持つ名前付き環境。

労働者環境

ウェブリクエストの処理に時間がかかりすぎると、パフォーマンスが低下します。Elastic Beanstalkは、サーバーの過負荷を回避するために、リクエストを処理するバックグラウンドプロセスを作成します。独立したコンピューティングリソースセットであるワーカー環境は、実行時間の長いタスクを処理し、ウェブサイトにサービスを提供するリソースが迅速に応答し続けることを保証します。

ECSとは何ですか?

Elastic Beanstalk では制限が多すぎると感じ、かつ EKS 経由で Kubernetes を管理するのはやり過ぎだと感じるなら、Amazon ECS は強力な中間点となります。Amazon ECS は、インフラストラクチャをコントロールしながら、Docker コンテナを大規模にデプロイ・実行できるフルマネージドのコンテナオーケストレーションサービスです。

ECSはEC2、Elastic Load Balancingなどの他のAWSサービスとネイティブに連携します。 S3管理するインフラストラクチャの量を選択します。制御する EC2 インスタンスでコンテナを実行するか、AWS Fargate にオフロードします (詳細は後述)。

ECSアーキテクチャ

ECSの主なコンポーネントは次のとおりです。

1. コンテナイメージ: OS、依存関係、設定があらかじめパッケージ化されたアプリ。 Amazon Elastic Container Registry（ECR） または外部レジストリを使用します。
2. タスク定義: 実行するコンテナ イメージ、割り当てる CPU/メモリの量、公開するポート、適用する IAM ロールを定義する JSON ブループリント。
3. クラスタ: コンテナが実行される EC2 インスタンス (または Fargate リソース) の論理グループ。
4. コンテナエージェント: クラスター内の各EC2インスタンス上で実行されるエージェント。ステータスを報告し、ECSから指示を受け取ります。
5. スケジューラ: リソースのニーズとスケーリング ルールに基づいて、利用可能なインフラストラクチャにタスクを配置します。

ECSの仕組み

タスクをデプロイすると、ECS はそれをクラスター内の EC2 インスタンス（または Fargate が管理するリソース）に配置します。これにより、以下のことが可能になります。

• 自動スケーリンググループを介してスケーリング動作を制御する
• コンテナごとにCPUとメモリの予約を設定する
• タスク配置戦略を定義する（スプレッド、ビンパック、ランダム）
• 定期的なタスクまたは1回限りのタスクをスケジュールする

Fargateとは何ですか？

EC2 インスタンス、自動スケーリンググループ、またはサーバークラスターを管理せずに AWS 上でコンテナを実行したい場合は、AWS Fargate が最適な選択肢です。

Fargateはコンテナ向けのサーバーレスコンピューティングエンジンです。Amazon ECSとEKS（Kubernetes）の両方で動作します。これにより、インフラストラクチャのプロビジョニングや管理をすることなく、Dockerコンテナをデプロイできます。

Fargateアーキテクチャ

Fargate のアーキテクチャは、次の 3 つの主要コンポーネントで構成されています。 

1. タスクの定義: 実行するコンテナ、割り当てる CPU/メモリの量、適用する IAM ロールまたは環境変数を記述する JSON テンプレート。
2. タスク: タスク定義の個々の実行インスタンス。実行するインスタンス数をFargateに指示すると、バックエンドのインフラストラクチャがFargateによって処理されます。
3. クラスター: タスクの論理的なグループ分け。Fargate が実際のコンピューティングを管理するため、EC2 インスタンスを設定したりスケールしたりする必要はありません。

Fargateで得られるもの

Fargate で得られるものは次のとおりです。

• 簡単でスケーラブルで信頼性の高いサービス
• サーバー管理は必要ありません
• キャパシティプランニングに時間を費やすことはありません
• ダウンタイムなしでシームレスに拡張
• 従量課金制の価格設定モデル
• 低遅延サービスであり、データ処理アプリケーションに最適です
• Amazon ECSとの統合により、企業は両方のサービスをより簡単に使用できるようになります

AWS コンピューティング サービスの比較: どれが適していますか?

AWSは、コンテナの実行やアプリケーションのデプロイに関して、非常に優れた柔軟性を提供します。 

しかし、その柔軟性には新たな課題が伴います。 

仕事に適したサービスを選択する。 

シンプルなウェブアプリから複雑なマイクロサービスまで、万能なソリューションは存在しません。それぞれのサービスは、制御性、シンプルさ、スケーラビリティ、そして移植性のバランスが異なります。

Elastic Beanstalk vs. ECS: インフラストラクチャの抽象化 vs. コンテナのオーケストレーション

Elastic BeanstalkとECSを比較評価する際、主な違いはインフラストラクチャの抽象化レベルとコンテナオーケストレーションの制御レベルです。

Elastic Beanstalkは、Amazon EC2、Auto Scalingグループ、Elastic Load Balancingを基盤としたマネージド型のPlatform-as-a-Serviceです。アプリケーションコードまたはコンテナイメージをデプロイするだけで、Beanstalkがインフラストラクチャをプロビジョニングし、インスタンスの置き換え、スケーリングポリシー、ローリングデプロイメントを管理します。 

これは、従来のWebアプリケーション、単一コンテナのワークロード、およびオーケストレーションの基本要素を管理したくない組織に適しています。

Beanstalkは、コンテナオーケストレーションに投資することなく迅速にデプロイしたい小規模組織や初期段階のプロジェクトによく選ばれます。

Amazon ECS（Elastic Container Service）は、コンテナオーケストレーションサービスです。タスク定義、CPUとメモリの予約設定、タスクレベルのIAMロールの割り当て、awsvpcなどのネットワークモードの制御などを支援します。 

ECSは、マイクロサービスアーキテクチャ、マルチコンテナアプリケーション、およびブルー/グリーンリリースやカナリアリリースなどの制御されたデプロイ戦略を必要とするシステムで最も効果を発揮します。

ECSはコンテナビルドパイプラインや自動化されたCI/CDワークフローとも自然に統合できます。そのため、コンテナ化されたマイクロサービスを大規模に運用する組織にとって最適なソリューションと言えるでしょう。

Elastic Beanstalk は以下のような用途に最適です。

• モノリシックアプリケーション
• 最小限のインフラストラクチャカスタマイズで済むアプリケーション
• 専任のサイト信頼性エンジニアリングリソースを持たない企業
• 最小限の実行可能な製品を迅速に展開する
  

Elastic Beanstalk は、以下のような場合には適していません。

• 分散型マイクロサービスアーキテクチャ
• カスタムネットワークトポロジーを必要とするアプリケーション
• きめ細かなスケーリングやタスク配置制御を必要とするワークロード
  

Amazon ECSは以下のような用途に最適です。

• コンテナ化されたマイクロサービス
• ビンパッキングやスプレッドなどのタスク配置戦略を必要とするアプリケーション
• サービスメッシュや高度な可観測性ツールとの統合
• 明示的なスケーリングポリシーを必要とするシステム
  

Amazon ECSでは、クラスター容量の定義（EC2起動タイプを使用する場合）、ネットワーク構成、スケーリングしきい値の管理が必要となるため、運用上の複雑さが増します。

AWS ECS vs. Fargate：コンテナオーケストレーション vs. コンテナコンピューティング 

多くのエンジニアは、AWS FargateとECSを二者択一的な比較対象として捉えがちです。しかし、ECSとFargateは競合するサービスではありません。実際には、Amazon ECSとAWS Fargateは異なるレイヤーで動作します。FargateはECSで使用されるコンピューティングオプションの一つです。つまり、ECSはEC2インスタンスまたはFargateのどちらでもコンテナを実行できるということです。

Amazon ECSは、オーケストレーションの制御プレーンです。

AWS Fargateは、コンテナ向けのサーバーレスコンピューティングエンジンです。

EC2起動タイプを使用してECSを実行する場合、クラスター内のインスタンスをプロビジョニングおよび管理するのはユーザー自身です。一方、Fargate起動タイプを使用してECSを実行する場合、AWSがコンピューティング能力を自動的にプロビジョニングします。

EC2上のECSは、以下のような用途に最適です。

• 長期間継続する定常サービス
• コスト最適化された生産ワークロードと予測可能な利用率
• リザーブドインスタンスまたはスポットインスタンスの恩恵を受けるワークロード
• ホストレベルのチューニングを必要とするアプリケーション
  

Fargate上のECSは、以下のような用途に最適です。

• 予測不可能なトラフィックパターンや、バースト的にトラフィックが集中するワークロード
• クラスター容量管理をなくしたい企業
• 国家のないサービス
• コスト最適化よりも運用上の簡便性が優先される環境
  

Fargateは、キャパシティプランニングやインスタンスライフサイクル管理の必要性を排除します。しかし、継続的に高い利用率が発生する場合、EC2上で稼働するECSの方がコスト効率が良い場合が多いです。

Elastic BeanstalkとFargateの比較

Elastic BeanstalkとAWS Fargateはどちらもインフラストラクチャ管理を軽減するが、それぞれ異なる抽象化レベルで動作し、異なるレベルのアーキテクチャ成熟度を前提としている。

Elastic Beanstalkは、Amazon EC2、Auto Scaling Groups、Elastic Load Balancingを基盤としたマネージド型のPlatform-as-a-Serviceです。サーバーのプロビジョニング、ヘルスモニタリング、ローリングデプロイメント、スケーリング構成を抽象化します。アプリケーションコードまたはDockerイメージをデプロイするだけで、Beanstalkが環境のライフサイクルを管理します。

AWS Fargateは、EC2インスタンスを管理せずにコンテナを実行できるサーバーレスコンピューティングオプションです。Fargateは、選択するオーケストレーションシステムに応じて、Amazon ECSまたはAmazon EKSと組み合わせて使用​​できます。 

この構成では、ECSまたはEKSがコンテナのオーケストレーション（スケジューリング、スケーリング、サービス管理）を処理し、Fargateが基盤となるコンピューティング能力を提供します。つまり、サーバーのプロビジョニングや管理は不要で、コンテナはAWSが管理するインフラストラクチャ上で実行されます。 

つまり、タスク定義、ネットワーク、CPUとメモリの予約、スケーリングポリシーはユーザーが定義し、基盤となるコンピューティング能力はFargateがプロビジョニングするということです。

エラスティックビーンストークは、次のような場合に適しています。

• 従来型の Web アプリケーションまたは単一コンテナをデプロイしています
• コンテナのスケジューリングやタスクの配置を直接制御する必要はありません
• コンテナオーケストレーションの基本要素を管理したくない
• アプリケーションのアーキテクチャは比較的シンプルで、複数のサービス間の連携を必要としません。
• あなたは、独自のインフラストラクチャのデフォルト設定と標準化されたデプロイメントパターンを好む。
  

以下の場合に適しています:

• モノリシックアプリケーション
• 初期段階の製品
• 内部ツールとダッシュボード
• 専任のインフラエンジニアがいない企業
  

Elastic Beanstalk は、次のような場合には適していません。

• コンテナネットワークやタスクごとのIAMロールをきめ細かく制御する必要があります
• サービスディスカバリを必要とする複数のマイクロサービスを実行しています。
• コンテナレベルでは、カナリアリリースやブルー/グリーンリリースなどの高度なデプロイ戦略が必要です。
• Beanstalkの環境レベルのスケーリングを超えた、独自の自動スケーリングロジックが必要です。
• コンテナネイティブの監視ツールとの直接統合を希望する
  

分散システムやマイクロサービス環境では、Beanstalkはオーケストレーション層を抽象化してしまうため、制約となる可能性がある。

Fargateが適しているのは次のような場合です。

• ワークロードはコンテナ化されています
• EC2インスタンスのプロビジョニングとクラスタ容量計画をなくしたい
• 交通パターンは変動的または急激な増加が見られる。
• タスクレベルのIAM分離が必要です
• サーバー管理なしでコンテナオーケストレーションを行いたい
  

以下の場合に適しています:

• ステートレスマイクロサービス
• トラフィックが予測不可能なAPIバックエンド
• イベント駆動型コンテナワークロード
• ECSタスク定義には慣れているが、EC2クラスターの管理には消極的な組織
  

Fargateは、インスタンスのライフサイクル管理、パッチ適用、クラスタの自動スケーリング設定を不要にすることで、運用上の負担を軽減します。

Fargateが適さないのは、次のような場合です。

• オペレーティングシステムレベルのカスタマイズが必要です
• GPU を利用したワークロードなど、特殊なインスタンスタイプが必要です。
• 大規模な定常ワークロードを実行する場合、EC2リザーブドインスタンスの方がコスト効率に優れています。
• デバッグやシステムチューニングにはホストレベルのアクセスが必要です
• カスタムネットワークドライバまたは高度なカーネルレベルの設定が必要です

ラスト Kubernetes サービス 

Kubernetes（K8s） コンテナオーケストレーションの業界標準ですが、簡単ではありません。設定と クラスターの維持ネットワークの管理、ワークロードのスケーリング、通信のセキュリティ保護はすべて、重大なオーバーヘッドを追加します。

ただし、次のようなコンテナ オーケストレーション タスクは自動化されます。

• サービスディスカバリー：Kubernetesは、ドメインネームサービス（DNS）またはIPアドレスを介してリクエストを受け入れるためにコンテナを公開します。
• ロードバランシング：コンテナリソースの需要が高すぎる場合、Kubernetesはリクエストを他の利用可能なコンテナにルーティングします。
• ストレージオーケストレーション: ストレージのニーズが増大すると、K8 はワークロードを処理するために追加のストレージをマウントします。
• 自己回復：コンテナに障害が発生した場合、Kubernetesはそのコンテナをサービスから削除し、新しいコンテナと交換できます。
• シークレットマネジメント：このツールは、パスワード、トークン、およびSSHキーを保存および管理します。

つまり、Kubernetesは便利ですが、複雑です。だからこそ、Amazon Elastic Kubernetes Service (EKS) を選ぶべきなのです。

EKSは、独自のコントロールプレーンを運用することなく、Kubernetesの完全な機能を提供します。完全な柔軟性とパワーを必要とする大規模な本番環境レベルのワークロード向けのマネージドKubernetesサービスです。

EKSアーキテクチャ

Amazon EKS アーキテクチャは次の要素で構成されています。

1. コントロールプレーン（管理対象）EKS が Kubernetes コントロール プレーン (API サーバー、コントローラー マネージャー、スケジューラー) を実行および管理するため、ユーザーが行う必要はありません。
2. ワーカーノード（お客様の責任）アプリケーションコンテナを実行する EC2 インスタンスを管理および保護します (または Fargate を使用します)。
3. Kubelet と Kube-Proxyこれらのサービスはワーカーノード上で実行され、ポッド通信と内部ネットワークを処理します。
4. VPC統合EKSは 仮想プライベートクラウド（VPC） 安全で分離されたネットワーク通信を実現します。

エラスティックコンピューティングクラウド 

Elastic Compute Cloud (EC2) は、AWS コンピューティングのインフラストラクチャ層です。カスタマイズ可能な仮想マシンを提供しますが、設定、セキュリティ保護、保守はすべてお客様の責任となります。

すべての上位レベルのサービス（ECS、EKS、さらにはElastic Beanstalkなど）はEC2上で実行されます。しかし、インスタンス、OS、ストレージ、ネットワーク、ソフトウェアスタックを完全に制御したい場合は、EC2単体が最適です。

EC2アーキテクチャ

EC2アーキテクチャは、次のコンポーネントで構成されています。

1. Amazon マシンイメージ (AMI): コンピューターの状態のスナップショット。何度でも複製できるため、同一の仮想マシンを展開できます。 
2. EC2の場所: コンピューティング、ストレージ、およびネットワークリソースが含まれる地理的領域。利用可能なロケーションのリストはAWS製品ラインによって異なります。例えば、北米のリージョンには、米国東海岸（us-east-1）、米国西海岸（us-west-1）、カナダ（ca-central-1）、ブラジル（sa-east-1）が含まれます。

アベイラビリティーゾーンは、十分にネットワーク化されたリージョン内の個別の場所であり、複数のアベイラビリティーゾーンにまたがるサービスの信頼性を高めるのに役立ちます。

EC2がサポートするストレージの種類

EC2 がサポートするストレージには主に XNUMX つの種類があります。 

エラスティックブロックストレージ

これらはEC2インスタンス自体の外部に存在するボリュームであり、異なるインスタンスに簡単にアタッチできます。EC2インスタンスのライフサイクルを超えて存続しますが、インスタンスにとっては物理的に接続されたドライブのように見えます。2つのECXNUMXインスタンスに複数のEBSボリュームをアタッチできます。

EC2インスタンスストア

これはEC2インスタンスに物理的に接続されたストレージボリュームです。一時的なストレージとして使用されるため、他のインスタンスに接続することはできません。そのため、インスタンスが停止、休止状態、または終了すると、データも消去されます。

ラムダ 

AWS Lambdaは、イベントに応じてコードを実行するサーバーレスコンピューティングプラットフォームです。AWSが最初に導入した主要サービスの一つで、開発者が仮想マシンのインストールや事前の設定をすることなくアプリケーションを構築できるようにしました。 

ラムダの仕組み

関数が作成されると、Lambda はそれを新しいコンテナにパッケージ化し、AWS クラスター上でそのコンテナを実行します。その後、AWS が必要な RAM と CPU 容量を割り当てます。Lambda はマネージドサービスであるため、開発者は設定を変更する必要がなく、運用タスクにかかる時間を節約できます。 

ニーズに応じて Lambda を検討する理由は次のとおりです。 

• サーバーやコンテナを管理する必要はありません。
• 使用量の急増やイベント量に基づいて自動的にスケールします。
• きめ細かな課金（ミリ秒単位で課金）を提供します。
• 強力なセキュリティとコンプライアンス（PCI、HIPAA、ISO 27001 など）を備えています。
• S3、API Gateway、DynamoDB などとの柔軟なトリガーと統合を提供します。

ラムダアーキテクチャ

Lambda アーキテクチャには、次の 3 つの主要コンポーネントがあります。  

1. トリガー： イベントが発生すると関数が起動します。イベントには、S3 ファイルのアップロード、API Gateway 経由の HTTP リクエスト、DynamoDB の新規レコード、スケジュールされたタスクなどがあります。Lambda はこれらのイベントをリッスンし、発生した時点で関数を起動します。
2. 機能： これはPython、Node.js、Java、Go、またはサポートされている他の言語で記述されたコードです。Lambdaは各関数を独自のステートレスコンテナ内で完全に分離して実行します。実行、同時実行、スケーリングは自動的に管理されます。
3. 目的地： 関数が終了すると、Lambda は出力を別の Lambda 関数、SQS キュー、SNS トピック、EventBridge バスなどの別の場所にルーティングできます。

包装機能

関数は、次の 2 つの方法のいずれかでパッケージ化できます。

• 10 MB 未満の関数の場合は、.zip ファイルを使用し、Lambda コンソールまたは CLI 経由でアップロードします。
  
• より大規模または複雑なデプロイメントの場合は、コンテナイメージ (Amazon Elastic Container Registry でホスト) を使用します。

関数が実行されると、その関数を実行するAWSコンテナが自動的に起動します。 コードが実行されると、コンテナは数分後にシャットダウンします。 この機能により、関数はステートレスになります。つまり、一度シャットダウンすると、リクエストに関する情報は保持されません。 注目すべき例外のXNUMXつは、/ tmpディレクトリです。このディレクトリの状態は、コンテナがシャットダウンするまで維持されます。

AWS Lambdaのユースケース

Lambdaはシンプルながらも汎用性が高く、様々なタスクを処理できます。以下にいくつか例を挙げます。

アップロードの処理

アプリケーションがストレージシステムとしてS3を使用する場合、オブジェクトを処理するためにEC2インスタンスでプログラムを実行する必要はありません。 代わりに、Lambdaイベントは新しいファイルを監視し、それらを処理するか、別のLambda関数に渡してさらに処理することができます。 このサービスは、ワークフローの一部として、あるLambda関数から別の関数にS3オブジェクトキーを渡すこともできます。 たとえば、開発者は、ある領域にオブジェクトを作成してから、それを別の領域に移動したい場合があります。

自動バックアップとバッチジョブ

スケジュールされたタスクとジョブはLambdaに最適です。例えば、EC2インスタンスを24時間7日稼働させる代わりに、Lambdaは指定した時間にバックアップを実行できます。また、レポートの生成やバッチジョブの実行にも使用できます。 

リアルタイムログ分析

Lambda関数は、アプリケーションが各イベントを書き込むときにログファイルを評価できます。 さらに、イベントが発生したときにイベントを検索したり、エントリをログに記録したりして、適切な通知を送信できます。

自動ファイル同期

Lambdaはリポジトリを他のリモートロケーションと同期できます。これにより、Lambda関数を使用して、別のサーバーやプロセスを作成することなく、ファイル同期をスケジュールできます。 

EC2とECS、Fargate、Beanstalkの関係

EC2、ECS、Fargateは、あたかも同等のサービスであるかのように比較されることが多い。しかし、実際はそうではない。

• EC2は、仮想マシンという形でコンピュータインフラストラクチャを提供する。 
• ECSはコンテナオーケストレーション機能を提供します。 
• Fargateは、コンテナ向けのサーバーレスコンピュータを提供します。 

これらのサービスは異なる階層で動作します。

ECSはEC2に取って代わるものではなく、コンピューティング能力がなければ動作しません。ECSを使用する場合、プロビジョニングしたEC2インスタンス、またはAWSが自動的にコンピューティング能力をプロビジョニングするFargateのいずれかで動作させる必要があります。つまり、ECSは常にインフラストラクチャ上で動作します。問題は、そのインフラストラクチャを自分で管理するか、AWSに任せるかだけです。

ECSとEC2

EC2を直接利用する場合、そのインスタンス上で実行されるすべての処理はユーザーの責任となります。これには、コンテナランタイムのインストール、スケーリングポリシーの設定、障害が発生したインスタンスの交換、デプロイメントの調整などが含まれます。サーバーとアプリケーションのライフサイクルの両方を管理することになります。

ECSを使用すると、責任はコンテナ層に移ります。ECSはタスクのスケジュール設定、ヘルスチェックの実行、および必要な数のコンテナの実行維持を行います。 

EC2起動タイプを選択した場合でも、インスタンス容量の管理は引き続きお客様自身で行います。ECSはコンテナオーケストレーションのオーバーヘッドを削減しますが、インフラストラクチャの所有権はお客様に残ります。

ファーゲート対EC2

EC2では、インスタンスファミリーを選択し、予約済みまたはスポット容量を使用してコストを最適化し、オペレーティングシステムレベルでパフォーマンスを調整できます。容量のプロビジョニング方法と、ワークロード間でのリソースの割り当て方法を制御できます。

Fargateでは、タスクレベルでCPUとメモリを定義するだけで、AWSが自動的にコンピューティングリソースを提供します。インスタンスのプロビジョニング、パッチ適用、スケーリングは不要です。 

これにより、キャパシティプランニングとインスタンス管理は不要になりますが、ホストレベルでのインフラストラクチャのカスタマイズや最適化もできなくなります。

AWS Elastic BeanstalkとEC2の比較

EC2を直接使用する場合は、スケーリングポリシー、ロードバランサー、ヘルスモニタリングなど、デプロイメントスタック全体を構築および運用する必要があります。

Elastic Beanstalkは、アプリケーションを実行するEC2インスタンス、およびアプリケーションの動作に必要なオートスケーリンググループとロードバランサーを自動的に作成および管理します。 

基盤となるインフラストラクチャは依然としてEC2ですが、インスタンスのライフサイクル管理は抽象化されています。違いは機能面ではなく、運用上の制御をどれだけ保持できるかという点にあります。

ECS から EKS への移行

ECS を使い始める正当な理由もあれば、後から ECS から移行する正当な理由もあります。サービス間の切り替えは可能ですが、最初から適切なサービスを選択することで、後々のコストのかかるやり直しやチームのフラストレーションを回避することができます。 

ECS は AWS ネイティブで、AWS エコシステムと緊密に統合された独自のサービスです。一方、EKS はアップストリーム Kubernetes を実行するため、クラウドに依存しない柔軟性と大規模なオープンソースエコシステムへのアクセスを提供します。

この切り替えは、チームが ECS の制約を超えたり、マルチクラウドまたはハイブリッド環境全体で標準化されたオーケストレーション モデルを採用したりする必要がある場合によく発生します。

ECSでマイクロサービスを実行しているチームが、将来のオンプレミスまたは他のクラウドへのデプロイメントをサポートしたいと考えているとします。EKSに移行することで、Kubernetesのポータビリティを維持しながら、AWSのマネージドインフラストラクチャのメリットを引き続き享受できます。

移行の概要は以下のとおりです。

1. ecs-to-eks ツールを使用して、ECS クラスター定義を Amazon S3 バケットにエクスポートします。
2. AWS CLI を使用して新しい EKS クラスターを作成し、エクスポートされた JSON を入力として渡します。
3. kubectl を使用して新しい EKS クラスターに接続し、スクリプトを使用して S3 からコンテナ定義をインポートします。
4. aws elbv2 および aws eks コマンド、または AWS CloudFormation を使用して、ワークロードをスケーリングおよび更新します。
5. アプリケーションが EKS 上で正常に実行されるようになったら、ECS クラスターを廃止できます。

AWS コンピューティングの決定表: Beanstalk vs. ECS vs. Fargate

道を選び、それを監視する

Elastic Beanstalk、ECS、Fargateのどれを選ぶかは、どれだけの制御を望むか、そしてチームがインフラストラクチャの管理にどれだけの時間を費やせるかによって決まります。Beanstalkで迅速にサービスを開始する場合でも、ECSとFargateでコンテナをフル活用する場合でも、一つだけ変わらないことがあります。それは、可視性が重要だということです。

LogicMonitor は 3 つすべてを監視できるので、5 つの異なるダッシュボードを操作することなく、AWS 環境をスムーズに実行し続けることができます。 

よくあるご質問