Amazon Web Services ブログ
Mistplay: Amazon S3 と Amazon Athena を使ったビジネス分析の改善
本記事は Mistplay のAI エンジニアであるSteven Wang氏によるゲスト投稿です。
Mistplay はモバイルゲーマー向けの世界トップクラスのロイヤルティプログラムです。数百万人のプレイヤーが Mistplay を使用して新しいゲームを発見し、ロイヤルティ報酬を獲得し、他のプレイヤーとつながっています。このプラットフォームにより、Playtika、Scopely、Peak などのモバイルゲームスタジオは、世界中のユーザーを獲得し、それらのユーザーと深く関わることができています。
Mistplay が AWS に移行した理由
Mistplay では十分な情報に基づいた意思決定を行い、計算されたリスクを取るにあたり、データに大きく依存しています。 Mistplay の Android アプリケーションは、ユーザーのインタラクションをキャプチャする大量のイベント情報を生成するため、チームにとって不可欠なデータソースとなっています。このデータは不可欠であり、ビジネス上の主要な疑問に答え、当社が可能な限り最高のユーザーエクスペリエンスを作る上で重要な役割を果たしています。
従来、Android アプリケーションは Firebase にイベントデータを送信するように設計されていました。そこから、デフォルトで利用可能な統合機能を使ってFirebase と BigQuery を統合し、 BigQuery でイベントデータを公開し、詳細に分析していました。
しかし当社のビジネスが成長するにつれ、既存のソリューションでは対処できないいくつかの課題に直面しました。たとえば、品質上・精度上の問題が増加し、処理データに影響を与えていることに気付きました。さらに、インフラストラクチャに対するコストが当社のビジネスと同じくらい急速に増加していました。料金モデルは理解しにくく、当社の使用パターンだと予想外に高額な請求が発生することがよくありました。
当社のデータが新しいホームを必要としていることは明らかでした。当社のイベント分析を AWS に移行することは自然な選択でした。当社では既に Amazon S3 と Amazon Athena を主要なデータレイクとして使用していたためです。 さらに、ツール類を1つのサービスセットで統合し、分析タスクを合理化し、AWS の下で既に実施されている既存のセキュリティ対策を活用したいと考えていました。最後に、AWS の明瞭な料金モデルのおかげで、予算作成が簡単に行えました。
本投稿では、Firebase と BigQuery から Amazon S3 および Amazon Athena に移行した方法と、分析機能、コスト構造、およびオペレーションがどのように改善されたかを説明します。
移行戦略
移行は2つのフェーズで構成されました。第１フェーズでは、オープンソースツールを使用して BigQuery から Amazon S3 に既存のデータを移行し、AWS Glue テーブルを構築してアクセス可能にしました。第２フェーズでは、 AWS SDK for Java を使用して Android アプリケーションから Amazon Kinesis Data Firehose にイベントを送信しました。
第１フェーズ
既存のデータを BigQuery から AWS S3 に移行するために、以下の戦略を採用しました。
- 「bq」コマンドラインツールを使用して、BigQuery テーブルを Google Cloud Storage バケットにエクスポートしました。「bq export …」コマンドはマネージド型インフラストラクチャで実行されるため、専用のコンピューティングリソースをスピンアップする必要はありませんでした。
- エクスポートされたデータは、クエリを簡単に行えるよう、クリーニングおよびフラット化されました。その後、データは圧縮された parquet ファイルとしてフォーマットされ、Amazon Athena 内での消費がよりコスト効率良く行えるようになりました。
- 次に、「gsutil」コマンドラインツールを使用して、変換されたイベントを Amazon S3 バケットにエクスポートしました。これは多数の異なる Amazon EC2 インスタンスから行われ、それぞれが特定のデータグループを処理しました。
- データが Amazon S3 に転送されると、AWS Glue クローラを使用して Glue データカタログのデータのインデックスを作成し、Amazon Athena でクエリを実行できるようにしました。
第２フェーズ
既存のデータが Amazon S3 に保存された後、Android アプリケーションから AWS に新しいデータを送信する手段が必要でした。そのために当社は Firehose 配信ストリームを使用しました。これにより、サーバーレスなやり方でイベントデータを簡単に取り込み、変換、保存できるようになりました。
- Java AWS SDK を 当社のAndroid アプリケーションに統合し、Firehose 配信ストリームへのイベントのポイントを開始しました。
- データを取り込むために、新しい Kinesis 取り込みストリームを作成し、PUT ソースから入力し、送信先をAmazon S3 としました。当社のイベントデータは Glue テーブルで定義された形式と必ずしも一致しないため、ソースレコード変換を使用して受信イベントを正しい形式に変換しました。また、レコード形式の変換を有効にして、イベントのオブジェクトサイズを小さくしました。
- クエリコストを削減するために、ストリーミングデータを日ごとにパーティション分割しました。これにより、アナリストは関心のある特定の日のイベントのみをクエリできます。Glue クローラを 24 時間ごとに実行するようスケジュールし、テーブルスキーマを最新の状態に保つようにしています。
この 2 段階のアプローチにより、圧縮された列指向ファイル形式を活用することで、履歴データを AWS に移行し、新しいイベントと統合しながら、コストを抑えることができました。
まとめ
本投稿では、Mistplay が Android アプリケーションイベントソリューションを GCP から AWS に移行した方法についての概要をご説明しました。特に、Firebase Analytics / BigQuery から AWS S3 + Athena に移行し、AWS サービスの明瞭な料金体系に加えて、サーバーレスデータレイクの信頼性、スケーラビリティ、シンプルさを活用することがどれほど簡単であるかといったポイントについて述べました。
Mistplay について詳しく知るには
Mistplay および当社の取り組みの詳細についてお知りになりたい場合は、 https://www.mistplay.com/#/ をご覧ください。
当社が使用した AWS サービスの詳細について
サーバーレスデータレイクのアーキテクチャについてさらにお知りになりたい場合は、以下の役立つリソースをご参照ください。
原文はこちらです。