Lean Baseball

No Engineering, No Baseball.

雑にWebアプリを公開するのにAWS App Runnerは便利でしたというメモ

気がつけば仕事も趣味も「クラウドなインフラで何かやる人*1」になったマンです.

個人的なプロダクト開発・運用やデータサイエンスな作業はGoogle Cloudメインでやってる私*2ですが, (そんな事情もあって)そういえばAWSのサーバレスなサービスにあまり触れてないな🤔と思い, ちょっと試しに触ってみました*3.

aws.amazon.com

Google CloudのApp EngineおよびCloud Runと比較されることが多いApp Runnerを試してみたのでその結果をメモとして残したいと思います.

なお, 「AWSとGoogle Cloudどっちがいい?」という話ではないのでその前提でお読みください(好きな方・目的に合う方を使うのがいいですよ!)

対象読者

Webアプリケーションを作る人かつ,

  • PythonのFlaskやDjangoあたりでWebアプリ開発をしたことがある(Hello worldに毛が生えた程度の内容ならなお良い)
  • Google App EngineやHerokuでアプリを作って動かしたことがある
  • AWSコンソールやGitHubを使って開発している

レベルの方ならついていけると思います(割と初心者よりかもです).

TL;DR

ひとまずアプリケーションを作って公開, というレベルならAWS App Runnerはめちゃ便利!

ただし, かゆい所に手が届かない所もあるのでそこは注意.

目次

やったこと

やったことですが,

  • Flask(Python)のWebアプリをApp Runnerにデプロイして公開
  • mainブランチにpushするとアプリが勝手にデプロイされる(main以外はGitHub Actionsでテストを走らせる)

というシンプルなモノです, 絵に描くと以下のようなノリです.

f:id:shinyorke:20220227192325j:plain
やったこと

なお, Applicationは予めgunicornで動かせるようにしておきます(8000番でlistenしています).

$  gunicorn main:app
[2022-02-28 19:41:28 +0900] [49388] [INFO] Starting gunicorn 20.1.0
[2022-02-28 19:41:28 +0900] [49388] [INFO] Listening at: http://127.0.0.1:8000 (49388)
[2022-02-28 19:41:28 +0900] [49388] [INFO] Using worker: sync
[2022-02-28 19:41:28 +0900] [49389] [INFO] Booting worker with pid: 49389
^C[2022-02-28 19:41:29 +0900] [49388] [INFO] Handling signal: int
[2022-02-28 19:41:29 +0900] [49389] [INFO] Worker exiting (pid: 49389)
[2022-02-28 19:41:30 +0900] [49388] [INFO] Shutting down: Master

ひとまず使ってみる

作ったアプリの公開は以下の2ステップでいけちゃいます.

  • GitHub Repositoryと接続
  • アプリケーションの設定

GitHub Repositoryと接続

GitHubにRepositoryとのつなぎ込みは, 画面をポチポチしつつ, アプリケーションのRepositoryに権限をつけるとすぐ出来ちゃいます.

f:id:shinyorke:20220228221642j:plain
設定はこんな感じ

ここの「デプロイ設定」で,

  • aws cliやコンソール, (コンソールの説明にはありませんが)別のCIをトリガーにしてデプロイする「手動設定」
  • リリース用のブランチを決めて, pushしたら自動的にデプロイされる「自動設定」

を選択できます.

小さなアプリケーションや個人的な開発であれば, 「mainにpush = デプロイ可能」みたいな感じでシュッと設定するのも有りです(上記スクショがその例).

アプリケーションの設定

コンテナ化したアプリケーションの動作設定もポチポチしたら終わっちゃいます.

f:id:shinyorke:20220228221930p:plain

  • ランタイムの選択
  • 構築コマンド(Pythonの場合, pip install -r requirements.txt をやる感じ)
  • 開始コマンド(この例だとgunicornの起動コマンド)
  • ポート

これもポチポチで終わります.

あとは, スケーリングの設定等色々選択(面倒な方は初回そのままでもいいかも)でサービスを作成するとアプリケーションが公開できちゃいます.

個人的には初めて触って1時間ちょっとでできちゃったので感動しました😀

Cloud Runと比べた感想

こうやって小一時間触って「めっちゃええやん!」ってなったApp Runnerですが, 私の普段使いはCloud Run(Google Cloud)だったりするので, ちょっと比べて見ました.

なお, 「どっちが優秀」とかそういう話じゃないです.

App Runnerの方が悩むポイント少ない(かも)

直感的に思ったのが, 「とりあえずアプリケーションをデプロイしたい!」ってなったときのやりやすさはApp Runnerやりやすいと思いました.

コンソールの内容に従うだけでできちゃうのはすごく気持ちいいし, 何よりGitHubにRepositoryがあるときは連携が秒でできてしまう(かつ, pushでデプロイする自動設定を選ぶと自前でCDを用意する必要がなくなる)のは開発者体験として最高だなと思いました.

Cloud Runも「ひとまずgcloud run deploy したらすぐ使える」便利さがありますが, コンソールからの使いやすさ, ひとまずGitHubにコードがあったらすぐ出せるという点でApp Runnerの方が直感的で初心者に勧めやすいなと思いました.

個人の感想ですけどね.

App Runnerができない・苦手なこと

一方, 超便利なApp Runnerですが,

  • カナリアリリース(いわゆるX%配布)みたいな事がApp Runner単独ではできない(Cloud Runは単体でカナリアができる). カナリアをやりたいときはAPI Gatewayとのあわせ技になる(はず).
  • GitHubから直接じゃないパターンだと一度ECR(Elastic Container Registry)にアプリケーションをupしてから動かすことになるので実質ECS(Elastic Container Service)を使うのと変わらなくなる(ECSより設定が楽とはいえ).

「ひとまずWebアプリケーションやらAPIを建てるのには便利だがちゃんと使おうとするとやることが増える」と言ったところでしょうか.

初手のデプロイがすごく楽な分, そこから仕事・プロ的に使うのに一気にハードル上がる感はあります.*4

結び

というわけで, 久々にAWSのサービスを触っていい感じだったのでメモとしてエントリーとして残しました.

App Runnerとは関係ない所ですが, 約半年ぶり?にAWSに触ったのですが, コンソールとかドキュメントがわかりやすくなってていいなと思いました.

個人開発は99%Google Cloudに依存していますが, たまにはAWS使おうかな...

ひとまず, App Runnerは気に入ったのでなにかの機会で使ってみようと思います!

Appendix: 参考文献

執筆にあたり, 以下のブログを参考にさせていただきました(感謝)

zenn.dev

iselegant.hatenablog.com

*1:狙ったわけではないですが仕事も個人もそういうノリになりました.

*2:理由はいくつかありますが, 自分が作るものの殆どが最終的にBigQueryに依存しているため, 同じGoogle Cloudで全部やっちゃおう!というのが最も大きな理由かもしれない

*3:&同僚との雑談からやろう!ってなったのも理由の一つです.

*4:私を含め, アプリを作りなれてる人的には良いのですが, 初心者の人がプロ仕様で作ったり公開したりするときにハマりどころ多そうだなと思いました.