Posted by on Mar 27, 2015 in #Azure, Visual Studio | 1 comment

When building scalable web apps/APIs using the cloud, we have a couple of things to keep in mind. Many of us are used to the concept of vertical scaling, when we’re simply building a Godzilla-like machine to host our applications and services. But with the cloud, scaling horizontally is a technique that has become much more accessible.

Scaling horizontally is the concept of using multiple instances of your deployment – and distribute the workload across them (using a load-balancer for instance). Horizontal scaling becomes a superior scaling technique in many cases – here’s an example:

With vertical scaling, you’re limited to very few fault domains – meaning if your hardware fails (which is not question about if it will, but rather when it will), your application or service becomes unavailable. In a horizontal scaling scenario your deployment would be spread out on different fault domains – and if one instance fails, your application or service would still be available (but with decreased resources).

In addition, scaling in becomes a possibility with horizontal scaling in the cloud – which is just as important as scaling out (let’s not pay for unused resources).

The core of building scalable web apps/APIs – is to decouple and create stateless solutions. In ASP.NET for instance, we shouldn’t use the local machine as the session state provider – as traffic would be spread across different instances (and with auto-scaling, instances may appear/disappear from the instance pool). With that we need to move the session state outside the instance itself – which is what this post is about.

One solution is to use an Azure Redis Cache as the session state provider – let’s look at that!

Create an Azure Redis Cache

Head to the Azure portal (preview portal) and hit the New button. You’ll find Redis Cache in the Data + storage tab.

newrediscache

Enter a DNS name, pick the pricing tier, resource group, subscription, choose a location (preferably close to your web app/API) and tap the Create button! After a couple of minutes your Redis Cache should be ready to use.

Test your Azure Redis Cache with the Redis CLI tool

There’s a command line interface tool available that you can use to make sure that your Redis Cache is working properly. If you are using Windows – head over to the GitHub repository by Microsoft Open Tech for Redis and grab the latest binary release:
https://github.com/MSOpenTech/redis/releases

The Redis CLI is available through the redis-cli.exe file, but in order to connect to your Redis Cache we need to identify a couple of settings. Head over to the Azure portal and find the page for your freshly-baked Redis Cache.

Find the host name of your Redis Cache and the access keys used to connect to it. If you click Show access keys you’ll be able to view the primary and secondary access key, use one of them when connecting to your Redis Cache.

rediskeys

Lastly you’ll need to enable non-SSL traffic to your Redis Cache in order to use the Redis CLI (I’d advise you to only allow access via SSL when in production). Click the ports label (Non-SSL port (…. disabled)) to configure the non-SSL port.

redishcliport

Note the non-SSL port and make sure to save the changes!

Use the Redis CLI tool to execute the following command:

redis-cli.exe -h [host name] -p [non-SSL port] -a [access key]

When the connection is established – you can make sure that it’s working with the ping command. If you use this command, the Redis Cache should respond with PONG.

rediscli

Alright, we should be good to go – let’s configure ASP.NET!

Configure ASP.NET to use the Azure Redis Cache

Find your Web.config file and locate the system.web section. If you don’t have a system.web/sessionState section, please add one. This is how I configured my sessionState section. If you’d like to use SSL like I am in my ASP.NET web app, be sure to specify the SSL port.

  <sessionState mode="Custom" customProvider="MySessionStateStore">
      <providers>
        <add name="MySessionStateStore"
             type="Microsoft.Web.Redis.RedisSessionStateProvider"
             host="[host name]"
             port="[SSL port]"
             accessKey="[access key]"
             ssl="true" />
      </providers>
    </sessionState>

Configure ASP.NET to use the Azure Redis Cache

Next up… test your Redis Cache! I’ll just do something simple:

Session["timestamp"] = DateTime.UtcNow.Ticks.ToString();

Run your ASP.NET project and use a couple of browsers to simulate multiple sessions.

Using the Redis CLI tool, have a look at the keys to make sure that the session variables are being stored in the Redis Cache – with the following command:

redisclikeys2

Yeah those are some odd key names (session/variable identifiers) – but hey, it’s working!

Alright, so that’s pretty much it! We’ve moved our session state provider outside of the local machine scope – with that our clients may be located on any of our instances, and still maintain their session! So we can scale our deployment in and out – however we’d like!

In addition, I’d advise you to read and perform the following for your web apps/APIs:
http://azure.microsoft.com/blog/2013/11/18/disabling-arrs-instance-affinity-in-windows-azure-web-sites/

Learn more about what you can do with Redis here:
http://redis.io/

-Simon Jäger