[ECS入門] 基本的な用語の説明と EC2 との比較【図解入り】

こんにちは。
久々の更新になってしまいました。

本業の方で AWS を用いたインフラ構築の案件を担当しており、
色々新規に勉強したことがあるため、備忘として残しておこうと思います。

今回は、AWS のECS というコンテナサービスの基本的なアーキテクチャについて書いていきます。
最初にECS に触れた時に、タスク定義やサービス定義など新しく聞く単語が多く、混乱してしまったので。

スポンサーリンク

ECS の概要

AWS が提供している、フルマネージドのコンテナオーケストレーションサービスです。

要は、数多くの Docker コンテナを機能や用途別に取りまとめて、ウェブアプリ(や API など)の機能を
提供できるように管理してくれるサービス
です。

通常、コンテナサービスを利用して1つのウェブ機能を提供するとなった場合、
複数の異なる機能を持ったコンテナを連動させることで、それを実装します。

提供するウェブサービスが少数であれば、使用するコンテナの種類や数も少なくてすむため、
人の目で管理することは難しくありません。

しかし、大規模なウェブサービスや、複数の小さなサービスから成るウェブサービスを
コンテナを用いて実装しようとすると、コンテナの種類、数ともに膨大なものとなり、
人の手で管理するのが難しくなってしまいます。

AWS ECS は、この問題を解決してくれるサービスということですね。


ちなみに、複数のコンテナを取りまとめて管理してくれるものとしては、
Kuberbetes(クバネティス,K8s)も有名ところだと思います。僕は触ったことありませんが。

EC2 との比較

EC2 と ECS のアーキテクチャの違いを分かりやすくするため、
Apatche、PHP、MySQL から成るウェブアプリケーションを、それぞれ EC2 と ECS とで
構築する場合を図にしてみます。

まず EC2 で上記ミドルウェアをインストールして各設定を終えた状態が下図です。
各ミドルウェアは、OS 上でそれぞれプロセスとして存在し、設定した内容に従い、
密に連携して動作することで、ウェブアプリケーションとしての機能を提供してくれます。
(下図の赤枠が1セットとなってサービスを提供してくれるということ)

EC2でウェブアプリを実装した場合のイメージ図


本番環境でウェブアプリケーションを運用するような場合、
通常ですと、上記と同じ機能を擁する EC2 インスタンスを複数台起動し、
前段に ELB を配置した AutoScaling 構成を取ることで、システムの冗長性を高めることができます。

この状態であれば、たとえ 1 台の EC2 が停止しようが、EC2 の中の Apatche プロセスが死んでしまおうが、
ウェブアプリ全体としてのサービスは停止せずに済むようになります(下図)。

EC2でウェブアプリを実装して冗長構成を取った場合のイメージ図


ECS の場合、Apatche や MySQL といったミドルウェア1つ1つが、OS のプロセスとしてではなく、
コンテナという仮想環境で動作します(下図)。

EC2 の場合と図を比較しても、OS の上層に Docker Engine がいて、各プロセスがコンテナに置き換わった
だけのように見えます。ECSクラスターと書かれている部分は、実際に Docker が動作するホストの EC2 インスタンス郡です。
(EC2 インスタンス郡は AWS Fargate とも呼ばれます)

ECSでウェブアプリを実装した場合のイメージ図


ただ、コンテナの1つ1つはあくまで仮想環境であるため、そのままではコンテナ同士で通信などを
行うことができず、複数のコンテナが連携して動作し、サービスを提供するということはできません。

(EC2 上で起動するミドルウェア同士は、当たり前ですがお互いに通信することができます。)

このコンテナ同士の連携を取りまとめ、設定し、管理するのが ECS の役割というわけです。


また、EC2 の場合と同様に、ECS でも ELB を前段に配置した冗長構成を取ることができ、
その場合は下図のようなイメージになります。

ECSで冗長構成を取った場合のイメージ図

スポンサーリンク

ECS の用語

1つの OS 上ですべてのミドルウェアが連携して起動する EC2 とは異なり、
ECS では複数の仮想環境(コンテナ)が連動して機能し、冗長構成を取る場合にはさらに
起動数分のコンテナの管理が必要になるため、ECS では設定する項目が多くあります。

ECS の設定項目は、大きく分けて以下の3つがあります。

  • コンテナ定義
  • タスク定義
  • サービス定義

コンテナ定義

コンテナ定義は、各仮想環境(コンテナ)がどのように構成されるかを定義します。

EC2 の例でいうところの、Apatche 、PHP、MySQL の各設定 みたいなもので、
ECS ではこれらが 1ミドルウェア 1コンテナ で起動するため、
今回の例では Apatche、PHP、MySQL の3種類のコンテナを定義してやることになります。

各コンテナで使用する Docker イメージを決定したり、どれだけのメモリをコンテナに割り当てるのかを設定できます。

タスク定義

上述したコンテナ定義だけだと、Apatche のコンテナ、PHP のコンテナ、MySQL のコンテナが
それぞれ独立して機能することになり、全体としてウェブアプリケーションとしての機能を提供できません。

そのため、何のコンテナをいくつ組み合わせてウェブアプリを構築するのか を定義するのがタスク定義です。

今回の例では、
「Apatche のコンテナ1つ、PHP のコンテナ1つ、MySQL のコンテナ1つを組み合わせて
WEBアプリケーションとしての機能を提供できるようにする」というのがタスク定義になります。

サービス定義

タスク1つが、Apatche,PHP,MySQL が起動してウェブアプリ機能を提供している
EC2 インスタンス1台 に相当すると考えると、タスクが落ちる (=EC2が落ちるに相当)、
もしくは、タスク内で起動しているいずれかのコンテナが落ちる(=ミドルウェアプロセスの停止に相当)
などした場合に、ウェブアプリとしての機能をタスクが提供できなくなるため、タスク単位で冗長性を持たせておく必要があります。

この、「同じタスクをいくつ起動させて冗長性を持たせるのか」を定義するのがサービス定義です。



以上、コンテナ定義、タスク定義、サービス定義が決める範囲は、下図のようになります。
コンテナ定義は各コンテナの内容、タスク定義は赤枠の設定、サービス定義はオレンジ枠の設定を行います。

ECSで出てくる各種定義の設定範囲

最後に

僕自身、まだまだ ECS の詳細までは理解しきれていませんが、
ひとまず基本的なところは押さえられたのではと思っています。

ただ、まとまり切らないうちに記事作成を始めてしまったため、
後々色々と追記していくかもしれません。



EC2 よりも時間当たりの料金を抑えて使用することができるため、
これからもこういったコンテナサービスの利用は広がっていくのでしょう。
もっと頑張って勉強していかないと、取り残されちゃいますね^^;

以上、同の参考になれば幸いです。

コメント