Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Hiroaki KARASAWA
June 12, 2023
53

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

Hiroaki KARASAWA

June 12, 2023
Tweet

Transcript

  1. スタートアップが Cloud Run に移行して
    2 年で 500 回リリースした話
    Hiroaki KARASAWA from dinii, inc.
    Mar 23, 2023 → Jun 9, 2023

    View full-size slide

  2. 自己紹介
    氏名:唐澤弘明 @karszawa
    所属:株式会社 dinii
    ● 飲食店のモバイルオーダーとレジの会社
    ● karszawa は黎明期にジョインしほぼすべての技術選定に関与
    ● Frontend → Full stack → Full stack + SRE
    今日の話
    ● App Engine から Cloud Run に移行した
    ● 可用性を維持しつつもスタートアップにとって超重要なアジリティを獲得できた
    ○ というか表裏一体だった

    View full-size slide

  3. 株式会社 dinii について

    View full-size slide

  4. エンジニアはフルタイムが
    10名

    View full-size slide

  5. ストリームにも入ってます!

    View full-size slide

  6. 新しい価値の提供
    【要求の厳しいシステムの開発】 vs 【新しい価値の提供】

    View full-size slide

  7. 移行前 (App Engine) の状況

    View full-size slide

  8. Place Image Here
    App Engine (flex) のデプロイ速度が遅かった
    アプリケーションは docker image で管理
    ● ローカル環境と確実に同じ状態を作りたい
    ● デプロイ時に毎回ビルドするので遅い
    毎週月曜 6:00 AM に定期リリース
    ● 飲食店の営業時間は避けたい
    ● 起床 ⇒ デプロイボタンを押す ⇒ 虚無 ⇒ 動作確認
    ○ 動作確認を開始するまで 20−30分 ぐらい
    デプロイが遅いため DB 再起動が障害時のベストプラクティスに
    (普通はそんなことないと思います)

    View full-size slide

  9. ① 障害時
    ● 【取り敢えず再起動】のコストが大きいため結果的に 【だいたい正解】だとしても決断が遅延
    ○ 👺 < 判断が遅い!
    ② 通常開発時
    ● 開発後の検証環境への反映も遅い
    ● もちろん機能提供までの時間も遅くなる
    ○ デプロイ回数 = サービス価値
    【補足】デプロイが遅いと何が辛いのか

    View full-size slide

  10. Place Image Here
    App Engine (flex) はスケーリングも遅かった
    ヘビータスクが CPU を食い尽くす
    ● 売上データを出力すると注文できなくなる
    ● スケーリングが遅く捌ききれない
    良いところもあった 💞
    ● CPU のスペックを自由に指定できた
    ● Cloud Run は vCPU のコア数だけ指定できる
    ● シングルプロセスの言語ではコアを増やしても
    パフォーマンスは上がりにくい
    データ出力機能が原因の鳴り止まない電話

    View full-size slide

  11. Cloud Run への移行後

    View full-size slide

  12. Place Image Here
    ① デプロイが 3 分で出来るようになった
    公式キャッチフレーズ
    【コンテナを秒単位で本番環境にデプロイ】
    事前に docker image をビルドしておく
    ● タグが打たれたら Cloud Build を起動
    デプロイ ⇒ 動作確認 ⇒ 二度寝
    ● リスクが小さいので 8:00AM でも良いかも
    デプロイに利用している GitHub Actions の画面

    View full-size slide

  13. Place Image Here
    ② 障害時の切り戻しは数十秒で
    互換性の有無で minor バージョンを変更
    ● 何か問題があったときも minor バージョンが同
    一ならカジュアルにリバート
    ※ データベース マイグレーションの扱いは注意
    環境変数で挙動を切り替えられるように作る
    ● 検証機能のオン・オフ
    ● 外部サービス起因の障害への対策
    よく分からないときは初手でリビジョンをリバートする

    View full-size slide

  14. Place Image Here
    ③ Cloud Build でビルドも高速化
    kaniko cache でキャッシング
    ● ビルド時間は 1 min+α ぐらい
    ● マシンスペックは最高(速いので結局安い)
    ○ ※ 全体費用の 0.3% ぐらい
    変更即デプロイで QA サイクルが高速化
    ● 一日に 5 ~ 10 回のデプロイを実現
    ビルド自体も Cloud Build でそこそこ速い

    View full-size slide

  15. Place Image Here
    ④ スケーリングもしやすい
    ● 同時実行数を必ず指定するデザイン
    ● 毎日 19:30 頃が緩やかなピーク
    ● Cloud Run での起因のインシデントは無し
    ○ データベースやアプリケーション起因の
    大規模障害は散発的に発生 …。
    ● 安い(全体の ⅕ 程度)
    リクエストの変化とインスタンス数の伸び
    ディナー
    ランチ

    View full-size slide

  16. 移行後にやっておけば良
    かったこと

    View full-size slide

  17. 1. Cloud Load Balancer の導入
    a. Cloud Run 自体に似たような機能があるが Load Balancer も入れといて損はない
    b. というか入れておいた方が移行がラク
    2. 同時実行数の設定に向き合う
    a. コネクションプール のサイズが律速になっているのが落とし穴
    3. startup prove の設定
    a. 最近できるようになった
    b. 立ち上げ前のアプリケーションへのリクエストを制限できる
    Cloud Run への移行後にやっておけば良かったこと

    View full-size slide

  18. Place Image Here
    まとめ
    App Engine ⇒ Cloud Run によりデプロイのコストが劇 的
    に安くなり 2 年で 500 回のデプロイを実現
    ● 1 deploy / 1 business day
    デプロイに利用している GitHub Actions の画面
    アップデートもたくさんあって嬉しい
    ● 最近は startup probe が嬉しかった
    今すぐ Cloud Run の PM を Twitter でフォローしよう ⇒ @steren

    View full-size slide

  19. Thank you.
    Proprietary + Confidential

    View full-size slide