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

Innovator Live Japan 3/23 【現場の本音】App Engine から Cloud Run に移行してみた - https://cloudonair.withgoogle.com/events/innovators-live-jp?tab=serverless_containers&expand=module:serverless_containers_top

• https://cloudonair.withgoogle.com/events/innovators-live-jp?tab=serverless_containers&expand=module:serverless_containers_top

GAE から Cloud Run への移行を引 き継いでみてわかったこと 株式会社ビザスク プラットフォーム開発グループ スペシャリスト 坂本 満

01/07 自己紹介

自己紹介 株式会社ビザスク プラットフォーム開発グループ スペシャリスト 経歴 : 何社か転々としながら 10 年程度広告配信のお仕事をしており 2022/02 に株式会社ビザスクに入社 坂本 満 お話しすること : GAE から Cloud Run への移行は既に社内で開始しており その担当者から運用・保守を引き継いだ側の視点での振り返りです

02/07 会社・サービス紹介

ビザスクのご紹介 Our Mission 知見と、挑戦をつなぐ 私たちは、世界で1番のナレッジプラットフォームをつくります。 様々なニーズにつなぐことで、実際に経験したことで得られた知識や意見を、知見として価値最大化します。 組織、世代、地域を超えて、知見を集めつなぐことで、世界中のイノベーションに貢献します。 News 社員数： 542名 2020年3月：東証マザーズ（現グロース）上場 © VisasQ Inc. All Rights Reserved. 6

ビザスクのご紹介 ビジネスモデルのご紹介 ● ビジネス領域に特化した日本有数のナレッジプラットフォーム ● 「スポットコンサル＝1 時間インタビュー」という短時間取引を、テクノロジー ×高度なオペレーションで高精度にマッチング ご依頼企業 アドバイザー 知見をマッチング インタビュー 社外の知見を活用 アドバイス／調査ニーズ 年間インタビュー マッチング数 © VisasQ Inc. All Rights Reserved. 約29,000件 オンラインアンケート ビジネス知見を活かす機会 業務委託 etc. 国内登録 16 万人超 海外登録 38 万人超 7

ビザスクのご紹介 多くの企業に浸透している『情報インフラ』 ● 業界・部署・部門を問わず様々なご依頼に対応 ● 新規事業・研究開発における調査、経営改革に際するアドバイスなど コンサルティングファーム 戦略／会計／ IT 系ファーム ・全社／事業戦略 ・M&A 戦略／PMI ・ビジネス DD ・事業再生 シンクタンク 大手事業法人 B2B 系事業会社の新規事業／研究開発／経営企画／デザイン部署を中心にご利用 TOP10 80%+ 金融機関 PE ファンド アクティブ運用ファンド メガバンクを含む銀行 日米欧証券会社 政府系金融機関 © VisasQ Inc. All Rights Reserved. 150+ 800+ 8

ビザスクのご紹介 世界 190 ヵ国 54 万人の知見が集まる、 国内最大級の知見のプラットフォームを構築 ● 2021 年 11 月、米国 Expert Network Service 大手である Coleman 社を買収し、幅広い国内外への情報・知見へのア クセスが可能 ● 登録者の過半数が外国人という、グローバルなプラットフォー ムを提供 540,000 advisors + © VisasQ Inc. All Rights Reserved. 190 countries 9

03/07 移行前後のアーキテクチャ

移行前のアーキテクチャ(創業時~) クライアント企業様 アドバイザー様 社内ユーザ App Engine (Standard) Python2.7 Cloud SQL

移行後のアーキテクチャ クライアント企業様 Cloud Run (Python3.9) アドバイザー様 Cloud Run (Python3.9) 社内ユーザ Cloud Run (Python3.9) Cloud SQL

04/07 移行方法・苦労や工夫

工夫 モニタリング ● SaaS での監視機構構築 ● 最近発表された Cloud Run 対応 APM のトライアル中 プロビジョニングツールを利用した Infrastructure as Code の推進 ● ローカル環境を作りやすくなり、検証が楽に ● 冪等性の担保 プロビジョニングツールの SaaS 移行 ● ● レビューコストの低減 CD / CI によるコスト低減

移行方法 ● サービス毎にアプリケーションの開発チームが分かれており、それぞれの事情で違うアプローチ 事情 チーム A チーム B チーム C 人数が少ない 機能が複雑で、移行対象も多い 修正しやすくしたい (社外ユーザが触る部分) アーキテクチャそのまま移行 リファクタリングが必要な部分はし ながら移行 アプローチ Python の version up アーキテクチャ一新

苦労した部分 チーム A ● ● 苦労した部分 ● ● Python の version up はそ れほどではなかった サービス分割による呼び出し 方法変更によるコスト増 チーム B ● ● 粛々と移行中 リファクタリングする場合 はそれなりに時間がか かっている チーム C ● ● ゼロからの構築のため時間が かかる。 Python 2.7 の EOL によるサ ポート停止発表 ○ 移行スケジュール見直 し サービス間連携の認証の仕組み idle から active 復旧時の timeout への対応 ○ Network Endpoint Group の timeout が 30sec だった当時の設定を引きずり Cloud Run の timeout も 30sec にしてしまっていた。 ○ 立ち上がりまでに 30sec 近くかかってしまう作りだったため timeout が多発。 ○ チューニングが難しく Cloud Run の min/max instance を適切に設定することで対応 ○ 現在の Network Endpoint Group の timeout は 60 min のため、Cloud Run の timeout も緩め た

05/07 移行前後での変化

GAE から Cloud Run に移行したからできたこと サービス特性毎にチューニングが可能に ● ● 外向き : AlwaysCPU 内向き : 通常(業務時間外は idle 化) ○ 業務中高負荷のものには CPU / memory を潤沢 ○ そうでないものには最小スペック

Cloud Run 移行による変化 サービス分割によるデグレードの抑制 ● 影響範囲を小さく デプロイ手順のツール化 ● deploy と switch-traffic の二つのコマンドで OK

Cloud Run 移行による変化 (2) 各サービスで役割分担に応じてさらに Cloud Run を分割 ● ● ● メリット ○ Cloud Run ごとにリソースを個別設 定できる デメリット ○ 設定・deploy 時間の高速化など改 善の余地がある ○ 分割したことによるアーキテクチャへ の影響(移行の作業が増える ) 解決策 ○ 同じ image を使うようにする ○ Cloud Run のサービスで統合できる ものは統合すること ■ batch と非同期処理 構成 ● ● ● ● ● 動的ページ 外部解放 API サービス間 API batch 非同期処理

Cloud Run の移行と分割について 同時にやったことによるメリット ● ● チーム毎の都合の良いタイミングで着手時期をずらせる 先行したチームのノウハウを後続のチームが活かすことができる 同時にやったことによるデメリット ● ● Python 2.7 の EOL によるサポート停止の影響で移行プランの再検討が必要になった 移行作業が想定よりも複雑になってしまった。 移行と分割を同時に実施したメリット < デメリット

移行前のアーキテクチャ(創業時~) クライアント企業様 アドバイザー様 社内ユーザ App Engine (Standard) Python2.7 Cloud SQL

GAE を Cloud Run に置き換えるだけのステップが必要だった クライアント企業様 アドバイザー様 社内ユーザ Cloud Run Python3.9 Cloud SQL

移行後のアーキテクチャ (現状) クライアント企業様 Cloud Run (Python3.9) アドバイザー様 Cloud Run (Python3.9) 社内ユーザ Cloud Run (Python3.9) Cloud SQL

06/07 今後の展開・Google への期待

今後の展開・Google への期待 今後の展開(社内) ● Cloud Run への移行の完遂 ○ サポート切れに間に合わせる Google への期待 ● Cloud Run の lifecycle 設定をいい感じにできるよ うにしてほしい ○ 現状は削除バッチを作って前段の Cloudflare の DNS レコードと同時に削除 ○ min idle instance が大きい状態で 1 日に複 数回リリースすると、トラフィックが外れたリビ ジョンの idle instance が残る

07/07 まとめ

まとめ これから対応される方に向けて ● ● SRE プラクティスに準じて、初手は 「GAE からの脱却」のみのスコープとし ましょう。「小さく始める」ことをお勧めし ます 分割はそのあとで https://cloud.google.com/blog/ja/products/devops-sre/four-steps-to-jumpstarting-your-sre-practice

• https://cloud.google.com/blog/ja/products/devops-sre/four-steps-to-jumpstarting-your-sre-practice

Thank you. Proprietary + Confidential