Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

0

Partager

Télécharger pour lire hors ligne

Architecting for Failure in a Containerized World

Télécharger pour lire hors ligne

My presentation from QConSF 2016 outlining some design strategies for building robust applications in the docker and container ecosystem. Video coming soon, I hope.

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir
  • Soyez le premier à aimer ceci

Architecting for Failure in a Containerized World

  1. 1. Architecting for Failure in a Containerized World Tom Faulhaber Infolace
  2. 2. How can container tech help us build robust systems?
  3. 3. Key takeaway: an architectural toolkit for building robust systems with containers
  4. 4. The Rules Decomposition Orchestration and Synchronization Managing Stateful Apps
  5. 5. Simplicity
  6. 6. Simple means: “Do one thing!”
  7. 7. The opposite of simple is complex
  8. 8. Complexity exists within components
  9. 9. Complexity exists between components
  10. 10. Example: a counter Counter Service 1 2 3 4 50 … Counter Service 1 2 3 4 50 …x Counter Service 1 2 3 4 50 1 2 3 4 50 1 2 3 4 50
  11. 11. Example: a counter Counter Service 1 2 3 4 50 … Counter Service 1 2 3 4 50 … Load Balancer 1 2 3 4 50 1 2 3 4 50
  12. 12. State + composition = complexity
  13. 13. Part 1: Decomposition
  14. 14. Rule: Decompose vertically
  15. 15. App Server Service #1 Service #2 Service #3
  16. 16. App Server
  17. 17. Rule: Separation of concerns
  18. 18. Example: Logging App Core Code Logging Driver Config Logging Server
  19. 19. Example: Logging Logger App Core Code Logging Driver Config Logging Server StdOut
  20. 20. Aspect-oriented programming
  21. 21. Rule: Constrain state
  22. 22. Relational DB Session Store
  23. 23. Rule: Battle-tested tools
  24. 24. Redis MySQL
  25. 25. Rule: High code churn →Easy restart
  26. 26. Rule: No start-up order!
  27. 27. time a b c d
  28. 28. time x a b c d
  29. 29. time x a b c d x x x
  30. 30. time x a b c d x x x
  31. 31. time a b c d
  32. 32. time a b c d
  33. 33. time a b c d
  34. 34. Rule: Consider higher-order failure
  35. 35. The Rules Decomposition Decompose vertically Separation of concerns Constrain state Battle-tested tools High code churn, easy restart No start-up order! Consider higher-order failure Orchestration and Synchronization Managing Stateful Apps
  36. 36. Part 2: Orchestration and Synchronization
  37. 37. Rule: Use Framework Restarts
  38. 38. • Mesos: Marathon always restarts • Kubernetes: RestartPolicy=Always • Docker: Swarm always restarts
  39. 39. Rule: Create your own framework
  40. 40. Mesos Agent Framework Executor Mesos Master Framework Driver Mesos Agent Framework Executor Mesos Agent Framework Executor
  41. 41. Rule: Use Synchronized State
  42. 42. Synchronized State Tools: - zookeeper - etcd - consul Patterns: - leader election - shared counters - peer awareness - work partitioning
  43. 43. Rule: Minimize Synchronized State
  44. 44. Even battle-tested state management is a headache. (Source: http://blog.cloudera.com/blog/2014/03/zookeeper-resilience-at-pinterest/)
  45. 45. The Rules Decomposition Decompose vertically Separation of concerns Constrain state Battle-tested tools High code churn, easy restart No start-up order! Consider higher-order failure Orchestration and Synchronization Use framework restarts Create your own framework Use synchronized state Minimize synchronized state Managing Stateful Apps
  46. 46. Part 3: Managing Stateful Apps
  47. 47. Rule (repeat!): Always use battle-tested tools! (State is the weak point)
  48. 48. Rule: Choose the DB architecture
  49. 49. Option 1: External DB Execution cluster Database cluster
  50. 50. Option 1: External DB Pros • Somebody else’s problem! • Can use a DB designed for clustering directly • Can use DB as a service Cons • Not really somebody else’s problem! • Higher latency/no reference locality • Can’t leverage orchestration, etc.
  51. 51. Option 2: Run on Raw HW HDFS Mesos Marathon App HDFS Mesos Marathon App HDFS Mesos Marathon App
  52. 52. Option 2: Run on Raw HW Pros • Use existing recipes • Have local data • Manage a single cluster Cons • Orchestration doesn’t help with failure • Increased management complexity
  53. 53. Option 3: In-memory DB Mesos Marathon App MemSQL Mesos Marathon App MemSQL Mesos Marathon App MemSQL
  54. 54. Option 3: In-memory DB Pros • No need for volume tracking • Fast • Have local data • Manage a single cluster Cons • Bets all machines won’t go down • Bets on orchestration framework
  55. 55. Option 4: Use Orchestration Mesos Marathon App Cassandra Mesos Marathon App Cassandra Mesos Marathon App Cassandra
  56. 56. Option 4: Use Orchestration Pros • Orchestration manages volumes • One model for all programs • Have local data • Single cluster Cons • Currently the least mature • Not well supported by vendors
  57. 57. Option 5: Roll Your Own Mesos Marathon App ImageMgr Mesos Master Framework Mesos Marathon App ImageMgr Mesos Marathon App ImageMgr
  58. 58. Option 5: Roll Your Own Pros • Very precise control • You decide whether to use containers • Have local data • Can be system aware Cons • You’re on your own! • Wedded to a single orchestration platform • Not battle tested
  59. 59. Rule: Have replication
  60. 60. The Rules Decomposition Decompose vertically Separation of concerns Constrain state Battle-tested tools High code churn, easy restart No start-up order! Consider higher-order failure Orchestration and Synchronization Use framework restarts Create your own framework Use synchronized state Minimize synchronized state Managing Stateful Apps Battle-tested tools Choose the DB architecture Have replication
  61. 61. Fin
  62. 62. References • Rich Hickey:
 “Are We There Yet?” (https://www.infoq.com/presentations/Are-We- There-Yet-Rich-Hickey)
 “Simple Made Easy” (https://www.infoq.com/presentations/Simple- Made-Easy-QCon-London-2012) • David Greenberg, Building Applications on Mesos, O’Reilly, 2016 • Joe Johnston, et al., Docker in Production: Lessons from the Trenches, Bleeding Edge Press, 2015
  63. 63. The Rules Decomposition Decompose vertically Separation of concerns Constrain state Battle-tested tools High code churn, easy restart No start-up order! Consider higher-order failure Orchestration and Synchronization Use framework restarts Create your own framework Use synchronized state Minimize synchronized state Managing Stateful Apps Battle-tested tools Choose the DB architecture Have replication

My presentation from QConSF 2016 outlining some design strategies for building robust applications in the docker and container ecosystem. Video coming soon, I hope.

Vues

Nombre de vues

198

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

18

Actions

Téléchargements

5

Partages

0

Commentaires

0

Mentions J'aime

0

×