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

みなさん。こんにちは。前回は、ECSのタスク配置戦略はどのようなものがあるかをお伝えしました。

タスク配置戦略は結局何を選ぶのが良いか

正解は無いのですが、優先するところを選ぶとすれば次の通りになります。

・コストを優先する : binpack

・サービスの安定した提供を優先する : spread(インスタンス分散)

また、ECS上で稼働するタスクが均等に負荷が上昇するならば問題無いのですが、実際のシステム運用において特定のタスクのみ負荷がスパイクすることは当然としてありえるため、特定のインスタンスに同じタスクが複数デプロイされた結果負荷が増大して障害を起こすこともあり得ます。

これを避けるとするならばインスタンス分散となりますが、システム全体の負荷を適切に制御できるようCPUやメモリの予約を取ったり、アプリケーション自体の最適化がなされた上でbinpackを選択するといったことも営利としてコストを意識しながらサービス提供を行う上では重要になります。

タスク配置戦略を取り巻くECSの機能に関して

先に述べた通り、タスク配置戦略で「これを選べばOK」といった話はなく、「EC2インスタンスに同居する他のコンテナと干渉しないようにアプリケーションが稼働するか？」「コストが無駄にとられないように適切なリソースの確保がタスク定義されているか？」というバランス感覚を保つことがコストパフォーマンスを意識する上で重要になり、ECS上で動くコンテナに対してメトリクスを確認しながらチューニングを行ってゆくことが必要になります。

基本的にタスクの適切な配置を行う上ではCapacity ProviderとCluster Autoscaling機能を使ってタスクの増減に従って適切にEC2がスケーリングするように設定された上で、タスクのコンテナが無駄なく配置されるようにCloudWatch等でコンテナのメトリクスを監視しながら、キャパシティの予約に関するパラメータをチューニングしてゆく事になります。

タスク配置戦略の勘所

ここまでの流れで、タスク配置戦略にはそれぞれメリット・デメリットが存在し、それらを選択して活用するためには結局タスクの最適化が重要になるという事を説明しました。

つまり、タスク配置戦略を起点として概ねの優先順序（取り組むべき課題）を決めた上で、アプリケーションチューニングへと繋がってゆく流れが見えてきます。

また、タスク配置戦略はサービスごとに設定できるため、負荷の増減が大人しいサービスに関してはbinpackまたはAvailability Zoneのspreadを選び、突然死をよく起こしたり負荷の増減が激しいサービスに関してはInstanceIdのspreadを選び……といったサービスごとのタスク配置戦略を選ぶ必要もあります。

Capacity ProviderとCluster Autoscalingの登場によって幾分かECS on EC2の構築と運用がやり易くなったものの、このようにサービスレベルで細分化して最適化しながらコストを削減する……という運用上の終わりのない改善プロセスに取り組む余裕が無い場合、思い切ってFargate環境へと移行してしまうのも手段かもしれません。

それでもEC2のインスタンス上でコンテナを動かしたい場合や、リザーブドインスタンスやSaving Plans等を活用して費用の削減をすることがチューニングにかかる工数に対してメリットであると判断できる場合は、これらのタスク配置戦略を可用性とコストの天秤にかけつつ、EC2を無駄なく使い切るためのチューニングに取り組むのが良いかもしれません。