この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
どうもコンサルティング部の後藤です。
本記事は AWS re:Invent2020 のセッション "How Zynga modernized mobile analytics with Amazon Redshift RA3"のレポート記事になります。
AWS Game Tech Blogで紹介されていて気になったのでまとめてみました。
セッション概要
セッションタイトル
How Zynga modernized mobile analytics with Amazon Redshift RA3
概要(機械翻訳)
Zyngaがどのようにモバイルゲームプラットフォームを近代化し、AWSを利用してアナリティクスとデータサイエンスの取り組みをレベルアップさせたかをご覧ください。このセッションでは、ZyngaのデータエンジニアリングのテクノロジーリードであるBharath Anandaram氏が、数千万人のプレイヤーが生成したデータを既存のインフラからAmazon Redshiftに移行した方法を紹介します。Zyngaは、RA3インスタンスを活用してクエリのパフォーマンスを急速に向上させ、同時に運用上のオーバーヘッドとコストを削減しました。Words With FriendsやZynga PokerなどのヒットフランチャイズをAmazon Kinesis、Amazon Redshift、Amazon S3などのAWSサービスでサポートし、ゲームのパーソナライズとエンゲージメントの向上を可能にしたアナリティクスソリューションについてご紹介します。
スピーカー
セッションレポート
アジェンダ
- アナリティクスの重要性
- 古い環境から移行した理由
- Redshiftを選択した理由
- 移行計画に役立つデータベーススコアカードについて
- 移行プロセスについて
- 学んだこと
アナリティクスの重要性について
ゲームにおけるデータアナリティクスとは、ゲームの何かを変更したり、追加したりするのに重要な決定材料となるとのこと。
データを活用するまでには、以下のようなステップを踏む必要があるそうです。
- 収集 : 意思決定を行うのに必要なデータを入手し、データにアクセスしやすくする
- 分析 : データ分析を行い、プレイヤーは何か気に入っているのか、気に入っていないのかを理解する
- 適用 : その結果を元に、新しいゲームを立ち上げたり既存のゲームを成長させる
また、データに適したデータ分析ツール、製品を選択することも重要視されており、Zynga社では以下のような指標を持っているようです。
- 月間1000万人以上のアクティブユーザ数
- 1日あたり約数テラバイトの非圧縮データ生成
- 1日あたり合計数約億件のレコードに相当し、計算処理は数百万個のクエリを実行
レガシー環境からRedshiftに移行した理由について
レガシー環境の問題点として、以下のような事を挙げられていました。
- 拡張性の無さ
- ストレージが約8週間分のデータしか保存出来なかった
- データが少ない分、予測モデルの能力が制限されてしまう
- ストレージが約8週間分のデータしか保存出来なかった
- スケール性の無さ
- ニーズに合わせてリソースをスケールアップ、ダウンが出来ない
- 無駄なリソースが発生し、運用にコストがかかる
- ニーズに合わせてリソースをスケールアップ、ダウンが出来ない
- メンテナンスコスト
- 年に約45日エンジニアの作業が必要
- 高コスト
Redsfitを選択した理由について
Zynga社では、以下のような評価基準を作成し、幾つかのソリューションを当てはめて判断していました。この評価は今年の3月 - 4月頃に行われたとのことです。
RedshiftにはRA3インスタンスを使用し、ソリューションBと数か月にわたる概念検証を行った結果から値を記載しているそうです。
評価表を見てみると、一部ソリューションBのが優れているように思いますが、レガシー環境とソリューションBでは扱うクエリ言語が異なることから、移行コストを大きく見積もったとのこと。また、Redshiftでは重いワークロードでも素晴らしいパフォーマンスを出しており、平均ETLの実行時間を30%以上削減出来たことから、Redshiftを選択したとのことでした。
移行について
フェーズ.1 Redshiftの構築
Redshiftの構築にはTerraformを活用していて、Terraformの実行にはJenkinsを利用しているのことでした。
Terraformを活用することで、複数のRedShiftを構築したり、IAMポリシーの変更やS3バケットの権限変更、その他多くの部分の変更点を一度に加えることが出来るようになったそうです。
フェーズ.2 データ移行
このデータ移行には、Redshiftクラスタにデータをインジェストするための新しいコンシューマを設定することが含まれているとのこと。
データ移行を行うにあたり、以下のようなことを行ったとのこと
- S3バケット内のステージングファイルを圧縮
- マニフェストファイルを利用してどのくらいの間隔で何個ファイルをロードするかを指定
- Redshiftに収集する全てのデータにはサーバのタイムスタンプを付与
- レガシー環境からS3にデータをエクスポートし、そのコピーを使用してRedshiftにインジェストするツールをセットアップ
- Redshift spectrumも使用
フェーズ.3 ETL移行
ETLとしてAirflowを使用しているとのこと。
移行を成功させるには、データのプロファイリングとデータ品質が必要とのこと。そのためにレガシー環境とRedshiftの間で入力を受け、ETL出力のデータ品質を比較するパラメータサーバを開発したようです。
ETLがRedshiftでマークされてからは、レガシー環境のETLを停止させ、RedshiftのETL出力をレガシー環境に出力することでエンドユーザはレガシー環境で最新のデータを作成することが出来るようになるとのこと。
フェーズ.4 コンシューマ移行
Zynga社の社員は何かしらの形でデータにアクセスしており、様々なクライアントを利用しているとのこと。
この作業はまだ実行中で、キューの処理の動作を調査したり、WLMを調整するためにクエリルーティングルールの作成に取り組んでいるとのこと。
それぞれ異なる設定で接続を管理するのは非常に手間がかかるため、現在はRedshift Data APIを使用するという選択肢を模索しているとのこと。
フェーズ.5 ロックアウトとEOL
まだこのフェーズには到達していないようですが、最終的にはレガシー環境を停止させ、ユーザアカウントをロックし、最終的なバックアップを取得してシステムをシャットダウンする計画があるようです。
まとめ
最後に成功事例として以下のようなことを挙げられていました。
- インジェストSLAを30%軽減
- データインジェストパイプラインによってコピーパフォーマンスが大幅に向上
- ETLパフォーマンスの向上
- ニーズによるスケーリング性能が可能
- 長期間の分析が可能
最後に
AWS re:Invent2020 のセッション "How Zynga modernized mobile analytics with Amazon Redshift RA3"のレポート記事でした。
最近は特にゲーム業界のデータ分析事例が多く上がってきて、今回はそのデータ移行に関するセッションでした。気になる方は是非セッションを確認してみてください。
13
