「みんなの考えた最強のデータアーキテクチャ」登壇資料解説

こんにちは！ゲンシュンと申します。zenn初投稿〜！
先日「みんなの考えた最強のデータアーキテクチャ」に登壇させていただきました。

アーカイブが残らない勉強会だったので自分の発表資料をslideshare等で残そうかと思ってました。ただ自分のスライドの作りとしてあまり文字を載せないため、意図しないことが伝わるかも〜ということでブログにスライド(画像)と話したことをサクッと書いてきます。

と、ここまで下書き保存から3週間放置してしまったので、月末とだいぶ出遅れちゃいましたがブログに残します...(汗

自己紹介

• 大学院を中退してFringe81(現Unipos株式会社)に拾っていただきました!
• プログラミング経験なかったのですが、フロントエンジニアとしてスタート！
• 前任の退職に伴い、新卒エンジニアの採用責任者に突然なりました!
• 1.5年で後任に引き継ぎ、広告事業のQAエンジニアとしてリハビリスタート!
• 上司の退職に伴いPM業メインに!

• 2021年6月、広告事業からuniposへ部署異動することに!
• 異動面談ではエンジニアとしてアサイン。久々に開発ができるぞ！
• と思いきや前任の退職に伴い、受け入れ面談実施日にデータ基盤立ち上げチームにアサイン!

• ちょうどデータエンジニア2年生になりました。ペーペーです。
• 縁って大事ですね〜

お品書き

こんな感じで話すよ。立ち上げからここまで移行結構したよ。つまり色々試したよ！
でもなんだんかんだ全部ダウンタイムゼロで乗り切れたから、意識したこととか書くよ！

uniposについて

• どういうデータを扱っているんだろう？というのをイメージできるために、uniposについて軽く紹介させてください。
• uniposとは、ピアボーナスを通じて「組織にとって良い行動」を社員同士で称賛し合うことで、組織風土を改善していくサービスです

• 「組織にとって良い行動」をポイント(ピアボーナス)付きでオープンに称賛
• この投稿をみた社員が拍手などで称賛の循環が生まれる、みたいなイメージです
• 投稿(宛先を複数人可)、ハッシュタグ、ポイント、リアクション、拍手、slackやteams等外部ツール経由の投稿
• などなど。人との繋がりやポイント、外部ツールなどのデータのイメージ、ざっくり持てましたでしょうか

現状のアーキテクチャ

端的にまとめるとこれです

• uniposはGCP上で動いているため、全てのデータをBQに集約することでデータレイクとする
• ゴリゴリのマイクロサービスアーキテクチャなので、各サービスのログやDBを一旦全部BQエクスポート
• 取りたい行動ログは、ログ(jsonとか)に落としてCloudLogging経由でBQエクスポート
• GoogleAnalyticsやSalesForceも頑張ってBQへエクスポート

• データウェアハウスはdbt、データマートはLookerで実装
• 実装の責務について、ただし厳密に定義してない
  • システム都合の領域はdbt
  • 分析時の都合はlooker
• システムの都合は可能な限りstg層で吸収、実体化したいデータをmart層で処理
  • mart層にある赤い矢印は、弊社のシステムの都合上どうしてもここで除去せざるを得ないものがある
  • 固有な事象なので特に触れず

超初期フェーズ

• 2021年7月、自分がjoinした直後のアーキテクチャ
• 当時はLookerとかdbtとかも無い
• 分析として欲しい情報がまず落ちていし、BQにエクスポートも出来ていないので、とにかくBQへ
• アナリストが分析したいデータをBQでクエリ叩いて分析する、というもの
• システム側のデータをBQにエクスポートし、分析したい情報をスケジュールクエリ経由で持ってくる

良かった点や課題感

• 「冪等性担保」がベースの作りとして保守されていたので、まず作って困ったら作り直すがやりやすい
  • GCPもuniposのシステムもデータ基盤も何もわからない自分が、GCPや裏側の事情を把握しながら欲しいテーブルを作る、ということが出来た
• 「どうせ分析時にjoinするからカラム追加してよ」という要望に、何も考えず対応してしまった。これにより地獄を見る

雑な例です。投稿マスター、部署マスター、みたいなテーブルで良いのに、部署with投稿マスター、みたいなSQLを作ってしまう

terraform移行フェーズ

• 前提、データ基盤はGCPのOWNER権限を貰ってデプロイ作業していた
• システム側では、このあたり全部terraformでコード化してやっているらしい
• ということで、突如terraform対応してくれと言われる。押忍

• 自前シェルでスケジュールクエリを作っていたのでterraformで作成するようにしただけ
• リポジトリがmergeされたタイミングでcloudbuildを走らせるようにしてみた
• デプロイ作業が楽〜

良かった点や課題感

• 人に権限を持たせないの良い
• 環境ごとの都合を吸収できたので結構嬉しい
• terraform applyで差分がわかるの地味に嬉しい
• システム変更に弱い作りになっており、俺がかなり頑張らないと保守運用できなくなってきた

• 2021年10月ぐらいに「システム側の大改修アイテム」が発生
• 雑に言うと、特定のデータがdatastoreからspannerにお引越し。それに伴いスキーマや仕様などが色々変わる
• 「どうせ分析時にjoinするからカラム追加してよ」「はーい」で、関係ないテーブルにもモロ影響が
• ダウンタイムゼロで乗り切るため地獄のテスト祭り。20テーブルぐらい影響受けたので全部自分で動確してた
• 多分死んでましたが無事乗り切れたのでヨシッ!

dbt移行フェーズ

• システム側の関心と、分析の関心をわけたい
• Lookerの導入が決まりデータ基盤を大幅にUPDATEする機運
• 同僚のtenajimaさんには感謝です、ホント

• 先程見せた現在のアーキテクチャに大きく近づきました
• stg層にシステム側の都合を吸収できたこと、分析時の都合をLooker側に閉じられたことが嬉しい

• 明確な意図はないが、github actionsでポチッと押してデプロイ(dbt run等)する方針にした
• dbt cloud使ってないです。今特に困ってないですが使うのはアリ

良かった点

• これまでの経験から今の完璧は1週間後に崩壊することを学んだので、速攻50点作って改善するスタイルを続けた
• dbtは一番難しいテーブルから検証した。コレ乗り越えれば全部いけるっしょ！

dbt移行の運用上意識したこと

• 「terraform由来」と「dbt由来」の併用期間を設けた
• ぶっちゃけダブルメンテ。ただ「dbt導入してLooker方面に影響あったーーー」という恐怖を気にせずとにかく実装してデプロイ！が出来た
• terraform由来から作られたデータ達、ありがとう！

• dbt検証から導入まで色々やってくれた同僚のtenajimaさんもやりやすかったとのこと
• この漫画の元ネタ知らないんですが、俺死んでますね

品質担保フェーズ

• 自分が保守運用にほぼリソース使ってしまっているので、とにかく減らしたい
• 自分の仕事は「価値ある情報って何？」を見つけること
• とにかくテスト実装しておかしいものはslackにWARN飛ばす

良かった点や課題感

• テスト内容は超厳しく実装し、どうしても難しい場合は緩くする
  • 絶対おかしいNULLとしゃーなしのNULLは意味が違うので
  • しゃーなしのNULLって本当にしゃーないんすよね
• 大事なテストととりあえず入れたテストがあまり区別できておらず、テストそのものの品質も大事だなーと思う最近

まとめ

色々移行とかありましたが、常に当時の最適な選択をし続けた結果です！

この世の全てのSNSは ゲンシュン でやってますよ！(大声宣伝)

記事を出すのがめちゃめちゃ遅くなってダサいですが、これ以外にも話したいネタはめっっちゃめちゃあるので、これから記事たくさん書きます！

データエンジニア、ぺーぺーな自分ですが、これからもよろしくおねがいします。以上