おもちゃとして遊ぶにしても別のコンテナランナーにした方がよい。というのが現状の結論だ。
絶対にやめたほうがいい。
コンテナ運用したいがAWSしか使えないならECS Fargateを選ぶのが良いし、AWS縛りが無く平易にコンテナ運用したいならGoogle CloudのCloud Runや、Azureのまだプレビュー中だが大いに期待できるContainer Appsを使うのが良いだろう。
ここしばらくTwitterで文句を言いつつAWSのApp Runnerを試していたのだけれど、こりゃどうにもダメだと思ったので記事にした感じ。
追記：この記事の半年後位に振り返り記事を書いた
追記：その翌年、振り返りというか決別記事を書いた
- おもちゃ
- App Runnerに何が足らないのか？
- AWSは高レイヤに弱い
- 注力されていない
- 競合サービス
- ネガティブフィードバック
- 追記: やっぱ自動デプロイに金取られるの納得いかねー
- 追記: 一時停止中は何もできないぞ気をつけろ
- 追記: WebSocketはサポートされていないぞ気を付けろ
- 追記: それでも使ってなんだか変な動きをしたら？ サービス自体を再作成
- 追記: 手前にCDNを挟むときはHostヘッダを転送しない
おもちゃ
ここでいう『おもちゃ』は、何かしら面白いところがあるけれど、プロダクションで使うには致命的に不足している要素がある。といったものを指している。
App Runnerに何が足らないのか？
全て。
競合するコンテナランナーと比べてあらゆる点で機能が負けている。比べるのもあほらしいくらいだ。2022年5月時点で特に気になっているのは以下辺り。
どうにもならん。
↑を書いてからググったら全く同じことが書かれていた。気になるところはみんな同じである。
App Runnerでできないこと (2022年3月時点)
複数イメージ管理
AWS WAF連携
シークレット管理
AWSは高レイヤに弱い
パブリッククラウドのPaaSと言えば、AzureならApp Service、Google CloudならApp Engineがある。AWS界隈なら最近みそがついてしまったが元祖とも言うべきHerokuになるだろう。
ここでAWS自身が提供しているBeanstalkの名前が出てくることは稀だろう。あれはPaaSと言ってはいるが、EC2とALBの薄いラッパーでPaaSとして求められている機能を十全には提供していないので評判が悪いという認識だ。実際自分も使う気にはなれない。
どうにもAWSは全般にクラウドの低レイヤな部分を充実させるのは上手いが、高レイヤな部分でアプリケーション運用に便利な機能を提供するのはヘタなように思える。
App Runnerにしても所詮ECSの薄いラッパーで、何ならラップして欲しくないところまでラップされて不便になっている。
注力されていない
App Runnerはおもちゃだと言ったが、ではおもちゃを脱却する動きはないのだろうか？ ないとは言わないがすこぶる鈍い。
ロードマップが公開されているのだが、そのIssue消化速度はすこぶる鈍い。
およそ1年でたったの11個。リリース前後で無数の改善点があるだろうにだ。
致命的なIssueが1周年を迎えようとしていたり、全く動いていないと言ってもいいくらいだ。
機能充実への投資がされていない。そんなサービスを使いたいと思うだろうか？
競合サービス
コンテナランナーを使うなら素直にGoogle CloudのCloud Runを使うのがよいと思う。あらゆる点でApp Runnerに勝っている。
ただ、個人的にはGoogle Cloudが赤字であるという一点で消極的。競合パブリッククラウドがめちゃくちゃ稼いでいる中で完全な赤字なのは何かしら致命的に筋の悪い点があるように思えてならない。
そんなわけでAzureのContainer Appsが早くGAしないかな、と思っている次第である。先日少し触ってみたけれど、App Serviceベースで非常に扱いやすそうかつ必要な機能が詰まっていて良い感じに見える。
コンテナランナーで後発サービスではさくらインターネットがHacobuneというサービスをオープンベータ提供していたのが記憶に新しい。これは正式提供される目があるのだろうか。
あとは常駐型ではなくFaaSとして必要な時だけ起動するアーキテクチャに興味があるので、そちらを攻めてみるなどしてみたい。Lambdaは実によいのでそれでやる感じ。HTTPリクエストを受けられるようにもなった。積極的に投資されているサービスは良い。
ネガティブフィードバック
AWSはこうしたネガティブな感想をどのように収集しているのだろうか？
僕はポジティブなフィードバックもしていないけれど、そっちはコミュニティだとか営業経由だとかで収集されていそうな雰囲気がある。
他方この記事のようにボロッカスな評価は得られているのだろうか。
余計なお世話なのだろうけれど健全にいい感じにサービスを開発改善していってほしい。
追記: やっぱ自動デプロイに金取られるの納得いかねー
https://aws.amazon.com/jp/apprunner/pricing/
自動デプロイ 1 USD/アプリケーション、月額 オプションとして自動デプロイを選択できます。自動デプロイとは、ソースコードのデプロイブランチ変更に従ってコンテナイメージを構築し、そのうえでデプロイを開始できる機能です。
んなもん競合サービスは空気のように提供している基本機能だろうがよぉ？ ありえねぇだろ？？？？？
$1あったらどんだけCodeXXX動かせると思ってるんだよ。意味わからんわホント。
追記: 一時停止中は何もできないぞ気をつけろ
大事なことを書くのを忘れていた。
競合サービスはHTTPのリクエストがなくなるとインスタンス数が0になり課金が停止するように構成できる。なんとApp Runnerは手動で一時停止できる。当然再開も手動だ。実行インスタンス数は0にはならない。
しかも一時停止中はリソースの削除と参照以外の操作が一切できなくなる。
他の操作をしたかったら停止を解除するという手間が必要となる。
Pausing and resuming an App Runner service - AWS App Runner
ダルすぎるでしょ。
なおそれにブチ切れている様子。
App Runner またテン下げ。環境変数の設定サービスの一時停止中は編集できないっぽい。DX低すぎ。
— 光電/7474 (@koudenpa) 2022年4月21日
追記: WebSocketはサポートされていないぞ気を付けろ
なおCloud Run
Using WebSockets | Cloud Run Documentation | Google Cloud
WebSocket は、追加の構成を必要とせずに Cloud Run でサポートされています。
なおContainer Apps
Ingress in Azure Container Apps | Microsoft Learn
Supports WebSocket and gRPC
もはや何も言うまい。
追記: それでも使ってなんだか変な動きをしたら？ サービス自体を再作成
何か変な状態になったらサービス自体を再作成する。深く考えるのはやめよう。時間の無駄だ。URLが変わってしまうが仕方ない。
自分の場合は以下のような時にサービスの更新が全く成功しなくなった（何か壊れた、ログは出ないので状況は分からん）。
- 参照するイメージのリソース名を間違えた
- ECR参照用のロールを変更しようとした
前者はともかく後者で壊れるのはおかしいだろ。意味わからん。App Runnerは本当にAWSのGAしたサービスなのか？ （全く同じTerraformコードのまま再作成では成功したのでロールがまずいわけではないだろう）
そもそも失敗すること自体に数十分かかる。コンテナ関連のクラウドリソース操作にかかる時間のスケールではない。
これはちょっと違う事例だけれど、
the only alternative appears to be to delete the entire service and start from scratch
サービス作成に失敗したら？ 消して作り直すしかない。笑うしかないね。
追記: 手前にCDNを挟むときはHostヘッダを転送しない
どうやらリクエストのHostを参照してenvoyでルーティングしているようで、（CloudFrontを前に置いてHostヘッダを転送して）サービスとは別なHostヘッダがリクエストに設定されている状態では404応答が返ってきた。
この際、App Runnerのサービスのメトリックとしては404が記録されない（その手前で404応答しているだろうから）ので注意されたし。
