【現場の本音】App Engine から Cloud Run に移行してみた

Google Cloud Innovators Live Japan

Mar 23, 2023

https://cloudonair.withgoogle.com/events/innovators-live-jp/watch?talk=serverless_container_20230323

Transcript

1. スタートアップが Cloud Run に移行して 2 年で 500 回リリースした話 Hiroaki KARASAWA from dinii, inc. Mar 23, 2023 → Jun 9, 2023
3. 自己紹介 氏名：唐澤弘明 @karszawa 所属：株式会社 dinii • 飲食店のモバイルオーダーとレジの会社 • karszawa は黎明期にジョインしほぼすべての技術選定に関与 • Frontend → Full stack → Full stack + SRE 今日の話 • App Engine から Cloud Run に移行した • 可用性を維持しつつもスタートアップにとって超重要なアジリティを獲得できた ◦ というか表裏一体だった
4. 株式会社 dinii について
5. エンジニアはフルタイムが 10名
7. 550万人
8. ストリームにも入ってます！
11. 新しい価値の提供 【要求の厳しいシステムの開発】 vs 【新しい価値の提供】
12. 移行前 (App Engine) の状況
13. Place Image Here App Engine (flex) のデプロイ速度が遅かった アプリケーションは docker image で管理 • ローカル環境と確実に同じ状態を作りたい • デプロイ時に毎回ビルドするので遅い 毎週月曜 6:00 AM に定期リリース • 飲食店の営業時間は避けたい • 起床 ⇒ デプロイボタンを押す ⇒ 虚無 ⇒ 動作確認 ◦ 動作確認を開始するまで 20−30分 ぐらい デプロイが遅いため DB 再起動が障害時のベストプラクティスに （普通はそんなことないと思います）
14. ① 障害時 • 【取り敢えず再起動】のコストが大きいため結果的に 【だいたい正解】だとしても決断が遅延 ◦ 👺 < 判断が遅い！ ② 通常開発時 • 開発後の検証環境への反映も遅い • もちろん機能提供までの時間も遅くなる ◦ デプロイ回数 = サービス価値 【補足】デプロイが遅いと何が辛いのか
15. Place Image Here App Engine (flex) はスケーリングも遅かった ヘビータスクが CPU を食い尽くす • 売上データを出力すると注文できなくなる • スケーリングが遅く捌ききれない 良いところもあった 💞 • CPU のスペックを自由に指定できた • Cloud Run は vCPU のコア数だけ指定できる • シングルプロセスの言語ではコアを増やしても パフォーマンスは上がりにくい データ出力機能が原因の鳴り止まない電話
16. Cloud Run への移行後
17. Place Image Here ① デプロイが 3 分で出来るようになった 公式キャッチフレーズ 【コンテナを秒単位で本番環境にデプロイ】 事前に docker image をビルドしておく • タグが打たれたら Cloud Build を起動 デプロイ ⇒ 動作確認 ⇒ 二度寝 • リスクが小さいので 8:00AM でも良いかも デプロイに利用している GitHub Actions の画面
18. Place Image Here ② 障害時の切り戻しは数十秒で 互換性の有無で minor バージョンを変更 • 何か問題があったときも minor バージョンが同 一ならカジュアルにリバート ※ データベース マイグレーションの扱いは注意 環境変数で挙動を切り替えられるように作る • 検証機能のオン・オフ • 外部サービス起因の障害への対策 よく分からないときは初手でリビジョンをリバートする
19. Place Image Here ③ Cloud Build でビルドも高速化 kaniko cache でキャッシング • ビルド時間は 1 min+α ぐらい • マシンスペックは最高（速いので結局安い） ◦ ※ 全体費用の 0.3% ぐらい 変更即デプロイで QA サイクルが高速化 • 一日に 5 ~ 10 回のデプロイを実現 ビルド自体も Cloud Build でそこそこ速い
20. Place Image Here ④ スケーリングもしやすい • 同時実行数を必ず指定するデザイン • 毎日 19:30 頃が緩やかなピーク • Cloud Run での起因のインシデントは無し ◦ データベースやアプリケーション起因の 大規模障害は散発的に発生 …。 • 安い（全体の ⅕ 程度） リクエストの変化とインスタンス数の伸び ディナー ランチ
21. 移行後にやっておけば良 かったこと
22. 1. Cloud Load Balancer の導入 a. Cloud Run 自体に似たような機能があるが Load Balancer も入れといて損はない b. というか入れておいた方が移行がラク 2. 同時実行数の設定に向き合う a. コネクションプール のサイズが律速になっているのが落とし穴 3. startup prove の設定 a. 最近できるようになった b. 立ち上げ前のアプリケーションへのリクエストを制限できる Cloud Run への移行後にやっておけば良かったこと
23. まとめ
24. Place Image Here まとめ App Engine ⇒ Cloud Run によりデプロイのコストが劇 的 に安くなり 2 年で 500 回のデプロイを実現 • 1 deploy / 1 business day デプロイに利用している GitHub Actions の画面 アップデートもたくさんあって嬉しい • 最近は startup probe が嬉しかった 今すぐ Cloud Run の PM を Twitter でフォローしよう ⇒ @steren
25. Thank you. Proprietary + Confidential