データ基盤VisionでTROCCOを使い始めた理由と導入後の変化

こんにちは。CARTA ZEROでデータエンジニアをしているharukiです。
この記事はCARTA ADVENTCALENDAR 12/17の記事です。

CARTA ZEROのデータ基盤Visionでは、Snowflakeとスプレッドシート連携の課題を解決するためTROCCOを導入しました。

TROCCOを選んだ理由

非エンジニアでも直感的に設定が可能
転送時間ベースの課金体系でスプレッドシート数の増加に強い
日本語サポートとSlack通知による運用の安心感

導入後の変化

導入1ヶ月で37件の転送設定が作成され、低コストで多数の連携を実現
データ利用状況がTROCCOに集約され、どのデータがどこで使われているかを把握できるように
一方で、ビジネスサイドの要望に対しデータ整備が追いつかない新たな課題も顕在化

今回は、TROCCO導入に至った経緯と導入後の変化について詳しく紹介します。

背景

当初は、プロダクト開発チームから来るデータに関する要望を受けて、データチームが開発を行う体制でした。Visionへのデータ取り込みからデータモデリング、プロダクトへの提供まで、全ての開発プロセスをデータチームが担っていました。しかし、プロダクト開発チームからの要望に対してデータチームの開発速度がボトルネックになっていきました。また、Visionで扱うデータの種類が増えるにつれて、データチームが理解すべきプロダクトの知識も多くなり、データの問題に対する原因の把握が難しくなっていきました。

そこで、2023年にDataOpsを導入し、プロダクト開発チームのエンジニアが自律的に開発運用を行う体制に変更しました。プロダクト開発チームは各プロダクトのデータ取り込みからデータモデルの開発運用まで行うようになり、データチームは各プロダクト開発チームにVisionをプラットフォームとして提供し、基盤のインフラ整備やガイドラインの策定、プロダクト開発チームへの支援に注力する役割へとシフトしました。その結果、開発サイクルが速く回るようになり、エンジニアだけでなくビジネスサイドのユーザーもデータを活用する機会が増えてきました。

ビジネスサイドのユーザーは、日常的に使い慣れたスプレッドシートでデータを分析・活用したいというニーズが強く、SnowflakeとGoogle スプレッドシートの連携が必要になる場面が増えていきました。

しかし、多くのスプレッドシートとSnowflakeの連携方法はGoogle Apps ScriptでRedash APIを呼び出してクエリしその結果をシートに書き出すというやり方でした。これをエンジニアでなく、ビジネスサイドのユーザーが行っていました。

利用状況の把握の難しさ

Google Apps Scriptでデータの連携が設定されているため、データチームがシートでのデータ利用状況を把握することが困難でした。Snowflakeのクエリ履歴からどのようなクエリが実行されているかは確認できますが、それがどのシートで使われているかの対応関係はわかりません。シートを管理しているのはビジネスユーザーであり、個々のシートの存在を把握することも難しい状況でした。

失敗時の対応

Google Apps Scriptは不安定なタイミングがたまにあり、実際に月に数回は失敗することがありました。
そのため、毎朝ビジネスサイドのユーザーがGoogle Apps Scriptの実行履歴を確認し、失敗している実行があれば再実行していました。

業務整理をしてスプレッドシートでデータを見なくても済むような手段を考えることも検討しました。そのためには、どのスプレッドシートでどのようにデータが使われているのか全体像を知る必要がありました。しかし、Google Apps Scriptで連携されている状態ではどこで連携されているかを把握すること自体が困難な上に、スプレッドシートの数も多いことが予想されていました。そこでまず、Google Apps Scriptでの連携によって発生しているビジネスサイドのユーザーの負担を軽くすること、そしてデータを連携している箇所を把握できる状態に変えることの2つを優先して取り組むことにしました。この2つを実現するために、Snowflakeとスプレッドシートを連携するためのツールとして、TROCCOを含む様々なツールを比較検討しました。

導入に至った理由

設定の簡単さ

TROCCOを主に使ってもらうのは非エンジニアのビジネスサイドの人たちです。その中でもSQLが書ける人をメインターゲットに考えていました。このような人たちが見たいデータをSnowflakeからスプレッドシートに書き出すことができるツールなのかどうかを重点的に見ていました。

TROCCOは非エンジニアでもSQLが書ければ、Snowflakeへのクエリの結果をどのシートに転送するかという流れで考えて直感的に設定していくことができます。
Google Apps Scriptを使ってRedashからデータを取得する処理を作るよりもはるかに簡単でした。

参考

【TROCCO®入門ガイド】データ転送設定の使い方

また、実際にデータを転送する設定とSnowflakeやスプレッドシートへの接続情報の設定が分かれています。TROCCOがSnowflakeに対して実行できる操作はSnowflakeのロールによって制御されるため、データチームがロールと接続設定を一体で管理することで、ビジネスサイドのユーザーに適切な権限範囲でTROCCOを利用してもらうことができます。運用としては、データチームが接続設定を作成し、ビジネスサイドのユーザーはその接続設定を選んでデータ転送設定を作成する形になります。転送設定と接続設定が分かれていることで、ビジネスサイドのユーザーとデータチームがそれぞれ管理すべき対象の境界が明確になり、適切に責任を分担して運用していくことができます。

転送時間ベースの課金体系

今回、他に比較検討したツールの多くはコネクション数ベースの課金体系でした。コネクションとは「データの転送元 ×転送先の組み合わせ」のことで、例えば1つのスプレッドシートに対して1コネクションとしてカウントされます。この課金体系では、スプレッドシートの数が増えるほどコストが高くなるため、シート連携の増加が予想される状況では障壁になると考え、検討対象から外しました。

一方で、TROCCOは転送時間ベースの課金体系になっています。そもそもシートで大量のデータを見るのは体験が悪く、ある程度集計されたデータを書き出して見るということがほとんどだったので、転送時間は短いものが多いです。転送時間が短く、転送先が多いというユースケースにTROCCOの課金体系がマッチしていました。

日本語でのサポート

データ系のSaaSは英語圏のプロダクトが多く、問い合わせの際に英語でのやり取りや時差を考慮する必要があります。しかしTroccoは日本の企業が提供するサービスなので、日本語で問い合わせができ、日本の勤務時間内に回答が返ってきます。言語の壁や時差を気にせずサポートを頼れるのはとてもありがたいです。

Slackへの通知

TROCCOでは転送ジョブの失敗時にSlackに通知できます。さらに通知内容を自由に決めることができます。エラー時の対応方法をPlaybookとしてドキュメントにまとめて、以下のように転送設定を管理しているビジネスユーザーをメンションして通知することで、ビジネスユーザーが自ら対応してもらうことができます。

以上の理由からSnowflakeからスプレッドシートへのReverseETLを主なユースケースとしてTROCCOを使っていくことに決めました。

導入後の変化

ビジネスサイドのユーザーでも一度転送設定の作り方を説明すると、次からは一人で作成できるようになりました。それほど簡単にデータ転送を設定できるため、導入して1ヶ月ほどしか経っていませんが、すでに転送設定が37件あります。転送設定の数はこれからも増えていく想定ですが、低コストで多くの転送を実現できています。

さらに、Snowflakeからスプレッドシートへのデータ転送に関する情報がTROCCOに集約されるようになったため、TROCCOの転送設定を見れば、どのデータがどのスプレッドシートで使われているかを、データチームとビジネスサイドのユーザー双方がすぐに把握できるようになりました。

依然として、スプレッドシートでデータを見ること自体が本当に適切なのかという課題は残っています。しかし、TROCCOによってスプレッドシート連携の実態が可視化されたことで、業務を整理してより良いデータ活用の形を模索するための土台が整いました。

一方で、これまで見えていなかった課題も顕在化しました。TROCCOを使ってスプレッドシートに連携できるデータを、ユースケースに合わせて加工済みのデータに限定して運用を始めました。以前のGoogle Apps ScriptとRedash APIを使った運用では、Redashで調査目的でさまざまなデータにアクセスできるよう権限を緩く設計していたため、加工前の取り込んだままのデータもスプレッドシートに連携できていました。しかし、Visionでは加工済みのデータのみを外部に提供するというポリシーで運用しているため、TROCCOを使った現在の運用ではビジネスサイドのユーザーが必要とするデータを適切に加工して提供する必要があります。ビジネスサイドからの要望に対してデータ整備が追いついていない状況になっており、次は、よりデータ活用の総量を増やしていくために、データ整備をスケールさせる方法を模索していきたいと思います。