trocco・BigQuery・Tableauを採用。アソビューがデータ分析基盤の再構築に挑んだ理由

はじめまして、アソビューでデータ基盤チームに所属している霧生です。

近年、モダンデータスタックの登場などによりデータ分析基盤は一層盛り上がりを見せています。選択肢も増えてできることが多くなった反面、どう構築していくか迷う場面も多いのではないでしょうか。今回はアソビューのデータ分析基盤の構成と現状の課題、将来的な改善をどう考えているのかなどを解説しますので、ご参考になれば幸いです。

現在のアソビューのデータ分析基盤

アソビューは創業10周年を超えており、当然ながら今までもデータを分析して事業やサービスに役立ててきました。しかし、コードやインフラの継ぎ足しを重ねたことにより秘伝のタレのような状態と化してしまい、多くの課題が生まれています。そこで、アソビューではこの問題を解消するために、昨年から株式会社DATALEさんとともにデータ分析基盤の再構築を行いました。

データ分析基盤を構築するにあたり、「使われる」データ分析基盤にすることを大切に設計・実装していきました。というのもそもそも「データ分析基盤は使われなければ意味がない」からです。ただデータを収集しているだけ、データ分析基盤を作ることだけが目的になってしまっている場合、どれだけ優れたアーキテクチャを組んでも、データからインサイトを得てビジネスに役立てるデータ活用のプロセスが進みません。

では、どうすればデータの活用が進むのでしょうか。その答えのひとつが弊社も利用しているBIツール、Tableauが提唱しているビジュアル分析のサイクルにあると考えています。

「どこからデータを分析していけばいいかわからない」「分析結果を見てもよくわからない」というユーザーからのフィードバックは「タスク」がないことに起因していることが多いです。

簡単な例ですが、「売り上げを上げたい」「コストを下げたい」といったタスクに対して、どんなデータを見ればいいか、さらにそのデータをどう見ればいいかなどを考えて、必要十分なデータを取捨選択していくことが重要です。こうして適切なデータを適切に扱うことで、より価値のある活用につながります。また、ビジュアル分析のサイクルはただのプロセスサイクルではないため、分析を行う中でさらに必要なデータが出てくることもあります。柔軟かつ高速にビジュアル分析のサイクルを回すことで、データ分析基盤は使われる・価値のあるものに進化していきます。

分析者と同じ視点に立ち、高速に新しいデータを連携して分析のプロセスを回す。これがデータ分析基盤を新規に作り上げていく段階では特に重要な観点だと考えています。そこで私たちが導入したのがtroccoです。troccoとはETL/データ転送機能を提供する分析基盤構築・運用支援のSaaSです。troccoを提供している株式会社primeNumberが日本企業ということもあり、日本語での手厚いサポートや日本でよく使われるSaaSからのデータ連携にも多く対応しています。troccoは主にGUIで設定を作成するため、初期の学習コストや設定作業のコストを大幅に削減でき、いち早くデータを提供できます。

また、データウェアハウスにはBigQueryを採用しました。これも構築・提供スピードを重視した技術選定です。GAなどの他のGoogleサービスとの親和性や、よく使われるSaaSとの連携に対応していることを考えて選択しました。

最終的なアーキテクチャは下記のようになりました。

troccoにはデータマート生成という機能があり、これを利用して収集したデータを最終的に分析可能な状態に変換してデータマートを構築しています。

BIツールは先にも出てきたTableauを利用しており、直近では社内のアクティブユーザー数が全社員の4分の1に迫る40人前後、Tableau Cloud上での分析結果のView数は約600view/日と、広く使われる状態を実現できていると感じています。今ではマーケティング施策やモニタリングだけではなく、アプリケーションへのデータの利活用や広告の最適化など、さまざまな用途でデータ分析基盤が使われています。

これは株式会社DATALEさんのご協力はもちろんですが、分析しているアソビュー社員のデータに対しての感度の高さや意欲など、さまざまな立場とスキルを持ったメンバーが揃い尽力した結果だと思います。データ分析基盤は使われなければ意味がないと冒頭で書きましたが、それはつまりエンジニアだけで作り上げるものではなく、使っている人や状況に応じてアーキテクチャも変わっていくべきということです。現状は前述の構成を使っていますが、運用している中での課題も出てきており、その解決のためには小手先の対応ではなくアーキテクチャレベルの改修が必要になっています。

将来的なデータ分析基盤の構想と導入したい技術

先に挙げた現状抱えている課題ですが、大きく分けて下記の2つがあります。

• データマートに対してのSQLの実行速度とデータ基盤全体の料金
• データ分析基盤の堅牢性

データマートに対してのSQLの実行速度とデータ基盤全体の料金

ビジュアル分析のサイクルを高速に回していくには、さまざまなデータについて異なる角度から何度もビジュアル分析を試すデータ探索によって、BIツールから素早く結果を取得できることが重要になります。アソビューではデータ分析基盤の利用が拡大し分析可能なデータが加速度的に増えていった結果、いくつかのテーブルで速度劣化が起きるようになりました。また、うれしい悲鳴ではありますが、データ分析基盤の利用が拡大し利用者が増えたことにより料金も大きく増加しています。

テーブルの構造変更やBigQueryの機能の利用など、現状のアーキテクチャでも改善できる部分は当然あると考えています。しかし投げるクエリやテーブルの性質、利用しているBIツールとの相性などを鑑みて、アソビューの場合は同時並行で検証を行っていたSnowflakeを利用することでこれらの課題に対して一定の効果が期待できると判断しています。

速度面では、データ探索中にTableauが類似したクエリを多く投げる点や、ライブ接続でViz*を見た場合に同じクエリが投げられる点などから、Snowflakeの強力なキャッシュ機能の恩恵を受けやすいこと。料金面では従量課金の方式がBigQueryではデータのスキャン料であるのに対して、Snowflakeはデータウェアハウスというコンピュートリソースの起動時間であるため、予測が立てやすく利用者が爆発的に増えた場合でも対応しやすい料金体系になっていることが理由です。

*…Tableauで作成した、ビジュアライズされたグラフや表。

また、管理側の目線ではクラウドサービスプロバイダーであるGCPのひとつの機能であるBigQueryよりも、データクラウドとしての機能に特化しているSnowflakeのほうがアクセスコントロールが優れている点もあり、管理と利用の両面でSnowflakeへの移行はメリットが大きいです。

一部ではすでにSnowflakeの実験利用が始まっています。GAなどBigQueryに依存したデータがあるので、Snowflakeだけでデータ分析基盤を構築することはできないですし、クエリの細かな違い、データの移行やどう活用するかのステップなど多くの課題がありますが、一歩一歩移行を進めていく予定です。

データ分析基盤の堅牢性

データ分析基盤の利用者が増えて、データ分析基盤自体の業務への依存度が高まっています。それに伴い、データの鮮度や状態といったデータ分析基盤の可用性や変更に対しての強さ、堅牢性の重要度が日々増しています。

troccoはGUIからの設定が主であるため導入コストの低さが特徴です。しかし、分析できるデータが増えて規模が大きくなるにつれて、データマートを構築するためのクエリやそれらを取りまとめるワークフローは複雑になっており、管理が煩雑で属人化が激しくなってきています。これをきっかけに、より使われるようになったからこそ堅牢性を上げていきたいと考えています。しかし、堅牢性は構築スピードとトレードオフになってしまうため、バランスをどう取るかに頭を悩ませています。

現状この問題に対してはdbtを導入することが良いのではないかと考えています。troccoにもdbt連携という機能があるため、どこでどう実行するか、Snowflakeへの移行も含め今後検討していく予定です。

終わりに

アソビューにおけるデータ分析基盤のアーキテクチャと、その設計意図に関しての紹介でした。

技術の更新が激しい界隈ですし、ここには書けていない課題も多くある状況です。お察しの通りアソビューのデータ分析基盤はまだまだ道半ば、なんなら走り始めた段階だと思っています。しかし、データ分析基盤の利用者は日々増えており、データドリブンな文化も浸透してきています。ここを走り切ってデータの利活用が進むことが大きく事業を成長させる重要な要素であることは間違いありません。

これからも、より「使われる」データ分析基盤になるように改善を続けていきます。1年後には別の姿になっているかもしれません。その時はまたどこかで共有できればと思います。本記事が皆さまの一助になれば幸いです。

編集：中薗昴

提供：株式会社Haul