世界の中心でApp Runnerを叫ぶ FINAL

Transcript

1. 世界の中⼼でApp Runnerを叫ぶ FINAL 2026/5/8 JAWS-UGコンテナ⽀部 #29 App Runnerありがとう会
2. 2 ⾃⼰紹介 • 部署 ◦ クラウド事業本部 • ニックネーム ◦ つくぼし • 推していたAWSサービス ◦ AWS App Runner • SNS/ブログ ◦ X(@tsukuboshi0755) ◦ DevelopersIO(つくぼし) 職種歴： 1. インフラエンジニア：3年 2. クラウドエンジニア：3.5年 3. 開発エンジニア：2年
3. 本LTは以前語れなかったApp Runnerとの思い出ベースで話します 3 世界の中⼼でApp Runnerを叫ぶ ~Aurora DQSLを添えて~
4. ⽬次 4 1. App Runnerとの思い出を振り返ってみる 2. App Runnerへの想いを叫んでみる 3. App Runner難⺠が辿り着くAWSサービスはどれか 4. まとめ
5. App Runnerとの思い出を振り返ってみる
6. 6 私とApp Runnerの経歴 • とあるパッケージ開発PJのインフラ担当に任命される • このパッケージが当初検証⽤途だった事もあり、インフラ設定が簡単 なApp Runner(とAWS Copilot CLI)で動いていた • このインフラ基盤のIaCを改修する所から全てが始まった • …結果1年半以上の⽉⽇をApp Runnerと共にする事になった
7. 7 最初のApp Runnerの印象 ネットワークを意識せずに動くアプリってありえるのか？？？
8. 8 出会った頃に気づいたApp Runnerのすごさ • VPCが必要ないサービスのみに接続を閉じておけば、基本VPC回りの エラーに遭遇する事がない • ALBの機能も抱き合わせているので、ロードバランサーもよしなに やってくれる • デプロイ周りの設定もGitHubやECRと統合し、簡単に設定できる →こいつすごくね？
9. 9 短絡的な私はこう考えた App Runnerを布教して簡易アプリからVPCを撲滅するぞ！！！
10. そして付き合っていく内にApp Runnerがどんなサービスなのか 私は思い知らされる事になった... 10
11. App Runnerへの想いを叫んでみる
12. VPCレスのコンテナ基盤は想像より需要がある 12
13. 13 VPCレスのコンテナ基盤は想像より需要がある • 開発を主戦場とする⽅は、クラウドであろうとNWインフラに苦⼿意 識を持つ事が多い印象がある • App Runnerはそのような開発者の⽅がファーストチョイスする際に すごい刺さりやすいサービスであった • Webサービスは基本VPCの中で動かさないといけないという固定観念 がどこかにあったが、App Runnerのおかげで完全に崩れた
14. やっぱりWebSocketに対応できなかったのが痛かったと思う 14
15. 15 やっぱりWebSocketに対応できなかったのが痛かったと思う • ⽣成AI時代に⼊ってからStreamlit(WebSocket)でAIエージェントアプ リを動かしたい需要が爆増した • 当時App Runnerはエージェントアプリと相性が良さそうに⾒えたた め、エージェント基盤としての対応が注⽬されていた...
16. 16 やっぱりWebSocketに対応できなかったのが痛かったと思う
17. 17 やっぱりWebSocketに対応できなかったのが痛かったと思う
18. ⽇に⽇に落ちていくサービスの更新頻度が悲しかった 18
19. 19 • 最初は今後のロートマップがGitHubで公開されるくらい期待された サービスだったんですよ？ • それがいつの間にかロードマップがクローズされた後は、新機能がな いどころかNode.jsやPythonのランタイムバージョンも期限切れまで 中々バージョンアップされない事態に... • あまりにもサービスの更新頻度が少ない上に、ランタイムも中々更新 されない不安がパッケージをECSに移⾏する決断を後押ししてしまっ た ⽇に⽇に落ちていくサービスの更新頻度が悲しかった
20. App Runner難⺠が辿り着くAWSサービスはどれか
21. VPCレスな基盤でWebアプリケーションを動かしたい！！！ 21 App Runner難⺠が求めていたこと
22. 候補①Amplify 22 • フロントエンドフレームワークをベースとしたフルスタックな基盤と して利⽤可能 • Gen 2でCDKベースになった事でIaC管理もしやすくなった • バックエンドを任せようとするとAppSync周りの管理が結構しんど いので注意 • そもそもコンテナが動かないのでdockerも使えない
23. 候補②Lambda Web Adaptor 23 • 通常のアプリケーションの書き⽅でLambdaコンテナが動く • Functions URLやNext.jsのstandaloneモード等を組み合わせる事で フロントエンドも組み込めたりする！ • Lambda特有の仕様(コールドスタート/tmpディレクトリ以外の書き 込み不可/コネクションプールの扱い等)はそのまま引き継がれる • なのでアプリの要件をしっかり固めておかないと、使い始めてからし んどい時があるのに注意
24. 24 • 制限の少なさやチューニング項⽬の多さにより、様々なアプリケー ション要件に対して柔軟に対応できる • 最近はExpress Modeも出たので構築難易度も下がっている • VPCの運⽤が必要な点を踏まえたとしても、本番環境で使うなら実績 ‧安定性‧運⽤負荷のバランスがとても優れている 最終的に⾏き着く先はECSになってしまうのでは...？
25. まとめ
26. 最後に 26 • App RunnerはVPCレスなAWSのコンテナ基盤としては今でも唯⼀無 ⼆のサービスです • App RunnerはVPCレスなWebアプリ構成がアリだというのを気づか せてくれた点で、間違いなく私の推しだった • やはり元App Runner⺠はVPC管理に⽂句をいいながらも、ECSの柔 軟さには叶いません
27. 改めてApp Runnerというサービスを推せて感謝です 27
28. お願い：次の推しAWSサービスを急募中です！！！ 28