BigQueryのデータ監視社内サービスを作った話 / Creating an Internal Service for Monitoring BigQuery Data

メルペイ Data Management チームは、社内データの利用者が「あんぜんに」「あんしんして」「かんたんに」データを活用できるような仕組みやプロセス構築、サポートを行っています。ある日、データを活用する複数のチームから、「BigQueryのデータが正しくないときにSlackの通知がほしい」という依頼を別々に受けました。このような要件に基づいてデータを監視を行うサービスは、社内にまだありませんでした。そこで今回の依頼者チームだけでなく、今後同様の依頼を受けた際に対応できるように、BigQueryのデータを監視するシステムをGCPで開発し、社内サービスとして立ち上げることにしました。
本セッションでは、どのようにそのサービスのシステムを構成したかについてお話します。

The Merpay Data Management Team builds and supports mechanisms and processes that allow users of internal data to leverage our information assets safely, securely, and easily. At some point, the team began receiving individual requests from several teams that use data in their work. The requesters wanted to receive Slack notifications when BigQuery data was not correct. However, at the time there was no internal service that monitored data based on requirements like these. In response, the team developed and launched a system as an internal service for monitoring BigQuery data internally that made notifications like the ones requested accessible not just to the team that made the request, but also to other teams that wanted to receive notifications in the future.
This session will talk about how the team configured the system of the service.

------
Merpay & Mercoin Tech Fest 2023は3日間のオンライン技術カンファレンスです。
IT企業で働くソフトウェアエンジニアおよびメルペイ・メルコインの技術スタックに興味がある方々を対象に2023年8月22日（火）、23日（水）、24日（木）の3日間、開催します。 Merpay & Mercoin Tech Fest は事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知ることができるお祭りです。

今年のテーマは「Unleash Fintech」。 メルペイ・メルコインのこれまでの技術的な取り組みはもちろん、メルカリグループのFintech事業における新たな挑戦をお伝えします。 セッションでは事業を支える組織・技術・課題などへの試行錯誤やアプローチなど多面的にご紹介予定です。

メルペイ・メルコインが今後どのようにUnleash（解放）していくのか、ぜひ見に来てください。

■イベント関連情報
- 公式ウェブサイト：https://events.merpay.com/techfest-2023/
- 申し込みページ：https://mercari.connpass.com/event/286670/
- Twitterハッシュタグ： #MerpayMercoinTechFest
■リンク集
- メルカリ・メルペイイベント一覧：https://mercari.connpass.com/
- メルカリキャリアサイト：https://careers.mercari.com/
- メルカリエンジニアリングブログ：https://engineering.mercari.com/blog/
- メルカリエンジニア向けTwitterアカウント：https://twitter.com/mercaridevjp
- 株式会社メルペイ：https://jp.merpay.com/

Transcript

1. Session Title BigQueryのデータ監視 社内サービスを作った話 @hyrrot (Hirobumi Takahashi) Data Manager, Data Management Team, Merpay
2. Hirobumi Takahashi / @hyrrot 2011年に楽天株式会社に入社、開発者向けグ ループウェア、CI/CD基盤、データ分析基盤の開発 と運用に従事。 2022年に株式会社メルペイに入社後、 dbtなどによ る分析データの準備のシステムの開発と運用など を通じ、アナリストの皆様に最強のデータ分析環境 を享受していただくために日々奮闘している。 株式会社メルペイ Data Manager
3. メルカリグループのデータ基盤 • Data Platform Team
 ◦ データパイプラインを通して、データをBigQueryに届ける
 • Data Management Team
 ◦ データの利用者が「あんぜんに」「あんしんして」「かんたんに」データを活用でき るような仕組みやプロセス構築、サポートを行う
 （今回の話はこっち！）

4. Data Management Team • BigQueryのデータを整え、データ利用者に届ける
 ◦ たとえば、dbtを用いて生テーブルを中間テーブルに変換
 ◦ dbtの定期的な実行の基盤として、Cloud Buildを始めとしたGCPのマネージ ドサービス、およびArgo Workflowsなどを利用

5. ある日、複数のチームから同時に来たリクエスト • 「BigQueryテーブル内のデータが正しくないときに通知がほしい」
 
 • チームA：
 ◦ BigQueryテーブルのデータを用いて、顧客企業に対する経費精算を行って いるが、テーブルのデータが、そのクエリの前提となる条件を満たしていな いときに、それを検出したい
 • チームB：
 ◦ BigQueryテーブルのデータを用いて、お客さまに対してポイントの付与オペ レーションを行っている。テーブルが、ポイントの誤付与が発生したことを示 すデータを含む場合、それを検出したい
 
 • 社内に、このような要求に簡単に応えるサービスはなかった

6. 全社で利用できる、BQデータの監視システムを作ろう • 「BigQueryテーブル内のデータが正しくないときに通知がほしい」
 ◦ データの「正しさ」をそれぞれのチームに定義してもらいたい
 
 • チームA、チームBに、以下のようなクエリを書いてもらう
 ◦ データが正しい場合、0行の結果を返す
 ◦ データが正しくない場合、1行以上の任意の結果を返す
 
 • もらったクエリを定期的に実行し、以下のような場合にチームに通知
 ◦ 1行以上の結果が返ってきた
 ◦ クエリの実行に失敗した
 
 • 命名：QueryMon（クエリもん）
 

7. QueryMon バージョン 1.0 • Argo Workflows上で、定期的に監視ワークフローを実行
 ◦ CronWorkflowがクエリを実行するService Account (SA)名を指定、Workflow内 でimpersonate
 • クエリ結果が1行以上 or 失敗の場合、Slackに直接通知
 
 
 
 
 

8. QueryMon バージョン 1.0 • 問題
 ◦ 監視が行われるべきであったにもかかわらず、行われなかったことを知ること ができない
 ▪ もし、このときにBQデータに問題があったら、チームは問題を見逃してし まう！
 ◦ 監視設定の変更が社内のCI/CDシステムを経由し、必ずQueryMonの管理者 の承認が要求される
 ▪ できれば、監視設定の権限をチームに委譲したい
 ◦ Argo Workflowsが社内の別チームの管理であり、トラブルシューティング時の コミュニケーションコストが上がる

9. QueryMon バージョン 2.0 • Cloud Scheduler / Cloud Pub/Sub / Cloud Functionsを利用して実装 
 • Cloud Schedulerは以下の情報をJSONとしてトピックへpublish 
 ◦ チーム名、クエリ名、クエリ、SA名、BQの実行プロジェクト、タイムアウト時間
 • QueryMonは監視結果をDatadogに送信 
 • 以下の場合に、DatadogがSlackに通知 
 ◦ あるチーム名&クエリ名の監視結果が1件以上、あるいは失敗時 
 ◦ あるチーム名&クエリ名の監視結果が一定時間存在しないとき 
 • チーム所有のGCPプロジェクト内のリソースは、チーム内の承認のみで変更可能 
 
 
 

10. Cloud Schedulerで別のプロジェクトの Pub/Subトピックにpublish • Cloud Schedulerは、Pub/Subトピックにpublishするジョブを
 定義できるが、この種のジョブは異なるプロジェクトへの
 publishをサポートしていない
 
 • Pub/SubのHTTPS (REST) APIを呼ぶことで解決
 
 
 
 

11. Cloud Schedulerで別のプロジェクトの Pub/Subトピックにpublish • publish APIは、リクエストのbodyに、publishするデータを
 BASE64エンコードして渡す必要がある
 • Cloud SchedulerのUIで、BASE64エンコードされた設定を
 直接管理するのは困難
 • Terraformを利用して設定
 
 
 
 
 
 
 { "team": "team1", "query_name": "query_name1", "query": "SELECT 1 LIMIT 0", "bq_executor_project_id": "some-project", "impersonate_service_account": "sa@some-project.iam.gserviceaccount.com", "timeout_seconds": 60 } publishされるデータ 
 BASE64エンコード Cloud Scheduler UI上で 
 publish API のbodyに指定するデータ 

12. Cloud Schedulerで別のプロジェクトの Pub/Subトピックにpublish resource "google_cloud_scheduler_job" "job" { // ...省略... http_target { // ... 省略... body = base64encode(jsonencode({ messages = [{ data = base64encode(jsonencode({ # Set team name "team" : "team1", # Set query name "query_name" : "query1", # Write a query "query" : "SELECT 1 LIMIT 0", # Set a executor project "bq_executor_project_id" : "some-project", # Set impersonate service account "impersonate_service_account" : "sa@some-project.iam.gserviceaccount.com", "timeout_seconds" : 60 }))}]})) } }
13. Datadogのmonitor設定 • querymon.monitor_result.returned_row_count というmetricに、クエリの実行結果の 返ってきた行数を格納
 • 以下のようなMonitorのクエリで、1行以上のデータが返ってきたことを検出
 
 
 
 
 • Alert Conditionで、metricが一定時間存在しない場合にalertを発生させるように設 定
 
 max(last_1h):max:querymon.monitor_result.returned_row_count{env:dev,query_name:query_name1,team:team1} > 0
 クエリ名
 チーム名

14. QueryMon バージョン2.0 • 1.0 と比べて良くなったところ
 ◦ 監視が行われなかったことの検出が可能に
 ◦ チームが監視の設定を自分たちで変更することが可能に
 ◦ Datadogがサポートする、Slack以外の通知先も設定できる（たとえば、 PagerDutyを利用して電話をかけることもできる）
 ◦ Argo Workflowsへの依存をなくし、コミュニケーションコストが軽減
 
 • まだ解決されていない問題点
 ◦ チームが所有してないSAで任意のクエリを実行できてしまう

15. チームが所有してないSAで任意のクエリを 実行できてしまう • 権限さえあれば、QueryMonのPub/Subトピックに任意のデータをpublishできてしまう
 • publishされるデータ内で、クエリを実行するSA名と、実行するクエリを自由に指定することができる
 • →自分のチームの責任範囲外のSAで、任意のクエリを実行されることを拒否できない
 
 • リスク軽減策
 ◦ トピックのpublish権限を厳格に管理（申請されたSAのみが利用可能とする）
 ◦ QueryMonがテーブルのデータそのものを扱わない
 ▪ ”maxResults”パラメータに0を指定してBQ query APIを呼ぶと、クエリの成功/失敗およ び結果の行数のみが得られ、データそのものは得られない
 →QueryMonの仕様上問題ない

16. まとめ • BQのデータが正しくないことを検出したい、という複数のチームの要件を叶えるた め、BQのデータを監視する仕組みを作り、社内に展開した