Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ソーシャルゲームの膨⼤なゲームログを扱うCygamesの Amazon Redshift 活用事例
Search
Cygames
PRO
August 06, 2020
Technology
2
3.8k
ソーシャルゲームの膨⼤なゲームログを扱うCygamesの Amazon Redshift 活用事例
2020/08/06 Amazon Redshift事例祭り(活用編)
Cygames
PRO
August 06, 2020
Tweet
Share
More Decks by Cygames
See All by Cygames
【TiDB User Day2025】リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか 〜『Shadowverse: Worlds Beyond』におけるTiDB採用のゲームサーバー設計〜
cygames
PRO
0
42
【CEDEC2025】『Shadowverse: Worlds Beyond』二度目のDCG開発でゲームをリデザインする~遊びやすさと競技性の両立~
cygames
PRO
2
500
【CEDEC2025】大規模言語モデルを活用したゲーム内会話パートのスクリプト作成支援への取り組み
cygames
PRO
2
1.4k
【CEDEC2025】現場を理解して実現!ゲーム開発を効率化するWebサービスの開発と、利用促進のための継続的な改善
cygames
PRO
0
1.1k
【CEDEC2025】ブランド力アップのためのコンテンツマーケティング~ゲーム会社における情報資産の活かし方~
cygames
PRO
0
1k
【CEDEC2025】『ウマ娘 プリティーダービー』における映像制作のさらなる高品質化へ!~ 豊富な素材出力と制作フローの改善を実現するツールについて~
cygames
PRO
0
380
【CEDEC2025】LLMを活用したゲーム開発支援と、生成AIの利活用を進める組織的な取り組み
cygames
PRO
1
3.4k
【TiDB GAME DAY 2025】Shadowverse: Worlds Beyond にみる TiDB 活用術
cygames
PRO
0
2.6k
雲だけじゃない!『GRANBLUE FANTASY: Relink』の世界に奥行きを出す半透明スプライト活用術
cygames
PRO
0
1.1k
Other Decks in Technology
See All in Technology
後進育成のしくじり〜任せるスキルとリーダーシップの両立〜
matsu0228
7
3.2k
Uncle Bobの「プロフェッショナリズムへの期待」から学ぶプロの覚悟
nakasho
2
100
多様な事業ドメインのクリエイターへ 価値を届けるための営みについて
massyuu
1
500
AWS IoT 超入門 2025
hattori
0
280
防災デジタル分野での官民共創の取り組み (2)DIT/CCとD-CERTについて
ditccsugii
0
120
AI時代だからこそ考える、僕らが本当につくりたいスクラムチーム / A Scrum Team we really want to create in this AI era
takaking22
7
4k
10年の共創が示す、これからの開発者と企業の関係 ~ Crossroad
soracom
PRO
1
690
空間を設計する力を考える / 20251004 Naoki Takahashi
shift_evolve
PRO
4
450
Git in Team
kawaguti
PRO
3
330
Azure Well-Architected Framework入門
tomokusaba
1
350
The Cake Is a Lie... And So Is Your Login’s Accessibility
leichteckig
0
100
なぜAWSを活かしきれないのか?技術と組織への処方箋
nrinetcom
PRO
1
190
Featured
See All Featured
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
189
55k
Automating Front-end Workflow
addyosmani
1371
200k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
What's in a price? How to price your products and services
michaelherold
246
12k
For a Future-Friendly Web
brad_frost
180
9.9k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
A better future with KSS
kneath
239
18k
How to train your dragon (web standard)
notwaldorf
96
6.3k
Build your cross-platform service in a week with App Engine
jlugia
232
18k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
2.7k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
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