Game success leads to rapid and unpredictable growth, and high-levels of read and write traffic can make scaling games even more difficult. In this session Ubisoft and AWS cover the architectural best practices for building scalable apps and the best ways to adjust your app if it begins to slow down. This session mainly focuses on scaling databases, and we focus on the following technologies: Couchbase, Cassandra, MySQL, Amazon RDS, and Amazon DyanmoDB.

2. Amazon Elastic Amazon Relational Amazon DynamoDB
Compute Cloud Database Service
(EC2) (RDS)

4. MySQL
App M
Servers

5. MySQL
M
Asynchronous
Replication
App
Servers
MySQL
S

6. MySQL
M
App
Servers
MySQL
S

7. MySQL
M
Asynchronous
Replication
App
Servers
MySQL
S

8. MySQL
M
Asynchronous
Replication
App
Servers
MySQL
S

9. App
Servers
MySQL
M

10. MySQL
S
Asynchronous
Replication
App
Servers
MySQL
M

11. data data data data
MySQL
data data data data
M
data data data data

12. MySQL MySQL
M S
MySQL
M
MySQL MySQL
M S

15. data data
MySQL MySQL
App logs logs
M S
Servers
Asynchronous
Replication

16. data data
MySQL MySQL
logs logs
M S
Asynchronous
Replication
App
Servers
Memcached
Instance01

17. - High concurrency of requests
- Maximum instance size
- I/O capacity on the EBS volumes
- Latency on the EBS volumes

18. - Client-side caching
- Request batching
- Stripe over multiple EBS volumes
- Shard the users between multiple data base instances:
…
function getDbId($userID) {
$db_id = ($userID % CONFIG::NUM_SHARDS);
return $db_id;
}
…
- Cache extensively
- Memcache
- Application server cache

19. MySQL MySQL
data
logs
data
logs
Memcached
M S
Shard_N Shard_N
...
App MySQL MySQL
data
logs
data
logs
Memcached
Servers M
Shard_01
S
Shard_01
Memcached MySQL MySQL
data
logs
data
logs
M S
Main_01 Main_01

20. - Persistence from Memcache to MySQL
- Failure of Memcache will degrade performance of
the shard
- Horizontal scalability during growth
- Cluster maintenance

21. - Change database technology – what will that mean?
- New knowledge to be build in dev and ops
- Changes in the development process
- Data abstraction layer
- Data relation model
- Changes in the operational process
- Cluster extension and upgrades
- Monitoring, backup and recovery
- Technology maturity and support

22. - Change the least code as possible
- Re-use work already done around Memcache
- Change data structure and relation:
USR_ACHVM_ID:
USR_ID: {
USR_ACC:
{ “type_id": 1,
{
"status": 1, “cntr": 2,
“id": 83463746374,
"xp": 2, “mtime": 1352203436,
“activation_time": 1351203195,
“mtime": 1352203436, “reached": 1352203195,
“lastlogin_time": 1352203034,
"last_active": 1352203195, “sub_achvms": [2,3,4,6],
...
"last_action": 1352203200, ...
}
"frnd_lst": [34234234,12425434,34311234], }
“team_lst": [34234234,34311234],
“data": [],
...
}

23. Couchbase
data
MySQL
data
logs
Node_N
S
...
Main_02
App
Couchbase
data
Servers MySQL
data
logs
Node_02 M
Main_01
Couchbase
data
Node_01

24. - Improved performance
- Allowed for easier scalability
- Simplified the data layer
- Facilitated the cluster operations and monitoring

25. - Serialization and deserialization
- Secondary indexes*
- Text search*
- Cluster replication *
* - will be addressed in v2.0 of Couchbase or existing
workarounds

26. - Know the limitations of each component from your stack
- Do not implement new technology as a fashion trend
- Don’t cut corners for delivery – you will work twice as hard to fix them
- Development and operation teams are the best allies for success

27. rds-modify-db-instance mydbinstance -c db.m1.xlarge --apply-immediately

28. Synchronous
Replication
App
Servers

29. App
Servers

30. Synchronous
Replication
App
Servers

31. App
Servers

32. Synchronous
App Replication
Servers

33. Scaling with Amazon DynamoDB

34. We are sincerely eager to
hear your feedback on this
presentation and on re:Invent.
Please fill out an evaluation
form when you have a
chance.