甘酸っぱいGCPレガシーApp Engine Python2からCloud Runへの移行の勘所 Ryusuke Kimura 株式会社ビザスク 基盤チーム システムアーキテクト

自己紹介と サービス概要 01

高校卒業後、クライミングにハマりフリー ターをしながら海外クライミングツアーに 明け暮れる。その後、システムエンジニ アとして様々な業務に従事。ここ五年ほ どはインフラ領域を主戦場としている。 現職ビザスクには 2020 年入社後、シス テムリプレースのプロダクトオーナー兼 SRE に従事。 木村 竜介 (Ryusuke Kimura) 基盤チーム システムアーキテク ト

■ ビジネス領域に特化した 日本最大級 のナレッジプラットフォーム ■ 「スポットコンサル = 1 時間インタ ビュー」という短時間取引を、テクノロ ジー x 高度なオペレーションで高精 度にマッチング ■ 2020 年 東京証券取引所マザーズ 市場に上場 会社説明 知見と、挑戦をつなぐ Connecting Insights and Aspirations Across the Globe 日本最大級のナレッジプラットフォーム ※アドバイザー数において。 2021 年 5 月 31 日時点のアドバイザー数は約 15 万人

あらゆる業界 / 職域を網羅した 15 万人のデータベース 約 120,000人 約 30,000人

02 ビザスクの システム歴史

Databases && Storage Application Server システム アーキテクチャは一貫して Google Cloud を採用 App Engine Datastore Cloud SQL Cloud Storage Cloud Tasks ● 2012 年創業以来、Google Clooud をクラウドイ ンフラとして採用 ● Application Server はApp Engine 1st gen Python2 ● Database は Cloud SQL, Datastore ● Storage は Cloud Storage ● 非同期処理は Cloud Tasks で制御 Google Cloud で Web Application を構築する場合の 一般的な構成。

ナレッジプラットフォームという概念を広めるために様々な試行 錯誤を行いながらサービスは拡充していった 2020 年 マザーズに上場 上場時点でメンバーは約 100 名 2012 年 12 月 ビザスクβ版を リリース 2017 年頃 - サービス拡大期 急速なサービス拡大に合わせて機能が増 えていったが、 Application もインフラも ツギハギだらけに 2015 年頃 BtoB 向けのシス テムを本格稼働 BtoB サービスが軌道に乗り始め CtoC 向けの基盤システムに載せる 2013 年 10 月 正式版リリース 最初はCtoCのサービスとしてスター ト

サービスの拡大でシステムは肥大化。 アーキテクチャやインフラは取り残されたままだった 上場後、ユーザーの増加や組織の増大で今後サービス、組織として守らなくてはいけないルール等も どんどん増えていくし、それを継続的に改善できる仕組みもエンジニア開発組織として中長期的に明 白だったので、2020年秋頃からGCPの全面リアーキテクトを決断し、システムを順次入れ替えを行っ ています

04 システムリプレースで の大きな変更点

システムリプレースでの大きな変更点 その 1 ● 新しい Google Cloud プロジェクトに移行 ○ 既存システムに影響しない形で全体の移 行を進めたかった ● Python2 => Python3 へのアップグレード ○ アップグレードに伴いアプリケーションの 修正も必要 ● AppEngine から Cloud Run の移行 ○ Compute サービスの中で最も汎用的に 利用ができそうかつ、サービスの拡充に 未来がもてた為 ● サービス分割 ○ ドメインレイヤーから大きく 4 つのサービ スに分割 ○ リポジトリも分割 Cloud Run App Engine service.visasq.com Before After service-a.com Cloud Run Cloud Run Cloud Run service-b.com service-c.com service-d.com

システムリプレースでの大きな変更点 その 2 ● Terraform の全面採用 ○ 部分的に採用していた Terraform を全面採用して、 インフラの属人化を防止 ○ サービスチームもインフラを気軽に試せるように、開 発者全員が持っている Sandbox GCP 環境に Visasq のサービスの複製ができるようにTerraform で調整 ● GCE on Elasticsearch から Elastic Cloud の移行 ○ 検索チームの新設に伴い、検索システムの改善速度 を上げるため、SRE 側で管理していた GCE on Elasticsearch から検索チームで気軽に変更、管理 がしやすい Elastic Cloud に変更 ● IAM の再設計 ○ Google Group によるグループ管理で簡素化 X Compute Engine Before After

05 分割されたサービスの Google Cloud の基本構成

分割されたサービスの基本構成 ● Serverless のサービスを柔軟に変更できるよう に Serverless NEG で構成 ○ 現状だと All Cloud Run で基本構成 ○ アプリケーションの都合で App Engineを 使わざるを得ない場合を想定して、LB + Serverless NEG を挟んだ。 ○ 全てのCloud Runは非公開 Cloud Run でセキュリティを担保 ○ 一部のサービスでこの構成で切替後、経 過をみているが、今の所この構成であん まり困っていない Cloud Run 分割されたサービスの基本構成例 service-a.com Frontend Service Cloud Run API Service Cloud Run Async Service Cloud Run Batch Service Cloud Tasks Cloud Load Balancing Serverless NEG Cloud Scheduler

セキュリティを担保するためにIAPの導入とURL マスクを利用し た動作確認の容易性を実現 ● IAPの導入でアプリケーションレイヤー手前で認 証を挟みセキュリティを担保 ○ 公開 Run を配置すると、LB経由とRun経 由の2系統でアクセス経路ができてしま い、セキュリティの担保がしづらいのでLB レイヤ以外のアクセスを遮断 ○ 一方で、AppEngineで利用していたバー ジョンをデプロイ後のトラフィック切替前の 動作検証の容易性を実現するためにURL マスク を利用してLBレイヤでのトラフィッ ク切替前のルーティングを実現 Cloud Run Services 分割されたサービスの基本構成例 service-a.com Cloud Run Revision (traffic 0%) Cloud Load Balancing Identity-Aware Proxy Cloud Run Revision (traffic 100 %) https://---.example.com で動的にルーティング

06 サービスの基本構成で 実際によかった所、 悪かった所

● Cloud Load Balancing を挟む事で ネットワークレイヤーの変更 がしやすくなった。 ● Serverless NEG があると、複数のサーバーレスサービスをつな げるので、サービスの中央管理がしやすくなるし、選択肢が広が る ● フルマネージド Cloud Run を選択したが、Anthos の採用は見 送った。なるべくインフラの管理は Google Cloud に任せて管理 するものを減らしたかったし、学習コストをあまりかけたくなかっ た ● 現状スパイクが発生しやすい状況で、 Cloud Run に乗り換えた ら、CPU とメモリが高スペックを選択できるのが嬉しい サービスの基本構 成で良かった点

Cloud Run になると App Engine がやってくれていたものをある程度自前 で管理する必要がある ● HTTP サーバー (gunicorn) の管理 ● yaml 定義して Deploy から、自前でリソースを作成、調整が必要 ○ Cloud Tasks ○ Cloud Scheduler, etc.. App Engine は Cloud Run よりも制約があるが、スケーリングやレスポンス 速度ってやっぱ早いな。って思った。 ● 現状コールドスタートの最適化がチューニングしきれてなく、一旦CPU を 大きめにしたり、concurrency を調整して、なるべくスケーリングをさせな いようにしている ● コールドスタートが予想以上に立ち上がりが遅かった ○ アプリケーション固有の問題かもしれない サービスの基本構 成で悪かった点

07 システムリプレースの戦 略について

knowledge　 Database Aチーム システムリプレースの戦略 ● Repository, Deploy, Application Server はチーム単位で用意 ● DB は既存のまま ● API 単位で既存システムの Endpoint を変更して切替え ● View も機能単位で入替 ● 一部の機能はゼロベースで作り直す (予定) Repository Cloud Build Cloud Run Bチーム Repository Cloud Build Cloud Run Clients 既存システム App Engine API Call

08 システムリプレース をしてよかった所、 悪かった所

新しい環境を用意したことで過去のしがらみをなるべく気にせず今のベスト エフォートを考えることができた ● 現実を直視すると、良い意味でも悪い意味でも妥協してしまいがちだけど も、まっさらな環境を用意することで新鮮な状態で時代の進化にある程度 追いつける状態に持ってこれた 各個人の Google Cloud Sandbox で環境再現をほぼ完璧にしたのでスク ラップ & ビルドが簡単にできるようになった ● All Terraform でかつ、Production, Staging 環境でしか試せないという 状況を徹底的に排除した ● クラウドリソースの破棄と再生成の再現率が高いとクラウドリソースの変 更に対しての億劫さがなくなり攻めるインフラができる GAE 1st gen Python2 から Cloud Run Python3 はすんなりいけた ● 1st gen 固有の処理の修正を行えばすんなりいけるはず。 システムリプレースで 良かった点

GAE が All in One なので SRE と Application チームでの対立が起きやす かった ● いままで Application 側で管理してた所でインフラ視点で良くない所を積 極介入したので、いわゆる DevOps の対立が発生しやすかった。 ○ どちらがやる・やらない問題、互いの利益が相反する構成等 Python2 から Python3 に移行するだけよりもはるかにリソースやコストが かかった(ている) ● 3年単位でシステム移行のメリット・デメリットをコスト計算しないと費用対 効果がでてこないので、Who, What, Why の部分の詰めや、関係各所の 調整が本当に難しかった ● これから全エンジニアのリソースの 2- 3 割程度をシステムリプレースに 継続的に割く。という意思決定は CEO の理解がなければ難しかった システムリプレースで 悪かった点

Web Application で構成困ったら LB + Serverless NEG + Cloud Run で 組めば大体 OK だったし選択幅も広がるよ

ビザスクでは、エンジニアとして働きたい方を募集してい ます。 ご興味のある方は「ビザスク エンジニア 採用」で是非 Google 検索エンジンから検索してみてください! https://visasq.co.jp/engineer-recruitment Google Cloud で継続的な攻める改善に共感を持った方は是非 連絡を!!

Thank you.