some advice from the guy who handle your applications uptime - scalaio 2013
TRANSCRIPT
HOW TO SCALE YOUR APP SOME ADVICE FROM THE GUY WHO HANDLES YOUR APP UPTIME
QUENTIN ADAM AT SCALA.IO
@WAXZCE2013
MY DAY TO DAY WORK : CLEVER CLOUD, MAKE YOUR APP RUN ALL THE TIME
WHEN YOU NEED TO SCALE
THERE ARE 2 WAYS
GROWING AND GROWING UNTIL YOU EXPLODE OR BECOME WEIRD
OR SPLIT THE WORK AND MAKE YOUR SOFTWARE WORK AS A TEAM
Build an army of fat app
YOU CAN DO BOTH
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
BEST LONG
TERM
SOLUTION
SO, HOW TO SCALE OUT ?JUST SOME FACTS
SPLIT PROCESS AND STORAGE
Storage• Databases• Files• Sessions• Events• …
Code• Can be replicated• Stateless• Process
Picking one instance or another doesn’t matter
STATELESSNESS IS THE KEY
CONSIDER MORE THINGS AS DATA• User account
• Users data
• Files
• Sessions
• Events
TRUST YOUR MIDDLEWARE
USE AN EVENT BROKER TO MODULARIZE YOUR APP
• AMQP
• Celery
• 0MQ
• Redis
• JMS
• Even some http chunk or websocket
• Some case : hadoop, akka…
• …
CRON + FS IS NEITHER AN EVENT QUEUE NOR A JOB SCHEDULER
CHOOSE YOUR DATASTORE WISELYYOU CAN SHOULD USE MANY DATASTORES
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 ?
USE ONLINE DATABASE / BE READY TO TEST IN JUST A FEW MINUTES NO NEED TO TRASH YOUR COMPUTER
COMMON MISTAKES
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
LOGS IN FILES I HATE IT
USE STREAMING I/O TO STREAM DATA DIRECTLY TO DATABASE
HTTP Post dataTemporarily store as file
or in memory
Store it into your storage
backend
Say OK to client
USE STREAMING I/O TO STREAM DATA DIRECTLY TO DATABASE
HTTP Post data
Directly stream your data to
Storage backend
Say OK to client
DO NOT USE MEMORY AS DATABASELIKE : SHARED / GLOBAL VARIABLE, CACHE “IN THE CODE”, INTENSIVE SESSION USAGE…
DO NOT USE A VARIABLE FOR MORE THAN ONE REQUEST
F(X) = X * 2F(2) = 4^ WE ASSUME THATFOR SAME INPUT, SAME OUTPUT
You have to understand that : you’re functional programing addicts ;-)
IT’S LIKE MATH FUNCTION
Example : GET should not change data on server
RESPECT HTTP
data will be lost
CODE WILL FAIL
CAREFUL USE OF DARK MAGIC
DO NOT CREATE MONSTERS
MAKE HARD COMPUTATION ASYNC
SPLIT THE CODE : MODULES
• Smallest code base
• Deploy as service for each other
• Focus on best technology for a problem
SCALE YOUR TEAMMODULARIZE YOUR TEAM
ALWAYS USE A REVERSE PROXY
Y U NO USE ONE ?
DO NOT BUILD “THE SERVER” WITH NO DOC
USE PROCESS DEPLOYMENT
THE GOOD WAY OF DEPLOY AN APP :
git push
EASY MOVING OR INCIDENT MANAGEMENT
KEEP CALM UNDER FIRE
TRACK BUG & GET METRICS
I’m @waxzce on twitter
I’m the CEO of
a non exclusive scala PaaS provider, give it a try ;-)
THX FOR LISTENING & QUESTIONS TIME
sponsors