• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
AWS Customer Presentation -Playfish
 

AWS Customer Presentation -Playfish

on

  • 1,657 views

AWS Tech Summit, London

AWS Tech Summit, London
9th November

Social gaming company, Playfish, discusses how they use Amazon Web Services to keep up with epic growth and scale.

Statistics

Views

Total Views
1,657
Views on SlideShare
1,650
Embed Views
7

Actions

Likes
1
Downloads
47
Comments
0

2 Embeds 7

http://blog.fasoulas.com 4
http://fasoulas.posterous.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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
  • And since you’re all here, I’d just like to tell you what a great place Playfish is to work And how you should all apply! We’re hiring many different roles in London Java, JavaScript, and ActionScript developers operations people architects Hadoop/etl engineers Something like 16 different positions listed in London, and more in other offices Check out our job site and apply today!
  • Now – questions!

AWS Customer Presentation -Playfish AWS Customer Presentation -Playfish Presentation Transcript

  • changing how the world plays games
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  • scale
  • scale
  • scale
  • scale
  • numbers
    • unique users per month: 50M
    • unique users per day: 10M
    • unique users in peak hour: 1.5M
    • http requests on one game in peak hour: 45M
    • analytics events processed per day: 500M
    • analytics data generated per month: 2TB
    • physical servers ever owned: 0
  • ec2 s3 elastic load balancing elastic mapreduce rds ebs simpledb cloudfront sqs
  • aws numbers
    • number of servers: >1000
    • s3 storage used: >100TB
    • data transfer per month: >2PB
    • cloudfront http requests per month: >40,000M
  • problems image: jon ross, http://www.flickr.com/photos/jon_a_ross/1482849745/
  • well-known limitations
    • ec2 disks die
    • ec2 instances die
    • ebs volumes die
  • less well-known limitations
    • s3 bucket put rate
    • simpledb domain put rate
    • ec2 instance firewall connection rate
    • ec2 availability zone capacity
  • the good bits image: randolph femmer, http://life.nbii.gov/dml/mediadetail.do?id=10299
  • the good bits
    • flexibility
    • agility
    • small operations team
    • infrastructure not platform
    • advanced features available to all
  •  
  • thank you!