AWS再入門ブログリレー2022 Amazon ECS編

こんにちは。AWS事業本部トクヤマシュンです。

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の26日目のエントリです。

このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう！という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。26日目のテーマは「Amazon ECS」です。

Amazon ECSとは？

Amazon ECSとは「フルマネージドなコンテナオーケストレータ」です。
コンテナ運用は一般的に複数のホストからなるクラスター構成を取り、その上で複数のコンテナが連携するワークロードを扱います。
コンテナワークロードを管理するシステムがオーケストレータで、AWSのフルマネージドなオーケストレータサービスがECSです。

ECSにより、下記のような設定を行うことができます。

• コンテナの配置管理
• Load Balancer統合による負荷分散
• コンテナの状態監視と自動復旧
• コンテナのスケーリング
• コンテナのIAM権限管理
• CloudWatch Metrics・Logs統合

ECSはDockerの知識に加えて、ECS特有の知識も必要となることが初学者の理解を難しくしていると感じます。
本記事ではECS特有の知識を、データプレーンとコントロールプレーンという概念に分けて説明します。

データプレーン

コンテナが稼働する環境を指します。大きく、下の3つに分類されます。

1.ECS on Fargate

ECS on Fargateは「フルマネージドなデータプレーン」です。
AWS Lambdaがリソースの管理を不要とするように、 動作するホストを意識することなくコンテナを稼働させることができます。

メリットとして、パッチ適応といったOSインフラの管理負荷を軽減できる、ホスト自体のスケーリングの考慮が不要、等があります。
デメリットとして、OSパラメーター等の詳細設定が不可、コンテナが稼働するホストにログインできない、等があります。

少し前までは料金も高かったですが、段々と安くなってきていてECSデータプレーンとして第一の選択肢となってきている印象です。
ホストのパッチ管理が不要になるメリットがとても大きいので、積極的に検討するのが良いと思います。

2.ECS on EC2

ECS on EC2は「EC2上で動作するデータプレーン」です。
自身の構築したEC2上でAmazon ECSコンテナエージェントを実行することで、EC2上にECSで管理可能なコンテナを稼働させることができるようになります。なお、ECSコンテナエージェントはAmazonによって提供されるECS対応AMIに含まれており、ここからEC2を起動させた場合には個別インストールは不要です。

メリットは、ホストのバージョンやパラメータを設定したり、ホストにログインして詳細設定やログ調査が可能なことです。
デメリットは、OSやミドルウェアへのパッチ適用やクラスタ管理が必要となることです。

3.ECS Anywhere

ECS Anywhereは「オンプレミス上で動作するデータプレーン」です。
データセンタやオフィスなど、自身の所持するハードウェアマシン上でコンテナを稼働させます。
なお、コントロールプレーンはAWS上でフルマネージドにて動作します。

メリットとしては、ハードの部分まで含めてホストを管理できることです。　　 デメリットはその裏返しでハードまで自分で管理が必要なことです。
ガバナンス要件でAWS上のリソースを利用できなかった場合等に利用するイメージです。

コントロールプレーン

コントロールプレーンでは4つの概念が登場します。

1.タスク定義

JSON形式で記述されるタスクのテンプレートです。マネジメントコンソールから作成も可能です。
コンテナで使用するDockerイメージや各タスク・コンテナに割り当てるCPUやメモリの量、環境変数などの稼働するタスクの設定を記述します。
タスク定義には複数のコンテナを指定することができ、1つのタスクとして複数のコンテナを稼働させることも可能です。

2.タスク

タスク定義を元に作られる、アプリケーションの実行単位です。
データプレーンの上でタスクが実行されることで、アプリケーションが動作します。

3.サービス

指定した数のタスクを同時に実行して維持するスケジューラーです。
タスクが何らかの理由で失敗または停止した場合、サービスはタスク定義から別のタスクを起動し、必要数を維持します。
また、サービスを活用することでタスクの負荷分散・スケーリングを行うことも可能となります。

4.クラスター

タスクまたはサービスの論理グループがクラスターです。
実体としてはデータプレーンで定義されるリソースの集合です。

触ってみる

では、実際に触ってみたいと思います。

AWSの提供するハンズオンであるIntroduction to Amazon ECSをベースに、ECS on FargateとECS on EC2の2つのパターンで実行してみます。

ECS on Fargateでのデモ

ハンズオン記載の通りの手順で実行すると、Fargate上で1つのタスクを稼働させることができます。

ECS on Fargateで稼働するタスク数の変更

ここでは、稼働するタスクの数2つに増やしてみましょう。

サービスの設定から、タスクの数を1→2に増加させてみます。

すると、サービスデプロイメントで必要数が2となり、起動保留中のタスク数が1となります。

時間が経つと、実行中の数が2となり、2つのタスクを稼働させることができました。

今回は手動でタスクの数をスケールさせましたが、オートスケーリングと組み合わせるとCPUやメモリ使用率に応じてスケールアウト/スケールインさせることも可能です。

ECS on EC2でのデモ

では、ECS on EC2でもタスクを稼働させてみましょう。

前準備として、Fargateで作ったサービス・タスク定義・クラスター・ALBのTarget Groupを削除しておきます。

下記の流れでECS on EC2にてタスクを稼働させます。

• クラスター作成
• タスク定義作成
• サービス作成

クラスター作成

ECSのコンソールからクラスターの作成ボタンをクリックします。

クラスターテンプレートの選択では、EC2 Linux + ネットワーキングを選択します。

クラスターの設定では下記を設定します。

• クラスター名
• EC2インスタンスタイプ
  • t2.micro
• インスタンス数
  • 1
• EC2 AMI ID
  • Amazon Linux 2 AMIを選択
  • ECSコンテナエージェントインストール済のAMIのみがリストに表示される

ネットワーキングは、今回構築する対象のVPC、サブネット、セキュリティグループを設定し、作成まで行います。

クラスターの作成ができました。この時点で登録済みコンテナインスタンスとしてEC2インスタンスが1つ登録されます。

タスク定義作成

次に、コンソールから新しいタスク定義の作成をクリックします。

起動タイプの互換性ではEC2を選択します。

タスクとコンテナの定義の設定では、タスク定義名、タスクロール、タスク実行ロールを設定します。

タスクサイズでは下記を選択し、コンテナの追加をクリックします。

• タスクメモリ
  • 512
• タスクCPU
  • 256

コンテナ名、イメージを設定し、ポートマッピングでは80:80を設定します。 これにより、コンテナインスタンスの80ポートにコンテナの80ポートがマッピングされます。

環境変数には、DB_HOST、DB_USER、DB_PASSを設定し、タスク作成まで行います。

サービス作成

タスクができたら、サービスの作成を実施します。 アクション→サービスの作成を選択します。

下記を設定し、サービスを作成します。

• 起動タイプ
  • EC2
• クラスター
  • 作成したクラスター名
• サービス名
  • 今回のサービス名（simplechat-ec2）
• タスクの数
  • 1

ロードバランシングではApplication Load Balancerを選択します。

ロードバランサのプロダクションリスナーポートは　新規作成で80番を設定し、サービスの作成まで実施します。

クラスターのECSインスタンス上で、サービスを起動することができました。

これで、ECS on EC2でタスクを稼働させることができました。

終わりに

以上、『AWS 再入門ブログリレー 2022』の 26日目のエントリ『Amazon ECS』編でした。紹介しきれていない機能や日々のアップデートがあるのでぜひチェックしてみてください。
明日 (3/11) はたかくにの「AWS Network Firewall」の予定です。お楽しみに！！