Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Cygames
August 06, 2020

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

2020/08/06 Amazon Redshift事例祭り(活用編)

Cygames

August 06, 2020
Tweet

More Decks by Cygames

Other Decks in Technology

Transcript

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

    View full-size slide

  2. ⾃⼰紹介
    藤⽥ 晋哉
    • データ分析基盤チーム エンジニア
    • キャリア
    – カジュアルゲームのサーバーサイド開発/運⽤

    – iOS/Androidプラットフォームの検証

    – データ分析基盤の開発/運⽤
    2/32

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  6. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  10. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  17. 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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide