この記事は Fusic その 2 Advent Calendar 2019 12 日目の記事です。

はじめに

• ECS 再入門 vol.1 ECS とは
• ECS 再入門 vol.2 ECS とオートスケール 👈 いまここ

前回は、ECSを使用するに当たって最低限必要な概念を説明しました。
今回は、ECSを本番環境で運用するに当たって必要になる、オートスケールについてもう少し深堀りしたいと思います。

ECS のオートスケール

ECS におけるオートスケールは、2つの概念の理解が必要です。

1つは、コンテナを動作させるためのコンテナインスタンスの Auto Scaling（普段EC2に対して行うものと同義）。

もう１つは、コンテナ自体をスケールさせる Application Auto Scaling です。

Auto Scaling

クラスタインスタンス（器）を増減するためのスケールです。
ECSをラーメンに例えるなら、丼を増やしたり減らしたりするスケールです。

大きく分けて3つあります。

1. AWS ECS Cluster Auto Scaling を使用してオートスケールする方法
2. Fargate を使う方法
3. 通常の Auto Scaling を自力で運用する方法

AWS ECS Cluster Auto Scaling

この記事を書いている真っ最中に、ECSの新機能が発表されました（泣。

https://aws.amazon.com/jp/blogs/news/aws-ecs-cluster-auto-scaling-is-now-generally-available/

これまでは、クラスタインスタンスのスケールには、CPU予約率等のメトリクスを監視して、Auto ScalingGroup を自前で組む必要がありました（後述）。
まだ詳しい調査はできていませんが、この新機能を使用すれば、今まで面倒だったコンテナインスタンスの Auto Scaling が楽に構築できるようになると思います。

Fargate を使う方法

Fargate の場合は、タスク = インスタンス なので、インスタンスのAuto Scalingを気にする必要はありません。 負荷に応じた Application Auto Scaling を組んでおけば、勝手にインスタンスが起動してきます。

ラーメンで例えると、ラーメンが入った器が提供されるということです。

ただし、タスクひとつに対して1つENIが必要であったり、ログドライバは awslogs しか選べなかったり、色々と制限があるので、要件によっては使用できないかもしれません。

通常の Auto Scaling を自力で運用する方法

Cluster Auto Scaling が発表されましたが、現状の EC2 起動タイプにおける一般的な Auto Scaling の方法だと思います。

クラスタのCPU予約率やメモリの予約率から、現在稼働しているコンテナの数等を割り出して、適切なインスタンス数にスケールするように、CloudWatchMetrics や AutoScalingGroup を調整します。

Application Auto Scaling

先述の Auto Scaling が器のスケールだとすれば、 Application Auto Scaling は 中身 のスケールです。 ラーメンなら、Auto Scaling でラーメン丼にラーメンを投入する作業になります。

ちなみに、Application Auto Scaling は ECS 固有のものではなく、スケーラブルなサービスのリソースを自動的にスケールするためのサービスの名称です。

こちらは純粋に負荷に対して設定して良いと思います。

図のように、サービスのCPU使用率50%のトラッキングをかけていれば、（インスタンスが適切にスケールしている前提で）タスクがCPU負荷50%を維持するようにスケールしてくれます。

Auto Scaling の注意点

起動速度

Fargate の方がコンテナ入りのインスタンスが上がってくるので起動速度が速くなりそうですが、実際はコンテナのキャッシュが効かないため、そこまでの速度は出ません。また、必ずインスタンスが起動してからコンテナがデプロイされる ので、インスタンスの起動時間+コンテナのデプロイ時間がかかります。イメージを軽くする以外はユーザー側でどうこうできるものではないので、AWSさんに頑張ってもらうしかないですね。

EC2起動タイプの場合、コンテナイメージのキャッシュが効くので、クラスタのリソースに余裕がある場合は、Fargateよりも早くコンテナが起動してきます。また、EC2 起動タイプの場合は、スケールアウトだけでなくスケールインの際にも注意を払わなければなりません。それが、インスタンスのドレイニングです。

ドレイニング

クラスタからインスタンスを外す際には ドレイニング と呼ばれる操作をする必要があります。これは、対象のインスタンスにリクエストが飛ばないようにして、エラーが発生しないようにするための操作です。

ラーメンで例えるとわかりやすいのですが、何も考えずにスケールインさせてしまう行為は客が食べている最中のラーメンの丼を取りあげる行為になります。事故が起こるのが目に浮かびますよね。

負荷が下がった際に、何も考えずにスケールインしてしまうと、リクエストを処理していたコンテナが強制終了してしまい、エラーレートが上昇する原因となってしまいます。

EC2起動タイプにおけるドレイニングの処理の自動化は、AWS公式ドキュメントがあるので、こちらを参考に構築すると良いと思います。

Fargate はおそらくそこまで自動化しているので、特に気にする必要はないと思います。

まとめ

今回はECSを使用する際のオートスケールについて少し詳しくまとめてみました。
私も、現在メンテナンスをしている環境に自前の Auto Scaling Group でスケールを調整している環境があるので、新機能の Cluster Auto Scaling に移行していければと思っています。