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

2ヶ月程度でGoogle Cloudへインフラをフルリプレースした際の話＆データパイプラインを構築した際の事例紹介（2022.09.03）

Transcript

1. 株式会社YOJO Technologies 自社システムをHerokuからGCPへフ ルリプレースした話 〜データパイプライン編〜 2022.09.09
2. -2- （C）YOJO Technologies Inc. 2022 All Rights Reserve 今日のテーマ • スタートアップならではの GCP活用方法やアーキテクチャ変遷を楽しんでもらえれば！ • 少ないリソース、専門のデータエンジニアがいない中でのデータパイプラインの変遷を楽し んでもらえれば！
3. -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. -4- （C）YOJO Technologies Inc. 2022 All Rights Reserve 患者とのスムーズなコミュニケーション 薬剤師向け管理画面 チャット形式での診断・相談・購入 患者向けチャットシステム YOJO 薬剤師と相談して漢方・サプリメントが購入可能
5. -5- （C）YOJO Technologies Inc. 2022 All Rights Reserve リプレース前の構成
6. -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. -7- （C）YOJO Technologies Inc. 2022 All Rights Reserve LINE登録者数が1年で急増！
8. -8- （C）YOJO Technologies Inc. 2022 All Rights Reserve 既存環境の問題点 • Herokuのコストパフォーマンスが見合わなくなってきた ◦ 海外リージョンを使用、DBがパブリックに公開... ▪ パフォーマンス遅延、セキュリティ問題 ◦ Heroku Enterpriseであれば東京リージョンやプライベート対応は可能だが費 用が高くなる • インフラ基盤の分散 ◦ ネットワーク遅延が大きい ▪ 複数クラウドをまたぐ＆外部APIも多く利用 ◦ ログも分散されてしまうためログ調査がしづらい
9. -9- （C）YOJO Technologies Inc. 2022 All Rights Reserve • ログデータの分散とインフラ運用基盤が分散し開発者が疲弊 現環境の問題点
10. -10- （C）YOJO Technologies Inc. 2022 All Rights Reserve そんな苦しみを解消するためにリプレースPJが立ち上がった
11. -11- （C）YOJO Technologies Inc. 2022 All Rights Reserve リプレースPJ エンジニア2人でリプレースまで2ヶ月と短期間のプロジェクト！ • 2022/4 某日 発案→承認 • 2022/4 要件固め&スケジュール調整→検証・実装 • 2022/5 検証・実装 • 2022/6 本番移行前作業と移行リハ • 2022/6/12 正式リプレース
12. -12- （C）YOJO Technologies Inc. 2022 All Rights Reserve
13. -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. -14- （C）YOJO Technologies Inc. 2022 All Rights Reserve • インフラメトリクスはCloud Monitoringで1本化 ◦ ダッシュボードを見ればボトルネックや問題箇所特定可能に • Cloud Loggingで複数サーバのログを時系列でデータの流れを追えるように！ • アラート(Slack通知)からそのまま時系列ログヘ飛べる！ ログ・アラート基盤を集約
15. -15- （C）YOJO Technologies Inc. 2022 All Rights Reserve • データベースのロード、dbtの実行はAirbyteにて 旧データパイプライン
16. -16- （C）YOJO Technologies Inc. 2022 All Rights Reserve • dbtの実行はCloudSchedulerとCloudBuildにて • CloudSQLに置き換えたことによりbigqueryのfederated-queriesを使用可能に 今のデータパイプライン
17. -17- （C）YOJO Technologies Inc. 2022 All Rights Reserve ちなみに....昔のデータパイプライン
18. -18- （C）YOJO Technologies Inc. 2022 All Rights Reserve スプシとGAS地獄
19. -19- （C）YOJO Technologies Inc. 2022 All Rights Reserve 2021年6月のPoC段階
20. -20- （C）YOJO Technologies Inc. 2022 All Rights Reserve データエンジニアが不在の中模索 めちゃめちゃしんどい！！！ • スプレッドシートはBQへ取り込んだ後 スケジュールクエリで加工 • Herokuログは専用のログドレイン機構 で吐き出すしかなかった • Firestoreは実は firebase-firestore-bigquery-export で簡単に連携ができた... • 広告データの加工はアプリケーション作 るしかないか...
21. -21- （C）YOJO Technologies Inc. 2022 All Rights Reserve 最大の過ち：ELTの発想がそもそもなかった
22. -22- （C）YOJO Technologies Inc. 2022 All Rights Reserve • EL処理はAirbyte、Troccoに！（Saasの活用） Saasサービスをもっと活用すべきだった • T処理はBigQueryとdbtで完結させた ELTにアーキテクチャを変えた（2021年末）
23. -23- （C）YOJO Technologies Inc. 2022 All Rights Reserve • BigQueryは4層構造を採用 • データレイクとして生データが保存された(Raw/Type)データセット • 再利用可能な単位にデータを横付けしたテーブルを作るWarehouse • 可視化用の最終成果物をMart T処理はdbtで
24. -24- （C）YOJO Technologies Inc. 2022 All Rights Reserve • dbtの実行はCloudSchedulerとCloudBuildにて • CloudSQLに置き換えたことによりbigqueryのfederated-queriesを使用可能に EL処理はGCPへのフルリプレースにてさらにシンプルに
25. -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を設定 しなければ外部からは接続不可