株式会社YOJO Technologies 自社システムをHerokuからGCPへフ ルリプレースした話 〜データパイプライン編〜 2022.09.09

-2- （C）YOJO Technologies Inc. 2022 All Rights Reserve 今日のテーマ ● スタートアップならではの GCP活用方法やアーキテクチャ変遷を楽しんでもらえれば！ ● 少ないリソース、専門のデータエンジニアがいない中でのデータパイプラインの変遷を楽し んでもらえれば！

-3- （C）YOJO Technologies Inc. 2022 All Rights Reserve 自己紹介 名前：尾崎皓一 経歴：2011-2014年：TIS株式会社 　　　 2014-2021年：フリーランス 2020年6月からYOJOに業務委託でジョイン 　　　　　主戦場はバックエンド 　　　 2021年6月：YOJO Technologies 　　　エンジニアマネージャー（と言いつつプレイングマネージャー） 息子2人（2歳＆1歳）が可愛い 写真は「りょーちゃんもお仕事する！」のワンシーン

-4- （C）YOJO Technologies Inc. 2022 All Rights Reserve 患者とのスムーズなコミュニケーション 薬剤師向け管理画面 チャット形式での診断・相談・購入 患者向けチャットシステム YOJO 薬剤師と相談して漢方・サプリメントが購入可能

-5- （C）YOJO Technologies Inc. 2022 All Rights Reserve リプレース前の構成

-6- （C）YOJO Technologies Inc. 2022 All Rights Reserve リプレース前の構成 ● もともとはHeroku、Vercel、Cloud Runを使用 ○ Heroku ■ Railsサーバーに使用 ■ サービス初期の開発・運用・保守を簡略化 ○ Vercel ■ Next.jsのホスティングサービスに使用 ■ プレビュー環境・デプロイの設定が簡単 ○ Cloud Run ■ GraphQLのBFFサーバーに使用 ■ LINE Webhook受信サーバーに使用 ● サービス初期では上記構成の選択は問題なかったが、サービス拡大に応じて徐々 に課題が出てきた

-7- （C）YOJO Technologies Inc. 2022 All Rights Reserve LINE登録者数が1年で急増！

-8- （C）YOJO Technologies Inc. 2022 All Rights Reserve 既存環境の問題点 ● Herokuのコストパフォーマンスが見合わなくなってきた ○ 海外リージョンを使用、DBがパブリックに公開... ■ パフォーマンス遅延、セキュリティ問題 ○ Heroku Enterpriseであれば東京リージョンやプライベート対応は可能だが費 用が高くなる ● インフラ基盤の分散 ○ ネットワーク遅延が大きい ■ 複数クラウドをまたぐ＆外部APIも多く利用 ○ ログも分散されてしまうためログ調査がしづらい

-9- （C）YOJO Technologies Inc. 2022 All Rights Reserve ● ログデータの分散とインフラ運用基盤が分散し開発者が疲弊 現環境の問題点

-10- （C）YOJO Technologies Inc. 2022 All Rights Reserve そんな苦しみを解消するためにリプレースPJが立ち上がった

-11- （C）YOJO Technologies Inc. 2022 All Rights Reserve リプレースPJ エンジニア2人でリプレースまで2ヶ月と短期間のプロジェクト！ ● 2022/4 某日 発案→承認 ● 2022/4 要件固め&スケジュール調整→検証・実装 ● 2022/5 検証・実装 ● 2022/6 本番移行前作業と移行リハ ● 2022/6/12 正式リプレース

-12- （C）YOJO Technologies Inc. 2022 All Rights Reserve

-13- （C）YOJO Technologies Inc. 2022 All Rights Reserve リプレース結果 ● Cloud Runを中心としたコンテナベース環境に移行 ○ 学習コストや運用コストの面でGKEよりCloud Runを採用 ● Cloud SQLはPrivate VPCへ ○ BigQueryへのデータ転送のためにリードレプリカを用意 ○ BigQuery ConnectionのためにリードレプリカはPublicだが、IP Rangeを設定しなければ外部からは接続不可 ● Cloud Loggingにログ基盤を集約 ○ ログ出力の一本化 ○ 時系列調査が非常に簡単になった

-14- （C）YOJO Technologies Inc. 2022 All Rights Reserve ● インフラメトリクスはCloud Monitoringで1本化 ○ ダッシュボードを見ればボトルネックや問題箇所特定可能に ● Cloud Loggingで複数サーバのログを時系列でデータの流れを追えるように！ ● アラート(Slack通知)からそのまま時系列ログヘ飛べる！ ログ・アラート基盤を集約

-15- （C）YOJO Technologies Inc. 2022 All Rights Reserve ● データベースのロード、dbtの実行はAirbyteにて 旧データパイプライン

-16- （C）YOJO Technologies Inc. 2022 All Rights Reserve ● dbtの実行はCloudSchedulerとCloudBuildにて ● CloudSQLに置き換えたことによりbigqueryのfederated-queriesを使用可能に 今のデータパイプライン

-17- （C）YOJO Technologies Inc. 2022 All Rights Reserve ちなみに....昔のデータパイプライン

-18- （C）YOJO Technologies Inc. 2022 All Rights Reserve スプシとGAS地獄

-19- （C）YOJO Technologies Inc. 2022 All Rights Reserve 2021年6月のPoC段階

-20- （C）YOJO Technologies Inc. 2022 All Rights Reserve データエンジニアが不在の中模索 めちゃめちゃしんどい！！！ ● スプレッドシートはBQへ取り込んだ後 スケジュールクエリで加工 ● Herokuログは専用のログドレイン機構 で吐き出すしかなかった ● Firestoreは実は firebase-firestore-bigquery-export で簡単に連携ができた... ● 広告データの加工はアプリケーション作 るしかないか...

-21- （C）YOJO Technologies Inc. 2022 All Rights Reserve 最大の過ち：ELTの発想がそもそもなかった

-22- （C）YOJO Technologies Inc. 2022 All Rights Reserve ● EL処理はAirbyte、Troccoに！（Saasの活用） Saasサービスをもっと活用すべきだった ● T処理はBigQueryとdbtで完結させた ELTにアーキテクチャを変えた（2021年末）

-23- （C）YOJO Technologies Inc. 2022 All Rights Reserve ● BigQueryは4層構造を採用 ● データレイクとして生データが保存された(Raw/Type)データセット ● 再利用可能な単位にデータを横付けしたテーブルを作るWarehouse ● 可視化用の最終成果物をMart T処理はdbtで

-24- （C）YOJO Technologies Inc. 2022 All Rights Reserve ● dbtの実行はCloudSchedulerとCloudBuildにて ● CloudSQLに置き換えたことによりbigqueryのfederated-queriesを使用可能に EL処理はGCPへのフルリプレースにてさらにシンプルに

-25- （C）YOJO Technologies Inc. 2022 All Rights Reserve HerokuからCloudSQL&Airbyteからdbtに ● Airbyteは元テーブルのカラムが変更されると、都度スキーマ更新を行なっ てから再取得が必要で、アプリケーションとの連携が面倒 ● Airbyteのサーバコスト削減 ● Cloud SQLはPrivate VPCへ ○ BigQueryへのデータ転送のためにリードレプリカを用意 ○ BigQuery ConnectionのためにリードレプリカはPublicだが、IP Rangeを設定 しなければ外部からは接続不可