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
August 06, 2020
Technology
2
3.4k
ソーシャルゲームの膨⼤なゲームログを扱うCygamesの Amazon Redshift 活用事例
2020/08/06 Amazon Redshift事例祭り(活用編)
Cygames
August 06, 2020
Tweet
Share
More Decks by Cygames
See All by Cygames
『GRANBLUE FANTASY Relink』キャラクターの魅力を支えるリグ・シミュレーション制作事例
cygames
0
320
『GRANBLUE FANTASY: Relink』最高の「没入感」を実現するカットシーン制作手法とそれを支える技術
cygames
1
270
『GRANBLUE FANTASY Relink』ソフトウェアラスタライザによる実践的なオクルージョンカリング
cygames
0
290
高品質なフォトグラメトリデータを取得するためのハードウェア&ソフトウェア開発
cygames
0
810
AIを活用した柔軟かつ効率的な社内リソース検索への取り組み
cygames
0
410
『GRANBLUE FANTASY: Relink』開発からリリースまでを支えたCI/CDの取り組み
cygames
0
190
『GRANBLUE FANTASY: Relink』専任エンジニアチームで回す大規模開発QAサイクル
cygames
0
200
『GRANBLUE FANTASY: Relink』クオリティと物量の両立に挑戦したフェイシャルアニメーション事例 ~カットシーンからランタイムまで~
cygames
0
200
『GRANBLUE FANTASY: Relink』キャラクターの個性にlinkした効果音表現
cygames
0
100
Other Decks in Technology
See All in Technology
塩野義製薬様のAWS統合管理戦略:Organizations設計と運用の具体例
tkikuchi
0
320
Road to Single Activity Uncovered
yurihondo
0
110
とある事業会社にとっての Kaggler の魅力
hakubishin3
7
1.6k
AWS DDKを利用したDataOps事始め
beex
1
170
エンジニア向け会社紹介資料
caddi_eng
14
270k
Bluesky 2019〜2022
yamarten
1
120
Japan AWS Jr. Championsがお届けする、アウトプットのすすめ
hamijay_cloud
0
210
地域DXにおけるGrafana活用事例
wacky
0
390
APIs for AI: Have we failed?
zdne
0
130
Nuxt × Vue Router の力を最大限に引き出す機能を紹介
ytr0903
2
330
フェンリルの SwiftUI の研修を覗いてみる / Fenrir SwiftUI Training
studio_rookery
0
160
LLMOps : ΔMLOps
shuntaito
13
2.1k
Featured
See All Featured
Happy Clients
brianwarren
97
6.7k
The Pragmatic Product Professional
lauravandoore
31
6.2k
How GitHub (no longer) Works
holman
311
140k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
26
710
A Tale of Four Properties
chriscoyier
156
22k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
92
16k
Faster Mobile Websites
deanohume
304
30k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
260
How to train your dragon (web standard)
notwaldorf
88
5.6k
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