ドキュメントから読み取れなかったApp Runnerで気になったこと

この記事は結論がありません。調べてみましたが原因がわからなかったのでApp Runnerに詳しい人がいましたらアドバイスいただけますと幸いです。

背景

会社でDatadogによるモニタリング基盤の構築を実装しています。最初はメディアサーバーやDBを監視するためにエージェント起動用のEC2を用意してそこからサーバーへの外形監視やDB監視を構築していました。
ただ導入しているエージェントを動かすためだけにサーバーを用意するのはもったいなかったのでコンテナにDatadogエージェントを導入し、そこから起動するようにしました。
せっかくなので昨年リリースされたApp Runner^[1]でDatadogエージェントコンテナを構築してみました。

アーキテクチャ図

App RunnerならECR^[2]にコンテナイメージをセットするだけで面倒なネットワーク周りの設定も簡略化でき、監視メディアを追加する際もレジストリにプッシュするだけでコンテナの自動デプロイで簡単に増やすことができるので、運用が楽になると思ったのが採用理由になります。

EC2からECSへのDatadogエージェント移行は後日会社のテックブログに詳しい解説を掲載します。

ただApp Runnerでメディアサーバーを外形監視すると奇妙なことがありました。

レスポンスタイム劣化

App Runner上のDatadogエージェントから弊社のメディアサーバーに外形監視し、取得したレスポンスタイムのグラフ結果は以下のようになります。

メディアサーバー毎のレスポンスタイム取得値

最初に数メディアをECS Fargateから監視し挙動を確認した後に、DatadogエージェントをApp Runnerに乗せ換えてみました。それがお昼時くらいのことですが移行直後から急激にレスポンスタイムが上昇していることがわかります。最初は移行直後だからと様子見しましたが、丸一日経っても改善しなかったため翌日にFargateに切り戻ししました。

Curl検証

DatadogエージェントがApp Runnerと相性が良くないのではと思いましたが、curlで単純なレスポンスタイムを取得するコンテナ^[3]を用意してFargateとApp Runnerからそれぞれ計測してみることにしました。

Dockerfile

FROM  curlimages/curl:latest

CMD  curl -s -o /dev/null -w '%{time_starttransfer}' <うちのメディアURL>

ローカルからの実行例

$ docker build -t curl-yuta .
$ docker run --rm curl-yuta
0.252717

FargateとApp Runnerから取得できたレスポンスタイムはこちらです。

Fargateコンテナ

App Runnerコンテナ

Datadogエージェントほど露骨ではありませんが、curlでもApp Runner経由で取得した方がレスポンスタイムが遅くなっていることがわかります。

謎のコンテナ

Datadogではエージェントを導入したホスト/コンテナが自動的にダッシュボードに登録されます。

Fargateコンテナ

FargateでDatadogエージェントコンテナを導入したときは1台登録されていました。
次にApp Runner上でDatadogエージェントをデプロイしたときの画面です。

App Runnerコンテナ

不思議なことに2台のエージェントコンテナが動いています。aws-fargate-request-proxyというコンテナが動いていますが、このコンテナの詳細がApp Runnerのドキュメントからは見つけることができませんでした。
あくまでも私の予想になるのですが、App Runner上にデプロイされたコンテナは直接外部通信するのではなく、あいだにプロキシコンテナが存在しその分時間が遅くなるのではないかと考えています。

予想アーキテクチャ図

もちろん私の推測なので違っていましたらアドバイスいただけますと幸いです。

現状

事業部から新規メディアリリースに伴う監視対象の追加依頼が発生した際は監視メディアのURLを編集したリストをGitHubにプッシュ、ECRにイメージがビルドされるとApp Runnerがトリガーとなり追加されたメディアのURLを監視するといった自動化を実現したかったのですが、ユーザー体感に近いレスポンスタイムを取得できないとなると諦めざるをえませんでした。

想定していた自動図

現在はFargate上でDatadogエージェントをデプロイし、監視するようにしています。

幸いなことにGitHub ActionsからECS Fargateへの自動デプロイはテンプレートがありましたのでやりたかったことはすんなり実現できました。
こちらに関しては会社のテックブログに近日公開しようと思いますので興味ありましたらそちらもご覧ください。

所感

App Runnerをチュートリアル以外ではじめて使ってみましたが、残念ながら仕事に活用できませんでした。
個人的には簡単にコンテナのデプロイができたので、別の機会で使ってみたいなと思います。

追記

弊社で契約しているAWS SAに聞いてみましたが、現在App Runnerは非同期処理が難しくWebリクエストベースでの利用に限定されているそうです。
https://github.com/aws/apprunner-roadmap/issues/96
案内されたissueによりますと、App Runnerは同時リクエストベースでスケールし、リクエストが来なければCPUをスロットリングし、メモリ課金のみのプロビジョニングされたコンテナインスタンスに状態遷移されるそうです。
上図のようにApp Runnerへのリクエストが発生しないプッシュ型のエージェントコンテナではコンテナが自動的にプロビジョニングされCPUがうまく動かないからだと思われます。

さきほどのApp RunnerコンテナのCPU使用率をみてますと値が0%のまま取得できていなかったのはコンテナがプロビジョニングされているからです。
ただプロビジョニング状態で(レスポンスタイムが遅くなっているとはいえ)、Datadogにデータを送信できているのは興味深いとも仰っていました。
こちらのissueについては機能リクエストも上がっており、対応中らしいので来年にはもしかするとDatadogエージェントコンテナをApp Runnerでも利用できるかもしれません。私はFargateで構築しましたので再構築はしませんが、興味ある人がいましたらApp Runnerのロードマップを確認してぜひ試してみてください。

LT資料

LTのスライド資料です。

英語記事

英訳しました。
https://dev.to/yuta28/not-documented-app-runner-specification-1929

参考文献

https://zenn.dev/taxin/articles/curl-time-measure
https://www.thousandeyes.com/ja/blog/measuring-performance-with-http-proxies
https://docs.datadoghq.com/ja/integrations/http_check/

脚注

1. https://aws.amazon.com/jp/apprunner/

2. https://aws.amazon.com/jp/ecr/

3. https://hub.docker.com/r/curlimages/curl