Amazon ECS Cluster Auto Scaling におけるスケールインの高速化

この記事は Faster Scaling-in for Amazon ECS Cluster Auto Scaling (記事公開日 : 2022 年 9 月 16 日) の翻訳です。

導入

これまで、Amazon Elastic Container Service (ECS) で Cluster Auto Scaling (CAS) をご利用のお客様から、スケールインイベント時のコンピュートリソースの余分な課金を削減するために、より迅速にスケールインしたいとのご要望をいただいていました。そして本日、より迅速なスケールインを実現する、スケールインステップの制限をオートスケーリンググループ (ASG) のキャパシティの 5% から 50% に引き上げる機能改善を発表します。私たちの分析によると、ステップ制限を 50% に引き上げることは、可用性を犠牲にすることなく、全体的なコスト効率を向上させるために最適であることが分かりました。この記事では、この機能改善について詳しく解説し、もたらされるスケールイン時間とコストの改善について、例を挙げてご紹介します。

背景

Amazon ECS は、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを容易にするフルマネージド型のコンテナオーケストレーションサービスです。Cluster Auto Scaling は、クラスターに登録された Amazon Elastic Compute Cloud (EC2) ASG のスケーリングを管理する Amazon ECS の機能です。ECS キャパシティプロバイダーは、Amazon ECS クラスターと ASG を結びつけるコンピュートインターフェースです。

キャパシティプロバイダーを使用すると、コンテナ化されたワークロードを様々な種類のコンピュートキャパシティで実行するための柔軟なルールを定義し、そのキャパシティのスケーリングを管理できます。CAS では、タスクに使用するインフラストラクチャの決定をキャパシティプロバイダーにお任せできるため、インフラストラクチャのスケーリングの管理ではなく、アプリケーションの構築とデプロイに集中できるようになります。キャパシティプロバイダーは、タスクがクラスターのインフラストラクチャにもたらす負荷に基づいて、ASG のスケールインとスケールアウトのアクションを管理します。

お客様は、アプリケーションのインフラストラクチャの可用性だけではなく、同時にコストも最適化したいと言います。これには、特にトラフィックの一時的なスパイクによってキャパシティがスケールアウトした後、長期間未使用となる場合が含まれます。この現象は、CAS が Amazon CloudWatch メトリクスの収集と集約を含む複数の手順でスケーリングアクションを実行する潜在的なプロセスであることに起因します。CAS の仕組みについては、こちらで詳しく解説しています。

具体的には、CAS はスケールイン動作を決定するために、CloudWatch アラームから 15 分相当のデータポイントを要求します。その後、Amazon ECS は、1 回以上のスケールインイベントを通じて、所定のスケールインステップの割合でキャパシティを削減していきます。スケールインステップでは、時間をかけて徐々にキャパシティを削減することで、トラフィックの急増に対応するための予備のキャパシティを確保します。その結果、コンピュートに対するコストが高くなる可能性があります。このコストは、小規模なワークロードにおいてはあまり重要でないかもしれませんが、大規模なワークロードにおいては望ましいものではないでしょう。

スケールイン時間とコスト改善を検証する

ピーク時のトラフィックにおいて、1000 タスクを実行するために c5.xlarge インスタンス 334 台を必要とする Amazon ECS サービスを、100 タスク、34 台まで縮小するシナリオにおいて、スケールインステップの制限を 5％ から 50％ まで改善するテストを実施しました。その結果、スケールインにかかる時間は 8 倍 (80 分から 10 分) 改善され、計算コストは 16 倍以上 (7.47 ドルから 0.46 ドル) 削減されました。この結果から、ECS によりプロビジョニングされた EC2 インスタンスはより迅速に解放され、キャパシティの需要に対するアプリケーションの応答性が向上することが期待できます。

スケールインの仕組みの改善は、使用した分のみ支払うという消費型のモデルを採用することで、AWS Well Architected Framework のコスト最適化の柱の原則に従います。また、需要とワークロードの使用率を監視して、リソースが過剰にプロビジョニングされていないことを確認することで、 AWS Well Architected Framework の信頼性の柱の原則に従います。CAS を利用することで、スケールインの性能が全体的に向上し、それに伴うコンピュートコスト全体が削減され、高い投資収益率につながると期待できます。

スケールインステップの改善を理解する

このスケールインステップの制限の改善によって、お客様が得られる価値と利益をシナリオに沿って確認してみましょう。

あるウェブサイトのリクエストを処理する Amazon ECS サービスを実行しており、日中はピーク負荷を処理するために 1000 タスク必要であるとします。このサービスは、ASG で構成される ECS キャパシティプロバイダーを使用してデプロイされており、サービスのタスクは Amazon EC2 インスタンス上で実行されます。このサービスは、未使用の CPU やメモリを最小化し、Amazon EC2 インスタンスの数を最小化するようにタスクをインスタンスに配置する binpack 配置戦略を使用します。このウェブサイトへのリクエストは 1 日の終わりに減少し、このサービスに必要なタスク数は 100 タスクとなります。サービスのスケールダウンは、タスクを実行するために必要な Amazon EC2 インスタンスの数が減少したことを、いずれ CAS が認識することを意味します。AWS 上のメトリクスをリアルタイムに収集して AWS リソースやアプリケーションを監視する Amazon CloudWatch 上で、ASG の Amazon EC2 インスタンスのスケールインを可視化することにしましょう。

この実験では、Amazon Elastic Container Repository (Amazon ECR) のパブリックリポジトリから BusyBox のベースイメージを使用して、サービスを作成します。このサービスは、最小サイズ 0、最大サイズ 1000 のオンデマンド c5.xlarge Amazon EC2 インスタンスを実行する ASG で構成される ECS キャパシティプロバイダー上で実行されます。ASG のメトリクスを有効化して、サービス内の Amazon EC2 インスタンスの数 (GroupInServiceInstances) を把握できるようにします。Amazon CloudWatch でダッシュボードをセットアップして、ASG のメトリクスを表示しましょう。

実験結果はグラフ 2 の通りで、ASG が 10 分間で 334 インスタンスから 34 インスタンスに (毎分 30 インスタンス) スケールダウンしたことが分かります。スケールインステップの制限の改善前に実施されたテストでは、グラフ 1 に示すように、ASG は 334 インスタンスから 34 インスタンスまで 80 分かけて (毎分 3.75 インスタンス) スケールダウンしています。スケールインステップの制限の改善により、スケールイン速度が毎分 3.75 インスタンスから毎分 30 インスタンスとなり、スケールダウン速度が 8 倍向上したことが分かります。なお、どちらのケースにおいても、タスクのスケールインが完了してから ASG のスケールインが開始されるまでに 15 分ほどかかっていることに注意してください。これは、CloudWatch のスケールインアラームが、ASG のスケールイン処理を開始する前に 15 データポイント (毎分 1 データポイント) を必要とするためです。ここでは、ASG のスケールインが既に開始されている場合のスケールイン時間の改善のみを対象としています。

グラフ 1 : このグラフは、スケールインステップの制限の改善前における Amazon EC2 インスタンスのスケールインを表します。ASG によってスケールダウンされた Amazon EC2 インスタンスの数は、GroupInServiceInstance の線 (緑) で表されます。

グラフ 2 : このグラフは、スケールインステップの制限の改善後における Amazon EC2 インスタンスのスケールインを表します。ASG によってスケールダウンされた Amazon EC2 インスタンスの数は、GroupInServiceInstance の線 (緑) で表されます。

スケールインが全体のコストに与える影響を分析するために、AWS Cost Explorer の時間別レポートを使用して、Amazon EC2 インスタンスの実行コストを追跡しました。表 2 に示すように、スケールインステップの制限を 50% に改善した場合、スケールインは 10 分間で完了し、1 時間を通してのAmazon EC2 インスタンスの実行コストは 6.24 ドルでした。スケールインステップの制限の改善前は、表 1 に示すように、80 分間のスケールインを含む午前 12 時から午前 2 時までの 2 時間の EC2 のコストは、13.22 ドルと 5.81 ドルでした。

次に、スケールイン期間に実行されたすべての EC2 インスタンスのコストから、同じ期間に 34 台の c5.xlarge インスタンスを実行した場合のコストを差し引いたコスト、すなわちスケールインのコストを計算しました。この差分は、100 タスクの定常状態に必要な 34 台のインスタンス数に対する、余分なコンピュートリソースのコストを意味します。どちらのシナリオにおいても、34 台の c5.xlarge Amazon EC2 インスタンスの実行コストは 1 時間あたり 5.78 ドルであることに注意してください。スケールインステップの制限を 50% に改善した場合、Amazon EC2 インスタンスのスケールインのコストは 0.46ドル (6.24 ドル – 5.78 ドル) となりました。スケールインのステップ制限の改善前は、Amazon EC2 インスタンスのスケールインのコストは 7.47 ドルでした (13.22 ドル – 5.78 ドル + 5.81 ドル – 5.78 ドル)。

スケールインにおけるコンピュートリソースのコストは、7.47 ドルから 0.46 ドルへと 16 倍以上削減されました。ただし、ASG で設定した EC2 インスタンスの種類や、EC2 インスタンスが実行されるリージョン/アベイラビリティゾーンによってコストが異なるため、結果は異なる可能性があります。

表 1 : この表は、AWS Cost Explorer で見た、スケールインステップの制限の改善前の Amazon EC2 インスタンスの 1 時間あたりの運用コストを表しています。

表 2 : この表は、AWS Cost Explorer で見た、スケールインステップの制限の改善後の Amazon EC2 インスタンスの 1 時間あたりの運用コストを表しています。

まとめ

AWS は、Amazon ECS のスケーリング速度を最適化するために、スケーリングと性能の改善に投資しています。最近発表した機能改善には、AWS Fargate の最適化 (アプリケーションを最大 16 倍速くスケーリング)、およびキャパシティプロバイダーの最適化 (より高速な CAS エクスペリエンスを提供) が含まれます。スケーリングエクスペリエンスをさらに簡素化するために、2022 年 5 月 27 日より、ASG キャパシティプロバイダーでマネージドスケーリングが有効な場合には、Amazon ECS は AWS Auto Scaling スケーリングプランを必要としなくなりました。

この記事では、Amazon ECS CAS のスケールインステップの制限の機能改善について紹介し、全体のスケールイン性能の向上と大規模なスケールインアクティビティに関連するコンピュートコストの削減に貢献することを示しました。これらの最適化は、ECS が利用可能な AWS リージョンで自動的に有効化されます。お客様側での追加のアクションは必要ありません。

ぜひこの機能改善をお試しください。本日から Amazon ECS を使用開始いただけます。