今更ながらApp Runnerを使ってみたらすごく便利だった（Fargateとの比較含む）

これまで、コンテナでアプリを構築する際は、Fargateを使ったりamplifyを使っていて、App Runnerは使ったことがなかったのですが、今回初めて使ってみて、設定がシンプルでとてもわかりやすかったので、内容を記事に残します。

作成するアプリの要件

作成するアプリに、以下のような要件があると仮定します。

• ロードバランサで負荷分散したい
• ヘルスチェックを行って死活監視したい
• リクエストに応じてオートスケールしたい
• ログを管理したい
• CI/CDを構築したい
• 通信をSSL化したい

Fargateを使ってこれらの仕組みを作ろうと思うと、結構大変ですよね。ざっと考えただけでも、以下のAWSリソースを作成する必要があります。もちろん、これでも一からコンテナオーケストレーションの仕組みを作ることを考えたら、かなり楽なのでしょうが。

• ALB
  • 負荷分散やヘルスチェックを行うために必要
• ECS Cluster、ECS Service、ECS Task Definition
  • コンテナを管理するために必要
• Auto Scaling
  • オートスケールするために必要
• Code Pipeline
  • CI/CDを行うために必要（Github Actions等でも代用可）
• ACM、Route53
  • 通信をSSL化するために必要
• Security Group、IAM Role
  • ネットワーク、権限の制御をするために必要

App Runnerを使うと、これらの要件を満たしたアプリケーションをあっという間に作ることができます（ただし、Fargateと比べていくつか制約もあるので、そちらは後述します）。

App Runnerの設定手順

コンテナのアプリケーションを作成してECRでプッシュするといった事前準備含めて、たった8つのステップでアプリケーションを構築できます！

1.コンテナで動くアプリケーションを用意する

今回は、以下のリポジトリに作ったGoのアプリケーションを使います。

https://github.com/hisami/go-eks-sample

一応、ローカルで動作確認をしておきます。
以下コマンドを打ってDockerイメージをビルドしコンテナを起動したあと、localhost:8080へアクセスすると、Server Running!!と表示されるはずです。

docker build . -t go-hello-app
docker run -d -p 8080:8080 go-hello-app

2.イメージをECRヘプッシュする

ECRにリポジトリを作ると、プッシュコマンドの表示というボタンがあるのでここを押すと表示されるコマンドを打って、ECRにイメージをプッシュします。
本当は、Github Actionsで自動化したいですが、今回のメインはApp Runnerの検証であるため、一旦手動設定でよしとします。

以上で、事前準備が終了で、ここから、App Runnerの設定に入ります。

3.ソースの選択

以下画面で、先ほど作成したECRのイメージを選択します。

4.デプロイ手順の設定

以下の自動を選択することで、ECRに新しいイメージがプッシュされたタイミングで新しいバージョンがデプロイされます。

5.CPUやメモリの設定

amplifyでコンテナを作成する場合は、現状CPUやメモリを設定できないのですが（コンテナの台数を増やすことはできる）、App Runnerの場合は設定できます。

6.Auto Scalingの設定

スケールの基準となる、インスタンスあたりのリクエスト数や、最小・最大インスタンスの設定を行います。Fargateの場合だと、スケールの基準を自由に設定可能ですが、正直、App Runnerで提供されているリクエスト数で十分かなという気がします。

7.ヘルスチェックの設定

ALBで設定するのと同じような、ヘルスチェックの設定が可能です。

8.ネットワークの設定

App RunnerからVPC内のリソース（DBなど）にアクセスする必要がある場合は、カスタムVPCを選んで設定していきます（少しハマりどころがあったので別の記事で紹介したいと思います）。
今回は、パブリックアクセスを選択します。

設定は終わり

以上で設定は終わりです。たったこれだけで、冒頭に記載したような要件のアプリケーションを構築することができます！簡単すぎて感動ものです。

Fargateとの比較

すごく簡単に設定できるApp Runnerですが、Fargateと比べた時に、以下のような制約があります。
（もし、内容が間違っていたり、こんな制約もあるよと、という点があればコメントいただけるとありがたいです。）

影響大

• 複数イメージの管理ができない
  • 複数コンテナを立ち上げられない
  • サイドカーコンテナのような構成が組めない
• パスベースのルーティングができない
  • ELBの細かい設定ができない
• Secrets Managerが使えない
  • アプリケーションで自前実装すれば可能
• WAFを直接アタッチできない
  • 前段にCloudFrontをおけばアタッチできるが、App Runnerの接続元をCloudFrontに制限することができない
• EFSをマウントできない
• Windowsコンテナ未対応
  • Windowsコンテナが必須であればその時点でNG

影響小

• ECS Execが使えない
  • ECS内にsshで入れない
• latestタグ固定でのDockerイメージの運用が必須になる
  • イメージを選択する画面で、タグを含めて選択する必要があるため
• Auto Scalingの細かい設定ができない

まとめ

簡単にアプリケーションをデプロイできるAppRunnerですが、その代償として上記の通りいくつか制約があります。
大きめのアプリケーションや、要件が厳しめのアプリケーションの場合は、App Runnerを使うのは難しいかもしれませんが、そうでない場合は積極的にApp Runnerを使っていくのが良いのではないかと思いました。コンテナでアプリを作っていれば、後からFargateに載せ替えることもできますし。また、App Runnerの機能はどんどんアップデートされていっているので、現時点では実現できない機能も将来的にはサポートされる可能性は高いと思います。