ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)

© 2021, Amazon Web Services, Inc. or its Affiliates.
Junya Yamamoto
2021/04/15
ゲームアーキテクチャパターン
(Aurora Serverless/DynamoDB)

⾃⼰紹介
名前︓⼭本純也
• AWS Japan ソリューションアーキテクト
• 主にゲーム系のお客様を担当しております
• 好きなAWSサービス
AWS Lambda

本セッションについて
対象の方
• ゲームのシステムを普段開発・運用されている方
• どのデータベースを使い分けたらいいかいまいち分からない
今日持ち帰っていただくこと
• AWSのデータベースサービスの使い分け方の指針について理解できる
• 例として、Amazon Aurora (Serverless)とAmazon DynamoDB
話さないこと
• サービス毎の細かいお話

Agenda
• オンラインゲームのアーキテクチャ例
• DBサービスの選択と考え方
・AWS の Purpose-Built Database
・適切なDBを選択する方法
・Working backwards…クエリを想定したデザイン
・ゲームにおけるDBの選定例
・DBはシステムの一部なので全体から俯瞰

オンラインゲームのアーキテクチャ例

オンラインゲームのバックエンドシステムの構成例
PC Mobile
(1) ゲームクライアント（プレイヤーの端末）
PC / モバイル / コンソール機

PC Mobile
ELB
API Server
DB Cache
Database
Job Worker
Queue
API (Out-Game)
(2) Request を受けて DB を参照/更新する API サーバ。
API サーバ⾃体は REST や gRPC などでステートレスに
構成されることが多い。

PC Mobile
ELB
API Server
Battle / Quest
DB Cache
Database
Job Worker
Queue
Match Making
Lobby
Game Server (In-Game)
API (Out-Game)
(3) ロビーやバトルルームのセッションなどを
ステートフルに管理するゲームサーバ。

PC Mobile
ELB
API Server
Battle / Quest
DB Cache
Database
Job Worker
Queue
Match Making
Lobby
API (Out-Game)
Batch Server
Batch
Processing
(4) ランキング集計など様々
なバッチ処理。
⽇次バッチ/⽉次バッチなど

PC Mobile
ELB
API Server
Battle / Quest
DB Cache
Database
Job Worker
Queue
Match Making
Lobby
API (Out-Game)
Batch Server
Batch
Processing
本セッションの
ターゲット
ゲームのワークロードに
おいて、DBは非常に重
要なシステムであるため
レイテンシーや可用性が
求めれています

ゲームアーキテクチャにおける
DBサービスの選定と考え方
Purpose-built Databases

多くのDBサービスがある

AWSにおけるDBサービス

データベースの選択
AWS では多様な
データベースの選択肢
ワークロードに応じて
最適な選択が可能
Purpose built
The right tool for
the right job
https://www.allthingsdistributed.com/2018/06/purpose-built-databases-in-aws.html
適材適所の選択

Amazon.com はどのような選択をしたのか
コスト削減、パフォーマンス向上、
より速い⾰新を実現するために、2016年から
すべてのOracleをAWSに移⾏開始
Purpose-Built Databases によって
ワークロードに最適なDBエンジンを提供でき、
コストとユーザー体験の最適化を実現
Relational
Key-value
Document
In-memory
Graph
Data warehouse
Oracle databases AWS Purpose-Built Databases

適切なDBを選択する方法

適切なDBを選択する方法
最初に作るアプリケーションにどのような要件が存在するのかをブレイクダウン
アプリケーション要件項目の例
• アクセスパターン (ユーザ数の想定は？)
• データ量 (保存されるデータ量は？)
• スケールパターン (スケールアップ・スケールアウト)
• ゲームとしての仕様 (どんなデータが保存される？)
• ユースケース (OLTP・OLAP)
• エンジニアのスキルセット (NoSQLの経験はある？)
• などなど

あるゲームアプリケーションの要件その1
ユーザ: 数万ユーザ
データ量: 数百GB
場所: リージョナル
レイテンシ: ミリ秒
リクエスト: 数千/sec
アクセス: ウェブ
拡張: スケールアップ/ダウン
開発者アクセス: APIアクセス
Communication

あるゲームアプリケーションの要件その2
ユーザ: 数百万ユーザ
データ量: PB
場所: グローバル
レイテンシ : ミリ秒
リクエスト: 数百万/sec
アクセス: ウェブ/モバイル
拡張: スケールアウト/イン
Communication
Gaming Media streaming

Working backwards
…クエリを想定したデザイン

Working backwards – クエリを想定したデザイン
アプリケーション
の目的

？？？
の目的
アプリケーションの
データモデル
目的を達成するためにはどのようなデータが必要なのか？
必要なデータ

クエリ
そしてどのようなクエリが必要となるのか？
データモデル
の目的
必要なデータ
？？？

アプリケーションや
サービス
アプリケーションの実装は最後
でもアプリケーションの目的を考えるのは最初
クエリ
データモデル
の目的
？？？
必要なデータ

ゲームにおけるDBの選定例

ゲームアプリケーションとDB
実際にアウトゲームにおけるデータの要件を決めつつ選定を行ってみましょう
PC Mobile
ELB
API Server
Battle / Quest
DB Cache
Database
Job Worker
Queue
Match Making
Lobby
API (Out-Game)
Batch Server
Batch
Processing
本セッションの
ターゲット

Case1: ゲームにおけるDB選定例
• ユーザ情報
• ユーザID
• レベル
• フレンド
• リーダキャラクター
• クエリ
• 特定ユーザのフレンドの
リーダキャラクターを取得
？
Application
？
TARO_MOMO
Lv200
taro

アプリケーション要件の整理
データ量: TB
リクエスト: 数万/sec
アクセス: モバイル
• 条件を列挙し、
まずは右のようなアクセス要件を洗い出す
• 下記要件も加えて考える
(リリースまでの期限は短く)
チームのメンバーはRDBの経験が豊富

Working backwards してみる
データ量: TB

データ量: TB
Aurora
(リリースまでの期限は短く)
•チームのメンバーはRDBの経験が豊富

Aurora
項目内容
ユーザID taro
Lv 10
リーダID 5
フレンドID hanako
項目内容
ユーザID hanako
Lv 20
リーダ 101
項目内容
リーダID 101
名前悪魔
ユーザの情報
フレンドの情報
キャラクタ
ーの情報

クエリ
フレンドのリーダキャラクター取得
Aurora
フレンドの情報
キャラクタ
ーの情報
ユーザの情報

クエリ
フレンドのリーダキャラクター取得
Aurora
UserID Lv LeaderID
taro 10 100
hanako 20 101
UserID FriendID
taro hanako
taro issun
User
Friend
CharcterID Name
101 悪魔
102 ドラキュラ
Character

結果：特定ユーザのフレンドのリーダキャラクターを取得
Application
Aurora
Auroraとは？
クラウド向けに再設計された MySQL, PostgreSQL と互換性
のある RDBMS。高スループット、大規模ストレージスケー
ラビリティ、および高可用性を備えたDB。
• 今回の要件
• データ量はTBレベル
• リクエストは数万Req/Sec
• チームのメンバーはRDBの経験が
豊富

Amazon Aurora Serverless v2の紹介
⾼い拡張性⾼い可⽤性
Multi-AZ、Global Database、
Read ReplicaなどのAuroraの
機能をフルに活用して、
ビジネスクリティカルな
ワークロードを強力に
サポートします
キャパシティを細かく調整し、
ピークロード用のキャパシティを
プロビジョニングする場合と比較
して、最大90%のコストを節約
できます
最⼤90%のコスト削減
数百から数十万件の
トランザクションまで、
瞬時にスケールできます
プロビジョニングとデータベースキャパシティの管理の複雑さを取り除きながら、
最も要求の厳しいアプリケーションとワークロードをサポートします。
Amazon Aurora Serverless v2 is available in preview for Aurora MySQL only.

Case2: ゲームにおけるDB選定例
• ユーザ情報
• ユーザID
• ニックネーム
• レベル
• 所持アイテム(複数)
• クエリ
• 特定ユーザ情報の取得
？
Application
？
TARO_MOMO
Lv200
taro

アプリケーション要件の整理
• 条件を列挙し、
まずは右のようなアクセス要件を洗い出す
データ量: TB
スケールアウト/イン
• 下記要件も加えて考える
スキーマレスなデータ構造

データ量: TB
スキーマレスな
データ構造

データ量: TB
Amazon DynamoDB
スキーマレスな
データ構造

項目内容
ユーザID taro
ニックネーム TARO_MOMO
レベル 200
所持アイテム剣
所持アイテム盾
Amazon DynamoDB

Amazon DynamoDB
項目内容
ユーザID taro
ニックネーム TARO_MOMO
レベル 200
所持アイテム [剣,盾]
User
クエリ
ユーザIDにマッチした情報を取得

結果：特定ユーザの情報取得
Amazon DynamoDBとは
API
Application
UserID
TARO_
MOMO
taro 200
Attributes
Primary Key
剣,盾
Nick
Name
Lv Items
規模に関係なく数ミリ秒台のレイテンシを実現するKVSおよびド
キュメントDBです。自動的にテーブルをスケールアップ・ダウ
ンして容量を調整し、パフォーマンスを維持します。
DynamoDB は、毎秒 2,000 万件を超えるリクエストをサポート
します。
• 今回の要件
• データ量はTBレベル
• リクエストは数万Req/Sec
• スキーマレスなデータ構造
• スケールについての考慮事項が減る
SQL互換のPartiQLが利用可能
HANAKO_
MOMO
hanako 100
Award
Champ

本セッションのまとめ

まとめ
• AWS の Purpose-Built Database の考え方の基本は “適材適所”
• 最適なデータベースの選定にはまず ”何を実現したいのか” から逆に考えていく
• 最適なデータベースを選択することで
“ユーザ体験の向上” や “運用負荷の軽減” を実現する事が可能になる

Thank you！

ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)

Similaire à ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB) (20)

Plus de Amazon Web Services Japan

Plus de Amazon Web Services Japan (20)

ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)