テクノロジー 2025.1.14

【初心者向け】 Amazon ECSの基本概念をわかりやすく解説してみた

AKIHISA

Amazon ECSとは
オーケストレータとは
オーケストレータの構造
Amazon ECSのコンポーネント　
Amazon ECSの機能
おわりに
関連記事

みなさんこんにちは！　開発統括部のAKIHISAです！

現在の開発において主流となっている「コンテナ」

AWSに提供されているAmazon ECSは、そんなコンテナを簡単に管理・運用できる強力なサービスです。

しかし、Amazon ECSは多機能なため、初めて利用する方はその仕組みや概念を理解するのが難しいと感じるかもしれません。本記事では、Amazon ECSの基礎を初心者の方にも分かりやすく解説していきます！

監修：AKIHISA
■保有資格
・応用情報技術者試験
・AWS Certified Cloud Practitioner
・AWS Certified Solutions Architect - Associate
・AWS Certified Developer - Associate
・AWS Certified SysOps Administrator - Associate
・AWS Certified Data Engineer - Associate
・AWS Certified Solutions Architect - Professional
・AWS Certified DevOps Engineer - Professional
・AWS Certified Advanced Networking - Specialty
・AWS Certified Security - Specialty
・AWS Certified Machine Learning - Specialty
・AWS Certified Database - Specialty
・AWS Certified Data Analytics - Specialty
・AWS Certified: SAP on AWS - Specialty
・Pythonエンジニア認定基礎試験
・Pythonエンジニア認定データ分析試験
・Pythonエンジニア認定実践試験
・Oracle Certified Java Programmer, Silver SE 11
・G検定
製造業からIT業界未経験でALHへ入社
AWSでの開発環境整備に力を入れており、IaC(Infrastructure as Code)やCI/CDを得意としている。
現在のプロジェクトでは、AWS環境にて構築しているWebサービスの運用保守エンジニアとして参画中。
好きなAWSサービスはAWS CDKとAmazon Q Developer

Amazon ECSとは

AWS公式サイトに、Amazon ECSの説明は次のように書かれています。

Amazon Elastic Container Service (Amazon ECS) はフルマネージドコンテナオーケストレーションサービスであり、コンテナ化されたアプリケーションをより効率的にデプロイ、管理、スケールするのに役立ちます。
https://aws.amazon.com/jp/ecs/

専門用語が多すぎて「Amazon ECSって何をするサービス？」となりませんか？

簡単に言えば、Amazon ECSはアプリケーションを動かすための「コンテナ」を自動で効率的に管理してくれるAWSのサービスです。

どのような仕組みで成り立っているのか、専門用語がわからない、といった疑問を解消することがこの記事のゴールです！

オーケストレータとは

オーケストレータは、複数のコンテナを効率的に管理するためにスケーリング・耐障害性の向上・コンテナのデプロイなどの役割があります。

詳しい説明をする前に、まずはWebサービスに使われているコンテナをイメージしてみましょう。

例えば、ECサイトで商品を購入するケースを考えてみます。

ユーザーが商品ページを開き「カートに入れる」ボタンをクリックすると、商品情報（商品名、価格、数量など）がサーバーへ送信されます。

このWebサービスのコンテナは、「大量のリクエスト」や「インフラの障害」に耐え、アプリケーションを更新したときに「問題なくデプロイ」できるでしょうか？

単にWebアプリケーションをコンテナ化しただけでは、これらの問題には耐え切ることができないことが多いです。

これらの問題を解決し、複数のコンテナを効率的に管理・スケールさせるための仕組みがオーケストレータです！

オーケストレータの機能について詳しく説明します。

スケーリング

スケーリングは、システムの負荷に合わせてコンテナ数を自動調整し、アプリケーションの可用性を高める仕組みです。

コンテナには設定されたリソース（CPU、メモリなど）が割り当てられ、アプリケーションを実行しています。

Webサービスでは「お昼時はアクセスが多い」「セール中は特にアクセスが集中する」「SNSで話題になりアクセスが急増する」といったように、時間帯やイベントによってリクエスト数が大きく変動します。

常に最大負荷時に対応できるだけのリソースを確保しておくとコストが無駄になってしまいます。

そこで、リクエスト数に応じてコンテナの数を動的に増減させる、つまりスケーリングを行うことで、効率的なリソース運用が可能になります。

しかし、このスケーリングを人手で行うのは非常に困難です。

例えば負荷が高まったことを監視し、新しいコンテナを作成してロードバランサーに登録するといった一連の作業を、人がリアルタイムで行うのは、ほぼ不可能だと思います。

オーケストレータは、このようなスケーリングを自動化します。

リクエスト数に基づいてコンテナを自動的に増減させ、システムの負荷を常に最適な状態に保ちます。

耐障害性の向上

全てのコンテナが１つのホスト上に配置されていたと仮定します。中核となるホストに障害が発生してしまった場合、Webサービス全体が停止するリスクがあります。

コンテナオーケストレータは、複数のホストにコンテナを分散配置することでこの問題を解決します。

これにより、1つのホストがダウンしても他のホスト上で稼働しているコンテナがサービスを継続できるため、システム全体の可用性が向上します。

さらに、オーケストレータは複数のホストに分散配置されたコンテナをグループ化し、ロードバランサーと連携することで負荷を分散できます。

これにより、システム全体の処理能力を高め安定性を向上させることができます。

コンテナのデプロイ

アプリケーションを更新した際、稼働中のコンテナを新しいバージョンに置き換える必要があります。

オーケストレータはアプリケーションを正常に保ちつつ、自動化することで安全かつスムーズにデプロイが可能です。

これにより、デプロイ時のシステムのダウンタイムを最小限に抑え、安定したサービスを提供できます。

オーケストレータの構造

オーケストレータの全体像は、次図のように「コントロールプレーン」「データプレーン」「イメージレジストリ」で構成されています。

それぞれどのような仕組みで成り立っているかを見ていきましょう

コントロールプレーン

コントロールプレーンは、オーケストレータの「頭脳」でありシステム全体を管理します。

前章で説明したように、オーケストレータは「スケーリング」「耐障害性の向上」「コンテナのデプロイ」など様々な機能を提供しています。

これらの機能を実現するために、コントロールプレーンはシステム全体の状態を監視し、必要な処理を実行します。

AWSにおいては、Amazon ECS, Amazon EKSがコントロールプレーンとして提供されています。

特徴	Amazon ECS	Amazon EKS
ベースとなる技術	AWS独自のオーケストレーションエンジン	Kubernetes (オープンソース)
強み	AWSサービスとの連携がスムーズ、学習コストが比較的低い	高度なカスタマイズ性、豊富な機能、活発なコミュニティ
適しているケース	AWSエコシステムを活用したい、シンプルな構成で運用したい	Kubernetesの経験がある、高度な機能が必要な場合、最新の技術を導入したい

データプレーン

データプレーンは、コンテナが実際に稼働している環境であり、コントロールプレーンの指示に基づいてコンテナが実行されます。

AWSにおいては、Amazon EC2, AWS Fargateが代表的なデータプレーンとして提供されています。

特徴	Amazon EC2	AWS Fargate
柔軟性	高い：OS、GPUなど細かい設定が可能	比較的低い：OSやバージョンは指定不可
管理の容易さ	低い：OS管理、セキュリティパッチ適用などが必要	高い：ホスト管理が不要
適しているケース	高度なカスタマイズが必要な場合、特定のOSや環境が必要な場合	サーバーレスな環境で迅速に開発・運用したい場合、ホスト環境に依存しないアプリケーション

また、Amazon ECS Anywhere, Amazon EKS Anywhereを利用すれば、コントロールプレーンをAWS上に、データプレーンをオンプレミス環境に置くことも可能です

イメージリポジトリ

イメージリポジトリは、コンテナイメージを保存および管理する場所です。

コンテナを実行する際、イメージリポジトリから必要なイメージを取り出して、コンテナを作成します。

AWSにおいては、Amazon ECRがイメージリポジトリとして提供されています。

Amazon ECRは、Amazon ECSやAmazon EKSと簡単に連携でき、セキュアなイメージの保存と管理を可能とします。

Amazon ECRやAmazon EKSでは、Docker Hubなどのパブリックなイメージリポジトリも利用できます。

コントロールプレ─ンをAmazon ECS、データプレーンをAWS Fargate、イメージリポジトリをAmazon ECRにした場合、オーケストレータの全体像は次の図のようになります。

Amazon ECSのコンポーネント　

これまでAWSにおけるオーケストレータの構造を見てきましたが、本章では具体的なサービスであるAmazon ECSに焦点を当てて解説していきます。

Amazon ECSは、ECSクラスター・ECSサービス・ECSタスク・タスク定義という主要コンポーネントで構成されています。

それぞれのコンポーネントがどのような役割を果たしているのか、詳しく見ていきましょう。

ECSタスク

ECSタスクは、1つ以上のコンテナを含むコンテナアプリケーションを実行するための最小単位です。

1つのECSタスクは、複数のコンテナによって構成されることもあります。

例えば、Webアプリケーションを実行するECSタスクの場合、Webサーバーのコンテナ（Nginxなど）とアプリケーションロジックを実行するコンテナが組み合わされて1つのECSタスクを構成します。

つまり、ECSタスクは「アプリケーションを構成するために必要な全てのコンテナをまとめたもの」と捉えることができます。

タスク定義

タスク定義は、ECSタスクを起動するための設定が書かれたテンプレートです。

コンテナイメージやECSタスクに割り当てるCPU・メモリなど、ECSタスクの詳細を決定する様々なパラメータが設定されます。

主な設定項目を以下表にて紹介します。

設定項目	内容
ファミリー名	タスク定義を一意に識別するための名前。初回作成時にリビジョンが1として定義され、タスク定義が更新されるごとにリビジョンが1ずつ増加します。
起動タイプ	ECSタスクを実行する環境（データプレーン）を指定します。FARGATE, EC2, EXTERNALから選択できます。
タスクロール	ECSタスクのライフサイクルイベント（開始、停止など）に適用されるIAMロールを指定します。
タスク実行ロール	コンテナ内のアプリケーションからAWS APIを呼び出す際に適用されるIAMロールを指定します。
ネットワークモード	コンテナがデータプレーン上でどのようにネットワークに接続するかを指定します。
タスクサイズ	ECSタスク単位で割り当てるCPUとメモリの量を指定します。
コンテナ定義	ECSタスクを構成するコンテナに関する詳細な設定を行います。コンテナイメージ、コンテナ単位のCPUやメモリ、ポートマッピングなどを指定できます。
ボリューム	コンテナで使用される永続的なストレージを指定します。Amazon EBS, Amazon EFS, FSx for Windows File ServerなどのAWSサービスや、Dockerボリューム, バインドマウントが利用可能です。

ECSサービス

ECSサービスは、ECSタスクを一定数実行し続けるための管理単位です。

指定したタスク定義に基づいて、ECSタスクを自動的に作成・開始・停止することでアプリケーションの可用性を高めます。

ECSサービスは、ECSタスクのライフサイクル全体を管理しています。

ECSタスクが失敗・停止した場合、自動的に新しいECSタスクを起動することで指定したタスク数を維持します。

負荷分散のためにElastic Load Balancing（ELB）と連携することや、Auto Scalingと組み合わせることで、負荷に応じて自動でスケールイン・スケールアウトさせることも可能です。

ECSクラスター

ECSクラスターは、複数のECSタスク実行環境をまとめ、コンテナアプリケーションを実行するための論理的なグループです。

ECSタスクのスケーリングに応じて、EC2やFargateなどのECSタスク実行環境の数を自動的に調整します。

ECSクラスター内ではECSサービスやスタンドアロンタスクを実行できます。

Amazon ECSの機能

Amazon ECSの基本的な機能について解説してきました。

ここでは、Amazon ECSで利用できる便利な機能について詳しく説明します。

Auto Scaling

ECSサービスにて設定できる機能で、需要の変化に合わせてECSタスクの実行数を自動的に調整します。

Auto Scalingでは、スケーリングポリシーを設定し、どのような指標を基にスケールするのかを決定します。

主なスケーリングポリシーとして、ステップスケーリング、ターゲット追跡スケーリング、予測スケーリングが提供されています。

ステップスケーリング

CloudWatchアラームを利用し、CPU使用率などのメトリクスを監視し、設定した閾値を超えた場合に、タスク数を段階的に増減させます。

例:

CPU使用率が60%を超えたら、現在のタスク数に対して10%増やし、80%を超えたら30%増やす。

CPU使用率が40%を切ったら10%減らし、20%を切ったら30%減らす。

このように、複数のステップを設定することで、負荷の変化に柔軟に対応できます。

ターゲット追跡スケーリング

CloudWatchメトリクスを監視し、設定した目標値に近づけるようにタスク数を調整します。

例:

CPU使用率の目標値を50%に設定した場合、CPU使用率が50%を超えるとECSタスクを増やす。

CPU使用率が50%を下回るとすぐにECSタスクが停止するのではなく、緩やかにECSタスクが停止される。

ステップスケーリングよりもシンプルな設定で、目標とするメトリクスの値を一定に保てます。

予測スケーリング

CloudWatchメトリクスの過去のデータを基に将来の需要を機械学習で予測し、それに合わせてタスク数を調整します。

例:

過去のCPU使用率のデータから、平日のお昼時にトラフィックが多いというパターンが判明した場合、その時間帯にECSタスクを増やすことができる。

ECSタスクを増やす時間帯に対して、事前に起動できる。

予測のみ設定できるので、過去のデータからどのようなチャートでスケーリングするのかを確認できます。

Container Insights

Amazon ECSの基本的なメトリクスでは、ECSタスクやコンテナ単位での詳細なメトリクスを取得できませんでした。

例えば、特定のECSタスクに過度の負荷がかかっている場合でも、ECSサービス全体のパフォーマンスに問題がないように見えてしまうことがありました。

このような課題を解決するために、より詳細なメトリクスやパフォーマンスを計測できるContainer Insightsが提供されています。

Container Insightsを使用すれば、ECSクラスター, インスタンス, ECSサービス, タスクファミリー単位のより細かいメトリクスを監視したり、ECSタスク単位のパフォーマンスを計測できます。

さらに、オブザーバビリティが強化されたContainer Insightsを使用すれば、Container Insightsの機能に加え、ECSタスクとコンテナの細かなメトリクスやコンテナ単位のパフォーマンスを計測できます。

これにより、インシデント発生時に問題が発生している箇所を迅速に特定し、問題解決までの時間を短縮できます。

キャパシティープロバイダー

キャパシティープロバイダーは、ECSクラスターのデータプレーンのリソースを管理し、柔軟なスケーリングを可能にする機能です。

データプレーンにはEC2とFargateの2種類を選択できると紹介しました。

キャパシティープロバイダーでは、それぞれに対応して設定できます。

EC2: AutoScaling Groupを指定する。

Fargate: FARGATEまたはFARGATE_SPOTを指定する。

複数のキャパシティープロバイダーをグループ化し、スケーリング時の挙動を定義したものをキャパシティープロバイダー戦略と呼びます。

キャパシティープロバイダーは、EC2とFargateで挙動が異なるため分けて説明します。

ECS on EC2

従来のECS on EC2では、EC2インスタンスのAutoScaling Groupと、ECSタスクのスケーリングを個別に管理する必要がありました。

キャパシティープロバイダーを利用すると、ECSタスクのスケーリングに合わせてEC2インスタンスのAutoScaling Group設定が書き変わります。

スケーリングを自動的に行えるため、管理を簡素化できます。

ECS on Fargate

ECS on Fargateでは、FARGATEとFARGATE_SPOTの2つのキャパシティープロバイダーを利用できます。

FARGATE: オンデマンド型のFargateで、安定した性能が求められるワークロードに適している

FARGATE_SPOT: スポットインスタンスを利用したFargateで、コストを抑えて利用したいワークロードに適している。

FARGATE_SPOTは、AWSのリソース状況によっては中断される可能性がある点に注意が必要です。

キャパシティープロバイダー戦略の例：

常に2つのECSタスクが稼働している必要がある場合、以下の様な戦略が考えられます。

ベース: FARGATE=2, FARGATE_SPOT=0

ウェイト: FARGATE: FARGATE_SPOT = 1:1

この設定では、まず2つのFARGATEタスクを起動し、負荷が増加するとFARGATEとFARGATE_SPOTが1:1の割合でスケールアウトします。

Service Connect

Service ConnectはECSサービス間の通信を簡素化する機能です。

例えば、ECサイトで商品を購入するWebサービスの例を考えます。

ECサイトのフロントエンドであるECSサービスから、商品検索や決済などのECSサービスへ接続する際にService Connectが役に立ちます。

Cloud Mapで管理される名前空間に対してECSサービスを登録し、名前解決によってECSサービス間の通信を実現します。

名前空間が同一であれば、ECSクラスターやVPCが異なってもECSサービス間の通信が可能です。

特徴

名前解決: Cloud Mapの名前空間を活用し、ECSサービス名を指定することで、対応するECSタスクのIPアドレスを自動的に解決する。

メトリクスとログ: 名前解決要求に関するメトリクスやログを取得でき、トラブルシューティングに役立つ。

追加リソース: ECSタスクに追加のコンテナが必要となるため、わずかな追加のコンピューティングリソースが必要になる。

デプロイ戦略: ローリングアップデートに対応している。

分散: Service Connectの仕組みでECSタスク間への接続を分散する。

サービス検出

ECSサービスへの通信を簡素化する機能です。

Service Connectと同様なユースケースで使うことができますが、細かな違いがあるので要件に合わせて使い分ける必要があります。

サービス検出は、Cloud MapとRoute 53を連携させてECSタスクのIPアドレスを管理し、ECSサービスへの通信を実現します。

Cloud Mapで登録されたECSタスクのIPアドレスが、Route 53のプライベートホストゾーンに登録されます。

プライベートホストゾーンによって名前解決しているため、ECSサービスだけでなく、EC2インスタンスなど他のVPCリソースからの接続も可能です。

特徴

名前解決: Route 53のDNSレコードを使用して、ECSタスクのIPアドレスを解決する。

メトリクスとログ: 名前解決要求に関するメトリクスやログは取得できない。

追加リソース: 追加のコンピューティングリソースは不要。

分散: Route 53の複数値回答ルーティングポリシーにより、ECSタスク間の接続を分散する。

デプロイサーキットブレーカー

デプロイサーキットブレーカーは、新しいバージョンのECSサービスへのデプロイ中に異常が発生した場合に、自動的に以前の安定したバージョンへロールバックする機能です。

これによりECSサービスの可用性を確保し、インシデント発生時の影響を最小限に抑えられます。

デプロイタイプがローリングアップデートの場合にのみ使用できます。

デプロイサーキットブレーカーは、以下の2つの段階でロールバックを判断します。

ECSタスク起動失敗: 新しいバージョンのECSタスクが起動できず、失敗回数が事前に設定された回数を超えた状態。

ヘルスチェック失敗: ロードバランサーによるヘルスチェックに繰り返し失敗し、再起動されたECSタスク数が指定回数を超えた状態。

おわりに

Amazon ECSの基本について解説してきました！

この記事を読み終えた皆さんなら、冒頭で紹介したAWS公式のAmazon ECSについて理解できるようになったのではないでしょうか。

Amazon Elastic Container Service (Amazon ECS) はフルマネージドコンテナオーケストレーションサービスであり、コンテナ化されたアプリケーションをより効率的にデプロイ、管理、スケールするのに役立ちます。
https://aws.amazon.com/jp/ecs/

Amazon ECSを活用することで、あなたが作成しているもしくは考案中のアプリケーションは、よりスケーラブルで、信頼性の高いものになるはずです。

ただ、実際にAmazon ECSを導入する際、どこから手をつければ良いか悩む方もいるのではないでしょうか？

まずは、AWSマネジメントコンソールにてAmazon ECSのサービスを試してみましょう！

AWS Hands-on for Beginnersには、簡単なチュートリアルも用意されていますのでぜひチャレンジしてみてください！

[AWS Hands-on for Beginners Amazon Elastic Container Service入門コンテナイメージを作って動かしてみよう](https://pages.awscloud.com/JAPAN-event-OE-Hands-on-for-Beginners-ECS-2022-reg-event.html)

※ 2024/7/29以降、上記ハンズオンで使用しているAWS Cloud9が新規アカウントで利用不可になっています。

これから初めてハンズオンを始める場合は、以下ブログ記事を参照ください。