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

Slide 1

Slide 1 text

ソーシャルゲームの膨⼤なゲームログを扱うCygamesの Amazon Redshift活⽤事例 1/全ページ株式会社Cygames データ分析基盤チーム藤⽥晋哉

Slide 2

Slide 2 text

⾃⼰紹介藤⽥晋哉 • データ分析基盤チームエンジニア • キャリア – カジュアルゲームのサーバーサイド開発/運⽤ ↓ – iOS/Androidプラットフォームの検証 ↓ – データ分析基盤の開発/運⽤ 2/32

Slide 3

Slide 3 text

アジェンダ • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 3/32

Slide 4

Slide 4 text

Cygamesについて 4/32 ビジョン : 最⾼のコンテンツを作る会社運営ゲームタイトル • グランブルーファンタジー • プリンセスコネクト︕Re:Dive • WORLD FLIPPER • Shadowverse • 神撃のバハムート and more !

Slide 5

Slide 5 text

アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 5/32

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Cygamesの分析基盤について 7/32 DataSource ゲームDB (MySQL) EC2上のアクセスログ DataLake S3 Redshift 分析業務内製BIツール不具合調査 DWH 毎⽇のログデータやdumpデータ

Slide 8

Slide 8 text

Cygamesの分析基盤について • 課題は⾊々あったがそのうちの⼀つがデータの容量の問題 • DataLakeとして使っていたS3の総容量は2.4PB – ゲームのステータス情報などを管理する関係で、いわゆる「横に⻑い」レコードが多い – ゲーム内のイベントなどで周回数を重ねることで報酬がもらえるものが多いので、レコード数も増えやすい – 期間も⼀番⻑く運⽤してるタイトルだと9年分くらい – S3のコストを抑えるために、ある程度昔のデータは⼀括でDeep Archive化するなどして今は1.5PBほどに 8/32

Slide 9

Slide 9 text

Cygamesの分析基盤について • そのためRedshiftに⼊れるデータはなるべく直近のものに絞って、古くなったレコードを削除して容量を空ける作業をしていた – ⼤体毎⽉どれかのクラスターが80%近くなっていたので毎⽉どのテーブルは消していいかなど分析担当者と調整していた • 容量が⼤きくなりやすいテーブルはRedshift Spectrumを使うことにして、 Redshiftのディスク容量を節約することにした 9/32

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

Cygamesの分析基盤について • S3にあるデータがSpectrum利⽤しづらい形だった – CSV形式で取得していたのであまり参照効率がよくない… – path/ テーブル名 / ⽇付ではなく、 path / ⽇付 / テーブル名の構造だったので扱いづらいデータ規模も⼤きく運⽤期間も⻑いため、⼀括で構造変えるのも少し怖い… • なので、Spectrumで扱いたいテーブルは元データは残したまま、前処理としてEC2上でバッチ処理させてSpectrumで扱いやすい形式で再配置することにした 11/32

Slide 12

Slide 12 text

Cygamesの分析基盤について 12/32 • Spectrum⽤データへの変換⽇次のdumpデータ (path/20200501/tablename) 前処理で csv→parquet Parquetに変換したデータ (path/tablename/date = 20200501/) Spectrumで参照 Pythonのパッケージで変換

Slide 13

Slide 13 text

S3 Redshift Spectrum⽤中間データ Redshift Spectrum 変換ゲームDB (MySQL) EC2上のアクセスログ毎⽇のログデータやdumpデータ Cygamesの分析基盤について 13/32 DataSource DataLake 分析業務内製BIツール不具合調査 DWH

Slide 14

Slide 14 text

アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 14/32

Slide 15

Slide 15 text

DataLakeExportの概要 • RedshiftのUNLOADコマンドがParquet形式に対応︕ クエリで指定したデータをParquet形式でS3に出⼒できるようになった︕ • これまでSpectrumなどデータレイクから参照するためには、 – UNLOADでCSV出⼒して利⽤する (圧縮効率がParquetに劣る) – AWS Glue などを⽤いてCSV → Parquetに変換してあげるなどが必要だったが、ParquetでUNLOADすることによって簡単に前処理が⾏えるようになった 15/32

Slide 16

Slide 16 text

DataLakeExportを活⽤してみた • Spectrumのために⾏なっている前処理は CSV→Parquetの変換や、S3内への再配置をしているので、⾃前の処理でなくてもUnloadだけでいけるのでは︖ • というわけで乗り換えてみた 16/32

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

DataLakeExport導⼊版 18/32 DataSource DataLake S3 Redshift 分析業務内製BIツール不具合調査 DWH Spectrum⽤中間データ Redshift Spectrum ゲームDB (MySQL) EC2上のアクセスログ毎⽇のログデータやdumpデータ

Slide 19

Slide 19 text

DataLakeExportを活⽤してみた • Spectrum⽤データ作成完了までが圧倒的に早くなった! – Redshiftのリソース使えるし当然だけど… 19/32 0 100 200 300 400 500 tableD tableC tableB tableA 変更後変更前 (単位 : 分) (1⽇分のデータの COPYにかかる時間含む)

Slide 20

Slide 20 text

DataLakeExportを活⽤してみた 20/32 • S3に配置する際の圧縮後のサイズはpythonのパッケージで処理するよりも⼤きくなった（=圧縮効率は落ちた) – 変更前はgzip圧縮、変更後はsnappy – といってもS3上のサイズなのでそれほど気にならない 0 200 400 600 800 1000 tableD tableC tableB tableA 変更後変更前 (単位 : MB)

Slide 21

Slide 21 text

DataLakeExportを活⽤してみた(まとめ) 21/32 • Redshiftのインスタンスタイプ拡張を検討する前に、 Spectrum利⽤でどうにかできないか考えてみる – これから分析基盤を構築する場合は、Spectrum利⽤がいつでもできるような DataLake設計にしておくことを強くお勧めします… • SQLで表現できるような前処理が存在する場合はUNLOADクエリで代替できないか考えてみる – EC2で処理しているならRedshiftがビジーな時間帯でなければ処理時間は早くなるケースが多そう – AWS Glueで処理している場合もRedshiftインスタンスが既にあるなら Glueの分の費⽤が抑えられそう

Slide 22

Slide 22 text

アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 22/32

Slide 23

Slide 23 text

RA3の概要 23/32 • Spectrumである程度容量を節約できてもやっぱりまだまだ容量との闘いが続くタイトルも多い • RA3タイプのインスタンスが発表された︕ どちらも64TB/node なのでds2から移⾏するとストレージが⼀気に増やせそう︕

Slide 24

Slide 24 text

RA3移⾏時に注意したこと 24/32 • RA3に移⾏しても普段の業務に⽀障が出ないかを検証する⽉額のコストは維持したいので、既存の構成と同じ費⽤になるような構成をRA3で考える • 現⾏のクラスタからスナップショットを取得してリストアして検証⽤クラスタを作成して以下を検証する – 分析担当者に普段業務で扱うようなクエリをテスト的に投げてもらって、処理速度が遅くなってないか – 毎⽇のS3からのロード処理が遅くなってないか • タイトル毎に構成も変わるので個別に検証していく

Slide 25

Slide 25 text

RA3移⾏時に注意したこと 25/32 あるタイトルAの場合 • 現⾏ : ds2.xlarge * 8nodes 移⾏後 : ra3.4xlarge * 2nodes に移⾏するパターン • コスト – 約13%ほどRA3の⽅が安くなる (マネージドストレージの費⽤込) • 分析に使うクエリの処理時間 – 全体的に早くなった︕ が、物によっては遅くなった︖ • ロード処理にかかる時間 – かなり遅くなった… – おそらくnode数が減ったことで並列実⾏数が減ったのが原因︖

Slide 26

Slide 26 text

RA3移⾏時に注意したこと 26/32 あるタイトルBの場合 • 現⾏ : ds2.8xlarge * 6nodes 移⾏後 : ra3.4xlarge * 12nodes に移⾏するパターン • コスト – 約13%ほどRA3の⽅が安くなる (マネージドストレージの費⽤込) • 分析に使うクエリの処理時間 – 全体的に早くなった︕ • ロード処理にかかる時間 – 今度はかなり早くなった︕︕︕ – 前のパターンの逆でnode数が増えたから︖

Slide 27

Slide 27 text

RA3移⾏時に注意したこと 27/32 • クエリ早くなる・ロード処理も早くなる・費⽤は少し下がるタイトルBのパターンに限ればいいことづくめなので移⾏しよう • 検証時同様、スナップショットからのリストアでRA3へ移⾏する移⾏までの流れ – 適当なエンドポイント名でRA3のインスタンスを⽴ち上げる – 移⾏当⽇にスナップショットを作成 (1.5hくらい) – 新規RA3インスタンスに取得したスナップショットをリストア (1hくらい) – エンドポイントを既存のクラスターと新規RA3インスタンスで⼊れ替える (15minくらい)

Slide 28

Slide 28 text

移⾏した結果 28/32 • 移⾏前 – 2~3ヶ⽉くらいおきに特定のイベントが開催されるたびに Redshiftの容量が圧迫されるためその度に容量削減作業を⾏なっていた

Slide 29

Slide 29 text

移⾏した結果 29/32 • 移⾏後 – 容量に⼀気に余裕ができた︕︕︕ – ロードにかかる時間や分析業務のクエリの処理時間も概ね事前の検証通りだった

Slide 30

Slide 30 text

移⾏した結果 30/32 • RA3に移⾏できたのはまだ最も⼤きい規模な1クラスターのみ徐々に他のクラスターもRA3に移⾏していきたい – AQUA(Advanced Query Accelerator) がGAになれば、他のクラスターにも適⽤しやすくなるかも • 構成によってはロード処理や⼀部クエリの処理時間が増えてしまい、業務に⽀障が出るため、現状のままでは少し難しそうだった… – 柔軟な構成が取れるように ra3.xlargeなどが出てくれたら嬉しい

Slide 31

Slide 31 text

RA3タイプのインスタンスに移⾏してみた(まとめ) 31/32 • Redshiftのストレージ容量が圧迫されて困っている場合には RA3に移⾏することで余裕ができる • nodeごとのスペックは従来のインスタンスよりも⾼いが、場合によってはロードやクエリの処理時間は落ちるので事前検証を推奨 – Cygames環境だと構成によっては処理時間が伸びてしまうケースもあった – 今後ra3.xlarge等のもう少し⼩回りの効くタイプが登場してくれることに期待

Slide 32

Slide 32 text

まとめ • ゲーム運営の扱うログデータは縦にも横にも⻑いのでRedshiftのストレージ容量が圧迫されることが多い – Spectrum利⽤することで多少余裕ができた • Spectrumのパーティションデータ作成など、前処理を⾏なっている場合は UnloadクエリのParquet出⼒で代替できる – カラムナーDBが苦⼿な処理でなければ処理時間は早くなることが多いはず • RA３インスタンスに移⾏すれば更にストレージに余裕ができる – 従来のものより⾼スペックなnodeだが、事前に検証は必要 32/32