Simply Distributed

Transcript

1. Simply Distributed KNIF 2015, Bandung
2. Who? Nugroho Herucahyono @xinuc Programmer @Bukalapak
3. Keandalan Sistem dalam Mendukung Penyediaan Layanan
4. “Andal" => reliable & scalable
5. reliable: fault tolerant scalable: able to grow
6. How a reliable & scalable system built?
7. Most systems start small
8. Typical web application Webserver Database Client
9. Typical web application • Need more features • Serve more users • Need to be more reliable
10. More features Add more code Split the system
11. More users Need to scale machine limitation add more machines
12. More business value Need more reliable System should be fault tolerant Self healing Backup, redundancy
13. How we do it? Current “Best practice”: • Split system into smaller services • Communicate with http • Scale independently • Gracefully handle failure
14. How we do it? Load Balancer Search Engine Client Authentication Content Management Search Scheduler Transaction Database 2 Database 1 Job Queue
15. How we do it? Current “Best practice” apparently is not the best: • Requires massive change to our system • Manual load balancing, replication • Manual resource management • Inefficient communication (http? really?)
16. How we do it? Load Balancer Search Engine Client Authentication Content Management Search Scheduler Transaction Database 2 Database 1 Job Queue Too Complicated!!
17. What would a good computer scientist do?
18. Introduce a new layer of abstraction!
19. A new layer of abstraction • Handle resource management • Handle load balancing • Handle service communication • Handle service failure • Handle replication
20. A new layer of abstraction We need “Operating System” of a cluster
21. A new layer of abstraction Cluster Operating system Operating System Pod Application Hardware Operating System Pod Application Hardware Operating System Pod Application Hardware
22. Cluster Operating System • Build in interprocess communication • Build in monitoring & supervision • Automatic load balancing • Automatic resource management • Scale with little / no system modification
23. What do we have now? • Erlang VM & OTP • Docker, Kubernetes
24. Erlang VM & OTP node 1 erlang vm erlang processes node 2 erlang vm erlang processes
25. Erlang VM & OTP Supervisor Supervisor Worker Worker Worker Worker Worker OTP Supervision Tree
26. Erlang VM & OTP • Build in interprocess communication √ • Build in monitoring & supervision √ • Automatic load balancing X • Automatic resource management X • Scale with little / no system modification √
27. Erlang VM & OTP • The building block is too low level? (erlang processes) • Your application need to be written in erlang (or other erlang vm languages)
28. Docker • Like virtual machine, but much lighter • Encapsulate our application into single “executable” • Remove dependencies, development vs production headache
29. Docker Host OS Docker Container Container Container Server
30. Kubernetes • Manages & monitors containers • Resource allocation between containers
31. Kubernetes Host OS Docker Container Container Pod Host OS Docker Container Container Pod Node 1 Node 2 Kubernetes
32. Docker & Kubernetes • Build in interprocess communication X • Build in monitoring & supervision √ • Automatic load balancing √ • Automatic resource management √ • Scale with little / no system modification X
33. Docker & Kubernetes • No build in interprocess communication • Still have to modify the system (split into smaller services) • Too complicated
34. Can we do better?
35. Let’s zoom out a bit • Service vs Process • Node vs Core They’re conceptually the same
36. Maybe we can push down the abstraction layer?
37. What if, our “Cluster operating system” is a real Operating System?
38. We need a real “Distributed Operating System”
39. Distributed Operating System Operating System Application Hardware Hardware Hardware
40. Distributed Operating System • Encapsulate multiple machines as a single node • Transparent from user / application point of view • Handle load balancing, replication & distribution automatically • Better yet, if we can add more machine on the fly
41. Is it possible? I have no idea.
42. We’ve done something similar • Raid • Multiple disk, single volume • Transparent from applications • Automatic failure handling & replication
43. We need Raid for CPU & Memory
44. Or maybe, we can push it down further, to the hardware level?
45. We need a real “Distributed Motherboard” :D
46. Distributed Operating System Operating System Application Hardware
47. Distributed Motherboard • Node 1, 32 Cores, 32 GB RAM • Node 2, 32 Cores, 32 GB RAM • Detected by operating system as 1 Node, 64 Cores, 64 GB RAM
48. Distributed Motherboard • We can add more node, on the fly • Motherboard will communicate between each other • Abstract their resources as a SINGLE NODE
49. Again, is it possible? I have no idea.
50. We’ve done that too • Hardware Raid Controller • Multiple Disk, detected as a single hardware • Transparent from operating system & application
51. Too much wishful thinking?
52. Why does it matter?
53. Why does it matter? Scalable & Reliable system is a SOLVED problem We already have Google, Facebook, etc as a prove
54. Why does it matter? • Scalable & Reliable system is not easy & cheap • Need a group of highly skilled experts to build
55. Case Study: WhatsApp
56. Case Study: WhatsApp • WhatsApp use Erlang VM & OTP • They can scale it without adding too much complexity
57. Case Study: WhatsApp
58. Case Study: WhatsApp We need more companies like WhatsApp
59. Small Startups? Can 4-fresh-graduate startup create a product used by a billion users?
60. Non profits? Can we create non profit system than serve billons of users?
61. ./bukalapak
62. more research on this, please :)
63. Thank you