Some advice from the guy who handle your applications uptime - scalaIO 2013
Download as PPTX, PDF3 likes1,080 views
This document provides advice on how to scale applications from Quentin Adam, who handles app uptime at Scala.io. It discusses two approaches to scaling: scaling up using a single large instance, which has single point of failure issues; and scaling out by splitting work across multiple instances. Key recommendations include: using statelessness, splitting processes and storage, choosing data stores wisely based on needs, avoiding files systems and memory as databases, respecting HTTP standards, making hard computations asynchronous, splitting code into modules, always using a reverse proxy, keeping documentation and deployments simple, tracking bugs and metrics.
Some advice from the guy who handle your applications uptime - scalaIO 2013
- 1. HOW TO SCALE YOUR APP SOME ADVICE FROM THE GUY WHO HANDLES YOUR APP UPTIME QUENTIN ADAM AT SCALA.IO @WAXZCE 2013
- 2. MY DAY TO DAY WORK : CLEVER CLOUD, MAKE YOUR APP RUN ALL THE TIME
- 3. THERE ARE 2 WAYS WHEN YOU NEED TO SCALE
- 4. GROWING AND GROWING UNTIL YOU EXPLODE OR BECOME WEIRD
- 5. OR SPLIT THE WORK AND MAKE YOUR SOFTWARE WORK AS A TEAM
- 6. YOU CAN DO BOTH Build an army of fat app
- 7. SO WE NEED TO BE ABLE TO DISPATCH THE WORK SCALE OUT SCALE UP • Many workers doing the same thing • 1 Fat instance • 1 Fat application • No SPOF • SPOF (single point of failure) • Growing is more easy • Hard to maintain • Introduce best practice • Always has a limit • Short term meaning
- 8. SO, HOW TO SCALE OUT ? JUST SOME FACTS
- 9. SPLIT PROCESS AND STORAGE Storage • Databases • Files • Sessions • Events •… Code • Can be replicated • Stateless • Process
- 10. STATELESSNESS IS THE KEY Picking one instance or another doesn’t matter
- 11. CONSIDER MORE THINGS AS DATA • User account • Users data • Files • Sessions • Events
- 13. USE AN EVENT BROKER TO MODULARIZE YOUR APP • AMQP • Celery • 0MQ • Redis • JMS • Even some http chunk or websocket • Some case : hadoop, akka… • …
- 14. CRON + FS IS NEITHER AN EVENT QUEUE NOR A JOB SCHEDULER
- 15. CHOOSE YOUR DATASTORE WISELY YOU CAN SHOULD USE MANY DATASTORES
- 16. DATASTORE CHOICES ARE DRIVEN BY USAGE Do I mostly read or write ? Do I need relational ? Do I need concurrent access ? Do I need atomicity of requests ? Do I need big storage capacity ? Make decisions based on needs Do I need high availability ?
- 17. USE ONLINE DATABASE / BE READY TO TEST IN JUST A FEW MINUTES NO NEED TO TRASH YOUR COMPUTER
- 18. COMMON MISTAKES
- 19. DO NOT USE THE FILE SYSTEM AS A DATASTORE File system are POSIX compliant • • • • • POSIX is ACID POSIX is powerful but is a bottleneck File System is the nightmare of ops File System creates coupling (host provider/OS/language) SPOF-free multi tenant File System is a unicorn STORE IN DATABASE, OR IN A DATASTORE LIKE S3/RIAKCS DEDICATED TO FILE MANAGEMENT
- 20. LOGS IN FILES I HATE IT
- 21. USE STREAMING I/O TO STREAM DATA DIRECTLY TO DATABASE HTTP Post data Temporarily store as file or in memory Store it into your storage backend Say OK to client
- 22. USE STREAMING I/O TO STREAM DATA DIRECTLY TO DATABASE HTTP Post data Directly stream your data to Storage backend Say OK to client
- 23. 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. F(X) = X * 2 F(2) = 4 ^ WE ASSUME THAT FOR SAME INPUT, SAME OUTPUT
- 26. IT’S LIKE MATH FUNCTION You have to understand that : you’re functional programing addicts ;-)
- 27. RESPECT HTTP Example : GET should not change data on server
- 28. CODE WILL FAIL data will be lost
- 29. CAREFUL USE OF DARK MAGIC
- 30. DO NOT CREATE MONSTERS
- 32. SPLIT THE CODE : MODULES • Smallest code base • Deploy as service for each other • Focus on best technology for a problem
- 33. SCALE YOUR TEAM MODULARIZE YOUR TEAM
- 34. ALWAYS USE A REVERSE PROXY Y U NO USE ONE ?
- 35. DO NOT BUILD “THE SERVER” WITH NO DOC
- 37. THE GOOD WAY OF DEPLOY AN APP : git push
- 38. EASY MOVING OR INCIDENT MANAGEMENT
- 39. KEEP CALM UNDER FIRE
- 40. TRACK BUG & GET METRICS
- 41. THX FOR LISTENING & QUESTIONS TIME I’m @waxzce on twitter I’m the CEO of sponsors a non exclusive scala PaaS provider, give it a try ;-)