ECSについて、あまり触れてこなかったので、アウトプットがてらまとめていこうと思います。
コンテナとは
ECSをまとめるにあたって、避けては通れないのが、コンテナです。
コンテナとは、アプリケーションを動かすための環境を仮想化する技術のことです。
アプリケーションを動作させるには、OS、ミドルウェア、プログラム、ライブラリなど必要な要素が複数あります。
コンテナはそれらの要素を役割に応じて組み合わせてパッケージングしていく技術という認識です。
例えば、Webサーバのコンテナを立てるってなった場合は、以下がインストールされている仮想環境を作ります。
・OS:Linux
・ミドルウェア:Nginx
※OSはあくまで、ホスト環境のOSをコンテナ内で指定しているOSっぽく動作させているだけで、仮想環境みたいにOSごとインストールしているわけでないので、ホスト環境のOSに依存します。つまり、ホストOSによってはコンテナ上で動かないOSなんかもあるということですので、ご注意を。
このように、役割に応じてそれぞれコンテナ内に必要な要素をインストールして、パッケージするのがコンテナの役割になります。
コンテナ技術の利点
ここからは、コンテナ技術が使われているツールとして有名なDockerを用いて解説しようと思います。
先ほど、コンテナについて説明しましたが、コンテナの何がいいんだって思われる方もいるかと思います。
そこで、ここではコンテナ技術を使う利点について、説明します。主な利点としては次の4点になります。
1点目:ホストOSが違っても正常に動作する
例えば、Dockerを動かす環境がmacOSであれ、Windowsであれほとんどの場合、同じ構成のものが正常に動作します。
※Dockerは元々Linux OS上で動作するアプリケーションであり、OSがMacやWindowsの場合、VM上にLinux環境を用意し、そこで、Dockerを用意するので、LinuxとMacやWindowsではボリュームデータなどの保存場所が違ったりなど少々異なる部分もあります。詳しくは、こちらの記事が参考になりました。

2点目:コンテナ間は干渉しない
例えば、複数のアプリケーションを同じPC、サーバ上で動かしていた場合、同様のミドルウェアをインストールすることがあると思います。その際、アプリケーションAだとバージョン1じゃないと動かない。ただ、アプリケーションBはバージョン2じゃないなどの状況が発生することがあります。
それぞれコンテナ化していれば、独立しているため、両者が依存せず、それぞれのバージョンを動かすことができるようになります。

3点目:環境の作成・削除・共有が簡単
ホストOS上にインストールする場合も、VM環境を立てる場合も、削除や共有が面倒ってことありますよね。
ところが、今回紹介するDockerではDockerfileやDockerイメージを共有することで簡単に環境の共有ができますし、コマンド一つで環境の作成や削除が可能なのです。
そのため、めんどくさい環境整理や他のPCでの再現性なども高いです。
また、1点目の利点でお伝えした通り、ほとんどのホストOSで動作するため、ホストOSの違いによる環境差異なども気をつける必要がないです。

4点目:OSをインストールしないため、軽量で速度が速い
Dockerは、通常の仮想マシンと違い、ゲストOSをインストールしません。
ゲストOSの代わりにホストOSのカーネルを利用してます。つまり、ホストOSのカーネルを共有しているってことになります。
こうすることによって、コンテナが軽量で、高速になるというわけです。
速度が速いことで、コンテナのスケール速度が上がりますし、デプロイも早いので開発サイクルも速くできます。

ちょっと長くなってしまいましたが、以上がコンテナ技術の良いところになります。
次の章からECSについて書いていきます。
ECSとは
コンテナ化されたアプリを簡単にデプロイ、管理、スケーリングできる完全マネージド型のコンテナオーケストレーションサービスのことです。
オーケストレーションってなんだよってなる方も多いと思うので何かというと、複数のシステムやサービスを連携させて動かし、複雑なタスクや業務の流れ(ワークフロー)を自動化する仕組みです。
これにより、手作業で行っていた面倒な作業を減らし、作業の効率を大幅に向上させることができます。
「オーケストレーション」という言葉は、音楽の管弦楽団(オーケストラ)に由来しています。オーケストラでは、指揮者が演奏者たちをまとめ、全体として美しい音楽を奏でます。同じように、オーケストレーションでは、異なるシステムやサービスを一つにまとめ、調和を取りながら動作させる仕組みを作るのです。
つまり、コンテナオーケストレーションは、プロビジョニングやスケジューリングからデプロイや削除までのライフサイクル全体を自動化することで、コンテナインフラストラクチャの管理を簡素化することができるということです。
これにより組織は、追加のメンテナンスのオーバーヘッドを発生させることなく、大規模なコンテナ化の恩恵を受けることができるので、運用・保守が楽になるということです。
ECSでできること
ECSでは以下のようなことが可能になります。
つまり、Dockerと連携できて、デプロイも簡単に可能。運用保守もAWSが結構肩代わりしたり簡単になるよってサービスです。
- Amazon ECR(Elastic Container Registry)、Dockerと連携して、Docker→ECR→ECSの流れで簡単にECS上にイメージをデプロイ可能
- ALBと連携することで、オートスケーリングも可能
- コンテナモードをFargateにすることで、インフラ管理が不要(サーバレス)
- デプロイタイプを設定可能(ローリング/BlueGreen)
ECSの構成要素
ECSは以下の4つの要素で構成されています。
- クラスター
サービスに基づいて、タスクを実行するための実行環境がクラスターです。
VPCのように、論理的に環境を分けることができるので、本番環境用、開発環境用など利用用途によって、分けることが可能になります。 - タスク定義
タスクを起動する時の設定を行います。主に定義する内容は以下のようなものがあります- コンテナ定義
どのECRのイメージを使ってコンテナを起動するかを設定する - タスクサイズ
CPUやメモリの割り当てを設定する - ポートマッピング
使用したいポート番号を指定できますが、指定しなかった場合も動的にポートが割り当てられる - 起動タイプ
EC2、Fargate、オンプレミスVMまたはサーバーの3種類が存在する
よっぽどの理由がない限り、運用コストを考慮してFargateを利用する(ただし、ランニングコストは他と比較し高くなる)
- コンテナ定義
- サービス
実行中のコンテナ全体を管理します。
例えば、実行中のタスクの稼働数を維持したり、障害時に自動でタスクの再起動を行います。また、ロードバランサーの指定やタスクを実行するネットワーク設定などの役割も行います。 - タスク
タスク定義に則って起動するコンテナのことです。タスクにはコンテナが一つ以上含まれます。タスク内で複数のコンテナを起動することも可能です。
また、障害などで停止したタスクがある場合は、サービスで設定した必要なタスク数をもとに、新しいタスクが自動的に起動します。
今後の執筆について
今回はDocker、ECSの概要みたいなところを記載しましたが、次はDocker何ができるの、ECS何ができるのみたいなところを実際にハンズオン形式のような形で書いていこうと思います。
暇な時間があれば見てやってください
参考
- Docker関連
- ECS関連
- https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html
- https://aws.amazon.com/jp/what-is/container-orchestration/
- https://envader.plus/article/441
- https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service_definition_parameters.html
- https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/launch_types.html
- https://iret.media/152253
- https://www.cloudsolution.tokai-com.co.jp/white-paper/2024/1126-526.html#anc-04-01
- https://envader.plus/article/180
