『FINAL FANTASY VII EVER CRISIS』の運用を支えるデータ分析基盤【CAGC2024】※2025年3月6日までの公開

アプリボットでは、複数のゲームタイトルにおけるKPI集計や、機械学習を用いた行動分析など、用途に応じたデータを収集・活用し、データドリブンで意思決定を行うための分析基盤を構築しています。
2019年よりAWS Athenaを用いた分析環境を構築し運用してきましたが、コストの増加やクエリ速度の問題などの課題も見えてきたため、より高速で低コストな分析環境の実現を目指しSnowflakeを用いた構成に変更を行いました。
Snowflake導入にあたってどの程度の効果が得られたのか、実際に運用を開始してみての所感も交え『FINAL FANTASY VII EVER CRISIS』の事例を元にお届けします。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=Rs7UFP9g

© SQUARE ENIX Powered by Applibot, Inc.　CHARACTER DESIGN: TETSUYA NOMURA / CHARACTER ILLUSTRATION: LISA FUJISE
Copyright © CyberAgent, Inc.

Transcript

1. 『FINAL FANTASY VII EVER CRISIS』を 　支えるデータ分析基盤 1 データ分析基盤チーム 三島 裕貴 データエンジニア 伊藤 直人 サーバーサイドエンジニア
2. 2 １. アプリボットのデータ分析 ２. 分析基盤「DIVE」 ３. Snowflakeの導入 ４. Snowflakeを使用してみて ５. まとめ 本日お話する内容はこちら
3. １. アプリボットのデータ分析 3
4. KPIを追い、ユーザーの行動を分析することで 施策を改善する ・独自のKPI定義 ・分析用ログ設計 ・BIツールでの可視化 ・機械学習を用いた分析 等 スマホゲームにおける分析の目的 4 アプリボットのデータ分析 現在運用中のタイトル
5. プロダクトチーム、データマイニング、データ分析基盤チーム 各チームが連携して分析を実施からプロダクト反映までを行う データ分析の体制について 5 データ分析基盤 チーム 行動ログの取得、 集計を担当 ・分析基盤の開発・運用 ・ KPI定義・ログ設計 プロダクトチーム プロダクトの開発、 運用を行う ・プロダクトの開発 ・施策の実施 データマイニング チーム データを活用して 分析 ・収集したデータを活用 ・運用改善の提案 2名 2名 アプリボットのデータ分析
6. 収集データについて 6 ・ユーザー行動ログ 　・社内KPIの定義に合わせて独自に設計 　・内容、出力タイミングを定めて実装 　・分析用途で使用 ・DB更新ログ 　・不足がないよう全てのDB更新履歴を取得 　・特定日時のユーザ状態を調査するために使用 アプリボットのデータ分析
7. アプリボットのデータ分析 7 BIツールについて ・アプリボットではRedashを使用 ・分析結果の可視化 ・施策や機能に合わせて60以上のダッシュボードを管理 ・OSSのため気軽に使用でき、カスタマイズも可能
8. ２. 分析基盤「DIVE」 8
9. DIVEとは ・大規模なデータを用いた分析のため 　に開発を行い、2019年に完成 ・S3にデータを集積しAthenaで参照 分析基盤「DIVE」 9 DIVE：Data Infrastructure Value Elevation
10. 運用を経ていくつかの課題がネックになっていた 10 ・コストの課題 　・AthenaはS3のデータを直接参照するため、Athenaの使用料とは別に 　　S3へのリクエストにコストがかかる ・速度の課題 　・パフォーマンスの不足、かつ調整ができないため、 　　調査対応に時間がかかる 　・機械学習を用いた大規模な処理がなかなか終了しない ・運用の課題 　・適切なパーティション管理やファイルの圧縮が必要 　・ログ追加、集計の際の各チームとの擦り合わせ 分析基盤「DIVE」
11. 課題解決のため、 新・DIVE を開発することに 11 Redshiftは使ったことあるけど コストが高くなりそうだなぁ〜 Redshift Serverless は プレビューだし...（当時） BigqueryはAWSで開発してる以上 噛み合わせが悪いよな... 分析基盤「DIVE」
12. そこで選ばれたのが、Snowflake でした 12 ・コストの課題 　⇨Snowflakeにデータを投入した後は、 　　ウェアハウスの稼働時間による従量課金制なので無駄なコストがかからない ・速度の課題 　⇨ウェアハウスの切り替えで高速なデータ抽出 ・運用の課題 　⇨自動で 　　・パーティショニング 　　・クエリプルーニング 　　・列指向に編成 　　を行ってくれるので手間要らず 分析基盤「DIVE」
13. FINAL FANTASY VII EVER CRISIS リリースに向けての目標 13 １. KPIのリアルタイムな可視化 ⇨ 売上、DAUなどは３分に1度更新できるように ２. 迅速な分析、調査が行えるパフォーマンスの実現 ３. 旧 DIVE（Athena使用）のときよりも安価に 分析基盤「DIVE」
14. Snowflakeを導入した新たな「DIVE」の構成がこちら 14
15. ポイント１. 転送効率を上げるための工夫 即時取り込みログ（Stream1） ・Firehose バッファ設定 ┗ バッファサイズ：128MiB ┗ バッファ間隔：60秒 ・Snowpipeを用いた即時転送 ・対象データ ┗ 行動ログの内、ログイン情報、 　 課金情報などKPIに関わるもの 15 新・分析基盤「DIVE」
16. ポイント１. 転送効率を上げるための工夫 定期取り込みログ（Stream2） ・Firehose バッファ設定 ┗ バッファサイズ：128MiB ┗ バッファ間隔：300秒 ・ServerlessTaskを用いた定期転送 ┗ 実行スケジュールを指定可能 ┗ 実行間隔：300秒 ・対象データ ┗ 即時取り込み以外の全てのデータ 16 新・分析基盤「DIVE」
17. ポイント２. 運用フローの整備 ・ログ定義をゲームサーバと同期 ・テーブル定義の追加、修正を反映 ・Snowpipe, ServerlessTaskの作成 これらをGitHubで管理、自動化することで 運用コストを削減 この後もう少し深掘って説明していきます 17 新・分析基盤「DIVE」
18. ３. Snowflakeの導入 18
19. Snowflake 導入 19 DIVE への導入にあたって ・ログファイルを DWH にロードする 　・アプリケーションから kinesis, Lambda などを経由して S3 に配置されている 　　ログファイルを Snowflake の DWH に定期的にロードする必要がある。 ・構築にかかる作業を旧 DIVE とほぼ同等のコストで実現する 　・ログテーブル数がかなり多いこともあり、DIVE では Athena で参照する Glue の 　　テーブル定義を独自ツールにより YAML から自動で生成している。 　　移行にあたって旧 DIVE と同様な構築コストで担保したい。
20. ３.1. Snowflake へのデータロード 20
21. Snowflake へのデータロード 21 データロード手法 ・COPY INTO 句 　・ステージングされたファイルから既存のテーブルにデータをロードする 　　・ステージには外部ステージ（S3やGCSなど）も存在する 　・ログファイルなどからデータをロードすること可能 COPY INTO mytable FROM s3://mybucket/data/files STORAGE_INTEGRATION = myint FILE_FORMAT = (FORMAT_NAME = my_json_format);
22. Snowflake へのデータロード 22 継続的データロード ・Snowpipe 　・クラウドメッセージングもしくは、Snowpipe REST 呼び出しによって継続的かつ 　　バッチ実行と比較し、リアルタイム性の高いデータロードを行える ・Task 　・単一のSQLや、ストアドプロシージャなど 任意の処理の実行が可能 　・スケジューリング設定も可能 　・まとめてコピーの実行が可能なためWHのコストを下げることが期待できる場面がある Snowpipe Task
23. Snowflake へのデータロード 23 S3を使用した際の Snowpipe の構築 1. S3のファイル配置イベントのSNSトピックを作成 2. 自身のAWSアカウントへのアクセス権の付与 3. 外部ステージ（S3）を Snowflake に作成 4. Snowpipe を構築 CREATE PIPE mypipe_s3 AUTO_INGEST = true AWS_SNS_TOPIC = 'arn:aws:sns:us-west-2:001234567890:s3_mybucket' AS COPY INTO snowpipe_db.public.mytable FROM @snowpipe_db.public.mystage FILE_FORMAT = (type = 'JSON'); Snowpipe 構築 SQL Amazon S3用Snowpipeの自動化
24. Snowflake へのデータロード 24 定期 Task でのデータロード CREATE TASK mytask SCHEDULE = '60 MINUTE' TIMESTAMP_INPUT_FORMAT = 'YYYY-MM-DD HH24' AS COPY INTO snowpipe_db.public.mytable FROM @snowpipe_db.public.mystage FILE_FORMAT = (type = 'JSON'); S3を使用した場合のデータロード
25. Snowflake へのデータロード 25 データロード手法の決定 ・ユーザー行動ログ 　⇨ 分析業務でリアルタイム性を高く要求する 　　 ため Snowpipe を採用 ・DB更新ログ 　⇨ 行動ログと比較してリアルタイム性が 　　 必要なかったため、コストメリットを取り 　　 Task を採用
26. ３.2. 構築の簡略化 26
27. 構築の簡略化 27 Athena（旧 DIVE）のテーブル構築 1. 独自ツールでパース可能な形式で yaml ファイルに記述する 2. 独自ツールを使用して aws-sdk により Glue に反映する この二つの手順しかなくシンプルだった ⇨ Snowflake に移行する場合も、同等程度の手順に収めたい definitions: sample: type: object description: サンプル properties: action_datetime: type: string format: date-time athena_type: timestamp description: ログ出力日時 user_id: type: integer format: int64 athena_type: bigint description: ユーザID yaml 定義の例
28. 構築の簡略化 28 Snowflake での簡略化の方針 ・Snowflake のリソース構築の独自ツールを作成 　・テーブル定義のみではなく、Snowpipe や Task の定義など必要なリソースを 　　全て作成可能なように 　・独自ツールは、今までと同様に YAML でテーブル定義する
29. 構築の簡略化 29 独自ツールの設計 ・YAML から Snowflake のリソースを構築するSQLを自動生成するツールに 　・Snowflake はほぼ全てのリソースが SQL にて操作可能 　　・テーブルの作成、変更や、Snowpipe, Task の作成、変更などももちろん可能 ・生成した SQL は golang-migrate にて Snowflake に反映 　・テーブルの変更などは、ALTER 文などが必要なため反映順序などが重要だった 　・golang-migrate は snowflake driver も対応している 　・golang-migrate を使用するために、独自ツールはマイグレーションファイルを生成
30. 構築の簡略化 30 ユーザー行動ログを定義した場合の生成例 definitions: schema_log: description: サンプル snowflake_table_type: schema version: 1 properties: uuid: snowflake_type: string description: UUID user_id: snowflake_type: bigint description: ユーザID action_datetime: snowflake_type: timestamp description: ログ出力日時 CREATE TABLE schema_log( 　action_datetime TIMESTAMP, 　user_id BIGINT, 　uuid STRING ); CREATE PIPE schema_log_pipe_v1 auto_ingest=TRUE ERROR_INTEGRATION = "${設定値}" aws_sns_topic = "${設定値}"" AS COPY INTO schema_log( action_datetime, user_id, uuid )　FROM ( SELECT TO_TIMESTAMP($1:action_datetime), $1:user_id, $1:uuid FROM @stage/schema_log/ ) PATTERN = ".*[-]v1$" FILE_FORMAT = (TYPE = 'JSON') on_error = continue; 10001_gen.up.sql 10001.yaml
31. 構築の簡略化 31 フロー
32. Athena（旧 DIVE）のテーブル構築 32 Snowflake（新 DIVE）のテーブル構築 1. 独自ツールでパース可能な形式で yaml ファイルに記述する 2. 独自ツールを使用し SQL を生成 3. golang-migrate により SQL を反映 1. 独自ツールでパース可能な形式で yaml ファイルに記述する 2. 独自ツールを使用して aws-sdk に より Glue に反映する 手順は一つ増えたものの2→3の間には手作業は必要なく 自動で実行可能なためほぼ同等の手順で実現することが可能に 構築の簡略化
33. Snowflake 導入 33 まとめ ・Snowpipe, Task を使用して、定期的にログを DWH にロードすることが可能になった ・Snowpipe, Task を要件に合わせ選定することで、コストを下げ導入した ・YAML ベースの独自ツールを作成することで、Snowflake 上のリソースの構築を簡略化 　できた
34. ４. Snowflakeを使用してみて 34
35. FINAL FANTASY VII EVER CRISIS リリース後 当初の目標を達成できたか？ 35 １. KPIのリアルタイムな可視化 ⇨ Snowpipeを用いての即時取り込みで毎分更新可能 ２. 迅速な調査 / 分析を行えるパフォーマンスの実現 ⇨ 用途毎にウェアハウスを管理、調整することで 　 ストレスフリーなデータ活用 ３. 旧 DIVE（Athena使用）のときよりも安価に ⇨ 後述 Snowflakeを使用してみて
36. Snowflakeを使用してみて 36 ・マイクロパーティショニング ・クエリプルーニング ・列指向に編成 　これらの恩恵がとにかくすごかった ・ウェアハウスの最低設定 x-small で Athena使用時の3倍~5倍 ・機械学習に使用するデータ抽出では small 使用で実行時間が1/10 以下に クエリが高速
37. Snowflakeを使用してみて 37 Snowflakeの導入によって分析が進化 ・用途に応じたウェアハウスを指定することで効率的にデータを抽出 ・決定木、サンキーダイアグラム、相関図等を使用した定常的な分析が可能に
38. Snowflakeを使用してみて 38 コスト削減に成功 ・デフォルトで高速なクエリ処理 ・ウェアハウスの稼働時間による従量課金制 ➡ 一度の起動で1分あたりのクレジットが発生するため、 　 定期実行するデータ抽出や集計はまとめて実行することで効率アップ 過去プロダクトと同等のデータ量になる月で比較 【Athena環境】 過去プロダクト 【Snowflake環境】 FINAL FANTASY VII EVER CRISIS 約25%削減！
39. 39 改善していきたいところ 改善点 現在使用しているスタンダードプランでは、各ウェアハウスが単一クラスタのため、 不特定多数が使用する場合、誰かが流した重いクエリが他者にも影響してしまう 解決策 ・ウェアハウスを複数立てることで負荷を分散 ・ウェアハウスのサイズを上げて実行時間を短縮 ・エンタープライズ版に変更する 　（各ウェアハウスが並列クラスタになる） Snowflakeを使用してみて
40. ５. まとめ 40
41. 41 まとめ FFVII EVER CRISIS では Snowflake の導入でコスト削減とパフォーマンス向上を実現 ⇨ マイクロパーティショニング等を自動で行なってくれるので 　 デフォルトで非常に高速なクエリ実行 ⇨ Snowpipe, ServerlessTask を用途によって使い分けることでコストダウンを図った ⇨ 独自ツールを作成してSnowflake上のリソースの構築を簡略化 ⇨ 収集データのフル活用、より高度な分析にチャレンジすることが可能に
42. ご清聴ありがとうございました！ 42