こんにちは、遊撃エンジニア兼代表の深澤です。
最近はインフラからサーバーをメインにいじっています。昔はクライアントも書いていました。
弊社は、「再現性を持ってユーザーに刺さるプロダクトをつくる」ことを目指しチームビルディングをしています。
なので、創業からのてんやわんや（スタートアップは皆そうです）の中で、数字とちゃんと向き合う方法を模索してきました。
結果として、今現在どういった分析基盤で仕事をしているかに関して書きたいと思います。
※注
- あくまで、2017年初頭にサービスインしたLIPSの分析基盤を、分析について何も知らない人間が組んできたという話です。開始の技術選定からは1年以上経っているので、参考程度にお願いします。
- 技術的には枯れた内容しかやっていません。分析は、技術だけでなく、掛けるコストやオペレーションに組み込むレベルの話が出来てはじめて意味をなすものなので、そちらの話がメインです。
1. 前提：限られたリソース
AppBrewは、コスメの口コミアプリであるLIPSを運営している会社です。
- イベントログ数は数千万per dayくらいの規模
- アプリなので、ログ分析からのファネル改善・リテンション改善が最重要な業務であり、命
- データ専任をおけるほどのリソースがない状態だった
2. スタートアップの分析基盤に必要なもの
- 技術（凝りすぎない程度に、とはいえちゃんとわかった上で組みたい
- 文化（リソース不足の状況だと、こちらが重要かなと思います
3. 技術面：基盤構成
LIPSのサービスはAWS上に載っています。
特にバックエンドの部分を抜き出すと上のようになっています。 ポイントとしては、
- EC2の各インスタンス上からfluentdでkinesisに投げる
- kinesisからfirehoseでredshiftのインスタンスに流し込む
- kinesisからfirehoseでS3に取り置く（Athenaで引ける（引くとは言っていない
- kinesisからlambdaを発火して、低レイテンシーでデータ分析用に使いたいデータ・サービスから改めて使いたいデータ（クリックログなど）をDynamoDBに流し込む
- Redash(Sassバージョン)を使い、Redshiftをメインのバックエンドとして利用する
- Redashは非エンジニア含む社員全員に公開している
他に蛇足として
- メインのRDSから必要なテーブルをdata pipelineでredshiftにdumpしているが、管理が面倒・タスクのトレーサビリティが低いので直近でembulkを利用する計画
- firebaseを利用しているので、BigQueryに流し込んではいる（あまり使えていない
というような構成になっています。 個別に説明すると、
Redshiftを利用している理由
- 個人的に慣れがあった
- サーバー立てる形式なので、高いとはいえ価格が見積もりやすく、皆が触れるBIバックエンドとしては安心感（クエリ課金は怖い
- 標準のpsqlがほぼ使えるので、導入しやすい（BigQueryがstandardSQLに対応した前後がサービスインのタイミングでした
Redshiftのデメリット
- スキーマを自前できっちり組まないといけない
- インデックスを適切に貼ったうえで、vacuumを定期的に回さないといけない（CIでやってます
なので、わかる人一人しかいない状態などであれば、firebaseからBigQueryに流し込んでいるものをそのまま使うなどがいいかもしれません。
スピードに関しては、インスタンスサイズ・スキーマやクエリ・インデックスの状態によって違い、完全にどちらが早いというようなデータは見つからなかったので言及は避けます。
参考データは以下
Dynamoを利用している理由
- サービス側から引きたいデータはredshift上ではスケーラビリティ・レスポンスタイムの関係で無理がある（当然
- クリックログやベクトルのようなデータだと、RDBMSはあまり向いてはいないし、メインのDB利用は密結合になるので嫌だった
- 永続化したいのでオンメモリのKVS等にのせるのも不安があった
- AWSを使っているので、Dynamoが選択肢に上がった
また、クリックログのようなデータであれば、スケーラビリティや速度（ある程度）は求められますが、ImmutableでConsistencyは不要なのでDynamoを導入しました。 ここからPythonの分析用インスタンスでデータを引いて、ごにょっています。
以下のリンクもかなり参考にしました。
とはいえ、そもそもスタートアップであれば普通はここまでやらなくていいかと思います。
4. 文化面：皆で分析したい
スタートアップのあるあるとして
- 肝心なところにログを仕込んでいない→欲しい時に数値取れない
- 一人に分析タスクが集中して、ボトルネック化・つらい
- リリースフローが雑なのですぐログが壊れる
三番目はちゃんとやれって話なのですが、上２つは、データに皆で触れる文化形成の問題が大きいのかなと思います。
AppBrewでは、意識を高めるために、オープン＆フラットな組織に加え、皆でクエリを書くようなRedash活用を心がけています。
Redash活用法
- 皆でログ仕込む・クエリ書く（エンジニアは5人、クエリを書く人は7人 全員が毎日書いているわけではないですが、ビズサイド含めかなりの人数がRedashで書く側に回っています
- slackに垂れ流す（毎日Redash見にいく習慣がないとなかなか活用出来ないので、slackで特定のチャンネルにKPI定期で貼っています
- issueにもredashのクエリをちゃんと貼る（まだ始めたばかりの習慣ですが、定性的な内容も出来る限り数字で裏を取ろうとします
- ちゃんと改善につなげる（CTRを上げたり、アクション率を上げたり、ちゃんと数字につなげるように業務自体を進めます
- 失敗した施策は取り下げる（リリース後も数字を確認して、失敗したらもとに戻すことを心がけます
※画像はイメージです
全部当たり前のことなのですが、全部が普段の業務レベルで染み付いていないとなかなか定着しないのも事実だと思います。
弊社もまだまだ改善中なので、こんな事例あるよというのがあれば、是非教えてください！
5. 最後に
今回は、AppBrewではベンチャーなりにちゃんとデータを活用していますという話を紹介しました。
このようにデータの下で仕事をすることで、再現性を持つ新規立ち上げプロセスを作ることを目標にしており、新規事業等も計画しています。
もしご興味がある方がいらっしゃったら是非私のtwitter
Yuta Fukazawa (@YFuka86) | Twitter
か、以下のwantedly(データ・サーバエンジニアの募集書いてませんでした）までご気軽にお願いします！
