はじめに
業務でcapacity providerに触れる機会がありましたので、ご紹介したいと思います。
Capacity Providerとは
capacity providerとは、ECSクラスターが必要とする計算リソースの管理を簡素化し、インフラストラクチャのスケーリングを自動化するための機能です。つまり、作業者はcapacity providerを設定するだけでタスクのオートスケーリングをECSに任せることができる機能です。
このcapacity providerは、ECSタスクが実行される計算リソース（EC2インスタンスまたはFargate）を指定するために使用されます。Fargate capacity providerとEC2 capacity providerを適切に活用することで、リソースの最適な利用とコスト効率を実現できます。ターゲット追跡スケーリングポリシーやフェイルオーバー機能を活用することで、柔軟性と高可用性も確保できます。
ざっくりcapacity providerについて説明したので、fargateとEC2、それぞれのcapacity providerについてお話ししていきたいと思います。
Fargate Capacity Provider
Fargate capacity providerはインフラストラクチャの管理やスケーリングを完全にAWSに任せることができます。タスクがfargateで実行され、自動的にスケーリングを行います。また、fargateとfargate spot[1]を組み合わせたタスクの起動ができるようになります。fargateとfargate spotを組み合わせることでコスト削減になり、かなりお得になります。
capacity provider戦略
このfargate spotをうまく使用するために必要なのがcapacity provider戦略と言われるものになります。capacity provider戦略はタスクをどのプロバイダーにどのように分散させるかを制御できます。capacity provider戦略で分散させる方法は、BaseとWeightの二つの値を使用して分散を制御します。
例を出すとfargateとfargate spotがこのようなBaseとWeightの値を取っているとします。
- fargate
- Base:2
- Weight:1
- fargate spot
- Base:0
- Weight:1
このような値を取るとき、最低タスク数が2となり、fargateがまず2つ立ち上がります。タスク数が3になった時、またfargateが立ち上がります。タスク数が4になった時、次はfargate spotが立ち上がります。そのあとは交互にfargateとfargate spotが立ち上がります。
このcapacity provider戦略はEC2 capacity providerでも利用できます。
オートスケール
fargateのオートスケールはシンプルで、タスクのスケーリングを決めるだけで動きます。タスクのスケーリングのポリシータイプは主に2つのものがあり、ターゲット追跡タイプとステップスケーリングタイプの2種類存在します。
ターゲット追跡タイプはターゲットするメトリクスを3つの選択肢から選びます。
- ECSのCPU使用率の平均
- ECSのメモリ使用率の平均
- ALBのリクエスト数
この3つのメトリクスのどれかを選択し、閾値を決めます。閾値を決めたら設定完了で、cloudwatchアラームが作成され、その閾値に近い値を維持するようにタスク数の増減を調整してくれます。
ステップスケーリングタイプは既存のcloudwatchのアラームから選択します。ターゲット追跡タイプと違うところは、タスク数を増やす場合のパターンと減る場合のパターンで分けることができて、あらゆる条件で柔軟に増減することができる点です。複数設定すると、あるメトリクスが閾値を超えたら2台増やす、別のメトリクスが閾値を超えたら3台増やすというようなことが可能です。
EC2 Capacity Provider
EC2 capacity providerでは、EC2インスタンスのスケーリングを管理できます。Auto Scalingグループと連携して、必要に応じてインスタンスの増加、削減を行います。このEC2 capacity providerの良い点は、Auto Scalingグループの管理をしなくてよくなくなることです。EC2 capacity providerを使ってない場合だと、EC2インスタンスとECSタスクのオートスケールが別々になります。
別々だと問題があって例えば、ECSタスクのオートスケールでタスク数が増えたとしても、EC2インスタンスがオートスケールしなかったら、ENIが足りない、メモリやCPUが足りない等の理由でタスクのオートスケールが機能しなくなります。また削減の方もタスク数が削減しても、EC2インスタンスの方で削減設定をしていなかったら無駄にEC2インスタンスが残って、コストが高くなります。
このような煩わしさを解消するにはlambdaでいい感じにするしかなかったですが、capacity providerが出たのでlambdaを使わずに解消することができます。
オートスケール
capacity providerを利用したECS on EC2のオートスケールはAuto Scalingグループとcapacity providerを連携する必要があります。連携させるとタスクのオートスケールとEC2インスタンスのオートスケールは連動した形になります。
タスクのオートスケールは前述したfargateと同様の設定を行うことでタスクの増減を実現します。EC2のAuto Scalingグループはcapacity provider reservationを元にオートスケールを行います。
capacity provider reservationはリソースに対して確保されたリソース容量を管理するための機能です。閾値を決め、連携するとcapacity provider reservationはcloudwatchアラームに追加されます。capacity provider reservationでどう増減するかの説明が難しいので、例を出して説明します。capacity provider reservationの値は以下のように決定します。
M：希望するインスタンス数
N：現在のインスタンス数
capacity provider reservationの閾値が100で、EC2インスタンスが1台に対してタスクが1つ載っているものが5台あるとします。この時、タスクのオートスケールが発生し、タスク数を6にしようとしています。その際にcapacity provider reservationの値が
となり、閾値の100を超えるため、閾値と同じになるようにEC2インスタンスを増やします。すると
となり、スケールアウトが完了します。また、タスクが減るのも同様で、先の例と同様のものが5台あったとして、タスク数を4にしようとしています。その際にcapacity provider reservationの値が
となり、閾値の100を下回るため、閾値と同じになるようにEC2インスタンスを減らします。すると
となり、スケールインが完了します。このようにcapacity providerを利用したECS on EC2のオートスケールはタスク数とEC2インスタンスの数の割合を見てオートスケールします。
閾値は100以外にもできて、例えば80にすると、インスタンスの数が5台に対してタスク数が4つになります。余剰にインスタンスがあるのでタスクが急に増えても大丈夫な体制になりますが、余剰分を余計に払うことになるので、この閾値は考えて設定する必要があります。
ECS on EC2のオートスケールの流れをまとめると、
アクセスが多くなる
→設定したメトリクスが閾値を超え、アラームを発生させる
→タスクのオートスケールでタスクを立ち上げようとする
→capacity provider reservationのメトリクスが100以上になりアラームを発生させる
→Auto ScalingグループでEC2が立ち上がる
→タスクが立ち上がる
fargateでは
アクセスが多くなる
→設定したメトリクスが閾値を超え、アラームを発生させる
→タスクのオートスケールでタスクを立ち上げようとする
→タスクが立ち上がる
となっていて、capacity provider reservationの分、タスクの立ち上がりがECS on EC2の方が遅いです。
まとめ
EC2とfargateのcapacity providerとそれに伴うオートスケールについて説明させていただきました。
EC2とfargateにはそれぞれ異なる特徴と利点があります。EC2はカスタマイズ性と制御性を重視するユーザーに適している一方、fargateは管理の手間を省き、スケーラビリティと簡便さを求めるユーザーに最適です。運用環境に応じて、最適な方を選択することで、効率的なコンテナ管理が実現できるのではないかと思います。
-
fargate spotはfargateよりも安い料金で使用できる、未使用のクラウドリソースを使用するfargateです。最大で70%の割引きで使用することができます。デメリットはリソース状況によっては中断されてしまうことがありますので注意が必要です。 ↩︎
Discussion