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.3k
ソーシャルゲームの膨⼤なゲームログを扱うCygamesの Amazon Redshift 活用事例
2020/08/06 Amazon Redshift事例祭り(活用編)
Cygames
August 06, 2020
Tweet
Share
More Decks by Cygames
See All by Cygames
『グランブルーファンタジー』100万行を超える大規模なシステム再構築~10周年のその先へ~
cygames
8
25k
グラブルミュージアム蒼の追想 MX4Dシアターのサウンド制作事例〜ゲームの世界観とアトラクション体験の両立に必要なこと〜
cygames
0
980
AIによる自然言語処理・音声解析を用いたゲーム内会話パートの感情分析への取り組み
cygames
0
1.4k
最大100倍高速化!PHPからJavaへのFFIを実現する、JNIを用いた高速なサーバAPIの実装方法
cygames
0
260
AIによる自然言語処理を活用したゲームシナリオの誤字検出への取り組み
cygames
0
200
ツール保守コスト大幅削減!テクニカルアーティストによるツールログサービスの開発と運用事例
cygames
0
210
C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制 ~プリコネ!グランドマスターズ開発事例~
cygames
24
20k
「最高のコンテンツ」を支える、Cygamesのデータベース技術の今までとこれから 〜次世代データベース「TiDB」の検証を開始したCygamesの取り組み〜
cygames
0
5.2k
ウマ娘 プリティーダービーのコンテ制作事例 ~コンテ制作専任チームの誕生とキャラクターを輝かせるコンテ術~
cygames
2
8.6k
Other Decks in Technology
See All in Technology
非同期推論システムによるコスト削減と信頼性向上
koki_nishihara
0
260
MapLibreとAmazon Location Service
dayjournal
1
160
LangSmith入門―トレース/評価/プロンプト管理などを担うLLMアプリ開発プラットフォーム
os1ma
3
180
検証を通して見えてきたTiDBの性能特性
lycorptech_jp
PRO
6
3.8k
GrafanaMeetup_AmazonManagedGrafanaのアクセス制御機能とマルチテナント環境下でのアクセス制御について
daitak
0
230
Building Dashboards as a Hobby
egmc
0
220
家族アルバム みてねにおけるGrafana活用術 / Grafana Meetup Japan Vol.1 LT
isaoshimizu
1
750
FrontDoorとWebAppsを組み合わせた際のリダイレクト処理の注意点
kenichirokimura
1
520
レガシーをぶっ壊せ。AEONで始めるDevRelの話 / Qiita Night 2024-2-22
aeonpeople
3
1.3k
現代CSSフレームワークの内部実装とその仕組み
poteboy
7
3.6k
Meta Quest 3 で動く桜マシマシ WebXR アプリを IBM Cloud Code Engine と Babylon.js で作った話
1ftseabass
PRO
0
120
ChatworkのSRE部って実は 半分くらいPlatform Engineering部かもしれない
saramune
0
160
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
456
32k
Thoughts on Productivity
jonyablonski
58
3.8k
For a Future-Friendly Web
brad_frost
172
9k
Atom: Resistance is Futile
akmur
259
25k
How to Ace a Technical Interview
jacobian
272
22k
Visualization
eitanlees
136
14k
The Invisible Customer
myddelton
114
12k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
9
8.3k
Web development in the modern age
philhawksworth
202
10k
Statistics for Hackers
jakevdp
789
220k
Fireside Chat
paigeccino
21
2.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
501
140k
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