Multi-CDN Monitoring Challenges

RSS
Multi-CDN Monitoring Challenges
Learn about 4 challenges facing enterprises that need to monitor multiple CDNs, including high data volumes and scaling for major events.
franz@hydrolix.io
|
Published:
Nov 12, 2024
|
7 minute read
Use Cases

Major enterprises, especially media and streaming providers, often use multiple content delivery networks (CDNs) to reliably deliver content. This is known as a multi-CDN strategy. It typically involves switching between CDNs to maximize performance and ensure that end users have a high quality of experience (QoE) and positive brand experience regardless of where they are.

A multi-CDN strategy is only effective with comprehensive monitoring. However, CDNs generate a tremendous amount of log data. In fact, enterprises using a multi-CDN strategy can generate terabytes of data every day.

Many observability and monitoring platforms can’t monitor this volume of data while remaining cost-effective. And many platforms can’t handle this volume of data at all. The sheer scale of the data can result in overprovisioning resources to handle and analyze incoming data as well as high costs to store it.

Hydrolix is a real-time data platform designed for ingesting, storing, and analyzing large volumes of data. It’s especially well-suited for use cases like multi-CDN monitoring and providing deep visibility into services from the origin to the edge. Many of the world’s largest streaming and media broadcasters (as well as enterprises in many other verticals such as retail, finance, and security) use Hydrolix as well as TrafficPeak, an Akamai Cloud observability solution powered by Hydrolix, for multi-CDN monitoring.

In this post, you’ll learn about the challenges of multi-CDN monitoring. In the next post, you’ll learn why a monitoring strategy is critical for multi-CDN switching and why Hydrolix and TrafficPeak are the best choices for implementing a multi-CDN monitoring strategy.

Multi-CDN Monitoring Challenges

For the majority of enterprises, the volume of log data continues to rise, with the average being 500% or more over the last three years. This leads to tough choices for teams. Often, they must choose between their data and their bottom line. The pressure to reduce costs usually wins. This typically means discarding data, keeping only a small sample of incoming data, or quickly moving data into tiered storage where it’s difficult to access.

This is a common story for many kinds of log data, but it’s especially relevant for multi-CDN data. Here are four major challenges of multi-CDN monitoring:

Multi-CDN Monitoring Generates Large Volumes of Log Data

Multi-CDN monitoring can generate terabytes of data every day for major enterprises. At Hydrolix, we have seen media providers ingesting more than 10 million log lines per second and more than 30 terabytes per day, with much of that data coming from CDNs.

Many observability platforms have challenges handling data at this scale. They may have bottlenecks when it comes to ingesting and analyzing that data, leading to outages or performance issues that aren’t addressed until end users are already frustrated and abandoning content.

For the platforms that can handle this level of scale, it’s often necessary to overprovision resources, leading to high costs. And many platforms rely on tightly-coupled storage for performance, making large volumes of data prohibitively expensive to retain.

To handle multi-CDN monitoring use cases, solutions must be able to handle large volumes of data in real time cost-effectively. And they must be able to handle the huge spikes in traffic that can occur with real-time events.

Real-Time Events Lead to Unique Challenges

Incident response teams know that the biggest events of the year can lead to the biggest nightmares. For a retail company, the biggest sales days (or weeks) of the year represent a huge chunk of revenue. For a streaming provider, the release of a long-awaited new season is an opportunity for new subscriptions—or even an important part of a campaign to retain current subscribers. And for major broadcasters, a major sporting event can draw hundreds of millions of viewers and massive ad revenue.

All that traffic is a tremendous opportunity to generate revenue. However, it also means congested networks and more potential for things to go wrong. In addition to slowdowns and possible outages, hackers often target major events for staging DDoS attacks and network intrusions.

Major spikes in traffic also lead to increased volumes of log data. For example, for the biggest sporting event of the year, a major media broadcaster ingested upwards of 11 million log lines per second. The following dashboard shows a snapshot of ingest metrics for Hydrolix during that event.

Dashboard shows Hydrolix ingestion statistics

Handling major events takes a tremendous amount of preparation. You need a platform that can scale up to handle spiky traffic and then scale down afterwards to reduce costs. Many platforms have challenges scaling up to this level.

To avoid outages and resource contention, it’s typically necessary to overprovision, leading to additional costs. This is because most solutions still rely on tightly-coupled storage and stateful components. This architecture must be scaled vertically and all at once. These solutions are often challenging to scale down gracefully after events are over, resulting in yet more overprovisioning.

Finally, after the event is over, what happens to all that data? You may want to keep it in order to make comparisons between future and past events. But if the event in question happens only once a year, the cost of storage can add up, especially if the event generated 41 terabytes of log data.

That leads to the next issue.

Short Retention Windows Limit Insights

As a result of high costs, it’s typical for enterprises to either discard their data or move it to cold storage where it’s not readily accessible. While it’s true that the most recent data is especially important for resolving issues in real time, many Hydrolix customers also need to keep their CDN data for long-term insights.

Let’s return to the example of major events. These are often the most important events of the year in terms of revenue generation and brand awareness, so it’s essential that they go smoothly. It’s typical to do a retrospective after events to look for areas of improvement. By retaining data long-term, you can compare events year over year. And CDN data can also provide valuable insights that are useful for BI, data science, marketing, and advertising.

For example, you can use CDN log data to see which assets were most requested during a sale. Then you can slice that data by geo, device, IP address, user ID, and more. That can inform future marketing and advertising campaigns and also provide valuable first-party data about your end users.

You can also use long-term trends to improve performance and reliability. For example, let’s say a CDN showed more latency in a specific geo during a major event. You successfully switched CDNs to improve performance for end users, but you’d like to prevent the issue from occurring again.

If you keep all your data long-term, you can determine whether it was a transient issue or a long-term trend. Are there CDNs that perform better in that specific geo at specific times? Can you implement a better CDN strategy for next year’s event to prevent issues from occurring in the first place?

It’s also typical to implement an automated process to switch between CDNs if performance falls beneath a certain threshold. But how do you define what that threshold should be? Set it too high and end users will have lower QoE. Set it too low and you might generate false alerts and stress out your teams unnecessarily. By having a comprehensive view of your CDN data over time, you can fine-tune alert thresholds for your use case.

Long-term data can even be used to more effectively control the cost of using CDNs. For example, you might be able to assign standard CDN tiers (as opposed to more expensive premium CDN tiers) for some workloads and regions. Or you might realize that just one CDN is required to ensure reliability for certain regions or times.

By understanding larger patterns in how CDNs are performing over time, you can be more proactive as opposed to reactive. Instead of troubleshooting issues and creating stress for on-call teams, you can start thinking about preventing issues from happening in the first place. And your data can also benefit other teams across the organization as well, including advertising, marketing, and data science teams.

If your retention windows are too short because of high costs, you get none of these benefits.

The question shouldn’t be: can I afford to keep this data? Instead, it should be: how can I maximize the value of this data?

Comparing Large Volumes of Origin to Edge Data is Challenging

Many observability platforms talk about the advantages of having a “single pane of glass” for all your data. But if you’re monitoring multiple CDNs along user devices, video players, and other services, you’ll need multiple dashboards. You may even be context-switching between multiple screens and tools.

Ideally, you should be able to compare CDN metrics in a single dashboard like the next image shows.

Map visualization of CDN metrics by country, including metrics like total edge hits

If all your CDN data is in one place, then you can compare metrics like edge hits and offload hits and visualize your data without context-switching.

However, with most platforms, you typically need to use complex, compute-intensive JOIN statements to analyze data across multiple CDN services. In addition to being more costly, JOIN statements tend to be slower when used to analyze large datasets—which is typical for multi-CDN data.

As a result, JOIN statements aren’t the best approach for real-time analytics of large datasets. That means that many platforms can’t easily compare data across CDNs, which is problematic when it comes to multi-CDN switching. How are you supposed to determine which CDN is best for specific geos and even specific users if you can’t directly compare the log data across CDNs?