Resiliency, scale, improved performance: There are some serious pros to adopting a multi-CDN approach. But using two or more CDNs can also increase the complexity of your systems. Here are eight tips to help you succeed in your multi-CDN strategy.
Group content by type
Content partitioning is a popular approach that involves grouping content by type (HTML, JS, CSS, images, video, API, etc.) and serving content types by specific CDN. The static nature and fixed size of assets (such as CSS, JS) and still images makes them simple to move to a multi-CDN architecture. It can also make it possible to choose CDNs with content specific features, like Instant Purge for HTML, rather than building for the lowest common denominator.
Ensure consistent headers for troubleshooting
Ensuring you have consistent headers helps when you’re diagnosing problems. Encourage your CDNs to work together by standardizing debug headers where possible and publish what you have. For example, what nodes did you hit on path? What is the request ID? Was it a cache hit or miss? How long did the request take from the time the first CDN server received the request? Check out Catchpoint CEO Mehdi Daoudi’s take on the need for consistent headers when debugging CDNs.
Institute consistent hashing of your working set
Instituting consistent hashing of your working set can make the dynamic choice of which CDN serves an object as deterministic as possible, while increasing your cache-hit ratio across all CDNs. If you’re letting DNS randomly choose how to serve 5% of your traffic (1 in 20 requests) and you have a large working set, you won’t be optimizing your users’ performance and will end up paying more for origin egress bandwidth.
Use CDN stacking
Stacking puts one CDN behind one or more other vendors, creating multiple tiers of CDNs. Benefits of this approach include consolidation of requests and better global cache hit rates leading to lower TCO. But note that traditional CDN stacking isn’t as effective in live-streaming scenarios because the content is dynamic, meaning all POPs from your stacked, mid-tier CDNs will still be requesting the same live stream.
Fastly’s Media Shield takes a different approach by helping large live video providers who use multi-CDNs dramatically improve origin offload, decreasing their origin bandwidth costs while improving performance for the end user. Place it between one or more edge CDNs and your origin to optimize multi-CDN deployments. Media Shield goes beyond normal CDN stacking by consolidating multiple requests for the same content down to one request back to origin, which means less origin infrastructure to scale and improved TCO.
Establish consistent monitoring parameters
Adopting a multi-CDN strategy allows you to improve performance by choosing the optimal CDN for content delivery. But to do that, you need visibility into how each CDN is performing. Using consistent monitoring parameters makes it easier and faster for you to compare CDN performance between providers, and thus enables you to fine-tune your multi-CDN implementation. Set these parameters across your synthetic and RUM providers, and monitor all of your CDNs in apples-to-apples scenarios wherever possible. Inconsistent monitoring strategies lead to confusing results due to object size differences, incongruent caching headers, inconsistent testing frequency, nonaligned DNS TTLs, etc.
Employ third-party reporting, logging, and monitoring
Not all CDNs offer real-time visibility into your traffic, but it can be critical in a multi-CDN scenario. Streaming logs is a great way to gain transparency and understanding into patterns for your end users’ traffic. With the integration of real-time logs, products like Splunk, Sumo Logic, Azure Data Explorer (ADX), BigQuery, and similar tools give you insight that previously didn’t exist with “black-box” CDNs (those that make logs available minutes or even hours later). End-to-end monitoring, including of the user’s browser/player, CDNs, and origins, will give you better context for identifying issues as they happen.
Use multi-authoritative DNS providers
A single authoritative DNS provider can represent a single point of failure in your infrastructure stack. It’s an industry best practice to use two authoritative providers that employ an anycast-based approach. This foundational layer is especially important in multi-CDN architectures. This ensures that DDoS attacks against your DNS provider doesn’t leave you with zero name servers to answer your customers queries and will also assist with consistency based on regional performance.
Video content providers should be aware of the option to route multi-CDN traffic using manifest or player delivery methods. You can read more about these delivery methods and other important multi-CDN practices in our multi-CDN research brief.
Seek feature parity and culture fit across providers
In the modern world of infrastructure as code, it’s vital to choose your CDNs based on what they can (or cannot) do for you and the needs of your business. You need to reduce support burden and costs, decrease mean time to resolution, and improve performance for your site or applications across all users — which often translates into revenue. In other words: You need advanced features that are easy to implement and maintain.
To use multiple CDNs together effectively, we recommend you use a parallel toolset from one provider to another. Operators typically tune down their multi-CDN implementation to match the lowest common denominator — if you’re using three feature-rich CDNs, and one basic CDN, you’ll only be able to use a basic feature set across your multi-CDN architecture. But if you swap the basic CDN for a more feature-rich CDN, you’ve ensured feature parity that lets you use more advanced features across your deployment.
As you venture into multi-CDN, you should also consider culture fit. You need CDN support teams that are, in essence, an extension of your team. They must be willing and wanting to work alongside you to quickly fix any issues you encounter. Etsy made sure any CDN they used was a culture fit with their technical team, but also that they had access to engineering resources when needed.