ステップ3：タスク定義とサービス構築によるコンテナ実行環境の完成

今回のステップの概要とECサイトとの関連について

このステップでは、前回構築したFargateクラスターとECRにプッシュしたコンテナイメージを使用して、実際にサーバーレスコンテナアプリケーションを実行する設定を行います。具体的には、Fargate専用のECSタスク定義の作成、Application Load Balancer用セキュリティグループの設定、そしてAWS Fargateサービスによる完全サーバーレスコンテナ実行を構築します。

ECサイトにとって、このステップは「完全自動化された店舗運営システムの設計と開店」のような役割を果たします。タスク定義は自動運営マニュアル、セキュリティグループは自動入店管理システム、Fargateサービスは人手を一切必要としない完全自動化店舗に相当し、これらによってインフラ管理なしで安定したECサイトサービスの提供が実現されます。

このステップで学ぶこと

ECSタスク定義によるコンテナ実行設計
Application Load Balancerによる負荷分散設定
AWS Fargateでのサーバーレスコンテナ実行
セキュリティグループによるネットワークアクセス制御

リソースの関わりと構成説明

ステップ3で作成するリソースは、ECサイトの実際のサービス提供を可能にするものです。それぞれのリソースがECサイトにどのように関わるのかを説明します。

ECSタスク定義とアプリケーション設計の関わり

ECSタスク定義「コンテナ実行設計書」は、ECサイトの「店舗運営マニュアル」のような役割を果たします。どのコンテナイメージを使用し、どれだけのCPUとメモリを割り当て、どのポートで通信するかを詳細に定義します。これにより、一貫した品質でECサイトサービスを提供できます。

Application Load Balancerと負荷分散の関わり

Application Load Balancer「アプリケーション負荷分散装置」は、ECサイトの「顧客案内デスク」のような役割を果たします。複数のコンテナインスタンス間でトラフィックを適切に分散し、特定のコンテナに負荷が集中することを防ぎます。これにより、多くの顧客が同時アクセスしても安定したサービスを提供できます。

AWS Fargateとサーバーレス実行の関わり

AWS Fargate「サーバーレスコンテナ実行環境」は、ECサイトの「フルオートメーション店舗システム」のような役割を果たします。サーバーの管理や保守を一切必要とせず、コンテナの実行に必要なリソースを自動的に提供します。これにより、インフラ管理の負担なくECサイト運営に集中できます。

実際の手順

実際の手順では、たくさんの設定値を入力することになります。本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。

1. タスク定義の作成

ECS でコンテナアプリケーションをデプロイする前に、ECS で使われる基本的な用語を確認しましょう。

Note

【AWSでの役割】

ECSタスク定義は、アプリケーションのブループリントとなるJSONフォーマットのテキストファイルです。タスク定義では、使用するDockerイメージ、各タスクまたは各コンテナで使用するCPUとメモリの量、使用する起動タイプ、コンテナのネットワーキングモード、ログ設定、タスクが使用するIAMロールなど、アプリケーションを形成する1つ以上のコンテナを記述するパラメータを指定できます。

【オンプレミスでの対応】

オンプレミス環境では「Kubernetesのマニフェストファイル」や「Docker Composeファイル」が対応します。これらのファイルでは、コンテナの実行設定、リソース制限、ネットワーク設定などを定義しますが、クラウドプロバイダー固有の機能は利用できません。

用語	説明
タスク	ECS でコンテナを実行する際の最小の実行単位であり、1 つのタスクには 1 つ以上のコンテナを含むことができます
タスク定義	コンテナイメージやリソース量などを設定したテンプレートで、タスク定義をもとにタスクを起動します
サービス	タスクを複数実行し続けるように設定したり、ALB との連携を設定したりできます

1-1. タスク定義を作成する

マネジメントコンソールの検索バーに「ECS」と入力し、ECS ダッシュボードを開きます。
ECS ダッシュボードから「タスク定義」「新しいタスク定義の作成」を選択します。
タスク定義の名前やタスクを実行する環境に関して、設定していきます。

項目	設定値
タスク定義ファミリー	ecs-handson-task
起動タイプ	AWS Fargate
タスクサイズ (CPU/メモリ)	.25 vCPU / .5 GB
タスクロール	なし
タスク実行ロール	新しいロールの作成（デフォルト） or ecsTaskExecutionRole

Tip

【解説】Fargateのタスクサイズ制限

Fargate を使用する場合、あらかじめ決められたCPUとメモリの組み合わせから選択する必要があります。これは、Fargateがサーバーレス環境として最適化されており、効率的なリソース配分のために標準化された構成を提供しているためです。Fargateの場合、CPUとメモリの組み合わせは事前定義されており、これによりコストの最適化と性能の予測可能性が実現されています。サーバー管理が不要になる代わりに、この標準化により運用の簡素化とコスト効率の向上が図られています。

Note

【Fargateタスク定義の制約事項】

Fargateタスクでは、EC2起動タイプと比較していくつかの制約があります。主な制約として、GPUの使用不可、特権モードの実行不可、Docker ボリューム設定の制限、特定のLinuxパラメータの非サポートなどがあります。また、ネットワークモードは常にawsvpcモードが使用され、ホストネットワークモードは利用できません。これらの制約は、Fargateがセキュアで標準化されたサーバーレス環境を提供するための設計によるものです。詳細な制約事項については、Fargateタスク定義の違いをご参照ください。

続いて、実行するコンテナについて、設定していきます。

項目	設定値
コンテナの名前	rails-app
必須コンテナ	はい
イメージ URI	push したイメージの URI
コンテナポート	3000

また、「ログ記録」の「ログ収集の使用」のチェックを外します。

Tip

【解説】ECSログ収集機能の活用

Amazon ECS では、コンテナ内で出力したログを Amazon CloudWatch Logs や Amazon Kinesis Data Firehose、Splunk などの宛先に転送するように、タスクを設定できます。ここでは、簡単のためログの転送を無効化していますが、本番環境では適切なログ収集と監視の設定が重要です。ログ収集により、アプリケーションの動作状況の監視、トラブルシューティング、セキュリティ監査などが可能になり、運用品質の向上に大きく貢献します。

他の項目はそのままに「作成」をクリックします。

2. ALB用のセキュリティグループを作成する

このハンズオンでは、複数のタスクにリクエストを負荷分散するために Application Load Balancer (ALB) と呼ばれるロードバランサーを使用します。

Note

【AWSでの役割】

Application Load Balancerは、複数のターゲット（EC2インスタンス、コンテナ、IPアドレスなど）間で受信トラフィックを自動的に分散するフルマネージドなレイヤー7ロードバランサーです。ALBは、HTTPヘッダーやメソッド、クエリ文字列、ホストやパスベースのルーティングなどのパラメータに基づいた高度なリクエストルーティング機能をサポートし、TLS終端、HTTP/2、AWS Web Application Firewall (WAF) 統合などの重要な機能も提供します。

【オンプレミスでの対応】

オンプレミス環境では「HAProxy」「NGINX」「F5 BIG-IP」などのロードバランサーが対応します。これらのソリューションでは、ロードバランサーサーバーの構築、設定、監視、スケーリングをすべて自社で管理する必要があります。

2-1. セキュリティグループを作成する

マネジメントコンソールの検索バーに「EC2」と入力し、EC2 ダッシュボードを開きます。
EC2 ダッシュボードの「ネットワーク&セキュリティ」以下の「セキュリティグループ」から「セキュリティグループを作成」をクリックします。
インターネット上から HTTP (80 番) ポートにのみアクセス可能な ALB 用のセキュリティグループを作成しましょう。

項目	設定値
セキュリティグループ名	ecs-alb-sg
説明	ecs-alb-sg
VPC	ecs-handson-vpc
タイプ (インバウンドルール)	HTTP
ソース (インバウンドルール)	Anywhere-IPv4

Tip

【解説】セキュリティグループによるネットワークセキュリティ

アウトバウンドルールはそのままにしておいてください。セキュリティグループは、AWS VPC内でのファイアウォール機能を提供し、インスタンスレベルでのトラフィック制御を行います。インバウンドルールでHTTPトラフィックのみを許可することで、不要なポートへのアクセスを防ぎ、セキュリティを向上させます。本番環境では、より細かいアクセス制御や、HTTPSの使用、特定のIPアドレス範囲からのアクセス制限などを検討することが重要です。

上記の項目を設定したら「セキュリティグループを作成」をクリックします。

3. Fargateへのデプロイ

この手順では、実行環境として Fargate を使用してコンテナアプリケーションをデプロイしていきます。

Note

【AWSでの役割】

AWS Fargateは、Amazon ECSで使用できる技術で、サーバーやEC2インスタンスのクラスターを管理することなくコンテナを実行できます。Fargateを使用すると、仮想マシンのクラスターをプロビジョニング、設定、またはスケーリングする必要がなくなります。各Fargateタスクには独自の分離境界があり、基盤となるカーネル、CPUリソース、メモリリソース、またはElastic Network Interfaceを他のタスクと共有しません。

【オンプレミスでの対応】

オンプレミス環境では「Kubernetesクラスター」や「OpenShift」が対応します。ただし、これらの環境では、ワーカーノードの管理、OS のパッチ適用、クラスターの監視、キャパシティプランニングなど、すべてのインフラ管理作業を自社で行う必要があります。

3-1. Fargate用のサービスを作成する

作成したクラスターの「サービス」タブから「作成」をクリックします。
「サービスの詳細」を設定します。

項目	設定値
タスク定義ファミリー	ecs-handson-task
タスク定義のリビジョン	1 (最新)
サービス名	ecs-fargate-service

「環境」を設定します。

項目	設定値
既存のクラスター	ecs-handson-cluster（デフォルト）
コンピューティングオプション	キャパシティプロバイダー戦略（デフォルト）
キャパシティプロバイダー戦略	カスタムを使用 (アドバンスト)
キャパシティプロバイダー	FARGATE
プラットフォームのバージョン	LATEST（デフォルト）

「デプロイ設定」を設定します。

項目	設定値
必要なタスク	2
ヘルスチェックの猶予期間	30

次に、サービスを作成するネットワークを設定します。

項目	設定値
VPC	ecs-handson-vpc
サブネット	2 つのパブリックサブネット（デフォルト）
セキュリティグループ	既存のセキュリティグループを使用（デフォルト）
セキュリティグループ名	default & ecs-alb-sg

セキュリティグループは、必ずdefaultに加えてecs-alb-sgを設定してください。

最後に、タスクへのリクエストを受け付ける ALB の設定をしましょう。

項目	設定値
ロードバランシングを使用	ON
ロードバランサーの種類	Application Load Balancer（デフォルト）
コンテナ	rails-app 3000:3000
Application Load Balancer	新しいロードバランサーの作成（デフォルト）
ロードバランサー名	ecs-fargate-alb
リスナー	新しいリスナーを作成（デフォルト）
ポート / プロトコル	80 / HTTP（デフォルト）
ターゲットグループ	新しいターゲットグループの作成（デフォルト）
ターゲットグループ名	ecs-fargate-tg

以上を設定したら、他の項目はそのままに「作成」をクリックしましょう！ALB などのリソースも同時に作成するため、作成には数分かかります。

3-2. 作成したサービスを確認する

作成したサービス名をクリックし詳細画面を開くと、タスクが 2 つ起動していることを確認できます。
続いて、デプロイされたアプリケーションにアクセスするために「正常性とメトリクス」タブ内のロードバランサー名をクリックします。
EC2 ダッシュボード内のロードバランサーが表示されるので、ALB の DNS 名をコピーします。
ブラウザで新規タブを開きDNS名を貼り付けます。
無事にRails アプリケーションが表示されれば完成です！

画面が表示されない場合はhttpではなくhttpsでアクセスしていないか確認してください

このステップで何をしたのか

このステップでは、ECSクラスターとECRリポジトリを基盤として、実際にコンテナアプリケーションを実行する環境を完成させました。具体的には、ECSタスク定義を作成してコンテナの実行設定を定義し、Application Load Balancer用のセキュリティグループを設定してネットワークアクセス制御を行い、AWS Fargateを使用したサーバーレスコンテナサービスを構築しました。

ECサイトでどのような影響があるのか

この構成により、ECサイトは完全に動作する本格的なクラウドアプリケーションとして稼働開始しました。Fargateによるサーバーレス実行により、インフラ管理の負担が大幅に軽減され、Application Load Balancerにより複数のコンテナインスタンス間での負荷分散が実現されました。これにより、多数の顧客が同時にアクセスしても安定したサービスを提供でき、まさに本格的なオンライン店舗としての機能を果たすようになりました。

技術比較まとめ表

技術領域	AWS	オンプレミス
タスク定義	ECSタスク定義 JSON形式のブループリント管理	Kubernetesマニフェスト YAML形式の設定ファイル管理
負荷分散	Application Load Balancer フルマネージドなレイヤー7ロードバランサー	HAProxy/NGINX 自前でのロードバランサー構築・運用
サーバーレス実行	AWS Fargate サーバー管理不要のコンテナ実行	物理サーバー/VM OS・ミドルウェアの継続的な管理
ネットワークセキュリティ	セキュリティグループソフトウェア定義のファイアウォール	iptables/物理ファイアウォール手動でのルール設定・管理

学習において重要な技術的違い

1. 実行環境の抽象化レベル

AWS: Fargateにより、サーバー管理から完全に解放され、コンテナの実行のみに集中できます。
オンプレミス: Kubernetesでも、ワーカーノードのOS管理、パッチ適用、ハードウェア保守が必要です。

2. 負荷分散の実装複雑さ

AWS: ALBの作成と設定のみで、高度な負荷分散機能が利用可能です。
オンプレミス: ロードバランサーの選定、構築、設定、監視、スケーリングをすべて自社で実装する必要があります。

3. セキュリティ設定の柔軟性

AWS: セキュリティグループにより、GUIベースでの直感的なファイアウォール設定が可能です。
オンプレミス: iptablesや専用ファイアウォール機器での複雑なルール設定が必要です。

4. 運用監視の統合性

AWS: CloudWatchとの自動統合により、包括的な監視とアラート機能が提供されます。
オンプレミス: 監視システムの構築、メトリクス収集、アラート設定をすべて独自に実装する必要があります。

実践チェック：画面キャプチャで証明しよう

下記のチェック項目について、実際にAWSマネジメントコンソールで設定ができていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。

ECSタスク定義の作成確認
ALB用セキュリティグループの作成確認
Fargateサービスの作成確認
実行中のタスク確認（2つのタスクが動作）
Application Load Balancerの作成確認
ブラウザでのRailsアプリケーション表示確認（ALB DNS名経由）

提出方法： 各項目ごとにスクリーンショットを撮影し、まとめて提出してください。ファイル名やコメントで「どの項目か」が分かるようにしてください。

構成図による理解度チェック

ステップ2のVPCとECSクラスター構成図に、このステップで作成したタスク定義、ALB、Fargateサービスを追記して、完全なコンテナアプリケーション実行環境の構成を完成させましょう。

なぜ構成図を更新するのか？

基盤構築から実際のサービス提供まで、システムが完全に動作する状態になりました。この変化を視覚的に理解することで、各コンポーネントがどのように連携してエンドユーザーにサービスを提供しているかを明確に把握できます。特に、トラフィックフローとコンテナライフサイクルの理解が重要です。

トラフィックフロー: インターネット → ALB → Fargateタスクへの通信経路
コンテナライフサイクル: ECRイメージ → タスク定義 → Fargateタスクへの展開プロセス
負荷分散メカニズム: ALBによる複数タスクへのリクエスト分散の仕組み

構成図の書き方

ステップ2で作成したVPCとECSクラスター構成図をベースに、以下の要素を追記してみましょう。

タスク定義: コンテナ実行設計書として表現
Application Load Balancer: インターネットゲートウェイの後段に配置
Fargateタスク: パブリックサブネット内に2つのタスクを配置
セキュリティグループ: ALBとタスク間のアクセス制御を表現
トラフィックフロー: ユーザー → ALB → タスクへの矢印で表現

💡 ヒント: ALBを中央に配置し、そこから2つのFargateタスクへ分散する様子を描きましょう。セキュリティグループは盾のマークで表現できます。

理解度チェック：なぜ？を考えてみよう

AWSの各リソースや設計には、必ず”理由”や”目的”があります。下記の「なぜ？」という問いに自分なりの言葉で答えてみましょう。仕組みや設計意図を自分で説明できることが、真の理解につながります。ぜひ、単なる暗記ではなく「なぜそうなっているのか？」を意識して考えてみてください。

Q. なぜECSではタスク定義を作成する必要があるのか？

Q. なぜApplication Load Balancerが複数のタスクの前段に必要なのか？

Q. なぜFargateを使用するとサーバー管理が不要になるのか？

Q. なぜセキュリティグループでネットワークアクセス制御を行うのか？

今回のステップで利用したAWSサービス名一覧

ECSタスク定義：コンテナ実行設計書
Application Load Balancer：アプリケーション負荷分散装置
AWS Fargate：サーバーレスコンテナ実行環境
セキュリティグループ：仮想ファイアウォール