こんにちは。ゲームソリューション部の出村です。
AWS re:Invent 2023のセッションである「Improving user experience at Epic Games using Amazon Timestream」のレポートをお届けします。
概要
Learn how Epic Games uses Amazon Timestream to derive business insights in near-real time to improve player and developer experiences. Epic Games is the company behind Fortnite, one of the world’s most popular video games, and who transformed gaming with Unreal Engine, the 3D creation engine that is now used across industries. Hear how they used Timestream to build a scalable solution for monitoring and deriving insights from the play time of millions of gamers across their catalog of games. Also discover how you can use the latest Timestream enhancements, such as customer-defined partition keys, UNLOAD, and scheduled queries, to derive insights in a performant and cost-effective manner.
スピーカー
- Ian Robinson : Principal Architect, AWS
- Ken Hawthorne : Senior Backend Engineer, Epic Games
動画
内容について
ここでは、このセッションの内容について注目した箇所を中心に解説します。セッション全体は動画で視聴できますので、そちらをご覧下さい。
まず最初にAmazon Timestreamについての紹介です。Amazon Timestreamとは時系列データベースであり、東京リージョンでは2022年7月より利用可能となりました。大量のデータをリアルタイムで検索できるようにするため、高いスループット、クエリーにより即座に検索できるようにする仕組み、可変なスキーマといった機能を備えています。
Amazon Timestreamのアーキテクチャについて解説します。アーキテクチャとしてはサーバーレスとなっています。
全体構成として、取り込みレイヤー、ストレージレイヤー、クエリーレイヤーという3レイヤーから構成されてます。それぞれのレイヤーは独立してスケールする仕組みとなっており、トラブルに強い仕組みを備えています。
この図は、Timestreamのインデックス、パーティショニングを図で示したものです。横軸が時間軸で縦軸がデータ分割に役立つメジャー値が指定されています。それらのデータが、メモリーとHDDなどの記憶媒体の双方に記録されています。
クエリーを実行した際には、この破線で囲まれた領域がデータが対象となる場合があり得ます。
そのためmeasure_nameカラムに設定する値は非常に高いカーディナリティの値を設定するよう推奨されてました。そうしないと、先の図からも分かる通り、クエリーを実行する際に非常に高いコストがかかってしまい、クエリーの実行速度も遅くなるためです。
ただ、このようなmeasure_nameを開発者が指定するのは何かとコードが複雑になりがちで、利用者側に負担をかけてきました。しかし今年から、このmeasure_nameを設定せず自動的にパーティションが設定される機能が追加されました。
Amazon Timestreamの歴史的経緯の説明です。Timestreamは当初はIoTで取得した情報を記録することを想定して設計されました。そのため、最初は1レコードに1つの値を記録する設計（シングルメジャー方式）となっていました。その後、複数の値を同時に記録（マルチメジャー方式）できるよう変更が加えられました。
レコードに対して単一の値を記録するシングルメジャー方式から、複数の値を記録するマルチメジャー方式をサポートしたことで、実行するクエリーも非常にシンプルになりました。左側のクエリーは、レコードがシングルメジャー方式で記録した場合のクエリーとなります。右側のクエリーは、1レコードで複数の値を記録したマルチメジャー方式でのクエリーとなります。
この分かる通りマルチメジャー方式だとクエリーがシンプルになるのはもちろん、クエリーの処理速度も向上しました。
AWSとしてはマルチメジャー方式を選択することを推奨しています。利点としてはデータ書き込みの処理負荷やデータ容量が減少すること、クエリーの処理速度が3倍程度向上することがあります。
先ほど紹介したmeasure_nameの指定が開発者への大きな負担となっていた点ですが、解決方法として顧客定義のパーティションキーが設定できる機能が追加されました。これは、このmeasure_nameに相当するカーディナリティの高い値が含まれるカラムをテーブル作成時に指定することで、後はTimestream側で判断して処理してくれる機能となっています。
この機能によってモデル化も容易になります。measure_nameが不要となり、パーティションキーを指定するだけでよくなります。
事例tとしてEpicGamesでどのようにTimestreamが利用されているのかみていきます。
Epic Game Luncherからプレイヤーのプレイ状況といった情報を取得しています。これが昨年12月のデータです。6800万人以上のアクティブユーザーから、1人当たり1分おきに83.4kのプレイ状況の情報が送信されています。1日に直すと33メガバイトのデータを処理していることになります。データ量は大した量じゃないですが数が非常に多いのが特徴です。
EpicGamesとしては、次の事を実現したいと考えてました。既存のコードやワークフローを利用したり、2週間のプレイデータを集計し取得するためのAPIコールが必要でした（このコールは非同期で取得できるようになりました）といったことです。
そのため、いくつかの対策を行いました。最初にデータの見直しを行い、取得した生データに対して集約する処理を行い、その結果を他のTimestreamへ記録するようにしました。この機能の実現には、Timestreamのスケジューリングされたキューの実行で実現しました。
生データを集約し、そのデータを別のTimestreamに記録するようにした結果、クエリー対象となるデータが63GBから3.5GBに削減できました。この際、ソースコードは一切変更してません。そして、これらのデータベースなどを稼働させるために必要なコストが90％以上削減できました。
最後に
Timestreamが、時系列データを処理するのに特化したデータベースであることがアーキテクチャ設計などの解説を通してよく理解できました。そのような大量の時系列データをニアリアルタイムで処理したい場合はMySQLのようなRDBではなく、Timestreamを利用するのが現時点では最も有効な手段といえるでしょう。
3
