Customer Presentaion-LittleBigPlanet: Taking an Idea to Market Using AWS

2,113 views

Published on

Slides from a customer presentation at the 'Powering games with Amazon Web Services' event in London.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,113
On SlideShare
0
From Embeds
0
Number of Embeds
1,261
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 2008ish
  • SONY MIDDLEWEAR
  • Teams – development (ci), production support (make deploy), ops (deploy), project management
  • Process with many steps
  • Process with many steps
  • Process with many steps
  • Worked at the start, worked well with some performance and bugfixes
  • System not designed for us, complexity added while making it fit our needs
  • Existing tools weren’t designed to solve our problems.
  • Programmable API. Free from resource constraints, utility billing great, S3 great – http endpoint.
  • Programmable API. Free from resource constraints, utility billing great, S3 great – http endpoint.
  • To his eternal shame
  • Less overhead in connections, 80k threads on one connection, minimal context switching, less memory use
  • Multiple connections share same RPC socket, ruby + cpp both speak same protocol
  • ~50 instances
  • In our case, hard to model users, don’t know if instances are all the same, contention
  • Customer Presentaion-LittleBigPlanet: Taking an Idea to Market Using AWS

    1. 1. Hello <ul><li>Gavin Sandie </li></ul>
    2. 2. Single ops, single dev <ul><li>6 million levels </li></ul><ul><li>10.8 million registered players </li></ul>
    3. 4. JAVA + ORACLE
    4. 5.
    5. 6. Deployment: 4 teams
    6. 7. Load testing: 3 teams
    7. 8. Support: 3 teams
    8. 9. Server Development: 1 team! 
    9. 10. System mostly “worked”
    10. 11. Problems?
    11. 12. Scalability
    12. 13. Barriers to change
    13. 14. Complexity
    14. 17. Rewrite
    15. 18.
    16. 19. AWS
    17. 20. AWS <ul><li>S3 was very appealing </li></ul>
    18. 21. Rewrite
    19. 22. Rewrite <ul><li>C++ and Ruby </li></ul>
    20. 23. AlexDB – K-V Store
    21. 24. EBS and S3 for writelogs
    22. 25. Fast resource serving (via S3 and haystacks)
    23. 26.
    24. 27. Telemetry events in SQS
    25. 28. Ruby
    26. 29. Business logic
    27. 30. Webapp framework
    28. 31. and S3
    29. 32. Infrastructure
    30. 33. Provisioning
    31. 34. Deployment
    32. 35. Deployment <ul><li>Simple DSL </li></ul><ul><li>Single line commands </li></ul>
    33. 36. <ul><li>PROVISION </li></ul><ul><li>$ ./provision production </li></ul>BUILD + DEPLOY $ ./build.sh $ switch_env production $ ./deploy 1234 BUILD + DEPLOY $ ./build.sh $ switch_env production $ ./deploy 1234
    34. 37. Configuration management
    35. 38. Non-blocking architecture
    36. 39. Simple RPC-like protocol
    37. 40. What did we learn/discover?
    38. 41. Large env – one small team
    39. 42. Deploy / Load testing Support / Development
    40. 43. On demand testing envs
    41. 44. On demand testing envs <ul><li>Uses the same code as production envs </li></ul>
    42. 45. Load testing is hard
    43. 46. Tools/code reuse
    44. 47. Tools/code reuse <ul><li>Tools should work with real hardware as well as virtual </li></ul>
    45. 48. 6 Million levels (and rising...)
    46. 49. Concurrent players (max) 20k / 30k / 80k all time peak
    47. 50. 1Tb data transfer per day
    48. 51. 3 billion k/v pairs stored
    49. 52. 3000 req/second (all-time peak: 20krps)
    50. 53. Focused
    51. 54. Communications
    52. 55. Thanks

    ×