More Related Content
Similar to ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB) (20)
More from Amazon Web Services Japan (20)
ゲームアーキテクチャパターン (Aurora Serverless / DynamoDB)
- 1. © 2021, Amazon Web Services, Inc. or its Affiliates.
Junya Yamamoto
2021/04/15
ゲームアーキテクチャパターン
(Aurora Serverless/DynamoDB)
- 2. © 2021, Amazon Web Services, Inc. or its Affiliates.
⾃⼰紹介
名前︓⼭本 純也
• AWS Japan ソリューションアーキテクト
• 主にゲーム系のお客様を担当しております
• 好きなAWSサービス
AWS Lambda
- 3. © 2021, Amazon Web Services, Inc. or its Affiliates.
本セッションについて
対象の方
• ゲームのシステムを普段開発・運用されている方
• どのデータベースを使い分けたらいいかいまいち分からない
今日持ち帰っていただくこと
• AWSのデータベースサービスの使い分け方の指針について理解できる
• 例として、Amazon Aurora (Serverless)とAmazon DynamoDB
話さないこと
• サービス毎の細かいお話
- 4. © 2021, Amazon Web Services, Inc. or its Affiliates.
Agenda
• オンラインゲームのアーキテクチャ例
• DBサービスの選択と考え方
・AWS の Purpose-Built Database
・適切なDBを選択する方法
・Working backwards…クエリを想定したデザイン
・ゲームにおけるDBの選定例
・DBはシステムの一部なので全体から俯瞰
- 5. © 2021, Amazon Web Services, Inc. or its Affiliates.
オンラインゲームのアーキテクチャ例
- 6. © 2021, Amazon Web Services, Inc. or its Affiliates.
オンラインゲームのバックエンドシステムの構成例
PC Mobile
(1) ゲームクライアント(プレイヤーの端末)
PC / モバイル / コンソール機
- 7. © 2021, Amazon Web Services, Inc. or its Affiliates.
オンラインゲームのバックエンドシステムの構成例
PC Mobile
ELB
API Server
DB Cache
Database
Job Worker
Queue
API (Out-Game)
(2) Request を受けて DB を参照/更新する API サーバ。
API サーバ⾃体は REST や gRPC などでステートレスに
構成されることが多い。
- 8. © 2021, Amazon Web Services, Inc. or its Affiliates.
オンラインゲームのバックエンドシステムの構成例
PC Mobile
ELB
API Server
Battle / Quest
DB Cache
Database
Job Worker
Queue
Match Making
Lobby
Game Server (In-Game)
API (Out-Game)
(3) ロビーやバトルルームのセッションなどを
ステートフルに管理するゲームサーバ。
- 9. © 2021, Amazon Web Services, Inc. or its Affiliates.
オンラインゲームのバックエンドシステムの構成例
PC Mobile
ELB
API Server
Battle / Quest
DB Cache
Database
Job Worker
Queue
Match Making
Lobby
Game Server (In-Game)
API (Out-Game)
Batch Server
Batch
Processing
(4) ランキング集計など様々
なバッチ処理。
⽇次バッチ/⽉次バッチなど
- 10. © 2021, Amazon Web Services, Inc. or its Affiliates.
オンラインゲームのバックエンドシステムの構成例
PC Mobile
ELB
API Server
Battle / Quest
DB Cache
Database
Job Worker
Queue
Match Making
Lobby
Game Server (In-Game)
API (Out-Game)
Batch Server
Batch
Processing
本セッションの
ターゲット
ゲームのワークロードに
おいて、DBは非常に重
要なシステムであるため
レイテンシーや可用性が
求めれています
- 11. © 2021, Amazon Web Services, Inc. or its Affiliates.
ゲームアーキテクチャにおける
DBサービスの選定と考え方
Purpose-built Databases
- 13. © 2021, Amazon Web Services, Inc. or its Affiliates.
AWSにおけるDBサービス
- 14. © 2021, Amazon Web Services, Inc. or its Affiliates.
データベースの選択
AWS では多様な
データベースの選択肢
ワークロードに応じて
最適な選択が可能
Purpose built
The right tool for
the right job
https://www.allthingsdistributed.com/2018/06/purpose-built-databases-in-aws.html
適材適所の選択
- 15. © 2021, Amazon Web Services, Inc. or its Affiliates.
Amazon.com はどのような選択をしたのか
コスト削減、パフォーマンス向上、
より速い⾰新を実現するために、2016年から
すべてのOracleをAWSに移⾏開始
Purpose-Built Databases によって
ワークロードに最適なDBエンジンを提供でき、
コストとユーザー体験の最適化を実現
Relational
Key-value
Document
In-memory
Graph
Data warehouse
Oracle databases AWS Purpose-Built Databases
- 17. © 2021, Amazon Web Services, Inc. or its Affiliates.
適切なDBを選択する方法
最初に作るアプリケーションにどのような要件が存在するのかをブレイクダウン
アプリケーション要件項目の例
• アクセスパターン (ユーザ数の想定は?)
• データ量 (保存されるデータ量は?)
• スケールパターン (スケールアップ・スケールアウト)
• ゲームとしての仕様 (どんなデータが保存される?)
• ユースケース (OLTP・OLAP)
• エンジニアのスキルセット (NoSQLの経験はある?)
• などなど
- 18. © 2021, Amazon Web Services, Inc. or its Affiliates.
あるゲームアプリケーションの要件その1
ユーザ: 数万ユーザ
データ量: 数百GB
場所: リージョナル
レイテンシ: ミリ秒
リクエスト: 数千/sec
アクセス: ウェブ
拡張: スケールアップ/ダウン
開発者アクセス: APIアクセス
Communication
- 19. © 2021, Amazon Web Services, Inc. or its Affiliates.
あるゲームアプリケーションの要件その2
ユーザ: 数百万ユーザ
データ量: PB
場所: グローバル
レイテンシ : ミリ秒
リクエスト: 数百万/sec
アクセス: ウェブ/モバイル
拡張: スケールアウト/イン
開発者アクセス: APIアクセス
Communication
Gaming Media streaming
- 20. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards
…クエリを想定したデザイン
- 21. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards – クエリを想定したデザイン
アプリケーション
の目的
- 22. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards – クエリを想定したデザイン
???
アプリケーション
の目的
アプリケーションの
データモデル
目的を達成するためにはどのようなデータが必要なのか?
必要なデータ
- 23. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards – クエリを想定したデザイン
クエリ
そしてどのようなクエリが必要となるのか?
アプリケーションの
データモデル
アプリケーション
の目的
必要なデータ
???
- 24. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards – クエリを想定したデザイン
アプリケーションや
サービス
アプリケーションの実装は最後
でもアプリケーションの目的を考えるのは最初
クエリ
アプリケーションの
データモデル
アプリケーション
の目的
???
必要なデータ
- 25. © 2021, Amazon Web Services, Inc. or its Affiliates.
ゲームにおけるDBの選定例
- 26. © 2021, Amazon Web Services, Inc. or its Affiliates.
ゲームアプリケーションとDB
実際にアウトゲームにおけるデータの要件を決めつつ選定を行ってみましょう
PC Mobile
ELB
API Server
Battle / Quest
DB Cache
Database
Job Worker
Queue
Match Making
Lobby
Game Server (In-Game)
API (Out-Game)
Batch Server
Batch
Processing
本セッションの
ターゲット
- 27. © 2021, Amazon Web Services, Inc. or its Affiliates.
Case1: ゲームにおけるDB選定例
• ユーザ情報
• ユーザID
• レベル
• フレンド
• リーダキャラクター
• クエリ
• 特定ユーザのフレンドの
リーダキャラクターを取得
?
Application
?
TARO_MOMO
Lv200
taro
- 28. © 2021, Amazon Web Services, Inc. or its Affiliates.
アプリケーション要件の整理
ユーザ: 数万ユーザ
データ量: TB
場所: リージョナル
レイテンシ: ミリ秒
リクエスト: 数万/sec
アクセス: モバイル
拡張: スケールアップ/ダウン
開発者アクセス: APIアクセス
• 条件を列挙し、
まずは右のようなアクセス要件を洗い出す
• 下記要件も加えて考える
(リリースまでの期限は短く)
チームのメンバーはRDBの経験が豊富
- 29. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
ユーザ: 数万ユーザ
データ量: TB
場所: リージョナル
レイテンシ: ミリ秒
リクエスト: 数万/sec
アクセス: モバイル
拡張: スケールアップ/ダウン
開発者アクセス: APIアクセス
- 30. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
ユーザ: 数万ユーザ
データ量: TB
場所: リージョナル
レイテンシ: ミリ秒
リクエスト: 数万/sec
アクセス: モバイル
拡張: スケールアップ/ダウン
開発者アクセス: APIアクセス
Aurora
(リリースまでの期限は短く)
•チームのメンバーはRDBの経験が豊富
- 31. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
Aurora
項目 内容
ユーザID taro
Lv 10
リーダID 5
フレンドID hanako
項目 内容
ユーザID hanako
Lv 20
リーダ 101
項目 内容
リーダID 101
名前 悪魔
ユーザの情報
フレンドの情報
キャラクタ
ーの情報
- 32. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
クエリ
フレンドのリーダキャラクター取得
Aurora
フレンドの情報
キャラクタ
ーの情報
ユーザの情報
- 33. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
クエリ
フレンドのリーダキャラクター取得
Aurora
UserID Lv LeaderID
taro 10 100
hanako 20 101
UserID FriendID
taro hanako
taro issun
User
Friend
CharcterID Name
101 悪魔
102 ドラキュラ
Character
- 34. © 2021, Amazon Web Services, Inc. or its Affiliates.
結果:特定ユーザのフレンドのリーダキャラクターを取得
Application
Aurora
Auroraとは?
クラウド向けに再設計された MySQL, PostgreSQL と互換性
のある RDBMS。高スループット、大規模ストレージスケー
ラビリティ、および高可用性を備えたDB。
• 今回の要件
• データ量はTBレベル
• リクエストは数万Req/Sec
• チームのメンバーはRDBの経験が
豊富
- 35. © 2021, Amazon Web Services, Inc. or its Affiliates.
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.
- 36. © 2021, Amazon Web Services, Inc. or its Affiliates.
Case2: ゲームにおけるDB選定例
• ユーザ情報
• ユーザID
• ニックネーム
• レベル
• 所持アイテム(複数)
• クエリ
• 特定ユーザ情報の取得
?
Application
?
TARO_MOMO
Lv200
taro
- 37. © 2021, Amazon Web Services, Inc. or its Affiliates.
アプリケーション要件の整理
• 条件を列挙し、
まずは右のようなアクセス要件を洗い出す
ユーザ: 数万ユーザ
データ量: TB
場所: リージョナル
レイテンシ: ミリ秒
リクエスト: 数万/sec
アクセス: ウェブ/モバイル
拡張: スケールアップ/ダウン
スケールアウト/イン
開発者アクセス: APIアクセス
• 下記要件も加えて考える
スキーマレスなデータ構造
- 38. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
ユーザ: 数万ユーザ
データ量: TB
場所: リージョナル
レイテンシ: ミリ秒
リクエスト: 数万/sec
アクセス: ウェブ/モバイル
拡張: スケールアップ/ダウン
スケールアウト/イン
開発者アクセス: APIアクセス
スキーマレスな
データ構造
- 39. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
ユーザ: 数万ユーザ
データ量: TB
場所: リージョナル
レイテンシ: ミリ秒
リクエスト: 数万/sec
アクセス: ウェブ/モバイル
拡張: スケールアップ/ダウン
スケールアウト/イン
開発者アクセス: APIアクセス
Amazon DynamoDB
スキーマレスな
データ構造
- 40. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
項目 内容
ユーザID taro
ニックネーム TARO_MOMO
レベル 200
所持アイテム 剣
所持アイテム 盾
Amazon DynamoDB
- 41. © 2021, Amazon Web Services, Inc. or its Affiliates.
Working backwards してみる
Amazon DynamoDB
項目 内容
ユーザID taro
ニックネーム TARO_MOMO
レベル 200
所持アイテム [剣,盾]
User
クエリ
ユーザIDにマッチした情報を取得
- 42. © 2021, Amazon Web Services, Inc. or its Affiliates.
結果:特定ユーザの情報取得
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
- 44. © 2021, Amazon Web Services, Inc. or its Affiliates.
まとめ
• AWS の Purpose-Built Database の考え方の基本は “適材適所”
• 最適なデータベースの選定にはまず ”何を実現したいのか” から逆に考えていく
• 最適なデータベースを選択することで
“ユーザ体験の向上” や “運用負荷の軽減” を実現する事が可能になる