こんにちは。ノバセルにてデータエンジニアをやっている山中(@yamnaku_)です。 本記事では、「マルチデータプロダクト」へ向けたノバセルのデータ基盤アーキテクチャの変遷と、その過程で得られた知見をご紹介したいと思います。
この記事は ノバセル Advent Calendar 2 日目です。
はじめに
ノバセルでは、「マーケティングを民主化する」というミッションのもと、お客様の広告効果の可視化や最適化のサービス群を展開しています。 これらのサービスでは、データを用いた合理的な意思決定ができるよう多くのデータを活用しています。一例を挙げると以下のようなものがあります。
- サイト訪問データ
- Web 検索データ
- 広告出稿関連データ
2020 年にスタートしたデータ基盤の導入・活用のプロジェクトは、「データですべてのプロセスをエンパワーする」というミッションでスタートしました。 そこから 4 年ほど、データ基盤を用いてノバセルの事業を支えている「データ」を迅速かつ安定的に提供するための取り組みを実施してきました。
本記事では、2020 年以降の Snowflake を中心としたデータ基盤の変革を通じ、その中で起こった変化や直面した挑戦についてご紹介します。
Snowflake 導入の経緯
ノバセルの事業立ち上げ当初、データ基盤は比較的シンプルな構成でした。
- アプリケーションデータベース(MySQL)に、分析済データも格納
- アプリケーションと分析処理が同一環境で動作
この構成には以下のような問題がありました。
- ストレージコストが非常に高い
- アドホック分析時のパフォーマンス低下
- アプリケーション・分析業務が互いに影響を及ぼし合う危険な状態
これらの課題を解決するため、2020 年に Snowflake を導入しました。 Snowflake を選択した理由は主に以下の 4 点です：
コスト優位性
- 効率的なストレージ圧縮
- 従量課金制による柔軟なコスト管理
ニアゼロメンテナンス
- インスタンス管理、indexing、partitioning などの管理が不要
- ストレージの自動最適化・圧縮
変化への柔軟性
- Schema on Read による柔軟なデータモデリング
- 事前のスキーマ設計が最小限で済む
高いパフォーマンス
- クエリに応じた最適なインスタンスを 1 秒で起動
- 年々向上するクエリパフォーマンスとストレージ圧縮率
この結果、ストレージコストを 8 分の 1 に削減することが出来たとともに、分析クエリのパフォーマンスも大幅に改善しました。 また、集計済みのデータだけでなく、集計前のローデータも Snowflake へロードするようにしたため、アドホックな分析の柔軟性も高まりました。
マルチデータプロダクトへ
Snowflake の導入後、ノバセルでは「マルチデータプロダクト」を目指して、システムアーキテクチャを変化させてきました。 「データプロダクト」（あるいは Data as a Product)についての明確な定義はありませんが、データ基盤やデータパイプラインに対して、プロダクトマネジメントのプラクティスを適用した概念と言えます。
ノバセルの場合、データ基盤やパイプラインによって生成したデータは、 BI などのインターフェースを通じてお客様に提供されています。 そのため、従来より通常のプロダクトと同様の性質を持ち、データプロダクトの概念を導入するのは自然の流れだったと言えます。 データプロダクトにおいてはマルチユーザー・マルチユースを重視する1ため、「データ・ロジック・ユーザーインターフェースの分離」が重要になります。
また、ノバセルのサービス群は多角化してきており、複数のサービスを共通のアーキテクチャで管理したり、サービス間のデータの移動を容易にする必要もありました。 よって、データメッシュのような分散的なデータ基盤アーキテクチャを採用することを目指しました。 2020 年〜22 年にかけてデータ基盤の活用や知見の蓄積を徐々に進めつつ、2023 年からこのアーキテクチャへの転換に必要な取り組みを本格的に開始しています。
それを経て、現在のデータ基盤のアーキテクチャ全体は以下の図のようになっています。
では、取り組みの内容とどのような変化が起こったかご紹介します。
ツールの標準化が出来た
Before
- データ基盤上でプロダクト開発するために必要な技術スタックが無い、または整備途上の状態
- 各システムが様々なコンポーネント/リソースに分離し、全体感が分からない
After
- dbt の導入によって、開発運用性が向上
- Dagster の導入とモノレポ管理に移行し、データパイプラインの全体把握を可能にした
マルチプロダクトを進めていく中で、初期フェーズでは技術スタックを共通化したり、過剰なアーキテクチャ分離を避けることが重要です。 とりわけ、データ基盤のアーキテクチャはさまざまな理由により統合管理することが難しくなりがちです。 データパイプラインツールの導入やモノレポ戦略は中長期的に重要な意思決定だと考えています2。
dbt の導入に合わせて、モデルのレイヤーや設計方針、SQL のフォーマッタルールなども策定しています。 フォーマッタにはSQLFluffを利用しています。
データ基盤上で開発チームが安全に開発できる環境が出来た
Before
- Snowflake のリソース(データベースやロール等)の作成は Snowsight から実施
- Snowflake のデータベースやスキーマの分割方針はバラバラ、アクセス制御の方針もバラバラ
After
- Snowflake のリソースを Terraform で管理/作成する
- データベースやスキーマの分割方針を策定。ファンクショナルロール/アクセスロール構成でのアクセス制御の標準化
ノバセルにおいては、アプリケーションまたはデータソース単位でデータベースを分離し、スキーマで環境(Prod/Staging/Dev)を分離する構成を採用しています。 世の中では、データベースで環境を分けることが多いように思いますが、ノバセルでは以下の理由で、このような構成にしています。
- セキュリティ: アクセス制御をデータベースロールによって行うため、アクセス権限の境界がデータベース単位になりやすい。設定ミスが起きても、データベースを跨いでアクセス可能になってしまうことは、スキーマを跨ぐ場合に比べて起きにくい。クライアントごとのデータソースを別々のデータベースに分割して、安全性を高めている。
- データへのオーナーシップを委譲しやすい: アプリケーションやデータソースのオーナーチームに権限を委譲しやすい。究極的にはデータベースの全権限をオーナーチームに委譲すれば、基盤側で管理する必要がなくなるため。
また、Terraform を自動生成可能な CLI ツールの開発なども行いました。 CLI ツールを利用すると、開発チーム自身で、データ基盤のセットアップが可能で、開発で必要なデータベースやロール、ユーザー、ウェアハウスなどが対話型のインターフェースを通じて作成可能になります。 この CLI は基盤チームが策定したデータベースやスキーマ、ロール設計のポリシーを反映した安全な Terraform を自動で生成します。 以下のような特徴を備えています。
- 開発チームがセルフで、素早くセットアップでき、基盤内の詳細な設計を知らなくても使い始めることができる
- 基盤チームの設計したリソースやアクセス管理設計が自動で適用されることを保証できる
このようなツール整備は、Platform Engineering や、それをデータ基盤に対して適用したData Developer Platformのコンセプトを参考にしています。
様々な ETL を利用して、効率的に開発できるようになった
Before
- 内製のデータ転送システムによるロード
After
- TROCCO, Airbyte, Fivetran などの複数の ETL ツールによるロード
- Snowpipe や External Stage などの Snowflake 機能によるロード
Snowflake 導入初期は、内製のデータ転送システムを作ることが多かったものの、TROCCO の導入により、ETL ツールによるロード処理を実装することが増えました。 その後、ニーズの変化・拡大に伴って、他の ETL ツールも併用する形になりました。 さらに、External Table やネイティブコネクタなどの Snowflake の便利な標準機能も増えてきており、選択肢はますます増えています。 コスト・メンテナンス性・拡張性などを天秤にかけて意思決定していきますが、ツールの発展も早く、数ヶ月前の意思決定が数ヶ月後には最適ではないということもざらにあるのが現状です。
今後はこれらのツールの整備や取捨選択が必要になるかと思っていますが、個人的に一つの評価軸になりうると考えているのが、dbt への組み込みやすさです。 今後のデータ基盤のツールは dbt を中心にエコシステムが形成されていると予想しており、dbt-external-tablesのように、dbt の中で ETL が実現できるようになっています。 サードパーティの ETL ツールも、(理論的には)dbt でセットアップすることが可能なため、dbt パッケージ化を待ち望んでいます。
ビジネス要件に合わせて BI ツールを使い分けるようになった
Before
- Redash を利用した、SQL ベースでのデータ提供
- 標準的なフロントエンドの技術スタックを利用したユーザーインターフェースによるデータ提供
After
- QuickSight, Exploratory, Tableau など複数の BI ツールをシーンによって使い分ける
ユーザーとのタッチポイントとなるユーザーインターフェースのレイヤーでも、状況に合わせて色々なツールを選択できるようになっています。 各ツールの特徴を一言で話すと、以下のようになります。
- カスタマイゼーションの幅が広く、コード管理も可能な QuickSight
- データ分析のロジックを埋め込める Exploratory
- ビジュアライゼーションの種類が多く、ユーザー数が多く情報豊富な Tableau
BI ツールも ETL と同様にさまざまな選択肢があり、新たなツールも次々と登場しています。 しかし、マルチプロダクトにおける異なる要件をうまくカバーできる BI ツールはまだ見出すことが出来ていません。 今後のデータプロダクトを推進する上で、以下の 2 つの機能を備えた BI ツールが見つかる、または新たに生まれると良いなと思っています。
- BI as code を実現できるツール。また、GUI での作成も可能であること。
- 外部パッケージのような形で、新たなビジュアライゼーションを簡単に追加できること。
まとめ
ノバセルのデータ基盤は、「マーケティングの民主化」というビジョンのもと、日々進化を続けています。 今後も、より良いデータ活用基盤の構築を目指して取り組んでいきます。
明日は、今年の新卒メンバーが、dbt unit_test での overrides の使い所についてわかりやすく紹介してくれます！ 乞うご期待！
ちなみに、先日行われたアーキテクチャ Conferenceでも、パネル掲示していただきました。
今日は #アーキテクチャcon_findy に来ております。弊社のアーキテクチャも紹介いただいています〜。
— Yamanaka | RAKSUL / NOVASELL (@yamnaku_) 2024年11月26日
1面使わせていただいている。ありがとうございます！ @findy_tools pic.twitter.com/QK3Bv0dsbm
- https://dhbr.diamond.jp/articles/-/9053↩
- アーキテクチャの変更は組織状況とも密接に関連する(コンウェイの法則)ため、状況を見極めて慎重に行う必要があります。結果論ではありますが、ノバセルではアーキテクチャの変更にあわせて組織も変化してきている(逆コンウェイの法則)ように思います。↩
