Tải bản đầy đủ
Objective 5.5: Scale and monitor communication

Objective 5.5: Scale and monitor communication

Tải bản đầy đủ

Choosing a pricing tier
The Service Bus has two types of tiers: a messaging tier for brokered messaging entities and a
notification hubs tier. When you create a Service Bus namespace, you choose a messaging tier
for all entities that will belong to that namespace. The tier you choose controls which entities
you have access to as follows:
■■

Basic tier  Queues and event hubs (up to 100 connections)

■■

Standard tier  Queues, event hubs, topics, and relays (up to 1000 connections)

Standard tier also supports advance brokered messaging features such as transactions,
de-duplication, sessions, and forwarding, so if you need these features for your solution,
select the standard tier.
MORE INFO  SERVICE BUS TIERS

For information on Service Bus tier pricing, see http://azure.microsoft.com/en-us/pricing/
details/service-bus/.

Specifically related to event hubs, the basic tier only supports a single consumer group, so
if you want to support parallelized processing across partitions, choose standard messaging
tier. In addition, standard tier provides additional storage up to seven days for event hubs.
MORE INFO  EVENT HUB TIERS

For information on event hub tier pricing, see http://azure.microsoft.com/en-us/pricing/
details/event-hubs/.

Notification hubs have a separate tier selection strategy outside of the namespace tier.
When you create a namespace that supports notification hubs, you choose a messaging tier
for brokered messaging entities, if applicable, and select a notification hub tier appropriate
to your expected push notification strategy. All tiers support unlimited devices, but there are
some differences between the tiers:
■■

■■

■■

Free tier  Up to 1 million messages per month; no support for auto-scale nor a
number of other enterprise features
Basic tier  10 million messages per month plus unlimited overage for a fee; support
for auto-scale; no support for other enterprise features
Standard tier  The same as basic tier with all enterprise features

MORE INFO  NOTIFICATION HUB TIERS

For information on notification hub tier pricing, see http://azure.microsoft.com/en-us/
pricing/details/notification-hubs/.

370

CHAPTER 5

Manage application and network services

Scaling Service Bus features
Service Bus entities scale based on a variety of properties, including
■■

Namespaces

■■

Partitions

■■

Message size

■■

Throughput units

■■

Entity instances

Not all of these properties impact every Service Bus entity in the same manner.
A Service Bus namespace is a container for one or more entities, such as relays, queues,
topics, event hubs, and notification hubs. In most cases, the namespace itself is not a unit
of scale, with some exceptions specifically related to pricing (referenced earlier), event hub
throughput (to be discussed), and the following:
■■

■■

For relays, there is a limit to the number of endpoints, connections overall, and
listeners.
The number of topics and queues are limited, and separately a smaller number of
partitioned topics and queues are supported.

Since pricing is not directly related to namespace allocation between relays, queues, topics,
and event hubs, you can avoid reaching some of these limits by isolating entities that could
be impacted into separate namespaces. For example, consider isolating individual relays that
might grow their connection requirements, or consider isolating partitioned queues and topics.
MORE INFO  SERVICE BUS QUOTAS

For the latest information related to namespace and other quotas for individual Service
Bus entities, see http://msdn.microsoft.com/en-us/library/azure/ee732538.aspx.

Beyond namespace selection, each entity has slightly different requirements for scale as is
discussed in this section.

Scaling relays
This section discusses how to scale relays for potential namespace limitations.
NAMESPACE

As mentioned previously, relay endpoints have a limited number of overall connections and
listeners that can be supported per namespace. When you are considering the design for
a relay service, you should consider the number of concurrent connections that might be
required for communicating with the endpoint.



Objective 5.5: Scale and monitor communication

CHAPTER 5

371

If the scale of the solution has the potential to exceed the quota per namespace, the
following approach can help to mitigate the limitation:
■■

■■

Design the solution to support publishing an instance of each relay service into multiple namespaces. This will allow for growth so that additional listeners can be added
by adding namespaces with a new relay service instance.
Design the solution so that clients sending messages to the relay service can distribute
calls across a selection of service instances. This implies building a service registry.

E XAM TIP

Relay services can be replaced with queues or topics to provide greater throughput, scalability, and design flexibility.

Scaling queues and topics
This section discusses how to scale queues and topics for potential namespace or storage
limitations and discusses the use of batching and partitions to help with scaling.
NAMESPACE

Queues and topics are similar in their scale triggers. Neither is particularly bound by the
namespace it belongs to except in the total number of queues or topics supported and the
limited number of partitioned queues and topics. Ideally, you will have a pattern for your
solution in terms of namespace allocations by Service Bus entities.
STORAGE

When you create a new queue or topic, you must choose the maximum expected storage
from 1 GB to 5 GB, and this cannot be resized. This impacts the amount of concurrent storage
supported as messages flow through Service Bus.
BATCHING

To increase throughput for a queue or topic, you can have senders batch messages to Service
Bus and listeners batch receive or pre-fetch from Service Bus. This increases overall throughput across all connected senders and listeners and can help reduce the number of messages
taking up storage.
MORE INFO  BATCHING AND PRE-FETCHING

For more information on batch send, batch receive, or pre-fetch, see http://msdn.microsoft.
com/en-us/library/azure/hh528527.aspx.

PARTITIONS

Adding partitions increases the number of message brokers available for incoming messages,
as well as the number available for consuming messages. For high throughput queues and
topics, you should enable partitioning when you create the queue or topic.
372

CHAPTER 5

Manage application and network services

MORE INFO  PARTITIONED ENTITIES

For more information on partitions, see http://msdn.microsoft.com/en-us/library/azure/
dn520246.aspx.

Scaling event hubs
This section discusses how to scale event hubs for potential namespace limitations and
discusses how to set throughput units or use partitions to help with scaling.
NAMESPACE

Each namespace can have multiple event hubs, but those event hubs share the throughput
units allocated to the namespace. This means that multiple event hubs can share a single
throughput unit to conserve cost, but conversely, if a single event hub has the potential of
scaling beyond the available throughput units for a namespace, you might consider creating a
separate namespace for it.
E XAM TIP

You can request additional throughput units for a namespace by calling Microsoft support.

THROUGHPUT UNITS

The primary unit of scale for event hubs is throughput units. This value is controlled at the
namespace level and thus applies to all event hubs in the namespace. By default, you get
a single throughput unit which provides ingress up to 1 MB per second, or 1,000 events
per second, and egress up to 2 MB per second. You pre-purchase units and can by default
configure up to 20 units.
PARTITIONS

A single event hub partition can scale to a single throughput unit; therefore, the number of
partitions across event hubs in the namespace should be equal to or greater than the number
of throughput units selected.

Scaling notification hubs
You can scale push notifications through notification hubs to millions of devices if you choose
basic or standard tier. With basic or standard tier, you can push an unlimited number of notifications, but the fees per notification will vary between these two tiers.

Monitoring Service Bus features
In this section you learn how to monitor queues, topics, event hubs, and notification hubs.



Objective 5.5: Scale and monitor communication

CHAPTER 5

373

MORE INFO  SERVICE BUS EXPLORER

Service Bus Explorer is a tool used for managing and monitoring Service Bus features such
as queues, topics, relays, and notification hubs. While you can use the management portal
to monitor basic communication statistics, this tool can provide additional insights. For tutorials and to access the source code, see https://code.msdn.microsoft.com/windowsazure/
Service-Bus-Explorer-f2abca5a.

Monitoring queues
To monitor a Service Bus queue from the existing portal, complete the following steps:
1. Navigate to the Dashboard tab for the queue, where metrics are presented in a graph

(see Figure 5-22).

FIGURE 5-22  The metrics graph shown on the Dashboard tab for a queue

2. You can show relative or absolute values by selecting from the drop-down list above

the graph (click the down arrow beside the word Relative shown in Figure 5-22).
3. You can choose the number of hours or days to include based on a predefined list

shown in the drop-down list above the graph (click the down arrow beside 1 Hour
shown in Figure 5-22).
It is useful to compare the number of incoming and outgoing messages to note any
behavior that indicates burst activities for messages received or reduced ability to process
requests as they are received. In addition, you can monitor queue length to note increases
indicating requests not yet processed.

Monitoring topics
To monitor a Service Bus topic from the existing portal, complete the following steps:
1. Navigate to the Monitor tab for the topic, where metrics are presented in a graph (see

Figure 5-23).

374

CHAPTER 5

Manage application and network services

FIGURE 5-23  The metrics graph presented on the Monitor tab for a topic

2. Click Add Metrics on the command bar to choose from a list of metrics, including topic

or specific subscription metrics. After selecting additional metrics to monitor, you will
be able to filter which metrics to show in the graph.
As describedw in the previous section for queues, you can show relative or absolute values
in the graph, and you can choose the number of hours or days to include based on a predefined list.
As with queues, it is useful to compare the number of incoming and outgoing messages to
note any behavior that indicates burst activities for messages received or reduced ability to
process requests as they are received across all subscriptions in aggregate. In addition, monitor the length of each subscription to look for problems with throughput to those endpoints.

Monitoring event hubs
To monitor a Service Bus event hub from the existing portal, navigate to the Dashboard tab
for the event hub, where metrics are presented in a graph.

FIGURE 5-24  The metrics graph presented on the Dashboard tab for an event hub

As described in the previous section for queues, you can show relative or absolute values in the graph, and you can choose the number of hours or days to include based on a
predefined list.


Objective 5.5: Scale and monitor communication

CHAPTER 5

375

It is useful to compare the number of incoming and outgoing messages to note any
behavior that indicates burst activities for messages received or reduced ability to process
requests as they are received. You can also monitor incoming and outgoing throughput to
measure throughput usage of this event hub for ingress and egress. Again, you are typically
looking for bursts or decreases in usage indicating a need to adjust scale.

Monitoring notification hubs
To monitor a Service Bus notification hub from the existing portal:
1. Navigate to the Monitor tab for the notification hub, where metrics are presented in a

graph.
2. You can show relative or absolute values, and you can choose the number of hours or

days to include based on a predefined list.
3. Click Add Metrics on the command bar to choose from a list of metrics, including

platform-specific metrics across each respective notification service and additional
metrics for notification hub messaging (see Figure 5-25).

FIGURE 5-25  The Choose Metrics dialog box for selecting notification hub metrics to monitor

It is useful to monitor registration operations to note when there are bursts or decreases
in those requests. In addition, monitoring errors for each platform notification service might
help you identify specific issues related to that platform.

376

CHAPTER 5

Manage application and network services

Thought experiment
Scaling Service Bus
In this thought experiment, apply what you’ve learned about this objective. You can
find answers to these questions in the “Answers” section at the end of this chapter.
You are designing a solution that will include Service Bus queues and event hubs.
Queues will be used for asynchronous requests to generate reports and email them
to customers on a monthly basis. You will have a peak period at the end of the
month during the last week, and the rest of the month, requests will be sporadic
and unpredictable. Reports are used to summarize data that is analyzed by the
system. The data is diagnostic data sent by devices (IoT) through event hubs to your
servers. The number of devices and amount of data collected is expected to grow.

1. What more do you need to know about this scenario to determine a scaling
strategy?

2. How will you choose a messaging tier and namespace allocation?
3. How will you approach optimizing queue throughput?
4. How will you approach optimizing event hub throughput?

Objective summary
■■

■■

■■

■■
■■

Service Bus pricing tiers fall into a few categories: a Service Bus messaging tier, an
event hub tier, and a notification hub tier.
Relay services are primarily scaled by adding namespaces and listeners for processing
messages.
Queues and topics are primarily scaled by choosing a larger storage size, adding
partitions, and batching messages on both send and receive.
Notification hubs are scaled by adjusting the tier to allow for increased message volume.
You can monitor queues, topics, event hubs, and notification hubs in the existing
management portal.

Objective review
Answer the following questions to test your knowledge of the information in this objective.
You can find the answers to these questions and explanations of why each answer choice is
correct or incorrect in the “Answers” section at the end of this chapter.



Objective 5.5: Scale and monitor communication

CHAPTER 5

377

1. Which of the following are valid statements about choosing a pricing tier for Service

Bus? (Choose all that apply.)
A. Relays are supported in basic or standard messaging tier.
B. Event hubs are only supported in standard messaging tier.
C. Standard messaging tier is limited to 1,000 connections. 
D. Notification hub tiers all support unlimited messaging, but the price varies. 
E. Free messaging tier only supports queues and topics.
2. Which of the following statements about scaling Service Bus are true? (Choose all that apply.)
A. Allocating relays to individual namespaces improves scalability per relay.
B. Increasing queue and topic partitions improves capacity to process messages at

the server.
C. Event hubs scale with paid throughput units.
D. Notification hubs scale to more devices by adding namespaces.
3. Which of the following statements about monitoring Service Bus entities in the

management portal are true? (Choose all that apply.)
A. You can monitor incoming and outgoing messages for queues, topics, and event hubs.
B. You can monitor ingress and egress for topics and event hubs.
C. Monitoring queue and topic length can indicate issues with throughput.
D. Monitoring notification hubs by device can help isolate issues local to a device.

Objective 5.6: Implement caching
Microsoft Azure offers several options for distributed, in-memory, and scalable caching
solutions over time. At present, the following options are available:
■■

Azure Redis Cache

■■

Azure Managed Cache Service

■■

In-Role Cache

The first two options offer an SLA of 99.9 percent (with the right configuration of Redis
Cache) and the latter does not since you are effectively self-hosting a caching service. Both
Managed Cache Service and In-Role Cache are primarily offered for backward compatibility
for existing customers using those features. Azure Redis Cache is considered the modern and
preferred approach for green field distributed cache implementations.

This objective covers how to:

378

CHAPTER 5

■■

Implement Redis Cache

■■

Implement Azure Managed Cache Service

Manage application and network services

Implementing Redis Cache
Azure Redis Cache is based on the open source project Redis Cache, allowing you to leverage
the vast resources in this open source community while leaving the reliability, security, and
hosting to Azure. Redis offers many features beyond a traditional key-value pair cache, including manipulating existing entries with atomic operations such as the following capabilities:
■■

Appending to a string

■■

Incrementing or decrementing a value

■■

Adding to a list

■■

Computing results or intersections and unions

■■

Working with sorted sets

In this section you learn how to create a cache, connect clients to a cache, and add or
retrieve objects.
E XAM TIP

The large Redis Cache size is 53 GB.

MORE INFO  REDIS DOCUMENTATION

For Redis Cache features, tutorials, and other documentation, see http://redis.io/documentation. 

Creating a cache (existing portal)
This feature is currently not available in the existing management portal.

Creating a cache (Preview portal)
To create a cache in the Preview portal, complete the following steps:
1. Navigate to the management portal accessed via https://portal.azure.com.
2. Click New on the command bar, and then click Everything.
3. Select Storage, Cache + Backup, and click the Redis Cache box on the Storage, Cache +

Backup blade.
4. On the Redis Cache blade, click Create.
5. For DNS name, supply a unique subdomain name for the cache. Select a pricing tier,

subscription, and location near the cache clients in your topology (see Figure 5-26).
You can choose a resource group or allow a new resource group to be generated (the
default behavior).



Objective 5.6: Implement caching

CHAPTER 5

379

FIGURE 5-26  Creating a new Redis cache in the Preview portal

6. Click Create to create the new Redis Cache instance.
NOTE  PRICING TIERS FOR REDIS CACHE

You can select options from each pricing tier. Basic tier has several options that supports
single node topology. Standard tier supports two-node master/subordinate topology with
99.9 percent SLA.

Configuring the cache
To configure the cache, complete the following steps:
1. To view your cache in the management portal after it is created, click Browse in the left

navigation panel, and select Redis Caches under Filter By.
2. From the list presented on the Redis Caches blade, select your cache to open the blade

for your cache.
3. To view your cache properties, select the Properties box on the cache blade. The Prop-

erties blade shows the host name address to your cache and indicates if SSL is required
and what port is used (see Figure 5-27). By default, the cache requires SSL and assigns
a port.

380

CHAPTER 5

Manage application and network services