この記事はmikan Advent Calendar 2023の24日目の記事です。
こんにちは。株式会社mikanでPlatform Engineeringチームのリーダーをしております。@hoshitocat です。Platform Engineeringチームは最近できたチームですが、その取り組み内容についてはまた後ほどご紹介できればと思っています。
昨日はQAチームのchiakiさんによる、 「テスト自動化で試行錯誤した話」でした。QAの自動化に取り組みたいと思っている方や、QAコスト削減方法に悩んでいる方はぜひ読んでみてください！
なお、mikan Advent Calendar 2023の他の記事は下記のリンクからご覧ください。
はじめに
mikanでは行動分析をAthenaで行っていましたが、現在は、分析上の課題感からBigQueryへの移行を完了させ、ほとんどの分析がBigQuery上で完結できるようになりました。
分析しやすい基盤構築をしたいと思っている人の参考になればと思います。
これまでの分析基盤の課題
クライアントから送信された行動ログがS3に蓄積され、それをAthenaを使って分析するということをやっていました。
生ログデータを対象にSQLを実行していたため、膨大なデータから必要なログを抽出し、クエリでコネコネして集計するということをやっていました。分析チームによる秘伝のタレがあり、それを分析したい人が使い回している状況でした。そのため、
- 普段よく使うデータを算出するにも秘伝のタレを使うことになり、クエリが複雑化する
- 複雑化したクエリを使い回しているため、分析の難易度が高い
- 生ログを毎回集計しているため、集計コスト（金額と時間）が高い
などの課題がありました。
mikanの分析基盤の歴史についてはこちらの記事で紹介されているので、興味のある方はぜひ！
BigQuery利用への意思決定
今回の課題を解決するためには、生ログからの直接集計を止めれば良いので、よく使うデータをまとめた中間テーブルを作成することができれば解決できそうです。
運用とセットで考えないといけないので、要件としては以下を満たすことができれば良さそうと考えました。
- 分析チームメンバーが管理者となって中間テーブルの作成、管理することができる
- 分析者（これは分析したい人全員が対象となるため分析チーム以外も含む）は中間テーブルを使って分析する
さらに追加要件として、分析チーム専任のエンジニアをアサインできないため、作成や管理方法をできるだけ簡単にする必要がありました。
具体的には、普段使っているSQLを使って中間テーブルを作成することができると良さそうでした。
Glueを使ってみるが断念
まず最初に考えたのが、現状の構成のまま中間テーブルを作れないか？ということでした。そこで、AWS Glueを使って生ログデータを加工し、中間テーブルを作ることができそうだったので検証していました。
しかし、mikanの分析データを扱う際にうまくPushdown Predicatesが機能せず、ETL処理に時間がかかりすぎてTimeoutしてしまうという問題がありました。
パーティションの切り方に問題がありそうだったので、Lambdaでそこを修正した上でGlueを使うことも考えたのですが、Lambdaの運用コストを考えると、今の分析チームでは運用コストが高すぎるとなり、一旦保留となりました。
AthenaではなくBigQueryを使うという選択肢
そうこうしている中、弊社の分析メンバーでBigQueryを使って分析基盤を運用した経験があるメンバーから、そっちだったら中間テーブルとか諸々の運用が楽なのにな〜という話がでました。
特にAthenaを使いたいという強い理由はなかったので、S3の行動ログを分析できれば良かったので視野を広げて調査してみると、STSを使えば、S3からGoogle Cloud Storage(GCS)へデータ移行を完全マネージドで実現することができそうなことがわかりました。
検証を進めていくうちにGCSへの移行は割と簡単かつ低コストでできることがわかりました。
料金については以下を参照して下さい。
STS以外にも
のようなものが使えそうでした。
詳しくは以下の記事がわかりやすかったです。
STSとDataprepの利用
歴史的経緯から、弊社の生ログデータには
- すでに使っていない古い要素
- duid（昔のユーザを一意に特定するためのもの）
- tutorial_category（ユーザに入力してもらう学習目的。今は別のものに置き換わっている）
- 不正なデータ
- uid（ユーザを一意に特定するためのID）が含まれていないもの
- timestampの無いもの
などのように不要なデータや不正なデータが混ざっています。そのため、今回データを移行する段階で、データのクレンジングや加工処理を挟むことができれば、その問題も解決できると考えました。
- 例
- すでに使っていない古い要素 → 削除
- 不正なデータ
- uidが含まれていないもの → 空文字列で追加 or 集計対象に含めないなら削除
- timestampがないもの → PartitionからTimestampを擬似的に生成（完全に正確なTimestampとはいえないが限りなく近いものになるはず）
BigQuery OmniやBigQuery Data Transfer Serviceなどを利用するよりも、一旦STSを使ってGCSへデータを移行できれば、DataFlowなどを使えば簡単に加工処理などできるため、そうすることとしました。
最終的に、STSでS3からGCSへ生ログのデータを単純に移行し、GCSからBigQueryのETLをDataprepを使って行うことにしました。
Dataprepを使う理由としては、運用コストと実装コストが低いことにあります。DataprepはGUI上で操作するだけで、DataFlowのジョブを作成できるので、非常に簡単に実装することができました。
実際にやったこと
STSを使ってS3のデータをGCSへ移行する
行動ログはクライアントからS3へ蓄積する仕組みがあり、それは今回変わらないので最新のデータはS3へこれからも吐き出されることになります。
そのため
- 過去の行動ログデータを移行する単発のJob
- S3へデータが書き込まれたらGCSへ同期するJob
の2つが必要でした。
過去の行動ログデータを移行する単発のJobに関しては、数百GBあるデータも20分程後で移行が完了し、めちゃくちゃ高速でした。
S3へデータが書き込まれたらGCSへ同期するJobに関しては、イベントドリブン転送というものがあり、それを利用することでほぼリアルタイムに同期することができるようになります。
Dataprepを使ってGCSからBigQueryへデータを格納する
Jobの作成は以下のようなGUI上でぽちぽちするだけで作成することができます。DatasetのPathには日付や正規表現を利用することができるので、GCS上のファイルパスやファイル名を工夫すれば、特定のデータだけを抽出することが簡単にできます。
また、Plansというものがあり定期実行することもできます。こちらもGUI上で設定でき、Jobの実行状況（実行中、成功、失敗の3種類）ごとにSlack通知などすることもできます。
運用
今回作成したもので、BigQueryで生ログデータを集計することができるようになりました。中間テーブルの作成は、この生ログデータを元にDataformを使って中間テーブルの作成をしています。数十分程度かかっていた分析が数秒で終わるようになったりと現時点でかなりの恩恵を得られています。
Dataformの活用に関しては、分析チームがまとめてくれると思いますので乞うご期待ください。
まとめと今後の展望
今回はSTSとDataprepを使って、S3にある行動ログをAthenaで集計していたものを、BigQueryで集計できるようにするところまでをノーコードで実現する方法について紹介しました。
分析基盤に十分にエンジニアリソースをかけることができない弊社でも簡単に実現することができたので、分析にお困りの方は検討してみると良いかもしれません。
今後の展望としては以下のようなことに取り組んでいきたいと思っています。
- STSを使わずに直接クライアントから行動ログをGCSへ格納する
- データの民主化が実現する一方でBigQueryへの課金額が心配なため、制限を設けるなどの対策をする
- サービスに利用しているデータストアと行動ログとを結合して分析できるようにする
おわりに
ここまで長くなりましたが、AthenaからBigQueryへの移行をかなり低コストに実現できたと思っています。今回の取り組みで、分析基盤を整えることで分析チームの日々の業務改善にも繋げられたので、同じ課題を抱えている方の参考になれば幸いです。
現在、mikanのバックエンドチームは私含め2名ということで、バックエンドエンジニアを絶賛募集中です。
今回は分析基盤の紹介になりましたが、インフラからAPIの運用など日頃から幅広い責務を担っています。
まだまだ、これから改善が必要なところがたくさんありますが、技術の意思決定にもガッツリはいっていけるフェーズかと思いますので、興味のある方は、まずはお気軽に一回お話しさせていただければと思います！
