VisasQ では Google Cloud がローンチされた初期時代から今まで Google CLoud AppEngine を主体としたインフラストラクチャを採用しています。 しかし、Python2 のサポートが 2020 年 1 月に終了する、という決定が下されて、私達はインフラ・アプリケーション共にアップデートをしなくてはいけない。という課題を 2020 年 1 月から取り組んでいます。 私達はこの課題にたいして「必要最低限のアップデートをする」という選択ではなく「全て作り直す」という選択をして、また長年利用していた AppEngine から Cloud Run に移行して、システムの一部分はリプレースすることにしました ・GAE App Engine から Cloud Run の移行についての苦悩や葛藤、Cloud Run に乗り換えてよかった事 ・GCPのアーキテクチャの構成等 をメインに紹介したいと思います

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

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

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

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

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

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

7. 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 を構築する場合の
一般的な構成。

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

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

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

11. システムリプレースでの大きな変更点 その 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

12. システムリプレースでの大きな変更点 その 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

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

14. 分割されたサービスの基本構成
● 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

15. セキュリティを担保するために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://<tag>---<service>.example.com
で動的にルーティング

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

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

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

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

20. 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

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

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

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

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

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

26. Thank you.