PowerPoint Presentation · • コンソール系ゲーム会社（テクニカルディレクター） • ブラウザソーシャルゲーム、スマートフォン向けソーシャルゲーム

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.

3-H1–2-16

AWS


自己紹介

森祐孝（もりゆうこう）ソリューションアーキテクト

経歴

• メーカー系SIer、電子マネー運営（サーバサイド開発）

• 独立系SIer

• 情報通信キャリア向けのSIでPL、PM

• コンソール系ゲーム会社（テクニカルディレクター）

• ブラウザソーシャルゲーム、スマートフォン向けソーシャルゲーム

担当

• ソーシャルゲーム、コンソールゲーム系のお客様

• Amazon Lumberyard 、GameLift

.

(Error Code: 42 – OOPS)

Retry


ゲームリリースの準備は大丈夫？？

メディアのレビュー

アプリストアのフィーチャリング

ソーシャルメディア

マーケティング・プロモーション

想定してた最悪ケースのシナリオ x 50

PLA

YER

S

TIME

ユーザ評価


Traditional: Rigid (柔軟ではない) AWS: Elastic (柔軟)

Servers

負荷

Capacity

過剰なキャパシティ無駄な投資 $$

負荷

ゲーム需要に対応出来ないゲームプレイヤーに不満売上に影響 :(

ゲームユーザの需要に合わせてサーバをスケール


アンチパターン –モノリシック

マルチプレイヤーゲームロジック

AI

ショップMODULE

認証

不正検出

マッチメイキング

チャット

BI + ETL

ゲームデータ


アンチパターン –モノリシックスケーリング


AI

ショップMODULE

認証

不正検出

マッチメイキングチャット

BI + ETL

ゲームデータ


AI

ショップMODULE

認証

不正検出


BI + ETL

ゲームデータ


分割


AI

ショップMODULE

認証

不正検出


BI + ETL

ゲームデータ


分割


サービスオリエンテッドアーキテクチャ

認証マッチメイキングHTTP(S)



認証

マッチメイキングHTTP(S)

認証

認証

HTTP(S)

ElasticLoad Balancer

(ELB)



認証マッチメイキング

HTTP(S)認証

認証

HTTP(S)マッチメイキング


200 TX/sec 50 TX/sec200 TX/sec 50 TX/sec


(ELB)


(ELB)


イベントドリブンアーキテクチャ


認証

認証

HTTP(S)マッチメイキング


200 TX/sec 50 TX/sec


(ELB)

AmazonSimple

Queue Service(SQS)


イベントドリブンアーキテクチャ


v1.0

認証

認証

HTTP(S) マッチメイキングv2.0

マッチメイキングv3.0

200 TX/sec 50 TX/sec


(ELB)

AmazonSimple

Queue Service(SQS)


• クライアントとの通信はAPIで• HTTP + JSON、gRPC等• フレンドリスト, リーダボード• バイナリアセットデータ• マルチプレイヤーゲーム• 高可用性• 拡張性


Region

マルチプレイヤーゲームサーバシステム

• ゲームAPIバックエンドサーバ• ユーザ認証、管理• マッチメイキング


Region



• S3+CloudFront• DLC, アセットファイル• ゲームセーブデータ• ユーザ生成コンテンツ


Region



• S3+CloudFront• DLC, アセットファイル• ゲームセーブデータ• ユーザ生成コンテンツ

• マルチプレイヤーゲームサーバ• ダイレクトソケット通信

• プレイヤーに合わせてスケール


• 最適なリージョンを選択• 2つ以上の Availability Zonesで• アプリ用EC2• Elastic Load Balancer• Amazon RDS

• Multi-AZ

ゲームAPIバックエンドサーバ


• Amazon Aurora• Amazonがクラウド時代にあわせて作ったRDBMS

• MySQL5.6, 5.7, PostgreSQL9.6互換• 最大64TBまで自動でスケール• 15台のレプリカ• 高速なクラッシュリカバリ• 高速なフェールオーバ• 秒単位のポイントインタイムリカバリ

ゲームAPIバックエンドサーバ

W RRRAurora Cluster


•

•

•

•

•

•

•


•

• ゲームデータ• アセット• ユーザ生成コンテンツ• ログや分析データ

• Amazon Cloudfront• コンテンツ配信

• Auto Scaling Group• 動的キャパシティ• ユーザの増加に合わせて• 計画的な負荷に関してはスケジュール設定


•

• ゲームデータ• アセット• ユーザ生成コンテンツ• ログや分析データ

• Amazon Cloudfront• コンテンツ配信

• Auto Scaling Group• 動的キャパシティ• ユーザの増加に合わせて

• Amazon ElastiCache• Memcached & Redis


AmazonElastiCache Redis

Elastic Load Balancing

Amazon EC2

Subscribe

ElastiCache(Redis)を使ったチャットの実装

clients

Publish

Subscribe

Subscribe

SUBSCRIBE chat_channel:114

PUBLISH chat_channel:114 "Hello all">> ["message", "chat_channel:114", "Hello all"]

UNSUBSCRIBE chat_channel:114

Pub/SubによるChatの実装


AmazonElastiCache

Redis


Amazon EC2

ElastiCache(Redis)を使ったリーダボード（ランキングボード）

clients

Sorted Setによるリーダーボード実装ZADD "leaderboard" 1201 "Gollum”ZADD "leaderboard" 963 "Sauron"ZADD "leaderboard" 1092 "Bilbo"ZADD "leaderboard" 1383 "Frodo”

ZREVRANGE "leaderboard" 0 -11) "Frodo"2) "Gollum"3) "Bilbo"4) "Sauron”

ZREVRANK "leaderboard" "Sauron"(integer) 3

reads/writes


AmazonElastiCache Redis

AmazonDynamoDB


Amazon EC2

AmazonRDS

write-through

reads/writes

DDB streams

mysql.lambda_async

reads/writes

Amazon S3

reads/ writes

オブジェクトデータ

非構造化データ

構造化データ

マネージドサービスを用いたデータのキャッシュ方法

clients


ELB

Region

CloudFrontCDN

• ゲームはライトヘビー• 限界までキャッシング• キーバリュー型へ変更（非正規化）

• バイナリストラクチャ• データベース = ボトルネック

DBの更新頻度が課題に


シャーディングは辛い。。

データのJOINが難しいデータの集計をDBを跨いで行う必要がある同じマスターデータをそれぞれに配置する必要があるオートインクリメントが使えない・・・・・


• フルマネージド• NoSQL データストア• プロビジョンドスループット• セカンダリインデックス• PUT/GET keys• TTL サポート• ドキュメント型のサポート• 400 KB アイテム• PITR可能なバックアップ• Amazon DynamoDB Accelerator

(Cache)

ELB

Region

CloudFrontCDN

Amazon DynamoDB


• パーティションキー= Primary key• ほとんどのゲームでのアクセスはUserIDをキーにデータ取得• スキーマを変更することなくアプリケーション側に値を追加するだけで、テーブル設計を変更可能（スキーマレス）

UserID(Partion key)

Level TopScore LastAccessTime

"101" 1 0 “2017-09-15T17:24:31"

"102" 10 1000 "2018-05-22T23:18:01"

"103" 35 3355 "2018-05-30T13:14:21"

"104" 1 192 "2018-05-12T11:07:56"

"105" 3 2224 "2018-05-18T07:33:42"

ユーザデータをDynamoDBで管理

Weapon

“Sword”

“Club”

“Knife”

Armor

“Chain Mail”

“Cloths”

{”UserID": {"S": ”103"},”Level": {”N":24},”TopScore": {”N":3355},” LastAccessTime": {"S": " 2018-05-30T13:14:21"},

}

{”UserID": {"S": ”103"},”Level": {”N":24},”TopScore": {”N":3355},” LastAccessTime": {"S": " 2018-05-30T13:14:21"},” Weapon": {"S": ” Sword"},” Armor": {"S": ” Chain Mail"}

}

これまでのSQLでの実装は？Select * from UserDatawhere UserID =”103”;

Select * from UserItemwhere UserID =”103”;


• パーティションキー= Primary key• ほとんどのゲームでのアクセスはUserIDをキーにデータ取得• スキーマを変更することなくアプリケーション側に値を追加するだけで、テーブル設計を変更可能（スキーマレス）

• Document型（JSON形式）も利用可能• TTLを活用してリセマラなどの要らなくなったデータを削除

UserID(Partion key)

Level TopScore LastAccessTime

"101" 1 0 “2017-09-15T17:24:31"

"102" 10 1000 "2018-05-22T23:18:01"

"103" 35 3355 "2018-05-30T13:14:21"

"104" 1 192 "2018-05-12T11:07:56"

"105" 3 2224 "2018-05-18T07:33:42"

ユーザデータをDynamoDBで管理

Weapon

“Sword”

“Club”

“Knife”

Armor

“Chain Mail”

“Cloths”

{”UserID": {"S": ”103"},”Level": {”N":24},”TopScore": {”N":3355},” LastAccessTime": {"S": " 2018-05-30T13:14:21"},” Weapon": {"S": ” Sword"},” Armor": {"S": ” Chain Mail"},”Item": {

"M": {"Potion": { "N": ”10" },"Revive": { "N": ”22" }

}}

Item

{“Potion”:10, ”Revive":22}

{"Potion":25}

{“Potion”:18, "Revive":33}

"101" 1 0 “2017-09-15T17:24:31"


Amazon DynamoDBを使ったマイクロサービス構成

AWS

Lambda

Amazon

DynamoDB

Amazon API

Gateway

Amazon

DynamoDB Stream

AWS

Lambda

Amazon S3

Amazon ES

Amazon

Athena

Amazon

DynamoDB

Query sideOLTP/Command side

1. API Gateway + Lambda + Amazon DynamoDB

コアとなるAPIバックエンドサーバ2. DynamoDB Streams + AWS Lambda

信頼性の高いイベントドリブンなシステム


API Gateway /games GET -

DynamoDB Table“games”

Lambda Function“getGames”

API GW/games GET

Response

Request


Region

マルチプレイヤーゲームサーバ

① APIを使ったログイン② マッチメイキング③ ゲームサーバのIPを取得

REST APIやgRPC(HTTP/2)を使った接続

マッチメイクに応じてインスタンスの起動やサーバアプリの準備を行う


Application Load Balancer

Amazon EC2

gRPCクライアント

gRPCを使ったAPI接続の注意点

Network Load Balancer

Amazon EC2

HTTP/1.1HTTP/2Application Load Balancer(ALB)は、HTTP/2への対応を行なっているがALBのバックエンドは、HTTP/1.1 となるためgRPCのクライアント・サーバ間で通信ができない

gRPC gRPC

gRPCサーバ

• Application Load Balancer

Network Load Balancer(NLB)TCP(L4)のバランサとして利用

※Idle Timeoutが350秒固定のためKeep Alive時のタイムアウトに注意

gRPCサーバ

• Network Load Balancer

HTTP/2gRPC

HTTP/2gRPC

gRPCクライアント


• 2系統のgRPC• Web APIの役割のステートレスな

gRPC• ゲームバトルのリアルタイム通信用ステートフルなgRPC

• CLB（TCPモード）を使った通信(ローンチ時はNLBが未リリース）

• データの永続化はRedis Cluster (ElastiCache)とAuroraを利用

• サーバの振り分けはLambda（C#)で実装

事例）黒騎士と白の魔王 –株式会社グラニ様

AWS Summit Tokyo2017

gRPC HTTP/2 API/

https://d1.awsstatic.com/events/jp/2017/summit/slide/game-tech/grani.pdf

https://d1.awsstatic.com/events/jp/2017/summit/slide/game-tech/grani.pdf


Region


Job

Job

Job Queue

Job

時間のかかる処理の場合、処理のキュー化も検討

Job




Region


A B C

Amazon SNSを用いたPUSHメッセージ

Amazon Simple Notification Service (SNS)

• Pub/Sub

• HTTP

•

• HTTP Amazon Simple

Queue Service (SQS) AWS Lambda

Push

• モバイルデバイスにプッシュ通知と SMS を送信Amazon SNS


Region




Region ARegion B

グローバル展開されたマルチプレイヤーゲームサーバ


• 同時接続300万にを超えるプレイヤーに耐えられる設計にする必要となった。

• 優先的に非同期処理を採用• 非同期メッセージ処理は、Amazon

SQSを利用したメッセージキューを利用• その他、DynamoDBやS3など分散アーキテ

クチャのサービスを利用

• Echo System SimulatorECSを採

用し、SQS/S3と組み合わせて非同期のシミュレーション処理を実行

• GameServerからECSへのrun taskについてはSQS/Lambdaを使って非同期に実行

Bluehole社

Nexon社


Region ARegion B

グローバルマルチプレイヤーゲームサーバ

DYNAMODB GLOBAL TABLES


AMAZON DYNAMODB GLOBAL TABLES

グルーバルに分散してるプレーヤー

Replica (N. America)

Replica (Europe)

Replica (Asia)

Global Table

初のフルマネージド、マルチマスター, マルチリージョンデータベース

高性能でグローバルに分散したアプリケーションを構築する

ローカルのテーブルに対して低レイテンシで読み込みと書き込み

マルチリージョンの冗長性を備えた高い災害対策

セットアップが簡単で、アプリケーションの修正は不要


Gaming Analytics


Amazon S3

データ分析

Elastic MapReduce

Redshift

データバックアップ

EC2 RDS

Storage Gateway

EBS

Redshift

コンテンツ配信

CloudFrontGlue

データアーカイブ

Glacier

Amazon S3を中心としたデータレイク

Athena

Amazon Lex

Amazon PollyAmazon Rekognition

Amazon Machine Learning

機械学習サービスの活用

IoT

AWS IoT

BI

QuickSight

データの加工 (ETL)


Asking Questions - Breakaway

{‘event_id’ : ‘05b00439-6a07-4112-9c8d-165f1643e5d1’, ‘event_type’ : ‘player_death’, ‘event_timestamp’ : ‘2017-05-01T21:05:18.000Z’, ‘arena’ : ‘el_dorado’, ‘position_x’ : 507.12, ‘position_y’ : 551.61 }


Breakawayの事例Death地点のヒートマップを作成し、マップを改善

中央での大量のDeath発生はRelic(アイテム)の配置によるもので予想どおり。Relicの配置によりDeathの位置調整が可能な確証が得られた。

アリーナが見渡せるジグラット付近のコーナーが危険だと判明、予想外。調査が必要。


BreakawayでのAnalytics Pipeline


Star Wars Galaxy of HeroesでのAnalytics Pipeline

How EA Leveraged Amazon Redshift and AWS Partner 47Lining to Gather Meaningful Player Insightshttps://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-gam301-how-ea-leveraged-amazon-redshift-and-aws-partner-47lining-to-gather-meaningful-player-insights

https://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-gam301-how-ea-leveraged-amazon-redshift-and-aws-partner-47lining-to-gather-meaningful-player-insights


Star Wars Galaxy of HeroesでのAnalytics Pipeline Ingest/Collect


Gaming Analytics Pipeline on AWS

http://docs.aws.amazon.com/ja_jp/solutions/latest/gaming-analytics-pipeline/welcome.html

Breakawayで実績のある分析プラットフォームを1クリックでCloudFormationから作成可能

GlobalInfrastructure

& Services

Pre-builtGame Services

& Tools

ContentCreation

Tools

Distribution&

Marketing


AWS

AWS

AWS


参考資料• ゲームの向けのAWS

https://aws.amazon.com/jp/gaming/• Amazon Game Tech

https://aws.amazon.com/jp/gametech/• Amazon Game Tech Blog

https://aws.amazon.com/jp/blogs/gametech/• AWS でのマルチプレイヤーゲームサーバーのパフォーマンス最適化• AWS でスケーラブルなゲームパターンを実装する方法

(Gaming whitepaper)

https://aws.amazon.com/jp/whitepapers/

https://aws.amazon.com/jp/gaming/

https://aws.amazon.com/jp/gametech/

https://aws.amazon.com/jp/blogs/gametech/

https://aws.amazon.com/jp/whitepapers/



Documents

PowerPoint Presentation · • コンソール系ゲーム会社（テクニカルディレクター） • ブラウザソーシャルゲーム、スマートフォン向けソーシャルゲーム