How to scale ?

Slides for dotScale 2013 opening talk : How to scale

Transcript

1. SCALING, WHAT YOU NEED TO KNOW QUENTIN ADAM @WAXZCE CLEVER CLOUD CEO 2013
2. WHEN YOU NEED TO SCALE THERE ARE 2 WAYS
3. GROWING AND GROWING UNTIL YOU EXPLODE OR BECOME WEIRD
4. OR SPLIT THE WORK AND MAKE YOUR SOFTWARE WORK AS A TEAM
5. Build an army of fat app YOU CAN DO BOTH
6. SO WE NEED TO BE ABLE TO DISPATCH THE WORK SCALE OUT •  Many workers doing the same thing •  No SPOF •  Growing is more easy •  Introduce best practice SCALE UP •  1 Fat instance •  1 Fat application •  SPOF (single point of failure) •  Hard to maintain •  Always has a limit •  Short term meaning
7. SO, HOW TO SCALE OUT ? JUST SOME FACTS
8. SPLIT PROCESS AND STORAGE Storage • Databases • Files • Sessions • Events • … Code • Can be replicated • Stateless • Process
9. Picking one instance or another doesn’t matter STATELESSNESS IS THE KEY
10. CONSIDER MORE THINGS AS DATA •  User account •  Users data •  Files •  Sessions •  Events
11. CHOOSE DATASTORE WISELY YOU CAN SHOULD USE MANY DATASTORES
12. DATASTORE CHOICES ARE DRIVEN BY USAGE Make decisions based on needs Do I need atomicity of requests ? Do I need concurrent access ? Do I mostly read or write ? Do I need relational ? Do I need big storage capacity ? Do I need high availability ?
13. •  Not a big volume •  DB have to manage data TTL •  Data model : K/V •  Multiple writes at the same time •  High availability I need to store sessions QUICK EXAMPLE
14. •  Not a big volume It’s OK, PG can handle small quantity of data •  DB have to manage data TTL No, I have to do it manually •  Data model : K/V No, PG is relational (mainly) •  Multiple writes at the same time No, PG is Atomic •  High availability PG is awesome ;-) Use of PG bouncer or similar allow good clustering I need to store sessions QUICK EXAMPLE
15. •  Not a big volume It’s OK, redis can handle small quantity of data •  DB have to manage data TTL Yes Redis can do it •  Data model : K/V Yes •  Multiple writes at the same time No, redis is pseudo Atomic (master/slave) •  High availability Redis is great, but cauterization is rude… I need to store sessions QUICK EXAMPLE
16. •  Not a big volume It’s OK, redis can handle small quantity of data •  DB have to manage data TTL Yes redis can do it •  Data model : K/V Yes •  Multiple writes at the same time OK, this is possible with memcached protocol •  High availability Clustering is built in, no downtime J I need to store sessions QUICK EXAMPLE
17. USE ONLINE DATABASE / BE READY TO TEST IN JUST A FEW MINUTES NO NEED TO TRASH YOUR COMPUTER
18. DON’T BE THAT GUY
19. DO NOT USE A TECHNOLOGY BECAUSE YOU <3 IT OR BECAUSE IT’S HYPE : USE IT BECAUSE IT FITS YOUR NEEDS BALANCE YOUR LEARNING CURVE WITH THE TIME SAVED
20. DO NOT CREATE MONSTERS
21. COMMON MISTAKES
22. DO NOT USE MEMORY AS DATABASE LIKE : SHARED / GLOBAL VARIABLE, CACHE “IN THE CODE”, INTENSIVE SESSION USAGE…
24. DO NOT USE A VARIABLE FOR MORE THAN ONE REQUEST
25. 2 + 2 = 4 FOR SAME INPUT, SAME OUTPUT
26. And data will be lost CODE WILL FAIL
27. DO NOT USE FILE SYSTEM AS DATASTORE File system are POSIX compliant •  POSIX is ACID •  POSIX is powerful but is bottleneck •  File System is nightmare of ops •  File System is create coupling (host provider/OS/language) •  Free SPOF multi tenant File System is a unicorn STORE IN DATABASE, OR DATASTORE LIKE S3 (AWS) DEDICATED TO FILE MANAGEMENT
28. CAREFUL USE OF DARK MAGIC
29. SPLIT THE CODE : MODULES •  Smallest code base •  Deploy as service for each other •  Focus on best technology for a problem
30. USE EVENT BROKER TO MODULARIZE YOUR APP •  AMQP •  Celery •  0MQ •  Redis •  JMS •  Some case : hadoop, akka… •  … CRON is not an event queue
31. MAKE HARD COMPUTATION ASYNC
32. ALWAYS USE A REVERSE PROXY Y U NOT USE ONE ?
33. USE PROCESS DEPLOYMENT
34. KEEP CALM UNDER FIRE
35. TRACK BUG & GET METRICS
36. Quentin ADAM Twitter : @waxzce THX FOR LISTENING & QUESTIONS TIME clever c l o u d