概要
- 2022年4月頃に、AWS のコンテナヒーロである Vlad Ionescu が Amazon ECS でのコンテナスケーリング時の起動速度をまとめたブログが公開された。
- 今回は、ブログを読み解きこのブログで語られた内容についてまとめていこうと思います。
※ なお、本ブログでは Amazon ECS / AWS Fargate についてのサービスを説明することは対象としておりません。あらかじめご了承ください。
ECS における各種データプレーンとタスク起動に比較
- そもそも Amazon ECS というのは、AWS が独自開発しているコンテナオーケストレーションサービスです。
- そのため、AWS 側が見てくれる領域とユーザ側が見なければいけない領域が異なる点には注視していないといけない。
- 下記を見てみると、領域の違いがわかるのですが、実際に稼働するコンテナのアプリケーションや、ECS Agent周りの責務はユーザ側にあり、稼働するコンテナの環境の選択もユーザの選択に依存します。
- ただし、ECS におけるタスク(コンテナ数)のスケジューリング等は AWS 側の責務になっているので、今回のタスクのスケーリングの改善は AWS 側の責務としてやらなければならないことですし、それにより大幅な改善がされてきたという話をここではまとめていきたいと思っています。
ECS におけるレート制限
- ECS を使用しているユーザに AWS は、毎秒数千のタスクをスケジューリングしていると公式のブログで記載されています。
- そのため、全体的なスケジューリングのワークロードは公平になるようレート制限を使用しています。
- ECS におけるレート制限は、トークンバケットアルゴリズムを使用し制限をかけています。(トークンバケットアルゴリズムの話はまた別記事で)
- ちなみにレート制限の種類は3つあります。これらのアプローチにより、ECS におけるイベントの挙動をバーストできる反面、速度部分での制限ともなります。
- Service Deployment rate limit : サービスを作成もしくは更新する際に、新しいタスクをロールアウトしたり、既存のタスクを新しいバージョンに置き換える際の速度を制御
- RunTask API rate limit : スタンドアロンタスクの起動できる速度を制御
- AWS Fargate capacity rate limits : Fargate におけるタスクの起動に特化したレート制限
ECS における各種データプレーンとタスク起動に比較
- 下記の図は、各データプレーンごとのタスク制限について示したものになります。
- 特徴的なのは、Fargate ですかね。
- AWS Fargate におけるレート制限はアカウント全体でかけられています。
- AWS アカウントのすべてのクラスター内の ECS 内の「サービス」が同じ AWS Fargate タスクの起動レートを共有していることを意味しています。
- ちなみに、AWS Fargate オンデマンドと AWS Fargate スポットで利用されるトークンバケットは分離されているようです。
- なお、EC2 を使用する場合、既存の EC2 インスタンスへのタスクの起動にレート制限はないようです。
Service Deployment Rate Limit におけるサービスの作成、更新の速度改善
- 2021年から2022年にかけて、Fargate で使用できるタスクが改善され、1分あたり最大500タスク、EC2の場合では、1分あたり 250 タスクの速度でデプロイできるようになったようです。
- また、スケジューリングの調整により、Fargate のデプロイ速度は16倍、EC2の場合ですと2倍速度が改善されたと記載されておりました。
これにより何が嬉しくなった？
- 例えば、ある web アプリケーションを ECS で稼働させています。
- このアプリケーションがトラフィックをさばくのに、1000個のタスクが必要だとします。
- その場合、ユーザは、サービスに必要なタスク数を1000にすると思いますが、ECS はこの1000個のタスクを一度に起動する訳ではありません。
- 徐々に現在のタスク数から目的の状態(この場合だと1000)に近づけるような動作となります。
- そのため、スケジューリングを行うタスクスケジューラの速度が向上すると、1000 個のタスクをより迅速に起動しタスクを目的のタスク数までに増やすサイクルを減らすことができるようになりました。
- ちなみに、単一のサービスの場合だと、EC2 より Fargate を使用した方がタスクの起動速度が速いようです。
- Fargate の場合ですと、標準のタスクサイズがありそのサイズのタスクを実行したい人用に事前にウォームアップ状態に保ったものがあるようです。
- ECS のタスクスケジューラは、タスク開始時にいつでも Fargateのタスクプールからタスクをリクエストするだけでよいのです。
- ECS のデータプレーンとして、EC2 を利用している場合ですと、スケジューラは事前準備されたタスクを利用できません。
- 任意のサイズのタスク用のスペースがある EC2 インスタンスを見つけて、そのスペースを確保してから、そのインスタンスでタスクを起動する必要するところに違いがあります。
ECS on EC2 と ECS on Fargate のスケーリング速度比較
- 下記は、ECS on EC2 と ECS on Fargate のスケーリング速度比較をした図になります。
- どちらもサービスの数が異なるもので、0 ~ 3500個のコンテナまでスケーリングさせた時のパフォーマンスを表しています。
- ECS on EC2 の場合、すべてが大体2分半前後でスケーリングを開始し、EC2 上の ECS では、1つだけのサービスが10分後に約 1600個のコンテナに到達します。
- 5つのサービスが10分後に3500個のコンテナに到達し、7つのサービスも10分後に3500個のコンテナに到達し、10個のサービスが10分後に2500個のコンテナに到達します。
(画像抜粋基: https://www.vladionescu.me/posts/scaling-containers-on-aws-in-2022/)
- ECS on Fargateの場合ですと、2つのサービスを使用する Fargate 上の ECS には約8分、3つのサービスでは約6分、5つのサービスでは約5分、7つのサービスでは約5分で3500個のコンテナまでスケールしていきます。
(画像抜粋基: https://www.vladionescu.me/posts/scaling-containers-on-aws-in-2022/)
2020 ~ 2022年にかけてのFargateのスケーリング速度の違い
- これは、かなり衝撃を受けたのですが、ECS Fargate のスケーリング速度の改善が年々改善されてきているのですが、ここまでの違いが出ているとは思っていませんでした。
- 2020年に Fargate を使用していた場合、約60分で 3500個のコンテナにスケーリングします。
- 2021年にはスケーリングが10分強で完了します。
- 2022年には同じアプリケーションのスケーリングが 5分強で終了します。
- 我々ユーザは気づいたら、2年の内にスケーリング時間が1時間から5分になっていたということです。
(画像抜粋基: https://www.vladionescu.me/posts/scaling-containers-on-aws-in-2022/)
2022年における Lambda / ECS(or EKS) on Fargate / ECS(or EKS) on EC2のスケーリング速度比較
- 下記の図は、各主要なサービスの0から3500個のコンテナ数にスケーリングするのにかかる時間を表しています。
- Lambda は瞬間に3000個まで急上昇しています。
- ECS on Fargate では、30秒後にスケーリングを開始し、約4分半で3500個らへんまでスケールしています。
- EKS on Fargate では、約1分後にスケーリングを開始し、8分半前後で3500個近くまで達しています
- EKS on EC2 では、2分半後にスケーリングが開始され、6分半前後で3500個付近に達しています。
- ECS on EC2 では、2分半後にスケーリングが開始され、10分前後で3500個付近に達しています。
(画像抜粋基: https://www.vladionescu.me/posts/scaling-containers-on-aws-in-2022/)
まとめ
- これにつきます。AWS の開発チームの皆さん。ありがとう。感謝感謝です。
参考/引用