ソーシャルゲームの膨⼤なゲームログを扱うCygamesの Amazon Redshift 活用事例

2020/08/06 Amazon Redshift事例祭り(活用編)

Transcript

1. ソーシャルゲームの 膨⼤なゲームログを扱うCygamesの Amazon Redshift活⽤事例 1/全ページ 株式会社Cygames データ分析基盤チーム 藤⽥ 晋哉
2. ⾃⼰紹介 藤⽥ 晋哉 • データ分析基盤チーム エンジニア • キャリア – カジュアルゲームのサーバーサイド開発/運⽤ ↓ – iOS/Androidプラットフォームの検証 ↓ – データ分析基盤の開発/運⽤ 2/32
3. アジェンダ • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 3/32
4. Cygamesについて 4/32 ビジョン : 最⾼のコンテンツを作る会社 運営ゲームタイトル • グランブルーファンタジー • プリンセスコネクト︕Re:Dive • WORLD FLIPPER • Shadowverse • 神撃のバハムート and more !
5. アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 5/32
6. Cygamesの分析基盤について • Amazon Redshiftを採⽤する前はNetezza1をDWHとして利⽤ – ゲームDBから直接Netezzaにロードする構成 – DataLakeなどはなし︕ – 容量削減などでNetezzaから過去のデータを消すと復元も⼤変だった… • タイトル毎に徐々にRedshiftへ移⾏していき、 2018年4⽉頃にRedshiftへ完全に移⾏完了︕ – 主にds2.xlargeでタイトル毎に2~16nodesで15クラスターで運⽤ – ⼤体1ゲーム1クラスター + 内製BIツール⽤などのクラスター 6/32 1. IBM PureData System for Analytics
7. Cygamesの分析基盤について 7/32 DataSource ゲームDB (MySQL) EC2上の アクセスログ DataLake S3 Redshift 分析業務 内製BIツール 不具合調査 DWH 毎⽇のログデータ やdumpデータ
8. Cygamesの分析基盤について • 課題は⾊々あったがそのうちの⼀つがデータの容量の問題 • DataLakeとして使っていたS3の総容量は2.4PB – ゲームのステータス情報などを管理する関係で、いわゆる「横に⻑い」レコードが多い – ゲーム内のイベントなどで周回数を重ねることで報酬がもらえるものが多いので、レコード数も 増えやすい – 期間も⼀番⻑く運⽤してるタイトルだと9年分くらい – S3のコストを抑えるために、ある程度昔のデータは⼀括でDeep Archive化するなどして 今は1.5PBほどに 8/32
9. Cygamesの分析基盤について • そのためRedshiftに⼊れるデータはなるべく直近のものに絞って、 古くなったレコードを削除して容量を空ける作業をしていた – ⼤体毎⽉どれかのクラスターが80%近くなっていたので毎⽉どのテーブルは消していいかなど 分析担当者と調整していた • 容量が⼤きくなりやすいテーブルはRedshift Spectrumを使うことにして、 Redshiftのディスク容量を節約することにした 9/32
10. Cygamesの分析基盤について • ユーザーの成⻑度合いなどを分析するために作成する時系列のテーブルを Redshift上で持っていたので特に容量圧迫していた • ⽇付でパーティションにすればSpectrumで扱いやすい形のはず︕ – と思ったがすんなりとは⾏かなかった… 10/32 name level A 1 B 5 2020-05-01のdump name level A 3 B 10 2020-05-02のdump name level date A 1 2020-05-01 B 5 2020-05-01 A 3 2020-05-02 B 10 2020-05-02 A 5 2020-05-03
11. Cygamesの分析基盤について • S3にあるデータがSpectrum利⽤しづらい形だった – CSV形式で取得していたのであまり参照効率がよくない… – path/ テーブル名 / ⽇付 ではなく、 path / ⽇付 / テーブル名 の構造だったので扱いづらい データ規模も⼤きく運⽤期間も⻑いため、⼀括で構造変えるのも少し怖い… • なので、Spectrumで扱いたいテーブルは元データは残したまま、 前処理としてEC2上でバッチ処理させてSpectrumで扱いやすい形式で 再配置することにした 11/32
12. Cygamesの分析基盤について 12/32 • Spectrum⽤データへの変換 ⽇次のdumpデータ (path/20200501/tablename) 前処理で csv→parquet Parquetに変換したデータ (path/tablename/date = 20200501/) Spectrumで参照 Pythonのパッケージで変換
13. S3 Redshift Spectrum⽤ 中間データ Redshift Spectrum 変換 ゲームDB (MySQL) EC2上の アクセスログ 毎⽇のログデータ やdumpデータ Cygamesの分析基盤について 13/32 DataSource DataLake 分析業務 内製BIツール 不具合調査 DWH
14. アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 14/32
15. DataLakeExportの概要 • RedshiftのUNLOADコマンドがParquet形式に対応︕ クエリで指定したデータをParquet形式でS3に出⼒できるようになった︕ • これまでSpectrumなどデータレイクから参照するためには、 – UNLOADでCSV出⼒して利⽤する (圧縮効率がParquetに劣る) – AWS Glue などを⽤いてCSV → Parquetに変換してあげる などが必要だったが、ParquetでUNLOADすることによって簡単に 前処理が⾏えるようになった 15/32
16. DataLakeExportを活⽤してみた • Spectrumのために⾏なっている前処理は CSV→Parquetの変換や、S3内への再配置をしているので、 ⾃前の処理でなくてもUnloadだけでいけるのでは︖ • というわけで乗り換えてみた 16/32
17. DataLakeExportを活⽤してみた 17/32 • Spectrum⽤データへの変換 ⽇次のdumpデータ (path/20200501/tablename) Parquetに変換したデータ (path/tablename/date = 20200501/) Spectrumで参照 Redshiftにcopy unload ('select * from tablename') to 's3://path/tablename/ʼ PARQUET PARTITION BY date
18. DataLakeExport導⼊版 18/32 DataSource DataLake S3 Redshift 分析業務 内製BIツール 不具合調査 DWH Spectrum⽤ 中間データ Redshift Spectrum ゲームDB (MySQL) EC2上の アクセスログ 毎⽇のログデータ やdumpデータ
19. DataLakeExportを活⽤してみた • Spectrum⽤データ作成完了までが圧倒的に早くなった! – Redshiftのリソース使えるし当然だけど… 19/32 0 100 200 300 400 500 tableD tableC tableB tableA 変更後 変更前 (単位 : 分) (1⽇分のデータの COPYにかかる時間含む)
20. DataLakeExportを活⽤してみた 20/32 • S3に配置する際の圧縮後のサイズはpythonのパッケージで 処理するよりも⼤きくなった（=圧縮効率は落ちた) – 変更前はgzip圧縮、変更後はsnappy – といってもS3上のサイズなのでそれほど気にならない 0 200 400 600 800 1000 tableD tableC tableB tableA 変更後 変更前 (単位 : MB)
21. DataLakeExportを活⽤してみた(まとめ) 21/32 • Redshiftのインスタンスタイプ拡張を検討する前に、 Spectrum利⽤でどうにかできないか考えてみる – これから分析基盤を構築する場合は、Spectrum利⽤がいつでもできるような DataLake設計にしておくことを強くお勧めします… • SQLで表現できるような前処理が存在する場合はUNLOADクエリで 代替できないか考えてみる – EC2で処理しているならRedshiftがビジーな時間帯でなければ処理時間は 早くなるケースが多そう – AWS Glueで処理している場合もRedshiftインスタンスが既にあるなら Glueの分の費⽤が抑えられそう
22. アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 22/32
23. RA3の概要 23/32 • Spectrumである程度容量を節約できてもやっぱりまだまだ 容量との闘いが続くタイトルも多い • RA3タイプのインスタンスが発表された︕ どちらも64TB/node なのでds2から移⾏するとストレージが ⼀気に増やせそう︕
24. RA3移⾏時に注意したこと 24/32 • RA3に移⾏しても普段の業務に⽀障が出ないかを検証する ⽉額のコストは維持したいので、既存の構成と同じ費⽤になるような 構成をRA3で考える • 現⾏のクラスタからスナップショットを取得してリストアして 検証⽤クラスタを作成して以下を検証する – 分析担当者に普段業務で扱うようなクエリをテスト的に投げてもらって、 処理速度が遅くなってないか – 毎⽇のS3からのロード処理が遅くなってないか • タイトル毎に構成も変わるので個別に検証していく
25. RA3移⾏時に注意したこと 25/32 あるタイトルAの場合 • 現⾏ : ds2.xlarge * 8nodes 移⾏後 : ra3.4xlarge * 2nodes に移⾏するパターン • コスト – 約13%ほどRA3の⽅が安くなる (マネージドストレージの費⽤込) • 分析に使うクエリの処理時間 – 全体的に早くなった︕ が、物によっては遅くなった︖ • ロード処理にかかる時間 – かなり遅くなった… – おそらくnode数が減ったことで並列実⾏数が減ったのが原因︖
26. RA3移⾏時に注意したこと 26/32 あるタイトルBの場合 • 現⾏ : ds2.8xlarge * 6nodes 移⾏後 : ra3.4xlarge * 12nodes に移⾏するパターン • コスト – 約13%ほどRA3の⽅が安くなる (マネージドストレージの費⽤込) • 分析に使うクエリの処理時間 – 全体的に早くなった︕ • ロード処理にかかる時間 – 今度はかなり早くなった︕︕︕ – 前のパターンの逆でnode数が増えたから︖
27. RA3移⾏時に注意したこと 27/32 • クエリ早くなる・ロード処理も早くなる・費⽤は少し下がる タイトルBのパターンに限ればいいことづくめなので移⾏しよう • 検証時同様、スナップショットからのリストアでRA3へ移⾏する 移⾏までの流れ – 適当なエンドポイント名でRA3のインスタンスを⽴ち上げる – 移⾏当⽇にスナップショットを作成 (1.5hくらい) – 新規RA3インスタンスに取得したスナップショットをリストア (1hくらい) – エンドポイントを既存のクラスターと新規RA3インスタンスで⼊れ替える (15minくらい)
28. 移⾏した結果 28/32 • 移⾏前 – 2~3ヶ⽉くらいおきに特定のイベントが開催されるたびに Redshiftの容量が圧迫されるためその度に容量削減作業を⾏なっていた
29. 移⾏した結果 29/32 • 移⾏後 – 容量に⼀気に余裕ができた︕︕︕ – ロードにかかる時間や分析業務のクエリの処理時間も概ね事前の検証通りだった
30. 移⾏した結果 30/32 • RA3に移⾏できたのはまだ最も⼤きい規模な1クラスターのみ 徐々に他のクラスターもRA3に移⾏していきたい – AQUA(Advanced Query Accelerator) がGAになれば、他のクラスターにも適⽤しやすくなるかも • 構成によってはロード処理や⼀部クエリの処理時間が増えてしまい、 業務に⽀障が出るため、現状のままでは少し難しそうだった… – 柔軟な構成が取れるように ra3.xlargeなどが出てくれたら嬉しい
31. RA3タイプのインスタンスに移⾏してみた(まとめ) 31/32 • Redshiftのストレージ容量が圧迫されて困っている場合には RA3に移⾏することで余裕ができる • nodeごとのスペックは従来のインスタンスよりも⾼いが、 場合によってはロードやクエリの処理時間は落ちるので 事前検証を推奨 – Cygames環境だと構成によっては処理時間が伸びてしまうケースもあった – 今後ra3.xlarge等のもう少し⼩回りの効くタイプが登場してくれることに期待
32. まとめ • ゲーム運営の扱うログデータは縦にも横にも⻑いのでRedshiftの ストレージ容量が圧迫されることが多い – Spectrum利⽤することで多少余裕ができた • Spectrumのパーティションデータ作成など、前処理を⾏なっている場合は UnloadクエリのParquet出⼒で代替できる – カラムナーDBが苦⼿な処理でなければ処理時間は早くなることが多いはず • RA３インスタンスに移⾏すれば更にストレージに余裕ができる – 従来のものより⾼スペックなnodeだが、事前に検証は必要 32/32