Amazon DynamoDB で作るサーバーレスなゲーム用フレンドマイクロサービス

ゲームな皆さんこんにちは、Game Developers Relations の石井宇大こと Taka (@takahiroishii_) です。

この投稿では 前回 に続き、ゲームバックエンドサーバーをマイクロサービス化させ、負荷分散や開発速度に繋げるべく、フレンドのマイクロサービスという例を取り上げて、今回も具体的にバックエンドコードの書き方までサンプルを使って解説したいと思います。

シリーズ化しつつあるこのゲーム用サーバーレスマイクロサービスですが、是非今後もこんなのが見たい等、リクエストがありましたらハッシュタグ「#AWSウェブマガジン」でフィードバックください !

本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。

*ハンズオン記事およびソースコードにおける免責事項 »

毎月提供されるクラウドレシピのアップデート情報とともに、クレジットコードを受け取ることができます。 

前回同様、今回もよりアドバンスドで実用的な Amazon DynamoDB の特徴を生かしたマイクロサービスを目指します。ゲームのバックエンドのサーバーレス化というテーマに入門したばかりという方は是非 AWS GameKit もチェックしてください !

また今回のサンプルもすでにお持ちの AWS アカウントに短時間でデプロイできる AWS Cloud Development Kit (AWS CDK) を採用しています。本記事を読みサンプルをダウンロードしてみて、実際に手元で確認してみてください !

サンプルコードはこちら »

このフレンドマイクロサービスではフレンドの状態を 3 つの state として分けて考える事にします。今回はプレーヤー基準でデータを所持するのでそれぞれの state はそのプレーヤーの相手のプレーヤーに対する状態を指す事になります。以下がその 3 つの state です。

1. Requested
2. Pending
3. Friends

「Requested」は プレーヤーが相手プレーヤーに対してフレンド申請を行い返事を待っている状態、「Pending」はプレーヤーが相手のプレーヤーからフレンド申請を受け取って返事を行うまでの状態、「Friends」はプレーヤーが相手のプレーヤーとフレンド状態でにあることをそれぞれ示します。

一見少なく見えるかもしれませんが、この 3 つのフレンドの状態 (state が無い状態も合わせて 4 つ) を使って以下の 4 つのプレーヤー主体のアクションをサポートする事ができます。

1. Request : プレーヤーが特定の相手プレーヤーに向けフレンド申請を送る
2. Accept : プレーヤーが特定の相手プレーヤーからのフレンド申請を承諾する
3. Reject : プレーヤーが特定の相手プレーヤーからのフレンド申請を拒否する
4. Unfriend : プレーヤーが特定の相手プレーヤーとのフレンド関係を解消する

更に今回はプレーヤー基準のデータとなるので、DynamoDB のテーブルは下記のようにシンプルにデザインしていきます。

Friend Table

PK : player_id	SK: friend_id	state	last_updated
string : プレーヤーの ID	string : 相手プレーヤーの ID	フレンドの状態	タイムスタンプ

上記でも話したようにプレーヤー基準でデータ管理を行うと、一般的にはアクションを試みる度にトランザクションが必要になります。例えば Request というアクションをプレーヤー A が行う場合、プレーヤー A のデータには Requested を、プレーヤー B のデータには Pending をそれぞれ Atomic に書き込む事が必要となるのです。

もちろんトランザクションを使う事にシステム上問題は無く、普段この方法を課題と感じる開発者の方は少ないでしょう。一方でより柔軟にスケールするバックエンドをデザインしたいと考えシステムデザインを行うと、このトランザクション部分は必ずしも同期的である必要は無い事に気づきます。

つまりプレーヤー A がプレーヤー B にフレンド申請を行った時、プレーヤー B から見ると必ずしも同期的にフレンド状態が変わっている必要がないのです。もし AWS サービスを上手く活用して非同期的に行う事ができ、なおフレンドの状態管理が Atomic に行えるなら、プレーヤー基準でデータを管理してもトランザクションを極限まで減らし、より柔軟にスケールするフレンドサービスを作る事が可能です。

今回はそんな課題を DynamoDB Streams と 昨年リリースした AWS Lambda の機能である イベントソースフィルタリング を使う事で解消して行きたいと思います。なおイベントソースフィルタリングの詳しい説明に関しては こちらのブログ を参考にしてみて下さい。

各アクションの実行時にプレーヤー A とプレーヤー B のそれぞれの state がどのように変化するのか見ていきましょう。

プレーヤー A	プレーヤー B
申請時	何も無し → Requested	何も無し → Pending
承認時	Requested → Friends	Pending → Friends
拒否時	Requested → 何も無し	Pending → 何も無し
解消時	Friends → 何も無し	Friends → 何も無し

この変化を確認しどう 2 人のプレーヤーの状態を非同期に変更して行くか考えましょう。

まずは事前準備として今回使う Friend Table で DynamoDB Streams を起動させるために新旧両イメージが表示される StreamViewType の NEW_AND_OLD_IMAGE という設定をしておきます。前回に引き続き本サンプルも AWS CDK を使っています。

const friendTable = new Table(this, "Friend", { tableName: friendTableName, ... // StreamViewType を明記する事で DynamoDB Streams を利用する事ができる stream: StreamViewType.NEW_AND_OLD_IMAGES, });

例えばフレンド申請時を例に考えると、アクションを起こすのはプレーヤー A なので最初にプレーヤー A の状態を書き換えます。DynamoDB の Friend Table 中にプレーヤー A の ID (player_id の値) とプレーヤー B の ID (friend_id の値)、そして Requested (state の値) の組み合わせで新規 item が作成されます。この時 DynamoDB Streams には下記のようなイベントデータが送られてきます。

{ "eventID": "380271641178688a170beb2fabd6c401", "eventName": "INSERT", "eventVersion": "1.1", "eventSource": "aws:dynamodb", "awsRegion": "us-east-1", "dynamodb": { "ApproximateCreationDateTime": 1659342437, "Keys": { "friend_id": { "S": "playerB" }, "player_id": { "S": "playerA" } }, "NewImage": { "friend_id": { "S": "playerB" }, "last_updated": { "N": "1659342437340" }, "player_id": { "S": "playerA" }, "state": { "S": "Requested" } }, "SequenceNumber": "23469600000000008634076814", "SizeBytes": 98, "StreamViewType": "NEW_AND_OLD_IMAGES" }, "eventSourceARN": "arn:aws:dynamodb:us-east-1:123456789012:table/Friend/stream/2022-07-27T07:25:17.774"}

申請時にはプレーヤーAの書き込みによって発生したイベントのみを指定の Lambda で受け取り、プレーヤー B の状態を書き換えたいのでこのイベントをイベントソースフィルタリングを使用してピンポイントに受け取ります。 以下が AWS CDK 内に定義された申請時イベント用のフィルター例です。

// 複数の Handler に対して使うイベントソースの共通プロパティを定義 const streamEventSourceProps: StreamEventSourceProps = { startingPosition: StartingPosition.LATEST, batchSize: 5, retryAttempts: 1, onFailure: stateHandleDLQ, reportBatchItemFailures: true, }; // player B に変更を行う Handler に紐付け requestStateHandler.addEventSource( // friendTable から流れる Streams にフィルターを付ける new DynamoEventSource(friendTable, { filters: [ // フィルターの中身を定義 FilterCriteria.filter({ eventName: FilterRule.isEqual("INSERT"), dynamodb: { NewImage: { state: { S: FilterRule.isEqual(State.Requested) }, }, }, }), ], ...streamEventSourceProps, }) );

このイベントソースフィルタリングでは、eventName が INSERT であり、state が Requested の時のみ requestStateHandler という Lambda Function が起動するように定義されています。つまり何度同じプレーヤーAからの申請のアクションが届いても、プレーヤー B のデータの書き換えは一度 (at least one) に抑えられ、入り口の冪等性を保った事になります。ここでの冪等性の確保は Amazon SQS の Standard Queues を使用した際のメッセージの重複の対応にもなるので、今回のサンプルのように入り口に SQS を配置し非常にスケーラブルなマイクロサービスを構築する事が容易にできます。

更に、今サンプルでは DLQ (Dead Letter Queue) も使用しているので、もし万が一 DynamoDB Streams によって起動した Handler がクラッシュしたり、何らかの理由で上手く処理されなかったとしても、DynamoDB Streams に送られたイベントは DLQ にSequenceNumber などのメタデータとして保存されます。実際の運営ではモニタリングをしつつ、予期せぬ出来事が起きてもこの DLQ を使って再処理を行う事ができるのでログの解析などの運営負荷を軽減する事ができます。

ここまでは DynamoDB Streams とイベントソースフィルタリングによるトランザクション無しの冪等性を保った非同期処理への変換を説明してきました。ここからは非同期ならではの考え方と、特性を理解し細かな Edge Case の対応を考えていきます。今回非同期で走る処理はアクションをされた相手プレーヤー、プレーヤー B のデータ変更です。アクション毎にこのデータ変更に Edge Case がないか確認していきましょう。

まずは解消時です、解消時にはプレーヤー B が行うデータ変更は以下のように ConditionExpression を利用した、現在の state が Friends の時のみ Delete といったロジックになります。

const rejectParam: DocumentClient.DeleteItemInput = { TableName: friendTableName, // PK はプレーヤー B、SK はプレーヤー A Key: { "player_id": playerBId, "friend_id": playerAId, }, // state=Friends というコンディションの時のみ Delete ConditionExpression: "#state = :friends", ExpressionAttributeNames: { "#state": "state", }, ExpressionAttributeValues: { ":friends": Friends, }, };

これが失敗する Edge Case は、state の流れからも確認できるように、すでにプレーヤー B 主体で解消のアクションを行ったか、DynamoDB Streams から同じイベントが複数回来た場合のみになります。

つまりどちらであってもレースコンディションに負けた事となり、冪等性を保つためにも解消時の Edge Case (ConditionalCheckFailedException) は無視でき、エラーハンドルは以下のようになります。

const rejectParam: DocumentClient.DeleteItemInput = { TableName: friendTableName, ... // 上記のパラメータの内容 }; try { await db.delete(rejectParam).promise(); } catch (e: any) { if (e.name == "ConditionalCheckFailedException") { // 想定しているエラーなのでここを無視する。 return; } throw e; }

拒否時や承認時も解消時と同じ流れになるので省きます。最後に申請時です、申請時にはプレーヤー B が行うデータ変更はデータが何も無い状態から Pending のデータの入力になります。条件は何も無いことになるので以下のような ConditionExpression を使います。

const friendParam: DocumentClient.PutItemInput = { TableName: friendTableName, Item: { "player_id": playerBId, "friend_id": playerAId, state: Pending, last_updated: timeStamp, }, // 申請時にはプレーヤー B のデータが無い事を条件にする ConditionExpression: `attribute_not_exists(player_id)`, };

これが失敗する Edge Case は、すでにプレーヤー B がプレーヤー A に対して申請を行った後になります。この場合問題なのがプレーヤー A とプレーヤー B の両方が Requested になっている可能性があるという事です。両プレーヤーが Requested になってしまうと承認が不可能になるので、この Edge Case だけは無視する事ができません。

この課題を解決する方法はいくつかあります。一つは上の ConditionExpression に OR を足しプレーヤー B の state が Requested 状態も含む事です。この方法だと後から申請した方が勝ち、先に申請したプレーヤーからは承認待ちの用に見える状態になります。もう一つの方法が上記の ConditionExpression から出るエラー　ConditionalCheckFailedException 後にトランザクションを使い、両プレーヤーの state を Friends に更新する方法です。後者の方法では先に申請したプレーヤーには承認されフレンドになったように見えるので自然です。

本サンプルではこの後者の方法を採用しました。以下がトランザクションの中身になります。

const updateReceiverParams: DocumentClient.TransactWriteItem = { Update: { TableName: friendTableName, Key: { "player_id": playerAId, "friend_id": playerBId, }, // プレーヤー A も申請をしているので state=Requested ConditionExpression: "#state = :requested", // 両プレーヤーが申請しているので Friends に変更 UpdateExpression: "SET #state = :friends, #last_updated = :last_updated", ExpressionAttributeNames: { "#state": "state", "#last_updated": "last_updated", }, ExpressionAttributeValues: { ":requested": Requested, ":friends": Friends, ":last_updated": timeStamp, }, }, }; const updateRequesterParam: DocumentClient.TransactWriteItem = { Update: { TableName: friendTableName, Key: { "player_id": playerBId, "friend_id": playerAId, }, // プレーヤー B も申請しているので state=Requested ConditionExpression: "#state = :requested", // 両プレーヤーが申請しているので Friends に変更 UpdateExpression: "SET #state = :friends, #last_updated = :last_updated", ExpressionAttributeNames: { "#state": "state", "#last_updated": "last_updated", }, ExpressionAttributeValues: { ":requested": Requested, ":friends": Friends, ":last_updated": timeStamp, }, }, };

このトランザクションが失敗する理由は大きく 2 つあり、一つは TransactionConflict という、同時に同じアイテムに対して複数のトランザクションが行われているケースと、もう一つは条件である state = Requested が失敗しているケースです。前者のケースはリトライにより解決でき、後者のケースはこれまでに話したレースコンディションと似た理由で無視する事ができます。

このように非同期に処理を行う事で Edge Case への対応が必要な場面は訪れます。ですが、上手く ConditionExpression を活用する事で対応できるのも DynamoDB の面白い所だと思います。

今回はフレンド機能、特にフレンドの状態管理の部分を DynamoDB Streams とイベントソースフィルタリングを上手く活用してマイクロサービスを完成させました。このサンプルには他にも基本的なフレンド情報の読み取りができる Read Handler も含まれます。テストする際にも簡単に SQS に Message を送る事で一連の流れを確認できるようになっていますので是非お試しください。

前回のサンプルも含め是非 DynamoDB と Lambda を使ったスケーラブルなゲームバックエンドを体感して、これからのゲーム開発にお役立てください !