Quentin ADAM slides on dotScale, about How to scale ?

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