初めに
こんにちは、Datadog JapanでSale Engineerを務めているBryantです。
アプリケーションをAmazon ECS on Fargateに載せている皆様に、こんなことを体験されたことありましたのでしょうか？アプリケーションに負荷テストを行い、すでに負荷が上がってきましたが、中々設定したECS Auto Scaling Policyが機能せず、数分間待ってからやっとタスクがスケールアウトし始めました。もし本番環境でスケールアウトの時間が長くなると、リクエストの処理の遅れ、レスポンスの遅延やエラー率の増加など、ユーザー体験を影響する可能性が高まり、ビジネス機会損失に繋ぎます。この状況に対して、Datadogは何かできることはあるのでしょうか？
DatadogのWorkflow Automationとは？
DatadogのWorkflow Automationは2023年6月GAになって、アラートやセキュリティシグナルに応じて、エンドツーエンドのプロセスを自動実行させる機能です。Workflow Automationのリリースによって、Datadogは観測(オブザーバー)のみならず、観測データに基づいた実行(アクション)の自動化も実現できるようになりました。
Workflow Automationでは、アクションはコンポーネントの形でご提供され、利用者はUI上でフロー図を描く形で、判定条件とアクションのフローを自由に組み合わせてデザインできます。現在、様々なテックスタックに連携するアクションが300種以上提供されており、アクションの開発も継続に行われます。
Workflow Automationに関してより詳細についてはこちらの公式ガイドとブログをご参照ください。
Workflow AutomationでECSのオートスケールはできるか？
Workflow Automationのアクションの一覧を探ってみれば、以下2点ECSに関連するアクションを見つけました。
① Describe ECS service: ECSサービスの詳細情報を出力
② Update ECS service: ECSサービスの構成をアップデート
ECS serviceの定義には必要なタスクの数(desired count)があり、この値を増減できると、スケールアウトとスケールインが実現できそうです。この発想を元に、早速以下のようなワークフローを作成してみました。
※ご注意点として、このワークフローを成功に実行するためには、以下2点前提条件が必要です。
① ECS Clusterを所有するAWSアカウントとDatadogがIntegration連携できました。
② アクション実行に必要な権限をAWS側でポリシーを作成し、実行用のAWSロールとバインドしました。そして、ワークフローが認証用のConnectionsに該AWSロールを登録しました。
ECS on FargateのAuto Scaling対照実験
では、AWS純正のECS Auto Scaling policyとDatadog Workflow Automationについて対照実験
を行い、スケールの時間を測ってみましょう。
実験は以下の構成で行います。
負荷テストツールLocustからECS on FargateにデプロイしたFlaskアプリケーションに対して継続にアクセスを行い、ECS側ではCPUの使用率に一定閾値をトリガーにして、タスクを１個から２個にスケールアウトさせます。ECSサービスに関しては、Datadog Agentをサイドカーで導入し、Flaskアプリケーションに対してコンテナメトリクス監視及びAPMが有効になっています。
AWSのECS Auto Scaling policy組
実験条件：
以下通り、ECSサービス平均CPU使用率を20%で設定し、トリガーされたらタスクが１つスケールアウトされます。
実験過程：
16:35 負荷テスト開始
16:36 Datadog画面でflaskappのCPU使用率が20％を超えたことを確認済み
16:41 CloudWatch側ではまだ16:30以降のメトリクスは未受領
16:42 CloudWatch側では最新メトリクスを受領し、スケールアウト開始
16:42 スケールアウト完了、以下にてスケールイベントをご参照可能
やはり、多くのエンジニアが体験されたことと同様、AWS純正のECS Auto Scaling policyを用いた場合、スケールアウトに必要な時間が長いです。
Datadog Workflow Automation組
実験条件：
以下通り、ECSのflaskappコンテナの平均CPU使用量の閾値を200m(換算で使用率が20%)でモニターを作成し、トリガーされたら前文で作成したワークフローを実行し、タスクを１つスケールアウトします。
実験過程：
17:06 負荷テスト開始
17:09 Datadog側でモニターがトリガーされた
17:09 Datadog側でワークフローが実行された(実行時間計18s)
17:11 スケールアウト完了、以下にてスケールイベントをご参照可能
実験結果まとめ
以下表に実験の結果を示しており、確かにDatadog Workflow Automationを利用して、ECS on Fargateのサービスでより迅速なAuto Scalingを実現できました。
※AWSのイベントで秒単位まで確認できず、秒で計算すると実質3分間ほどの差分が出てきます。
時間の差分原因は大きく検知と実行2点あると考えます。
・検知：ECS Auto Scaling policyではCloudWatchメトリクスに依存しますが、CloudWatchのメトリクス収集間隔は仕様上5分間であり、メトリクスが届くまで待つ時間が長いです。一方、Datadog側でAgent経由でのメトリクス収集間隔は15sで、同じく1分間の頻度で評価すると、より速い検知が実現できます。
※補足に、AWSでは詳細モニタリングを有効化することで、メトリクスを1分間隔で利用可能です。Workflow Automationと同じ程度にできる想定ですが、無料枠以外では料金が発生します。
・実行：Datadog側ではワークフローの実行には時間が必要で、モニターがトリガーしてからスケールまでの時間はAWSのAuto Scaling policyより少し遅くなります。
終わりに
本文書では、Amazon ECS on Fargate上稼働しているアプリケーションに対して、AWSが提供したAuto Scaling policyとDatadogのWorkflow Automationを用いたAuto Scalingの速度比較を実施しました。結果的に、Workflow Automationは2-3分程度早めにスケーリングできました。また、Workflowを利用する際には、簡単なCPU、メモリやLoadbalancerのメトリクス以外、APMのメトリクス(処理の遅延、エラー率)またはログなど、よりスケーリングに適切なトリガー条件を設定可能です。
Workflow Automationは、観測データに基づいて自動実行を実現することで、様々な手動作業を削減し、作業ミスを防止することが可能です。これにより、運用コストの大幅な削減が期待できます。是非とも、お試しください。