Building Robust Windows Azure Applications with P&P Guidance

AZR323a Building Robust Windows Azure Applications with P&P Guidance @MaheshKrishnan Principal Consultant, Readify

AgendaWhat’s covered • Auto Scaling • Scaling concepts • Addressing scaling using Windows Azure Scaling Application Block (WASABi) • Transient errors • The Basics • Addressing these errors using Transient Fault Handling Application Block (TOPAZ)

Cloud benefits – a recap • Zero or low upfront cost • Lower on-going cost • Seemingly infinite resources • Elasticity on demand

Scaling - Basics • Helps balance running cost with load and performance • Vertical Scaling • Increase or decrease VM size • (Scale up/down) • Horizontal Scaling • Increase or decrease number of instances • (Scale out/in)

Manual scaling • Manual scaling useful for once-off scaling. Not good under other scenarios • Manual intervention = mistakes

Two types of scaling • Proactive • Reactive

My auto scaling wish list • Should be built into Azure • Scale out/in based on time table • Scale out/in based on perf. counters, queue size, etc • Work to my SLAs • Don’t break the bank (work within budget) • Configuration not done in code

Wish list (contd) • On heavy load, start cutting back on high CPU tasks/features • Make optimum use of my billing cycles • Preferably host in Azure on a Worker role • Cover multiple sites with one App

Options for Auto scaling • Use a SaaS provider • Azure Watch • Build your own • Leverage on p&p Guidance and existing framework • Windows Azure Scaling Application Block (WASABi)

WASABi Features • Supports auto-scaling of instances • Throttling • Scaling options: • Can be reactive or proactive • Hosting: • In Azure: worker role • On premise: Windows service, Stand alone app

Installation • Use NuGet • Install-Package EnterpriseLibrary.WindowsAzure.Autoscaling • Install the Enterprise Library Configuration Editor

Configuration • Some additions to the App/Web.config file • Two additional configuration files: • One for rules, such as Rules.xml • One fore Service info, such as Services.xml • Rules and Service info configuration can be stored in Blobs

Changes in code public class WorkerRole : RoleEntryPoint { private Autoscaler _autoscaler; ... public override boolOnStart() { _autoscaler = EnterpriseLibraryContainer.Current. GetInstance<Autoscaler>(); _autoscaler.Start(); ... } public override void OnStop() { _autoscaler.Stop(); ... } }

Proactive scaling • Constraint Rules • Using time tables • Budget limits • Ranking for overlapping rules • Overrides reactive rules

Proactive or constraint rules <rules xmlns= "http://schemas.microsoft.com/practices/2011/entlib/autoscaling/rules"> <constraintRules> <rule name="Default" rank="1"> <actions> <range min="2" max="6" target="SM.Website"/> </actions> </rule> <rule name="Peak" rank="10"> <timetable startTime="08:00:00" duration="08:00:00" utcOffset="+10:00" >  <daily/> </timetable> <actions> ... </actions> </rule> </constraintRules> </rules>

Reactive scaling • Use conditions to change instance count or perform specific action • Monitor: • Performance counters thresholds • Queue lengths • Custom business metrics thresholds • Even instance counts

Reactive rules <reactiveRules> <rule name="ScaleUpOnHighUtilization" rank="15" > <when> <greater operand="CPU" than ="60"/> </when> <actions> <scale target="SM.Website" by="1"/> </actions> </rule> <rule name="ScaleDownOnLowUtilization" rank="20" > <when> <less operand="CPU" than ="30"/> </when> <actions> <scale target="SM.Website" by="-1"/> </actions> </rule> </reactiveRules>

Operand • Can be one of the following: • performanceCounter • queueLength • instanceCount <operands> <performanceCounter alias="CPU" performanceCounterName="\Processor(_Total)\% Processor Time" source="SM.Website" timespan="00:05:00" aggregate="Average"/> </operands>

What to monitor? • \Processor(_Total)\% Processor Time • \Memory\Available Bytes • \.NET CLR Memory(_Global_)\% Time in GC

Throttling • Use config settings to cut back on features (like some CPU intensive features, or only allowing paid users) • Throttling is faster than generating new instances <rule name="ThrottlingRule" rank="50" > <when> <greater operand="CPU" than ="60"/> </when> <actions> <changeSettingsettingName="Throttle" target="SM.Website" value="true" /> </actions> </rule>

Stabilization • The Oscillations problem • Cool down settings – for both Scale up and down • Settings to scale during first few minutes of hour or scale down during last few minutes of an hour <stablizer> <role roleAlias=“SM.Website” scaleDownCooldown=“00:10:00” scaleUpCooldown=“00:10:00” scaleDownOnlyinLastMinutesOfHour=“10” scaleUpOnlyInFirstMinutesOfHour=“30”> </stablizer>

demo WASABi in action Name Title Group

Transient Errors Handling them using TOPAZ

Typical cloud implementation– a recap • Shared infrastructure • Virtualized environment • Multi-tenanted

Transient Errors • Occurs in: • Data Management - SQL Database, Tables • Messaging – Queues, Service Bus • Caching • Examples of errors: • SQL Database Throttling • Dropped/Stale connections • Infrastructure issues • Service unavailability

Some Transient Error codes

Transient Error Handling Application Block • Will detect known Transient errors • Allows you to specify Retry strategies • Contains classes/methods to perform retry logic easily

Retry policies • Fixed Interval • Example – Retry 4 times at 1 second interval • Incremental Interval • Example – Retry 4 times at 1, 2, 3, and 4 second intervals • Exponential Back off • Example – Retry 4 times at 2, 4, 8 and 16 seconds intervals

Installation • Use NuGet • Install-Package EnterpriseLibrary.WindowsAzure.TransientFaultHandling • Install the Enterprise Library Configuration Editor

Configuration • Allows you to configure Retry strategies

Using the App block with SQL Database • Contains ReliableSqLConnection class • SQLConnectionExtension contains extension methods for SqlConnection • Ex - OpenWithRetry • SQLCommandExtensioncontains extension methods for IDbConnection • Ex – ExecuteCommand

ReliableSqlConnection usage //Use retry aware connection using (var conn = new ReliableSqlConnection (connString, retryPolicy)) { conn.Open(); varcmd= conn.CreateCommand(); cmd.CommandText= sqlStmt; //retry aware ExecuteCommand int count = cmd.ExecuteScalar(); }

Other scenarios (LinqToSql, EF) sqlRetryPolicy.ExecuteAction(() => { // Invoke a LinqToSQLquery. }); return sqlRetryPolicy.ExecuteAction<IEnumerable<string>>( () => { // Invoke a EF LINQ query return result; });

Gotchas • Remember that queries are actually executed when they are enumerated • Similarly, Updates/Delete/Inserts are called when SaveChanges are called • Avoid Lazy loading

demo TOPAZ in action Name Title Group

SummaryWASABi • Auto scaling can be done reactively or proactively • Create a separate Worker role (or use existing one) • Install the NuGet package • Specify constraint and reactive rules in configuration files • Initialise the App Block

SummaryTOPAZ • Helps handle transient errors by retrying • Install NuGet package • Specify retry strategy in configuration files • Most common usage scenario: SQL Database • Use ReliableSqlConnection instead of SQLConnection • Use extension methods on IDbCommand when executing queries • Use ExecuteAction method on RetryPolicy for everything else (including ORMs)

© 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Building Robust Windows Azure Applications with P&P Guidance