Designing apps for resiliency

Download Designing apps for resiliency

Post on 16-Apr-2017




0 download

Embed Size (px)


<p>Designing Apps for Resiliency</p> <p>Designing Apps for ResiliencyMasashi NarumotoPrincipal Lead PMAzureCAT patterns &amp; practices</p> <p>1</p> <p>AgendaWhat is resiliency?Why its so important?Process to improve resiliencyResiliency checklist</p> <p>Everybody is talking about it but the its definition is not clear. Ill clarify what it meansWhy everybody is taking about it? Theres a number of reasonsMain part of this topic is how to make your app resilient.Ill show you some of the example of checklist2</p> <p>What is Resiliency?Resiliency is the ability to recover from failures and continue to function. It's not aboutavoidingfailures, butrespondingto failures in a way that avoids downtime or data loss.High availability is the ability of the application to keep running in a healthy state, without significant downtime. </p> <p>Disaster recovery is the ability to recover from rare but major incidents: Non-transient, wide-scale failures, such as service disruption that affects an entire region.</p> <p>DR? Data backup? These are all true statements but none of them clearly define what resiliency means.</p> <p>In order to be HA, it doesnt need to go down and come back online. If youre app is running w/ 100% uptime w/o any failures, its HA but you never know if its resilient. Once something bad happens, then it may take days to come back online which is not really resilient at all.</p> <p>DR needs to be a catastrophic failure such as something that could take down entire DC. For example..</p> <p>3</p> <p>Why its so important?More transient faults in the cloudDependent service may go downSLA &lt; 100% means something could go wrong at some pointMore focus on MTTR rather than MTBF</p> <p>Why its so important? Why everybody is talking about resiliency?</p> <p>Transient faults because of commodity HW, networking, multi-tenant shared modelRemote services could go down at any time99.99% means 4 mins downtime a month. Do you want to sit down and wait for 4 minutes or do something else?Id rather do something because you never know its going to be 4 minutes or 4 hours.</p> <p>Based on the assumption that anything goes wrong at some point, focus has been shifting from MTBF to MTTR </p> <p>4</p> <p>Process to improve resiliencyDefine requirementsIdentifyfailuresImplementrecovery strategiesInject failuresSimulate FODeploy apps in a reliable mannerMonitor failuresTake actions to fix issues </p> <p>Were getting into more interesting part.We discussed what resiliency means, why its so important.Now were getting into how part.</p> <p>This is the process to improve resiliency in your system in 7 steps from plan to respond.Lets talk about each step.Clearly define your requirements, otherwise you dont know what youre aiming forIdentify all possible failures you may see and Implement recovery strategies to bounce back from these failuresTo make sure these strategies work, you need to test them by injecting failuresDeployment needs to be resilient too. Because deploying new version is the most common cause of failuresMonitoring is key to QoS. Monitor errors, latency, throughputs etc. in percentile.You need to take actions quickly to mitigate the downtime</p> <p> 5</p> <p>Defining resiliency requirementsMajor incident occurs</p> <p>Service recovered</p> <p>Data backup</p> <p>Data backup</p> <p>Data backupRecovery Time Objective (RTO)Recovery Point Objective (RPO)RPO: The maximum time period in which data might be lostRTO: Duration of time in which the service must be restored after an incident</p> <p>Business recoveredMaximum Tolerable Outage (MTO)</p> <p>Therere two common requirements when it comes to resiliency.</p> <p>RPO: defines the interval of data backup RTO: defines the requirements for hot/warm/cold stand-byMTO: how long a particular business process can be down6</p> <p>SLA (Service Level Agreement)</p> <p>If you look at well-experienced customers, they define availability requirements per each use case.Decompose your workload and define availability requirements (uptime, latency etc.) per eachHigher SLA comes with cost because of redundant services/components.Measuring downtime will become an issue when you target 5nines7</p> <p>Composite SLA</p> <p>Composite SLA = ?Composite SLA = ?CacheFallback action:Return data from local cache99.94%99.95%99.95%99.95% x 99.99% = 99.94%1.0 (0.0001 0.001) = 99.99999%Composite SLA for two regions = (1 (1 N)(1 N)) x Traffic manager SLA1 (1 0.9995) x ( 1 0.9995)= 0.99999975(1 (1 0.9995) x ( 1 0.9995)) x 0.9999 = 0.999899 </p> <p>The fact that App Service offers 99.95% doesnt mean that the entire system has 99.95%.Other important fact is that SLA doesnt guarantee that it always up 99.95% of the time. Youll get money back when it violates SLA.Its not just a number game. This is where resiliency comes into play.</p> <p>SLA is not guaranteed. If we dont meet SLA, you get money back.Definition of SLA varies depending on the service.8</p> <p>Designing for resiliency</p> <p>Reading data from SQL Server failsA web server goes downA NVA goes downIdentify possible failuresRate risk of each failure (impact x likelihood)Design resiliency strategy- Detection- Recovery- Diagnostics </p> <p>In order to design your app to be resilient, you need to identify all possible failures first.Then implement resilient strategies against them,</p> <p>9</p> <p>Failure mode analysis </p> <p></p> <p>To help you identify all possible failures, we published list of most common failures on Azure.It has a few items per each service. 30 to 40 items in total. Lets take a look.</p> <p>In the case of DocumentDB. When you fail to read data from it, the client SDK retries the operation for you. The only transient fault it retries against is throttling (429). If you constantly get 420, consider increasing its scale (RU)DocumentDB now supports geo-replica. If primary region fails, it will switch traffic to other regions in the list you configureFor diagnostics, you need to log all errors at client side.</p> <p>10</p> <p>Rack awareness</p> <p>Web tier Availability setMiddle tierAvailability setData tierAvailability setFault domain 1</p> <p>Replica #1Replica #1Replica #2</p> <p>Fault domain 2Fault domain 3</p> <p>Shard #2Shard #1</p> <p>You can think of rack as power module. If it goes down, anything belong to it go down all together.So its better to distribute VMs across different racks for redundancy sake.This is where availability set comes into play.Each machine in the same AS belongs to different rack.VMSS automatically put VMs in 5 FD, 5 UD but it doesnt support data disk yet. </p> <p>11</p> <p>Load balance multiple instances</p> <p>Application gateway forL7 routingSSL termination</p> <p>Avoiding SPOF is critical for resiliency. Many customers still dont know these basics. They deploy critical workload on a single machine.For that, you nee to have redundant components. One goes down but still others are running. In this case, put VMs in the same tier into the same availability set with LB.LB would distribute requests to VMs in backend address poolHealth probe can be either Http or Tcp depending on the workload.By default it pings root path /. You may want to expose health endpoint to monitor all critical component.</p> <p>12</p> <p>Failover / Failback</p> <p>Traffic managerPriority routing method</p> <p>WebApplicationData</p> <p>WebApplicationData</p> <p>Automated failoverManual failbackPrimary regionSecondary region (regional pair)</p> <p>WebWebWebDataApplicationApplicationData</p> <p>Theres a risk of data loss in FO, take a snapshot and ensure the data integrity.13</p> <p>Data replication</p> <p>Azure storageGeo replica (RA-GRS)</p> <p>LocationMode = PrimaryThenSecondaryLocationMode = SecondaryOnly</p> <p>Periodically check If its back online</p> <p>If its less frequent transient faults, set the property to PrimaryThenSecondary. Itll switch to secondary region for youIf its more frequent or non-transient faults, set the property to SecondaryOnly otherwise it keeps hitting and getting errors from primary.</p> <p>You need to monitor the primary region, when it comes back then set the property back to PrimaryOnly or PTS</p> <p>One thing to notice is that Azure storage wouldnt failover to secondary until reginal wide disaster happens which I dont think we have had yet. </p> <p>This strategy is applicable for read not write.</p> <p>14</p> <p>Retry transient failures</p> <p>See Azure retry guidance for more details&lt; E2E latency requirement</p> <p>Lets take a look at a few resiliency strategies to recover from failures you identified above. </p> <p>Exponential back-off for non-interactive transactionQuick liner retry for interactive transaction </p> <p>Anti-patterns:Cascading retry (5x5 = 25)More than one immediate retryMany attempts with regular interval (Randomize interval)</p> <p>15</p> <p>Circuit Breaker</p> <p>Remote service</p> <p>Your applicationUser</p> <p>Hold resources while retrying operationLead to cascading failures </p> <p>Failed</p> <p>People often say dont waste your time, lets circuit break and fail fastThat is only a part of the problem. Real issues is the cascading failures.Also by keep retrying failed operations, the remote service cant recover from the failed state</p> <p>16</p> <p>Circuit Breaker</p> <p></p> <p>17</p> <p>BulkheadService AService BService CThread poolThread poolThread pool</p> <p>Workload 1Workload 2Thread poolThread poolThread pool</p> <p>Workload 1Workload 2MemoryCPUDiskThread poolConnection poolNetwork connection</p> <p>Type of resources to isolate are not limited to but they are most common ones.18</p> <p>Other design patterns for resiliencyCompensating transactionScheduler-agent-supervisorThrottlingLoad levelingLeader election</p> <p>See Cloud design patterns</p> <p>19</p> <p>Principles of chaos engineeringBuild hypothesis around steady state behaviorVary real-world eventsRun experiments in productionAutomate experiments to run consistently</p> <p>Control GroupExperimental GroupHW/SW failuresSpike in trafficVerify differenceIn terms of steady stateFeed production traffic</p> <p>Given the chaotic nature of the cloud and distributed system, always something happens somewhere.</p> <p>it makes sense to follow chaos engineering principles.</p> <p>Define the steady state as the measurable outputof a system, rather than internal attributes of the systemIntroduce real-world chaotic events such as HW-failure, SW-failure, spike in traffic etc.Best way to validate the system at production scale is to run experiment in production.Netflix at least once a month, inject faults in one of their regions to see if their system can keep up and running.Since its such a time consuming tasks, you should automate the experiments and run them continuously</p> <p>Chaos engineering is not testing, its validation of the system. </p> <p></p> <p>20</p> <p>Testing for resiliencyFault injection testingShut down VM instancesCrash processesExpire certificatesChange access keysShut down the DNS service on domain controllersLimit available system resources, such as RAM or number of threadsUnmount disksRedeploy a VMLoad testing Use production data as much you canVSTS, JMeterSoak testingLonger period under normal production load</p> <p>Tools = Chaos monkey/kong, ToxiProxy</p> <p>21</p> <p>Blue/Green and Canary releaseWebAppDBWebAppDB</p> <p>Blue/Green DeploymentWebAppDBWebAppDB</p> <p>Canary release90%10%Current versionNew versionCurrent versionNew versionLoad BalancerReverse Proxy</p> <p>Deploy current and new version into two identical environments (blue, green)Do smoke test on new version then switch traffic to it.</p> <p>Canary release is to incrementally switches from current to new using LB.Use Akamai or equivalent to do Canary. The unique name for this environment comes from a tactic used by coal miners: theyd bring canaries with them into the coal mines to monitor the levels of carbon monoxide in the air; if the canary died, they knew that the level of toxic gas in the air was high, and theyd leave the mines.</p> <p>In either case you should be able to rollback if the new version doesnt workGraceful shutdown and Switching DB/Storage are the challenge.</p> <p>Github route request to blue and green, compares the result from blue and green. Make sure they are identical. </p> <p>Dark launch: Deploy new features without enabling it to users. Make sure it wont cause any issues in production, then enable it.</p> <p>22</p> <p>Deployment slots at App Service</p> <p>This is how it works in App Service. You can have up to 15 deployment slots23</p> <p>Dark launching</p> <p>New featureToggle enable/disableUser InterfaceProduction environment</p> <p>Deploy a new feature to prod env without enabling it to users. Make sure it works with in the prod infrustracture, no memory leaks, no nothing.Then enable it to users on UI. If something bad happens, then disable it in UI.Facebook does this.24</p> <p>Resiliency checklist</p> <p>All other proven practices are in this doc.</p> <p>You can use this list when you have ADR with your customers. Give us feedback.25</p> <p>Other resources</p> <p>26</p> <p>Resiliency / High Availability / Disaster Recovery</p> <p>ThrottlingCircuit breakerZero downtime deploymentEventual consistencyData restoreRetryGraceful degradationGeo-replicaMulti-region deployment</p> <p>27</p>