Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
ソーシャルゲームの膨⼤なゲームログを扱うCygamesの Amazon Redshift 活用事例
Cygames
August 06, 2020
Technology
2
2.4k
ソーシャルゲームの膨⼤なゲームログを扱うCygamesの Amazon Redshift 活用事例
2020/08/06 Amazon Redshift事例祭り(活用編)
Cygames
August 06, 2020
Tweet
Share
More Decks by Cygames
See All by Cygames
ウマ娘 プリティーダービーのコンテ制作事例 ~コンテ制作専任チームの誕生とキャラクターを輝かせるコンテ術~
cygames
0
3.4k
ウマ娘 プリティーダービーの大規模シナリオ制作を効率化するソリューション~社内Webアプリ開発運用事例~
cygames
0
2.1k
ゲーム以外でも最高のコンテンツを!ゲーム会社の作る漫画アプリ『サイコミ』の開発と運用
cygames
0
170
ダイナミックな変更を可能にするCyllista Game Engineのオープンワールド向けプロシージャル背景制作ツールと描画機能
cygames
0
420
社内報とオウンドメディアの運営で得られた効果 ~企業カルチャーの浸透~
cygames
0
150
『プリンセスコネクト!Re:Dive』アニメ撮影におけるテクニカルアーティストの役割 ~最高のアニメRPGを作るための自動化制作事例~
cygames
0
960
AAAタイトル開発と在宅勤務を支えるゲームエンジンエンジニアとテクニカルアーティストの取り組み
cygames
0
3.2k
【メモあり】ダイナミックな変更を可能にするCyllista Game Engineのオープンワールド向けプロシージャル背景制作ツールと描画機能
cygames
0
1.7k
ゲーム制作効率化のためのAIによる画像認識・自然言語処理への取り組み
cygames
3
4.9k
Other Decks in Technology
See All in Technology
EKS AnywhereとIAM Anywhereを組み合わせてみた
regmarmcem
0
430
Goで実装するブランドネットワークとの接続ポイント
pongzu
2
290
漫画で使えそうな背景画像をblenderを使って作ってみた!
nokonoko1203
1
340
Istioを活用したセキュアなマイクロサービスの実現/Secure Microservices with Istio
ido_kara_deru
3
460
hey BOOK
heyinc
26
290k
ECS Fargate+Mackerelにおける監視費用を削減するまでの話
nulabinc
PRO
1
530
プロダクトマネージャーの役割と育成、評価
middleokada
18
12k
今 SLI/SLO の監視をするなら Sloth が良さそうという話
shotakitazawa
1
290
第22回 MLOps 勉強会:みてねのMLOps事情
tonouchi510
1
1.1k
8日で作るオレオレRISC-V CPU
matsud224
1
180
Sysdig Secure/Falcoの活用術! ~Kubernetes基盤の脅威モデリングとランタイムセキュリティの強化~
owlinux1000
0
320
品質特性のすすめ
honamin09
0
180
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
506
37k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
11
4.9k
Building Adaptive Systems
keathley
25
1.2k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
37
3.3k
Creatively Recalculating Your Daily Design Routine
revolveconf
207
10k
What the flash - Photography Introduction
edds
63
10k
How New CSS Is Changing Everything About Graphic Design on the Web
jensimmons
213
11k
Making the Leap to Tech Lead
cromwellryan
113
7.4k
Infographics Made Easy
chrislema
233
17k
Git: the NoSQL Database
bkeepers
PRO
415
59k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
119
28k
Fireside Chat
paigeccino
13
1.4k
Transcript
ソーシャルゲームの 膨⼤なゲームログを扱うCygamesの Amazon Redshift活⽤事例 1/全ページ 株式会社Cygames データ分析基盤チーム 藤⽥ 晋哉
⾃⼰紹介 藤⽥ 晋哉 • データ分析基盤チーム エンジニア • キャリア – カジュアルゲームのサーバーサイド開発/運⽤
↓ – iOS/Androidプラットフォームの検証 ↓ – データ分析基盤の開発/運⽤ 2/32
アジェンダ • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた – DataLakeExportの概要 –
活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 3/32
Cygamesについて 4/32 ビジョン : 最⾼のコンテンツを作る会社 運営ゲームタイトル • グランブルーファンタジー • プリンセスコネクト︕Re:Dive
• WORLD FLIPPER • Shadowverse • 神撃のバハムート and more !
アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた –
DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 5/32
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
Cygamesの分析基盤について 7/32 DataSource ゲームDB (MySQL) EC2上の アクセスログ DataLake S3 Redshift
分析業務 内製BIツール 不具合調査 DWH 毎⽇のログデータ やdumpデータ
Cygamesの分析基盤について • 課題は⾊々あったがそのうちの⼀つがデータの容量の問題 • DataLakeとして使っていたS3の総容量は2.4PB – ゲームのステータス情報などを管理する関係で、いわゆる「横に⻑い」レコードが多い – ゲーム内のイベントなどで周回数を重ねることで報酬がもらえるものが多いので、レコード数も 増えやすい
– 期間も⼀番⻑く運⽤してるタイトルだと9年分くらい – S3のコストを抑えるために、ある程度昔のデータは⼀括でDeep Archive化するなどして 今は1.5PBほどに 8/32
Cygamesの分析基盤について • そのためRedshiftに⼊れるデータはなるべく直近のものに絞って、 古くなったレコードを削除して容量を空ける作業をしていた – ⼤体毎⽉どれかのクラスターが80%近くなっていたので毎⽉どのテーブルは消していいかなど 分析担当者と調整していた • 容量が⼤きくなりやすいテーブルはRedshift Spectrumを使うことにして、
Redshiftのディスク容量を節約することにした 9/32
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
Cygamesの分析基盤について • S3にあるデータがSpectrum利⽤しづらい形だった – CSV形式で取得していたのであまり参照効率がよくない… – path/ テーブル名 / ⽇付
ではなく、 path / ⽇付 / テーブル名 の構造だったので扱いづらい データ規模も⼤きく運⽤期間も⻑いため、⼀括で構造変えるのも少し怖い… • なので、Spectrumで扱いたいテーブルは元データは残したまま、 前処理としてEC2上でバッチ処理させてSpectrumで扱いやすい形式で 再配置することにした 11/32
Cygamesの分析基盤について 12/32 • Spectrum⽤データへの変換 ⽇次のdumpデータ (path/20200501/tablename) 前処理で csv→parquet Parquetに変換したデータ (path/tablename/date
= 20200501/) Spectrumで参照 Pythonのパッケージで変換
S3 Redshift Spectrum⽤ 中間データ Redshift Spectrum 変換 ゲームDB (MySQL) EC2上の
アクセスログ 毎⽇のログデータ やdumpデータ Cygamesの分析基盤について 13/32 DataSource DataLake 分析業務 内製BIツール 不具合調査 DWH
アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた –
DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 14/32
DataLakeExportの概要 • RedshiftのUNLOADコマンドがParquet形式に対応︕ クエリで指定したデータをParquet形式でS3に出⼒できるようになった︕ • これまでSpectrumなどデータレイクから参照するためには、 – UNLOADでCSV出⼒して利⽤する (圧縮効率がParquetに劣る) –
AWS Glue などを⽤いてCSV → Parquetに変換してあげる などが必要だったが、ParquetでUNLOADすることによって簡単に 前処理が⾏えるようになった 15/32
DataLakeExportを活⽤してみた • Spectrumのために⾏なっている前処理は CSV→Parquetの変換や、S3内への再配置をしているので、 ⾃前の処理でなくてもUnloadだけでいけるのでは︖ • というわけで乗り換えてみた 16/32
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
DataLakeExport導⼊版 18/32 DataSource DataLake S3 Redshift 分析業務 内製BIツール 不具合調査 DWH
Spectrum⽤ 中間データ Redshift Spectrum ゲームDB (MySQL) EC2上の アクセスログ 毎⽇のログデータ やdumpデータ
DataLakeExportを活⽤してみた • Spectrum⽤データ作成完了までが圧倒的に早くなった! – Redshiftのリソース使えるし当然だけど… 19/32 0 100 200 300
400 500 tableD tableC tableB tableA 変更後 変更前 (単位 : 分) (1⽇分のデータの COPYにかかる時間含む)
DataLakeExportを活⽤してみた 20/32 • S3に配置する際の圧縮後のサイズはpythonのパッケージで 処理するよりも⼤きくなった(=圧縮効率は落ちた) – 変更前はgzip圧縮、変更後はsnappy – といってもS3上のサイズなのでそれほど気にならない 0
200 400 600 800 1000 tableD tableC tableB tableA 変更後 変更前 (単位 : MB)
DataLakeExportを活⽤してみた(まとめ) 21/32 • Redshiftのインスタンスタイプ拡張を検討する前に、 Spectrum利⽤でどうにかできないか考えてみる – これから分析基盤を構築する場合は、Spectrum利⽤がいつでもできるような DataLake設計にしておくことを強くお勧めします… • SQLで表現できるような前処理が存在する場合はUNLOADクエリで
代替できないか考えてみる – EC2で処理しているならRedshiftがビジーな時間帯でなければ処理時間は 早くなるケースが多そう – AWS Glueで処理している場合もRedshiftインスタンスが既にあるなら Glueの分の費⽤が抑えられそう
アジェンダ • ⾃⼰紹介 • Cygamesについて • 弊社の運⽤している分析基盤について • DataLakeExportを活⽤してみた –
DataLakeExportの概要 – 活⽤事例 • RA3タイプのインスタンスに移⾏してみた – RA3の概要 – 移⾏時に注意したこと – 移⾏した結果 22/32
RA3の概要 23/32 • Spectrumである程度容量を節約できてもやっぱりまだまだ 容量との闘いが続くタイトルも多い • RA3タイプのインスタンスが発表された︕ どちらも64TB/node なのでds2から移⾏するとストレージが ⼀気に増やせそう︕
RA3移⾏時に注意したこと 24/32 • RA3に移⾏しても普段の業務に⽀障が出ないかを検証する ⽉額のコストは維持したいので、既存の構成と同じ費⽤になるような 構成をRA3で考える • 現⾏のクラスタからスナップショットを取得してリストアして 検証⽤クラスタを作成して以下を検証する –
分析担当者に普段業務で扱うようなクエリをテスト的に投げてもらって、 処理速度が遅くなってないか – 毎⽇のS3からのロード処理が遅くなってないか • タイトル毎に構成も変わるので個別に検証していく
RA3移⾏時に注意したこと 25/32 あるタイトルAの場合 • 現⾏ : ds2.xlarge * 8nodes 移⾏後
: ra3.4xlarge * 2nodes に移⾏するパターン • コスト – 約13%ほどRA3の⽅が安くなる (マネージドストレージの費⽤込) • 分析に使うクエリの処理時間 – 全体的に早くなった︕ が、物によっては遅くなった︖ • ロード処理にかかる時間 – かなり遅くなった… – おそらくnode数が減ったことで並列実⾏数が減ったのが原因︖
RA3移⾏時に注意したこと 26/32 あるタイトルBの場合 • 現⾏ : ds2.8xlarge * 6nodes 移⾏後
: ra3.4xlarge * 12nodes に移⾏するパターン • コスト – 約13%ほどRA3の⽅が安くなる (マネージドストレージの費⽤込) • 分析に使うクエリの処理時間 – 全体的に早くなった︕ • ロード処理にかかる時間 – 今度はかなり早くなった︕︕︕ – 前のパターンの逆でnode数が増えたから︖
RA3移⾏時に注意したこと 27/32 • クエリ早くなる・ロード処理も早くなる・費⽤は少し下がる タイトルBのパターンに限ればいいことづくめなので移⾏しよう • 検証時同様、スナップショットからのリストアでRA3へ移⾏する 移⾏までの流れ – 適当なエンドポイント名でRA3のインスタンスを⽴ち上げる
– 移⾏当⽇にスナップショットを作成 (1.5hくらい) – 新規RA3インスタンスに取得したスナップショットをリストア (1hくらい) – エンドポイントを既存のクラスターと新規RA3インスタンスで⼊れ替える (15minくらい)
移⾏した結果 28/32 • 移⾏前 – 2~3ヶ⽉くらいおきに特定のイベントが開催されるたびに Redshiftの容量が圧迫されるためその度に容量削減作業を⾏なっていた
移⾏した結果 29/32 • 移⾏後 – 容量に⼀気に余裕ができた︕︕︕ – ロードにかかる時間や分析業務のクエリの処理時間も概ね事前の検証通りだった
移⾏した結果 30/32 • RA3に移⾏できたのはまだ最も⼤きい規模な1クラスターのみ 徐々に他のクラスターもRA3に移⾏していきたい – AQUA(Advanced Query Accelerator) がGAになれば、他のクラスターにも適⽤しやすくなるかも
• 構成によってはロード処理や⼀部クエリの処理時間が増えてしまい、 業務に⽀障が出るため、現状のままでは少し難しそうだった… – 柔軟な構成が取れるように ra3.xlargeなどが出てくれたら嬉しい
RA3タイプのインスタンスに移⾏してみた(まとめ) 31/32 • Redshiftのストレージ容量が圧迫されて困っている場合には RA3に移⾏することで余裕ができる • nodeごとのスペックは従来のインスタンスよりも⾼いが、 場合によってはロードやクエリの処理時間は落ちるので 事前検証を推奨 –
Cygames環境だと構成によっては処理時間が伸びてしまうケースもあった – 今後ra3.xlarge等のもう少し⼩回りの効くタイプが登場してくれることに期待
まとめ • ゲーム運営の扱うログデータは縦にも横にも⻑いのでRedshiftの ストレージ容量が圧迫されることが多い – Spectrum利⽤することで多少余裕ができた • Spectrumのパーティションデータ作成など、前処理を⾏なっている場合は UnloadクエリのParquet出⼒で代替できる –
カラムナーDBが苦⼿な処理でなければ処理時間は早くなることが多いはず • RA3インスタンスに移⾏すれば更にストレージに余裕ができる – 従来のものより⾼スペックなnodeだが、事前に検証は必要 32/32