【徹底解説】ECSのタスク配置戦略って何？（第1回）

みなさん。こんにちは。

ECSにはデプロイ前後の動きを制御するためのデプロイメント戦略があれば、コンテナがどのインスタンスで起動され、スケーリングする時にどのように増減するのかを決めるためのタスク配置戦略（Task Placement Strategy）という設定項目が存在します。

ここで「アレ？」と思った方も多いと思いますが、お察しの通りFargateを起動タイプとして選んでいる場合、インスタンスの概念が抽象化されているためタスク配置戦略を決める事はありません（設定されたAvailabilityZoneに対して均等に配置されるように動きます。）

今回はEC2を起動タイプとして選択した際に設定できるタスク配置戦略に関して説明します。

3つのタスク配置戦略

タスク配置戦略として、ECSでは「binpack」、「random」、「spread」の3つの選択肢が与えられています。

それぞれ、簡単に説明すると以下のようになります。

・binpack : EC2のインスタンス数が最小となるよう、コンテナの要求するCPUやメモリのリソースに基づいて配置する

・random : 存在するインスタンスの中から、ランダムでコンテナのスケールイン・スケールアウトが行われる

・spread : インスタンスまたはAvailability Zoneに対して均等にコンテナが存在するよう配置される

これらの概念を簡単に理解するために、簡単な構成図を用いてタスク配置戦略ごとのスケールイン・スケールアウト時の動きに関して解説します。

タスク配置戦略ーbinpackの場合

binpackの場合、スケールアウトやデプロイの追加時に「EC2のインスタンス数が最小となる」ように動くため、リソースに余裕があるインスタンスBにデプロイされる事になります。

binpackを用いる際の主なメリットとしてはEC2インスタンスのリソースに対して適切に配置が行われ、無駄なリソースの消費が無いという点で余計な費用を支払わずに済む反面、DR（ディザスタリカバリ）やインスタンス障害から考えると、Availability Zoneに対する適切な配置やインスタンス障害に対する可用性の担保が行われないため、万が一のリスクを抱えることになります。

また、「タスクはコンテナインスタンスに配置され、未使用の CPU またはメモリを最小にします。」というドキュメントの説明に対する直感に反するようですが、実際の動きとしてはコップに順番に水を注ぐように、単一のインスタンスにリソースを寄せて足りなくなれば次のインスタンスを選び（起動し）、リソースを減らす時は一番余裕のあるインスタンスに存在するタスクから優先してコンテナが終了されます。

タスク配置戦略ーrandomの場合

randomの場合、EC2インスタンスのリソースに余裕がある限りランダムにコンテナが配置されます。

図にはてはめると、新しくApplication Cをデプロイした時に、どちらのインスタンスに配置されるかは完全にランダムになります。

デフォルトでEC2を利用する場合はrandomが選ばれますが、これは文字通り戦略を取らない事と等しいので、実運用に乗せる場合はbinpackまたはspreadを選んで、タスク配置戦略のメリットを得られるように構築するのが良いです。

タスク配置戦略ーspreadの場合

spreadの場合、Availability ZoneまたはEC2インスタンスに対して均等に配置されます。

図に当てはめて考えると、spreadでAvailability Zone( “field”: “attribute:ecs.availability-zone”)を指定した場合はAvailability Zone単位で均等に配置され、EC2インスタンス(“field”: “instanceId”)を指定した場合はインスタンスごとに均等に配置されます。

アプリケーションCが新たにデプロイされた時はそのコンテナ数が2つ以上の場合、それぞれの設定で単一のAvailability Zone、EC2インスタンスに偏って配置されることはありません。
ただし、binpackを選んだ場合と違ってEC2のスケールアウトの影響の予測が難しいため、コストの面で負担が増える可能性があります。

次回は、タスク配置戦略は結局何を選ぶのが良いか？お伝えします。

SunnyCloudでは、AWSの環境構築、移行支援などのソリューションもご提供しております。