How Can You Scale Azure SignalR Services for High-Concurrency Applications?

Introduction to SignalR and the Importance of Scaling

SignalR is a library for ASP.NET developers that reduces the complexity of creating real-time web functionality to integrate it into applications. Real-time web functionality is the ability of server-side code to present content to connected clients as soon as it becomes available to the server rather than waiting for clients to request new data.

Real-time capability is essential for highly-interactive applications, such as real-time chat apps, real-time gaming, or collaborative web platforms.

As these applications grow, and the customer base expands to several geographic regions, the ability to scale the SignalR service also becomes an essential factor. Scaling is the process of ensuring that applications can manage a high number of concurrent connections without compromising performance.

Using Azure Key Vault to Secure Connection Strings

Setting Up Azure Key Vault

Before integrating SignalR with Azure Key Vault, you need to set up the Azure Key Vault in the Azure portal. This service provides a secure store for secrets, keys, and certificates, allowing them to be securely accessed from your application without storing sensitive data in your source code.

Steps to Configure Azure Key Vault:

1. Create an Azure Key Vault through your Azure portal.

2. Add SignalR Service connection strings as secrets within the Key Vault.

3. Integrate Azure Key Vault in your ASP.NET Core application by adding the Key Vault client library, which can be installed via NuGet.

Video Source: BeCloudGuru on YouTube

Code Example for Azure Key Vault Integration

Here’s how you can add the Azure Key Vault client library to your ASP.NET Core project and configure it to retrieve SignalR connection strings:

This setup secures the connection strings and other secrets, making them available to your application in a secure manner.

Adding Multiple Instance Endpoints

For applications that need to handle high numbers of concurrent users, configuring multiple service endpoints is essential. This configuration not only allows for handling more users but also provides high availability and load balancing.

Example of Setting Up Multiple Endpoints

Here is a simple example of how you might configure multiple endpoints in your application:

Custom Router Configuration for Optimized Message Routing

Why Use a Custom Router?

The default router in SignalR randomly selects an endpoint, which might be sufficient for many applications. However, for more complex scenarios such as geographically distributed users, a custom router can optimize resource usage and improve response times by directing messages based on specific criteria like user group, geographic location, or connection load.

Code Example for a Custom Router

Here's an example of how to implement a custom router in SignalR:

Configuration explained in a cross-region scenario

The ServiceEndpoint object has an EndpointType property with one of two values – primary or secondary. Primary endpoints are endpoints that are preferred by the clients to receive client traffic as these endpoints have a stable network connection. Secondary endpoints have a less stable network connection and serve as alternatives for the server to client traffic.

For instance, service endpoints handle broadcast messages with secondary tunnelling while the client traffic is carried out with primary endpoints. In cross-region situations, the network might be unstable.

As an example, choose an app server located in East US – the SignalR Service endpoint in the same East US region is primary, all other endpoints in other regions have the secondary type. This means that service endpoints in other regions may receive messages from this app server; however, no clients from other regions are routed to this app server across regions. The following image explains the situation:

A client tries to /negotiate with the app server using a default router. The SDK randomly selects one endpoint from the supported set of available primary endpoints, but if the primary endpoint is unable, then the SDK randomly selects from all available secondary endpoints.

The endpoint is marked as available if the connection between the server and the endpoint for the service is alive. In the case of a cross-region client tries to /negotiate with the app server where East US hosted by default; it always returns primary endpoint within the same region if all East US endpoints are unavailable. The router redirects the client to endpoints in remaining regions.

For the End

Successfully scaling SignalR services to support 500,000 concurrent users is a testament to the robustness and flexibility of Azure's cloud services. By utilizing Azure Key Vault for secure configuration management and implementing custom routers, we ensured our application was not only scalable but also secure and efficient. Azure SignalR, alongside critical technologies like Azure Service Bus and Microsoft Orleans, forms the backbone of our real-time communication infrastructure.

This strategic integration of Azure services has greatly enhanced our user experience and set a new benchmark for real-time applications in the industry. In upcoming discussions, I will further elaborate on how other services were configured and detail the mistakes encountered during this journey, providing a comprehensive insight into our path to success.