在大多数情况下，客户使用单一的CDN（例如Amazon CloudFront）来向观众提供在线视频流。然而，在某些情况下，您可能会选择使用多CDN部署，出于一些特殊原因，比如需要在媒体交付架构的所有部分实现并行冗余，或者使用特定的CDN来覆盖它们在某些地区的独特覆盖范围。虽然使用多CDN部署可以提供某些优势，但它也可能带来一些挑战，例如对源服务器的额外负载，这需要更多的思考或不同的解决方案。
这篇博客详细介绍了Amazon CloudFront最近推出的Origin Shield（源盾）如何通过减少源服务器的负载来优化多CDN媒体工作负载。减少源负载不仅能提高源服务器的可用性，降低运营成本，还能提升观众的整体体验。一些在生产环境中使用CloudFront Origin Shield的客户报告称，源负载减少和源请求的p90延迟分别降低了高达57%和67%。点击此处了解更多关于AWS边缘网络的信息。
Origin Shield基础
在深入探讨多CDN示例之前，最好先明确一下CloudFront Origin Shield是什么，以及它如何优化那些仅使用CloudFront作为唯一CDN来向观众提供内容的工作负载。
并非所有源都是一样的。例如，有些源对它们能够处理的请求数量更加敏感。特别是对于运行需要更多计算资源的源，如即时打包，或者对于那些不像云端源那样能够轻松扩展的本地源来说，这种情况尤为突出。自2016年以来，CloudFront通过提供区域化的中间缓存（Regional Edge Caches）来帮助保护源免受过度负载，且这一服务自默认启用以来无需额外费用。这些区域边缘缓存自动保护您的源并在其覆盖的区域内合并请求（见图1）。
| 合并请求：指的是将多个来自不同用户或请求来源的相同内容的请求合并成一个请求来访问源服务器。换句话说，当多个用户请求相同的内容时，区域边缘缓存（Regional Edge Cache）会缓存这个内容，并且多个用户的请求会先从缓存中获取，而不是每个请求都直接去源服务器，这样可以减少对源服务器的负载。 |
对于跨多个区域或地理区域的工作负载，或者覆盖多个区域边缘缓存（Regional Edge Cache）的工作负载，您可能希望进一步优化源服务器的负载。现在，只需两次点击，您就可以将CloudFront的一个区域边缘缓存配置为CloudFront Origin Shield（源盾）。Origin Shield可以与任何可通过HTTP访问的源配合使用，例如AWS Elemental MediaPackage、AWS Elemental MediaStore、Amazon S3、Amazon EC2，或任何其他第三方或本地流媒体源。
CloudFront Origin Shield提供了一个集中式缓存层，位于源服务器前面，帮助提高CloudFront的缓存命中率，合并来自多个区域的针对同一对象的并发请求。作为一般最佳实践，您应始终选择离源服务器最近的Origin Shield区域。
启用后，所有来自任何CloudFront接入点（PoP）或区域边缘缓存的源请求将通过Origin Shield位置进行最终缓存检查。任何尚未保存在Origin Shield位置的内容将受益于集中合并请求，从而确保最少只有一个请求会到达源服务器。与之前的图示不同，现在来自Portland区域边缘缓存的源请求将不再直接到达源服务器，而是会转到位于N. Virginia的Origin Shield区域边缘缓存位置。
通过利用CloudFront现有的区域边缘缓存（Regional Edge Caches），Origin Shield并不会在所有情况下引入额外的缓存层。如上所示，分配给美国东部（N. Virginia）区域的接入点（PoP）将继续以其常规方式使用该区域的边缘缓存，即使该区域被指定为Origin Shield区域。然而，来自其他区域的区域边缘缓存的请求将受益于额外的缓存层，因为它们现在会在Origin Shield区域进行额外的缓存检查，从而提供源服务器卸载的好处。
适合使用Origin Shield的场景
Origin Shield可以轻松地集成到任何CloudFront工作负载中。然而，在以下几种情况下，Origin Shield的优势尤为明显：观众分布在多个区域、涉及按需处理（如即时打包或动态图像转换）、或源服务器位于本地并存在扩展或带宽限制的情况。
法国M6集团的子公司Bedrock Streaming表示：“我们在由CloudFront提供服务的直播频道上启用了Origin Shield，并立即看到这些频道的源服务器负载减少了超过26%，而无需进行任何架构更改。我们获得的额外源保护以及源服务器成本节省，使得Origin Shield的低成本定价非常值得。” —— Yann Verry，运营负责人。
虽然Origin Shield可以优化源服务器负载，在使用CloudFront直接向观众交付内容时，它也可以在多CDN部署中为其他CDN提供内容，尤其是在大型直播事件中。
理解和管理多CDN的权衡
如NFL超级碗等直播事件的OTT（Over-the-Top）视频交付每年都在不断增长。这类规模的事件内容提供商有时会使用多CDN策略来交付这些关键任务事件。采用多CDN架构的原因因提供商而异，但通常是为了增加冗余或提升在某些地区的性能，其中一个CDN可能在某些区域有专门的覆盖。在此，我们假设您正在使用包含三个CDN的多CDN策略——Amazon CloudFront和另外两个CDN（我们称之为CDN 2和CDN 3）。在涉及多个CDN的情况下，我们通常会看到每个CDN直接从媒体源服务器拉取内容。
如前所述，尽管在某些情况下使用多CDN架构是有特定原因的，但与单一CDN方案相比，使用多CDN架构也存在一些需要考虑的权衡，例如增加源负载、增加源成本、运营开销以及CDN之间功能不一致等。以下是这些权衡的具体解释：
• 增加源负载：当观众请求清单中标识的段时，每个相同视频段的请求都会在多个CDN之间重复，因为每个CDN会独立填充自己的缓存。这会给媒体源带来不必要的负载，并且更可能影响源的可用性。
• 增加源成本：源负载直接与源的运营成本相关。每个源处理的请求都会产生成本，如即时打包以及向CDN传输数据的出站费用。直接通过源处理多个CDN请求会增加这些成本。
• 运营开销：每个CDN都需要独立的配置，这需要时间和专业知识来理解每个CDN的细微差别。为了保持内容交付的一致性，您可能需要反复配置功能，如源故障转移，这需要在每个CDN中独立完成。
• 功能不一致：并非所有CDN都具有相同的功能，如无服务器边缘计算功能。如前所述，为了保持内容交付的一致性，由于某些CDN缺乏可比较的功能，您可能会被迫限制使用某些CDN的高级功能。
如果您正在使用或考虑采用多CDN架构，CloudFront Origin Shield可以通过使用单一的CloudFront分发来交付内容给您的观众和下游CDN，从而帮助减少这些权衡。实现这一点的方法是将其他CDN配置为使用CloudFront作为它们的源，并将它们的源请求发送到CloudFront的接入点。
正如前面所述，现在所有的请求都将由CloudFront的接入点处理，这些接入点将自然地使用CloudFront的区域边缘缓存，然后在到达源之前通过Origin Shield位置。这种安排提供了多个优势，有助于最小化使用多CDN架构的权衡：
• 最小化源负载：所有请求，无论是直接观众请求还是非CloudFront CDN的源请求，都会受益于一个共同的缓存键，这将帮助最大化边缘缓存的效率，提供更快的观众响应。此外，任何尚未在Origin Shield缓存中的内容请求都会在到达源之前进行合并，从而减少源的负载。
• 最小化源成本：由于只有CloudFront Origin Shield从您的源获取内容，源处理的请求量将减少。这将帮助您降低运营源服务器的成本，例如出站流量和即时打包费用。
• 集中配置点：Origin Shield为您的整个CDN架构提供了一个集中配置点。现在，您可以利用CloudFront的Origin Group进行源故障转移，而无需在每个CDN中复制和维护类似的功能。同样，您还可以使用CloudFront的Lambda@Edge功能，部署无服务器逻辑来实现跨源的动态负载均衡等高级功能。
• 改善网络性能：CloudFront的所有接入点都连接到AWS网络，这是任何云服务提供商中最大的全球基础设施，具有一致的高性能。通过将CloudFront作为其他CDN的源，您现在能够更快地将它们的请求引入AWS骨干网，通过连接到附近的CloudFront接入点来提高请求速度。
使用CloudFront Origin Shield的客户在生产环境中已经看到显著的改进，包括其整体缓存命中率、源负载和源请求的网络性能。例如，用户已经看到：
• 启用Origin Shield后，源负载减少了57%
• 跨区域源请求的首字节延迟（p90）减少了56%，现在通过AWS骨干网进行
• 跨区域源请求的最后字节延迟（p90）减少了67%，现在通过AWS骨干网进行
如何在您的多CDN部署中设置Origin Shield
CloudFront Origin Shield已集成到CloudFront分发的源设置配置中。设置非常简单，可以通过最小的更改轻松引入您的多CDN架构中。
步骤1 – 启用Origin Shield：默认情况下，Origin Shield并未启用。您可以在CloudFront分发的源设置中按源启用它，方法是进入“创建或编辑分发”界面，然后点击“启用Origin Shield”旁边的“是”选项。
步骤2 – 选择位置：接下来，选择Origin Shield区域。点击下拉菜单选择Origin Shield区域。
读者注意：选择Origin Shield区域时，始终选择距离您的源服务器最近的区域，以获得最佳性能。
截至本文发布时，CloudFront在12个AWS区域提供Origin Shield，但未来可能会增加更多位置。如果您的源位于下拉菜单中显示的AWS区域之一，请选择相同的区域作为Origin Shield区域。如果您的源位于下拉菜单中未显示的AWS区域，请参阅CloudFront的开发者指南，了解根据AWS和CloudFront的网络拓扑，推荐使用哪个Origin Shield位置。
对于位于AWS区域以外的源，例如位于您自己数据中心的本地源，请选择与您的源连接延迟最低的Origin Shield区域。您可以根据我们推荐的AWS区域选择，选择离源最近的AWS区域。或者，您可以在接近源的几个不同AWS区域设置EC2实例，并使用ping命令测试这些区域与您的源之间的典型网络延迟。
步骤3 – 更新DNS：
多CDN架构通常使用DNS负载均衡器将观众流量分配到每个CDN，每个CDN都有自己独特的CNAME来接收分配的流量。在使用CloudFront Origin Shield的多CDN架构中，您将使用CloudFront的端点作为其他CDN的源。为了增加可见性，您可能希望为每个CDN的CloudFront端点使用自定义CNAME。
以我们示例中的三个CDN为例，您将在CloudFront分发中设置三个CNAME——Cloudfront.example.com接收直接从DNS负载均衡器发送到CloudFront的观众流量，fetch.CDN2.example.com和fetch.CDN3.example.com分别接收并区分来自其他CDN的流量到CloudFront。
读者注意：尽管流量可能通过不同的CNAME到达您的CloudFront分发，它们仍将共享相同的缓存键。当CloudFront为您的分发构建缓存键时，它使用的是分发的默认域名（即d123.cloudfront.net）作为主机，而不是将流量定向到分发的特定CNAME。
使用不同的CNAME来区分流量的原因，是为了让您能够更好地了解和报告多CDN架构中每个CDN的性能。
步骤4 – 测试、确认和监控
与任何工作负载一样，在将生产流量切换到新架构之前，在预生产环境中测试您的架构非常重要。作为多CDN架构监控最佳实践的一部分，我们建议使用CloudFront的附加日志和报告功能，以获得最大程度的可见性。CloudFront提供了几种方式，通过访问日志、实时日志和AWS CloudWatch指标，帮助您了解多CDN架构的性能。
CloudFront提供免费的访问日志*，并且只需几次点击即可启用（*标准Amazon S3存储费用适用）。如果您为每个CDN源端点设置了唯一的CNAME，如步骤3所述，您的访问日志将显示请求解析到CloudFront分发的哪个域名，在第16字段“x-host-header”中。
启用Origin Shield后，第14字段“x-edge-result-type”将显示一个新的可能值——OriginShieldHit，表示该对象源自Origin Shield区域外，并且是从Origin Shield缓存中提供的。如果请求从CloudFront接入点路由到同时作为Origin Shield的区域边缘缓存，则在日志中报告为“Hit”，而不是“OriginShieldHit”。
此外，您还可以考虑使用CloudFront的实时日志和CloudFront提供的八个额外的实时AWS CloudWatch指标，为您的CDN基础设施创建主动的仪表盘、监控和警报，以确保应用程序的整体健康和性能，如总体缓存命中率、以及4xx和5xx错误率。
移除Origin Shield
如果您不再需要使用多CDN架构，考虑继续使用Origin Shield，即使只是用于CloudFront单独的观众交付，因为它仍然能提供有价值的源负载优化和跨区域请求合并。如果您不再需要使用Origin Shield，可以轻松地禁用此功能，方法是返回到您的源设置，选择“否”来关闭“启用Origin Shield”选项，然后保存配置。
关于高可用性和堆叠CDN的注意事项
将CDN作为其他下游CDN的源时，需要额外关注提供源盾服务的CDN的可用性记录、冗余性和可扩展性。CloudFront及其Origin Shield功能是按照AWS的高可用性最佳实践构建的，具有容错性和冗余性。
CloudFront作为一项服务能够处理海量流量，并在其数百个接入点之间平衡负载。为了更好地确保您的应用程序对最终观众的可用性，作为最佳实践，我们不建议在将CloudFront作为源时启用第三方的源盾或集中式专用缓存。这样做可能会将所有第三方CDN请求集中到单一的CloudFront接入点。通过让其他CDN的解析器将负载分配到其最近的CloudFront接入点（POP），您可以更好地保护您的工作负载，避免受到单一POP可用性事件的影响。
至于Origin Shield，所有Origin Shield区域都利用CloudFront的区域边缘缓存，这些缓存位于AWS区域内，并使用至少三个可用区。这使得Origin Shield能够快速动态地扩展，处理任何规模的工作负载。为了冗余性，Origin Shield使用每请求的错误追踪和多个KPI来触发自动故障转移到两个备用的Origin Shield区域中的一个。如果您的流量自然涉及多个区域，那么备用Origin Shield区域可能已经将您的内容缓存，并会无缝继续保护您的源。
