At this point I should probably tell that you that playfish was founded with this goal
We make social games – here are just a few of them
We launched our first game, Who Has the Biggest Brain? way back in December 2007
Since then our games have become much richer, starting with this game, Pet Society, Which lets people adopt a pet and decorate a house for it…
… and chat with other pets and owners.
Restaurant City puts the player in the place of a restaurant owner You build a restaurant up and decorate it how you like…
… whether as a rock-themed bar …
… or something Barbara Cartland might go to.
More recently, we have added a couple of sports games A FIFA-branded football game…
… and a Madden-branded American football game.
Since November last year, we’ve been part of Electronic Arts.
So, a little bit about the scale of what we do. This graph shows how the number of game users has grown over time. It starts when we launched our first game. As you can see, impressive growth! …
… until you see what the scales are. … This graph is actually just the first month that Playfish had a game out. After that, things grew a LOT faster…
… as you can see here. the pink box highlights what was shown on the last graph. This graph shows the first six months - we’d almost reached a million users, two orders of magnitude more than the last graph…
… but things continued to grow. Once again, the pink box highlights the last graph. How do you cope with that growth?
A few numbers showing roughly where we’re at currently (*) In one month, about 50 million people will play one of our games (*) Each day, about 10 million will (*) 1.5 million of those will do so during just one hour of that day And during that hour, on just one of our 15 games, we’ll see (*) 45 million http requests This doesn’t even include static content – these are just requests to our app servers on just one game. To make our products better, we want to analyse what these users are up to (*) Meaning that we have to process 500 million separate analytics events per day (*) And around 2 terabytes of analytics data per month. But in all the time that Playfish has been going (*) we’ve never owned a single server.
So, I’m sure given that this is an AWS event that you’ve guessed that we use AWS. (*) The big three for us are EC2, S3, and CloudFront. (*) All of our app servers, databases and load balancers run on EC2. All of our static data is stored in S3 and served via CloudFront. All of our backups and dynamically generated data are also stored in S3. (*) (*) We’re now using SQS for some backend services. (*) (*) And we’re using Elastic MapReduce along with Hive to process our analytics data. (*) Two services we’re not using are elastic load balancing and relational database service (*) This is simply because they didn’t exist when we started out, and we had already Rolled our own versions by the time they came out
It’s not all been plain sailing
There are several things that are well documented as limitations to be aware of (*) (*) (*) Experienced AWS users will have seen all of these, and they’re fundamentally no different to dealing with physical hardware. Assume that things might fail, and make sure it’s not catastrophic when it does.
There are also some limitations that are less well understood (*) (*) (*) (*) These are really examples of where the abstractions start to leak a bit. One piece of advice I’d offer here is to take the premium support, which is really helpful when these things happen.
But enough about problems – what about the good bits?
On ‘agility’, anecdote about pets shards IaaS not PaaS: lower risk (lower knowledge barrier, lower risk if decide to migrate elsewhere) Advanced features: availability zones, highly reliable distributed storage, block store migrated between machines
numbers <ul><li>unique users per month: 50M </li></ul><ul><li>unique users per day: 10M </li></ul><ul><li>unique users in peak hour: 1.5M </li></ul><ul><li>http requests on one game in peak hour: 45M </li></ul><ul><li>analytics events processed per day: 500M </li></ul><ul><li>analytics data generated per month: 2TB </li></ul><ul><li>physical servers ever owned: 0 </li></ul>
aws numbers <ul><li>number of servers: >1000 </li></ul><ul><li>s3 storage used: >100TB </li></ul><ul><li>data transfer per month: >2PB </li></ul><ul><li>cloudfront http requests per month: >40,000M </li></ul>
problems image: jon ross, http://www.flickr.com/photos/jon_a_ross/1482849745/
well-known limitations <ul><li>ec2 disks die </li></ul><ul><li>ec2 instances die </li></ul><ul><li>ebs volumes die </li></ul>
less well-known limitations <ul><li>s3 bucket put rate </li></ul><ul><li>simpledb domain put rate </li></ul><ul><li>ec2 instance firewall connection rate </li></ul><ul><li>ec2 availability zone capacity </li></ul>
the good bits image: randolph femmer, http://life.nbii.gov/dml/mediadetail.do?id=10299
the good bits <ul><li>flexibility </li></ul><ul><li>agility </li></ul><ul><li>small operations team </li></ul><ul><li>infrastructure not platform </li></ul><ul><li>advanced features available to all </li></ul>