Voicyアドベントカレンダー 1日目の記事です。

初めまして、Voicyでエンジニアリングマネージャをしているやまげんです。今年もVoicyのアドベントカレンダーを始めたいと思います。

アドベントカレンダーにはベテランのエンジニアから今月入社したエンジニアまで参加しており、 Voicyの開発組織が伝わるかなと思うので気になるトピックがあったらぜひみてみてください。

本日はデータ分析基盤の紹介したいと思います。

Voicyのデータ分析基盤についてとその設計

音声プラットフォームVoicyはMAU250万人を超える大きなサービスへと成長してきました。

そしてこれからも成長をするために日々全社で奮闘中の毎日です。

Voicyのソフトウェアとして求められる性質はプラットフォームビジネスを最大化できること。それを実現するためには、LayerX CTOの松本さんが提唱している3つのファクターが重要と捉えています。

スケーラビリティ
レジリエンス
データ

https://note.com/y_matsuwitter/n/n895bdfb2407a

詳しくは松本さんの記事を参考にしていただければと思うのですが、データ分析基盤は3つの項目のデータに寄与することになります。

効果を最大化するためにどのような設計を考えたか説明していき、最終的にはアーキテクチャを説明できればと思います。

Voicyのデータ基盤に求められること

前節で説明したように、プラットフォームビジネスを最大化するためにデータが必要ということになるのですが、データがあると具体的にどのようなビジネス価値が生まれるでしょうか？

意思決定

プラットフォームでは日々たくさんのユーザが、サービスに訪問をして行動をしています。そのとき生まれるデータはユーザ自身の行動であり、市場を表します。その市場を理解することで、市場を最大化するための意思決定の純度を上げることができます。例えば、MRRなどのマクロの行動は経営の方針を決めて、ABテストなどで注視するミクロ行動はプロダクト開発の次の行動を決めます。このように意思決定の純度を上げるためにデータを活用することができます。

ユーザの価値の最大化

プラットフォーム内の行動を分析することで、ユーザ自身の理解につながります。ユーザの理解が進むということはそのユーザの嗜好がわかるということであり、そのユーザに届けるべきコンテンツの類推につなげることができます。その応用がレコメンドであり検索でありと捉えることができて、これはデータが溜まるほど精度が上がるエコシステムを作成することができて、サービスが伸びれば伸びるほど価値が増加していきます。

商品価値の最大化

ユーザ自身の行動を知って市場を知ることはつまり、Voicyにはどのようなユーザがいるのかを知ることができます。現在サードバーティデータの追い風が激しい世の中になっている中で、ファーストパーティデータでユーザのことを知ることができるプラットフォームはそれだけで強みになります。ユーザが行動する以上そこにはimpressionが発生するので、そのimpressionに対して適切なコンテンツを掲載することはプラットフォームの強みとなり強力な商品となります。 Voicyもブランディング商品として、「Voicy Branding Program」を販売しています。そこには裏付けとなるデータがあり、商品価値を裏から支えてると言っても過言ではありません。

上記で述べたようなことはデータをビジネスに変えるというなら当然考えられるべきことではありますが、ここで重要なことはそれを提供できるデータ基盤であることが求められます。

ではその中でVoicyのデータ基盤に求めていることを述べると大きく二つと考えています。

データをマネジメントできること
小さくスタートできて最終的にデータ分析基盤もスケールできること

データをマネジメントできること

データマネジメントはDMBOKで定義されている11の項目を達成できるということを意識しています。 DMBOKに関してはゆずたそさんが出している解説本がとてもわかりやすいのでおすすめです。

https://yuzutas0.hatenablog.com/entry/2020/07/16/173000

データマネジメントは企業におけるデータ活用において、必要とされる広範囲の領域を11の項目に押さえています。

データガバナンス
データアーキテクチャ
データモデリングとデザイン
データストレージとオペレーション
データセキュリティ
データ統合と相互運用性
ドキュメントとコンテンツ管理
参照データとマスターデータ
データウェアハウジングと
ビジネスインテリジェンス
メタデータ
データ品質

これらをゆくゆくは実現可能なアーキテクチャにするということが大事と捉えています。

小さくスタートできて最終的にデータ分析基盤もスケールできること

ここまで長らく色々と語ってきましたが、いわばWhyの話です。Whyは方針を決める上で重要ではあるけど具体的な何を作るかは決めていません。 Whatを決めていく上で重要と考えているのが、「小さくスタートできて最終的にデータ分析基盤もスケールできること」です。 Voicyはスタートアップであり、データ分析基盤も自分一人で構築しました。つまり一人で構築可能でかつ運用可能な基盤にする必要があり、最小限の労力で実現していかなければなりません。またスタートアップはビジネスの移り変わりも早いということを理解しておかねばなりません。

そんな中でDMBOKの11項目もすぐに実現することは不可能です。重要なのは組織が増えて必要になったときに実現可能な基盤になっていること。そのために最低限やることを決めて疎結合なアーキテクチャを採用することで、小さく始めても失敗許容の大きい基盤にして、スケールがいくらでもできるようにしました。

Voicyのデータ分析基盤 VDAM

VDAMはVoicyのサービスから発生するログデータや行動データを処理するログ基盤と、そのデータを貯めるデータレイク、及び周辺コンポーネントの総称を指すデータプロダクトを指します。なおVDAMは "VDAM is a data DAM"の再帰的頭字語です

アーキテクチャ

アーキテクチャの概要は以下になっています

Voicyではアプリケーション基盤はAWSを採用していますが、データ分析基盤はBigqueryがDMBOKの事項を小さく実現できると捉えてGCPを利用しています。全体ではラムダアーキテクチャを採用しており、マルチクラウド(AWS - GCP)において多様なコンポーネントに対応できるようにしています。大きく6つのコンポーネントがあります

Stream Processor

データをリアルタイムに処理をしてDatalakeに保存するコンポーネントです。現在Bigqueryのストリーミングインサートを主に使用していますが、その他Cloud Pub Sub + DataFlowなどのクライアントに依存しづらいストリームも実現可能な構成にしています。

Batch Processor

データをバッチで処理をしてDatalakeに保存するコンポーネントです。現在はDataflowによるETL処理を行っています。

Data lake

あらゆるデータを貯めるデータレイクです。現在はインターフェースとして便利なBigQueryで実現をしていますが、一部データはあらゆるデータ形式に対応しているGCSに保存をしています。またスプレッドシートをデータレイクとしても扱っています。ここはVoicy以外のサービスドメインのデータが入っても問題ありません。