Applying principles of chaos engineering to serverless
1 like296 views
The document discusses the application of chaos engineering principles to serverless architectures, highlighting the importance of controlled experiments to test system resilience and build confidence in handling failures. It outlines a step-by-step process for conducting chaos experiments, emphasizing the need for clear communication, careful timing, and defining steady states and realistic failure injections. Additionally, it addresses challenges specific to serverless environments, such as increased complexity and unknown failure modes.
Applying principles of chaos engineering to serverless
- 1. APPLYING PRINCIPLES to SERVERLESSt a b chaos engineering of A E S of
- 3. Offices in London and Katowice
- 4. Offices in London and Katowice WE’RE HIRING! https://bit.ly/2HfLzGE
- 5. history of Smallpox est. 400K deaths per year in 18th Century Europe. earliest evidence of disease in 3rd Century BC Egyptian Mummy
- 6. history of Smallpox est. 400K deaths per year in 18th Century Europe. earliest evidence of disease in 3rd Century BC Egyptian Mummy 1798 first vaccine developed Edward Jenner
- 7. 1798 first vaccine developed 1980 history of Smallpox Edward Jenner WHO certified global eradication est. 400K deaths per year in 18th Century Europe. earliest evidence of disease in 3rd Century BC Egyptian Mummy
- 9. Vaccination is the most effective method of preventing infectious diseases
- 10. stimulates the immune system to recognize and destroy the disease before contracting the disease for real
- 11. Chaos Engineering controlled experiments to help us learn about our system’s behaviour and build confidence in its ability to withstand turbulent conditions
- 15. it’s about building confidence, NOT breaking things
- 16. I’m gonna inject you with a deadly disease now
- 18. STEP 1. define “Steady State” aka. what does normal, working condition looks like?
- 19. this is not a steady state
- 20. STEP 2. hypothesize steady state will continue in both control group & the experiment group ie. you should have a reasonable degree of confidence the system would handle the failure before you proceed with the experiment
- 21. explore unknown unknowns away from production
- 22. treat production with the care it deserves
- 23. the goal is NOT, to actually hurt production
- 24. If you know the system would break, and you did it anyway… then it’s NOT a chaos experiment. It’s called being IRRESPONSIBLE.
- 26. STEP 3. inject realistic failures e.g. server crash, network error, HD malfunction, etc.
- 30. STEP 4. disprove hypothesis i.e. look for difference with steady state
- 31. if a WEAkNESS is uncovered, improve it before the behaviour manifests in the system at large
- 32. Chaos Engineering controlled experiments to help us learn about our system’s behaviour and build confidence in its ability to withstand turbulent conditions
- 34. Chaos Engineering controlled experiments to help us learn about our system’s behaviour and build confidence in its ability to withstand turbulent conditions
- 35. communication
- 36. ensure everyone knows what you’re doing
- 37. ensure everyone knows what you’re doing NO surprises!
- 39. run experiments during office hours
- 42. smallest change that allows you to detect a signal that steady state is disrupted
- 43. rollback at the first sign of TROUBLE!
- 45. Don’t try to run before you know how to walk.
- 46. by Russ Miles @russmiles source https://medium.com/russmiles/chaos-engineering-for-the-business-17b723f26361
- 47. chaos monkey kills an EC2 instance latency monkey induces artificial delay in APIs chaos gorilla kills an AWS Availability Zone chaos kong kills an entire AWS region
- 50. there is no server…
- 51. there is no server… that you can kill
- 54. there are more inherent chaos and complexity in a Serverless architecture
- 55. smaller units of deployment and A LOT more of them!
- 56. more difficult to harden around boundaries serverful serverless
- 58. ? SNS Kinesis CloudWatch Events CloudWatch LogsIoT DynamoDB S3 SES more intermediary services, and greater variety too
- 59. ? SNS Kinesis CloudWatch Events CloudWatch LogsIoT DynamoDB S3 SES more intermediary services, and greater variety too each with its own set of failure modes
- 60. serverful serverless more configurations, more opportunities for misconfiguration
- 61. more unknown failure modes in infrastructure that we don’t control
- 62. often there’s little we can do when an outage occurs in the platform
- 65. missing fallback when downstream is unavailable
- 67. STEP 1. define “Steady State” aka. what does normal, working condition looks like?
- 68. what metrics do you monitor?
- 69. 9X-percentile latency error count yield (% of requests completed) harvest (completeness of results)
- 70. STEP 2. hypothesize steady state will continue in both control group & the experiment group ie. you should have a reasonable degree of confidence the system would handle the failure before you proceed with the experiment
- 71. API Gateway
- 72. consider the effect of cold-starts & API Gateway overhead
- 73. use short timeout for API calls
- 74. the goal of a timeout strategy is to give HTTP requests the best chance to succeed, provided that doing so does not cause the calling function itself to err
- 75. fixed timeout are tricky to get right…
- 76. fixed timeout are tricky to get right… too short and you don’t give requests the best chance to succeed
- 77. fixed timeout are tricky to get right… too long and you run the risk of letting the request timeout the calling function
- 78. and it gets worse when you make multiple API calls in one function…
- 81. set the request timeout based on the amount of invocation time left
- 86. log the timeout incident with as much context as possible e.g. timeout value, correlation IDs, request object, …
- 91. be mindful when you sacrifice precision for availability, user experience is the king
- 92. STEP 3. inject realistic failures e.g. server crash, network error, HD malfunction, etc.
- 93. where to inject latency?
- 94. hypothesis: function has appropriate timeout on its HTTP communications and can degrade gracefully when these requests time out
- 96. should also be applied to 3rd parties services we depend on, e.g. DynamoDB
- 98. what’s the blast radius?
- 100. hypothesis: all functions have appropriate timeout on their HTTP communications to this internal API, and can degrade gracefully when requests are timed out
- 103. large blast radius, risky..
- 105. could be effective when used away from production environment, to weed out weaknesses quickly
- 106. not priming developers to build more resilient systems
- 107. development
- 109. Priming (psychology): Priming is a technique whereby exposure to one stimulus influences a response to a subsequent stimulus, without conscious guidance or intention. It is a technique in psychology used to train a person's memory both in positive and negative ways.
- 112. make dev environments better resemble the turbulent conditions you should realistically expect your system to survive in production
- 113. hypothesis: the client app has appropriate timeout on their HTTP communication with the server, and can degrade gracefully when requests are timed out
- 118. STEP 4. disprove hypothesis i.e. look for difference with steady state
- 119. how to inject latency?
- 120. static weaver (e.g. AspectJ, PostSharp), or dynamic proxies
- 122. manually crafted wrapper library
- 128. configured in SSM Parameter Store
- 130. no injected latency
- 134. factory wrapper function (think bluebird’s promisifyAll function)
- 140. ERROR INJECTION
- 142. the only way to truly know your system’s resilience against failures is to test it through controlled experiments
- 146. vaccinate your serverless architecture against failures
- 147. Offices in London and Katowice WE’RE HIRING! https://bit.ly/2HfLzGE