完全図解 これがFiNC分析基盤だ！
こんにちは。FiNCデータ分析グループのこみぃです。
今日はFiNCの分析基盤の主な構成を説明していこうと思います。
Redshift周りの構成
FiNCの分析基盤の特徴はとにかくRedshiftを始めとしたAWSの機能を使い倒していることだと思います。
まずは全体像を御覧ください。
基本的にはすべてのデータをRedshiftに集めており、それをRedashで参照しているという構造ですね。
では、一つずつ説明していきます。
DMSを使う
サービスのデータベースのデータが必要になること。分析をするなら当然起こることですね。
FiNCの本番DBはRDSです。Redshiftへのデータの転送はDMSを使って行われます。
Kinesisを使う
アプリからストリーム的にデータを流したいということがあると思います。アプリ内でのユーザーの行動のログなどがそうですね。
これらを効率よくRedshiftに送り込むため、FiNCではKinesisを利用しています。
また、Kinesisは外部サービスのデータの収集にも使われます。例えばAppsflyerのデータの収集はPushAPIからデータを受け取る形ですが、このPushAPIからのデータの受取りもKinesisを使っています。
Kinesisを使いこなせると、Redshiftに簡単に集められるデータがとても増えます。
Fluentdを使う
アプリのログはKinesisで集めますが、サーバーサイドのログはどうすればいいでしょうか。
FiNCではFluentdを使っています。FluentdはRedshiftにデータを書き込んでS3も転送してくれるプラグインが存在しますのでそれを使えば構築は簡単です。
LambdaFunctionを使う
こちらも用途はKinesisと似ていますが、外部サービスのPullAPIからデータを取得する必要がある場合などにはLambdaFunctionを使うと便利な場合があります。
Jenkinsなどで定期的にデータを取得してS3に配置し、そのデータをLambdaFunctionでRedshiftにコピーするというのがFiNCでの利用法です。
Facebookなどに出稿している広告のKPIなど、外部サービスのデータを参照したい要望はとても多く、それをRedshiftで参照できるととても便利ですよね？
その要望に答えるために主に使うのが前述のKinesisと、このLambdaFunctionです。
サマリーテーブルという仕組み
上記の仕組みによりRedshiftに様々なデータを集めることは成功しましたが、FiNCではここでもう一つ工夫を加えています。
それが深夜に実行されているサマリーテーブルという処理です。
例えばプッシュ通知の成果を参照・分析したい場合には以下のようなデータを集計する必要があります。
- プッシュ通知の送信履歴
- プッシュ通知を受け取ったユーザーのアプリ内での行動履歴（送信を受けてアプリを開いたかなど）
- そのユーザーのデモグラ情報やアプリ上でのステータス
Redshiftにデータが集まっているとはいえ、これを集計するクエリを毎回実行していては日が暮れてしまいます。
そこで、分析に必要なこれらの数値を深夜にあらかじめ集計しておくわけです。それが我々がサマリーテーブルと呼んでいる処理になります。
図にするとこういうことですね。
この処理をすることのメリットは大きく2つです。
1. 実際の分析作業の際のクエリが単純・高速になる
2. データ分析チームのメンバー以外でもデータの参照がしやすくなる
こちらについては先日のX-Tech JAWS 【第3回】にて弊社の鈴木からも紹介させていただいた内容です。
FiNCのデータ戦略と AWSでのデータプラットフォーム構築 / Healthcare Data in FiNC
プッシュ通知の他に、例えば以下のようなデータを日次で集計しています。
- 記事の閲覧履歴
- ユーザーの数日間のリテンション
まとめ
FiNCの分析基盤を簡単にまとめると以下のような感じです。
- すべてのデータはRedshiftに集める
- AWSの機能を使い倒す
- サマリーテーブルという、事前集計をする処理を行っている
今回はこのあたりで！！
