概要
AWS App RunnerのVPCリソースへのアクセスが可能になり、色々と検証している中で、ECS・Fargateとの違いなどを簡単にまとめてみました。
目次
注意
個人的な主観レベルのものであったり、短い時間での操作によって判断したものもあるため、内容に間違い・変更がある可能性がある点はご了承下さい。
(2022年2月13日に執筆しました。新規情報があれば随時更新していきます。)
アップデート情報
- 2023/01/06: AWS Secrets ManagerとAWS Systems Managerからのシークレットの取得に対応 <- new!!
- 2022/11/1: VPC内からのプライベートアクセスに対応
- 2022/10/28: マネージドランタイム(ソースコードのプッシュから自動デプロイ)にPHP, Go, .Net, Ruby対応
- 2022/09/26: マネージドランタイム(ソースコードのプッシュから自動デプロイ)にNode.js 16対応
- 2022/09/16: クロスリージョンのECRからのデプロイに対応
- 2022/08/30: Route53のAliasレコード対応
- 2022/04/12: X-Rayサポート開始
- 2022/02/22 : GitHubとの連携時の対応ランタイム追加
- Java(Corretto 8, Corretto 11)、Node.js 14
- docs.aws.amazon.com
前提
以下のメリット・デメリットは、AWS App Runnerの特徴をベースに記述しています。
App RunnerのメリットはECS・Fargateにないもの、App RunnerのデメリットはECS・Fargateにあるもの、といったイメージです。
AWS App Runnerのメリット
- CI/CDの簡易化
- VPCやELBのリソースの隠蔽
- VPCやELBを作成せずにアプリのプロビジョニングが可能
- 既存VPCリソースへのアクセスも可能に
- go-to-k.hatenablog.com
- ロググループの自動作成
- 以下3種類のログが自動で作成される
- アプリケーションログ
- デプロイログ
- イベントログ
- 以下3種類のログが自動で作成される
- セキュリティグループの隠蔽
- ECS, ELB用
- AutoScalingポリシーの簡易化
- ECS・Fargateの際のようなCloudWatch Alarmが必要ない
- しかし別途設定がいる(ECSと少し項目が違う)
- SSL証明書の発行
- ACMでの設定・管理がいらない
- しかし同じような手順は行う必要がある
AWS App Runnerのデメリット
- ECR連携で自動デプロイをする場合、実質latestタグ固定の運用が必要
- 自動デプロイは特定のイメージタグのプッシュをトリガーにするために、固定のタグの必要がある
- タグをイミュータブル(上書き禁止)にできない
- ECRにはイミュータブルタグ機能がある
秘匿な環境変数が扱えないカスタムドメイン設定でALIASレコードが未対応- 2022/08/30 ALIASレコード対応されました!!
- AWS WAFをアタッチできない
- Fargateでの運用ではELBにアタッチする
- App Runnerへのインバウンドを制御するセキュリティグループがつけられない
- 現状App Runnerにアタッチするセキュリティグループはアウトバウンドに使われるものであるため
- IP制限ができない
- 上記の通り、WAFやインバウンド用セキュリティグループがつけられないため
- CloudFrontを前段に置けば可能
- アクセスログが出せない
- ELBアクセスログのようなログ
- どうしても欲しくて起票しました。
- サイドカーコンテナを組み込めない
- ECSのContainer Insightsレベルのメトリクスは取れない
- ECS Execができない
- スケーリング基準が同時実行数のみ
- 他のメトリクスでのスケーリングは現状できない
- AutoScalingの最低台数を0にはできない
- 何台立ち上げているのかわからない(わかりづらい)
- アクセスが来ない期間は、Active Instancesメトリクスが0になるため
- 料金の大部分(vCPU代)はActive Instancesに起因して料金発生する(0なら発生しない)ので、Fargateと比べて厳密にわからなくても良いところはある
- スペックの種類が少ない(以下のCPU, Memoryの組み合わせのみ)
- 1 vCPU, 2 GB
- 1 vCPU, 3 GB
- 1 vCPU, 4 GB
- 2 vCPU, 4 GB
- カスタムドメインやAutoScalingConfigurationがCloudFormation未対応
- CLIかカスタムリソースが必要
- Arm(Graviton)イメージ未対応
- EFS未対応
- Windowsコンテナ未対応
どちらでも変わらないこと
- ソースコードまたはDockerfile(ECR連携の場合)の管理
- スペック指定の必要
- CPU
- メモリ
- AutoScalingのルール定義
- 最小台数
- 最大台数
- スケールアウトの閾値
- App Runnerでは同時接続数(デフォルト: 100)
- ヘルスチェックルール定義
- IAMロールの管理
- App Runnerの方が少しは楽
- CloudWatch Logsなどへのポリシーはいらないため
- App Runnerの方が少しは楽
- ポートや環境変数の管理
- やらなくても良い
ロードマップ
今後のApp RunnerのロードマップをGitHubのissuesにて見ることができます。
欲しい機能などのissueがあればgoodリアクションをすると良いですね。
実際にロードマップに機能追加のリクエストを出してみました。起票の仕方なども書いてみたので、よかったらぜひご覧下さい。
最後に
App Runnerをちゃんと触ってみて、すごく便利だなと思いつつも痒いところに手が届かない点が見えてきました。
でもフルマネージドサービスってトレードオフというか、こういうことですよね。
あまり機能を詰めてもECS・Fargateと変わらなくなってしまうし・・・
ただFargateのフルマネージド感や便利さもすごかったのに、さらに便利なマネージドサービスが出てくるところが技術の進化・変化を感じますね。
今後いい塩梅に機能が追加されてくれたらもっと素晴らしいサービスになりそうで、今後に期待です。
※Twitter始めました!
良かったらぜひ。
Twitter ID → @365_step_tech