DatadogのWorkflow Automationを活用し、ECS on FargateのAuto Scalingをより迅速に実現

## 初めに
こんにちは、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上でフロー図を描く形で、判定条件とアクションのフローを自由に組み合わせてデザインできます。現在、様々なテックスタックに連携する[アクション](https://docs.datadoghq.com/ja/service_management/workflows/actions_catalog/)が300種以上提供されており、アクションの開発も継続に行われます。

Workflow Automationに関してより詳細についてはこちらの[公式ガイド](https://docs.datadoghq.com/ja/getting_started/workflow_automation/)と[ブログ](https://www.datadoghq.com/ja/product/workflow-automation/)をご参照ください。

## Workflow AutomationでECSのオートスケールはできるか？
Workflow Automationのアクションの一覧を探ってみれば、以下2点ECSに関連するアクションを見つけました。
① Describe ECS service: ECSサービスの詳細情報を出力
② Update ECS service: ECSサービスの構成をアップデート

ECS serviceの定義には必要なタスクの数(desired count)があり、この値を増減できると、スケールアウトとスケールインが実現できそうです。この発想を元に、早速以下のようなワークフローを作成してみました。
![workflow-example.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/89e4f1a4-5618-2e58-533d-d5b8f05ea5e5.png)

###### ※ご注意点として、このワークフローを成功に実行するためには、以下2点前提条件が必要です。
① ECS Clusterを所有するAWSアカウントとDatadogが[Integration連携](https://docs.datadoghq.com/ja/getting_started/integrations/aws/)できました。
② アクション実行に必要な権限をAWS側でポリシーを作成し、実行用のAWSロールとバインドしました。そして、ワークフローが認証用の[Connections](https://docs.datadoghq.com/ja/service_management/workflows/connections/)に該AWSロールを登録しました。

# ECS on FargateのAuto Scaling対照実験
では、AWS純正のECS Auto Scaling policyとDatadog Workflow Automationについて対照実験
を行い、スケールの時間を測ってみましょう。

実験は以下の構成で行います。
![Screenshot 2024-12-24 at 12.51.04.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/a809ae6e-9ab4-29c7-6c93-9f8d4da6f31d.png)

負荷テストツール[Locust](https://locust.io/)からECS on FargateにデプロイしたFlaskアプリケーションに対して継続にアクセスを行い、ECS側ではCPUの使用率に一定閾値をトリガーにして、タスクを１個から２個にスケールアウトさせます。ECSサービスに関しては、Datadog Agentをサイドカーで導入し、Flaskアプリケーションに対してコンテナメトリクス監視及びAPMが有効になっています。

#### AWSのECS Auto Scaling policy組

###### 実験条件：
以下通り、ECSサービス平均CPU使用率を20%で設定し、トリガーされたらタスクが１つスケールアウトされます。
![Screenshot 2024-12-24 at 13.06.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/7b9a55d4-aa4e-32b4-74ef-3c5fe8ae8c8e.png)

###### 実験過程：

16:35 負荷テスト開始
![Screenshot 2024-12-08 at 16.44.51.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/8c832b5b-8557-0d79-d43b-4f029c487a05.png)

16:36 Datadog画面でflaskappのCPU使用率が20％を超えたことを確認済み
![Screenshot 2024-12-08 at 16.39.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/4637afd4-e5ff-f9dd-7d72-7d21ca5ab042.png)

16:41 CloudWatch側ではまだ16:30以降のメトリクスは未受領
![Screenshot 2024-12-08 at 16.41.00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/e10223f9-1123-c7ef-5934-91ada1358f90.png)

16:42 CloudWatch側では最新メトリクスを受領し、スケールアウト開始
![Screenshot 2024-12-08 at 16.42.23.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/c3010049-7b5c-a759-496b-68e3dc25c998.png)

16:42 スケールアウト完了、以下にてスケールイベントをご参照可能
![Screenshot 2024-12-08 at 16.43.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/59e4f277-b972-1203-9a2c-b85d44d7634f.png)

やはり、多くのエンジニアが体験されたことと同様、AWS純正のECS Auto Scaling policyを用いた場合、スケールアウトに必要な時間が長いです。
#### Datadog Workflow Automation組

###### 実験条件：
以下通り、ECSのflaskappコンテナの平均CPU使用量の閾値を200m(換算で使用率が20%)でモニターを作成し、トリガーされたら前文で作成したワークフローを実行し、タスクを１つスケールアウトします。
![Screenshot 2024-12-08 at 17.02.09.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/ee18dfa2-c3df-d8ff-e2a4-7393b67f4f40.png)

###### 実験過程：

17:06 負荷テスト開始
![Screenshot 2024-12-08 at 17.12.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/661a83f7-6c4d-6365-85d0-d864753bed3d.png)

17:09 Datadog側でモニターがトリガーされた
![Screenshot 2024-12-08 at 17.11.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/ef719b6d-de9b-2ba3-ef2b-99e7f25548d6.png)

17:09 Datadog側でワークフローが実行された(実行時間計18s)
![Screenshot 2024-12-24 at 13.36.44.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/f3eaeaed-c610-3ba0-93e6-d8298058709d.png)

17:11 スケールアウト完了、以下にてスケールイベントをご参照可能
![Screenshot 2024-12-08 at 17.13.30.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/72c4a477-473f-869d-1593-919f89248de2.png)

#### 実験結果まとめ
###### 以下表に実験の結果を示しており、確かにDatadog Workflow Automationを利用して、ECS on Fargateのサービスでより迅速なAuto Scalingを実現できました。
![Screenshot 2024-12-24 at 13.48.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3953043/9f4ecafa-32d6-612a-5c40-e97bc61ed938.png)
※AWSのイベントで秒単位まで確認できず、秒で計算すると実質3分間ほどの差分が出てきます。

時間の差分原因は大きく検知と実行2点あると考えます。

・検知：ECS Auto Scaling policyではCloudWatchメトリクスに依存しますが、CloudWatchのメトリクス収集間隔は仕様上5分間であり、メトリクスが届くまで待つ時間が長いです。一方、Datadog側でAgent経由でのメトリクス収集間隔は15sで、同じく1分間の頻度で評価すると、より速い検知が実現できます。
 ※補足に、AWSでは[詳細モニタリング](https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/manage-detailed-monitoring.html)を有効化することで、メトリクスを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は、観測データに基づいて自動実行を実現することで、様々な手動作業を削減し、作業ミスを防止することが可能です。これにより、運用コストの大幅な削減が期待できます。是非とも、お試しください。