Google Cloud 大型赛事直播案例分享- Google Cloud

举办直播活动需要大量的规划和充足的准备。Google Cloud 可以为需要在全球范围内举办直播活动的客户提供充足支持。本次分享的案例是使用 Media CDN 对 2022 年 FIFA 世界杯足球比赛进行全球分发。直播活动的最大特点是难以预估的海量观众同时观看赛事，这在直播场景中是独一无二的。在本文中，我们将介绍我们与媒体合作伙伴合作中所总结的一些最佳实践和经验教训，这些内容涉及到基础架构的规划、安全性配置以及 Google Cloud 产品的应用，例如用于转码的 Live Stream API、用于源站存储的 Google Cloud Storage、用于分发的 Media CDN 以及如何通过云日志与监控满足运维的要求。

举办直播活动时需注意的事项

可以将举办直播活动视为一个旅程，从获取内容版权开始，到直播活动的最后一天结束。让我们将该旅程分为 6 个阶段，以便于理解和跟踪：

1. 完成视频交付架构

2. 容量规划

3. 实施安全性

4. 冻结配置

5. 监控和预案

6. 测试回退计划并从细节着手

完成视频交付架构

Google Cloud 的 VPC 具有独特的网络架构——VPC 作为一个全球性的 VPC，在每个区域都拥有子网，这让处理多区域架构并提升服务可用性变得更加简单。

准备举办直播活动时考虑以下设计部署模式，从本质上讲，这将看到大量的并发连接和访问。

1. 借助冗余部署提升弹性：虽然在同一区域内规划两个不同可用区的冗余始终是一种选择，但另一种选择是在两个 Google Cloud 区域（类似于下面描述的区域）中进行部署，其中主播放服务器（用于在地面和本地演播室的流之间切换或插入 SCTE 标记）和 Live Stream API 部署在靠近最终用户的 Google Cloud 区域中，并选择附近的另外一个区域作为备份（例如将孟买作为主要区域，选择德里作为备份区域）。

2. 使用 SRT 进行采集：与 RTMP 或 RTP 相比，SRT（安全可靠传输）作为来自传送或直接来自体育场的源流更可靠。

3. 使用 Google Cloud Storage 作为源站：使用 Google Cloud Storage（GCS）作为源站，而非即时打包（JITP）源站。管理和扩展 JITP 是一项挑战，尤其是在高并发环境中。如果基础设施的伸缩没有与用户增长的速度匹配，那么对源站的请求的任何突发峰值都可能导致来自源的 5xx 错误。另一方面，GCS 的扩展性非常好，每个项目的默认带宽配额为 200 Gbps（Meida CDN 和Cloud CDN 的出口不受此配额的限制），QPS 的软限制为 300K，这两者都可以通过提升配额工单来增加。

4. 用于交付的 Media CDN：Media CDN 构建在 Live Google 现有的基础设施与网络之上，该基础设施和网络已被成功应用数十年，用于交付 YouTube 视频和大文件下载，每天支持数百万并发用户使用 Google 自己的应用程序。除了基础设施（数以千计的本地城域网部署）和网络优势外，Media CDN 的源站屏蔽、合并回源、源站故障切换、重传和超时配置、实时日志记录等功能在管理高并发事件方面也可以提供独特的优势。

5. Cloud Armor：大多数的体育赛事都将安全作为法律要求，使用 Google Cloud Armor 的安全功能可以满足这些要求。

容量规划

Media CDN 的容量规划有两个主要要求：峰值出口速率和每秒峰值队列数 (QPS)。这两个要求都可以根据配置参数和业务数据进行计算。

• 峰值出口速率：可以使用并发用户数（或并发用户的历史数据）和平均用户播放比特率的业务假设来计算

o 例如，5 百万并发用户 x 1 Mbps 平均比特率 = 4.76 Tbps ~ 5 Tbps 峰值出口速率

• 峰值 QPS：并发用户数乘以 2，然后除以片段持续时间（因为在每个片段结束时，播放器将请求一个新的清单文件和一个新的视频片段 = 2 个请求——这仅适用于 HLS v3，因为音频和视频片段被混合，对于其他单独的音频/视频/字幕也需要相应地考虑乘数）

o 例如，（500 万并发用户 x 2）/6 秒段持续时间 = 166 万 QPS

实施安全性

大多数体育机构都有合规性要求，例如令牌身份验证以避免盗用、实施 DRM、基于位置的控制、版权问题等。让我们讨论如何在不影响扩展需求的情况下管理它们。

1. 令牌身份验证以避免被盗用：Media CDN 原生支持双令牌身份验证，以验证短令牌和长令牌的请求。如果客户想要撤销不良行为者的特定签名 URL，违反并发规则或盗版企图在令牌到期时间之前访问的内容，可以使用 Network Actions 功能（目前处于内部预览阶段，在此期间您可以联系您的客户团队以获得访问权限）。

2. 源站保护：Media CDN 可以从任何互联网可访问的 HTTP(S) 端点提取内容。在某些情况下，我们的客户可能希望对源站请求进行身份验证，以便仅允许 Media CDN 提取内容，并防止未经授权的访问。 Cloud Storage 通过 IAM 权限来支持这一需求。

3. 实施 DRM ：如前所述，管理和扩展 JITP 在高并发环境中具有挑战性。如果基础设施扩展没有跟上用户增长的速度，那么任何对源站请求的突然激增都可能导致来自源站发生 5xx 错误。有些解决方案只提供与 packager 的 DRM 集成。 JITP 可能会在流量上涨期间成为瓶颈，但是 Google Cloud 的 Live Stream API 和我们的一些 ISV 合作伙伴解决方案支持使用 DRM 进行预打包（该 Live Stream API 的功能处于内部预览状态）并发布到 GCS 存储桶，这使得操作比管理 JITP 的扩展问题更容易。（您将不得不考虑扩展 DRM 代理服务器，我们的许多合作伙伴在过去已经毫无问题的实现了这一目标）。

4. 地理位置和 IP 限制：Cloud Armor 边缘安全策略使您能够根据地理位置和 IP 地址为存储在缓存中的内容配置过滤及访问控制策略。

冻结配置

以下关键要素在避免事故方面发挥着重要作用。在规划直播活动时，正确配置它们至关重要。

Live Stream API 配置：

• 分段持续时间：分段持续时间在用户的感知延迟与最终用户的 QoE 中发挥着重要作用。较短的分段持续时间可能会增加重新缓冲并降低 QoE，因为最终用户网络的拥塞超出了交付架构。理想情况下，4 至 6 秒的片段是两者之间的一个很好的平衡点，在某些情况下，它还可以通过减少 CDN 服务的 HTTP 请求数量来降低交付成本。

• 最终确定比特率阶梯：确定比特率阶梯以在质量和平均比特率之间取得平衡，因为较高的平均比特率会增加峰值出口率。您必须在两者之间取得平衡，以免超过所批准的容量。

o 峰值出口/峰值并发用户将超过批准的数量或您可能已经考虑的初始假设时，也可以删除最高比特率。但是，这种做法可能会带来风险，如果您之前没有对此进行测试，那么建议先在暂存环境中进行测试，然后再在直播生产环境中实施。（为此，主清单缓存 TTL 应小于分段持续时间，否则从 Live Stream API 中删除最高比特率时，4xx 错误将迅速激增）。

• 路径和分段命名法：使编码器发布路径与 GCS 存储桶、分段命名法、Vary、ETag 和 Last-Modify Header 在源站（主源和备份）之间保持一致，以便于源站的故障转移

Media CDN 配置：

接下来的重要内容是配置 Media CDN 以管理故障转移并提供最大的缓存性能。

源站故障切换：在 Media CDN 源站配置中配置主源站和故障转移源站，并定义以下源站故障转移配置：

服务配置：在 Meida CDN 服务配置中，定义以下缓存模式和 TTL 以获得更好的缓存效果，并在需要时灵活地动态修改比特率阶梯。

服务配置路由规则：

设置监控并准备预案

本节分为 3 个部分：通知、识别和解决。

通知：

Google Cloud 通过电子邮件，短信，Slack，Pub/Sub/Pager 等通知渠道为用户提供警报功能，但是配置正确的策略将可以更好并及时的帮助您快速获取有关任何事件的通知。

大多数情况下，以下 4 个指标的趋势变化将帮助您在早期识别任何事件。

1. 5xx 错误应少于请求总数的 1%

2. 3xx 响应应少于总请求的 1%（除非您在服务中配置了重定向）

3. 4xx 错误应该少于总请求的 10%（这些可能是用户尝试尝试不可用的 url 或尝试使用过期的签名令牌，例如来自黑客的尝试）

4. P95 延迟应小于 1 秒（取决于您的片段持续时间和平均播放比特率）

Google Cloud 警报支持使用 MQL 的基于比率的警报，使用下面的 MQL 为 5xx、4xx 和 3xx 响应配置警报。

fetch edgecache.googleapis.com/EdgeCacheRouteRule

| metric 'edgecache.googleapis.com/edge_cache_route_rule/request_count'

| {

filter metric.response_code_class == '5xx' //change this response code class as per your alerting policy

;

ident

}

| group_by [resource.location],

[value_request_count_aggregate: aggregate(value.request_count)]

| ratio

| mul(100)

| condition val() > 1 //Please use 10 when you configure alert for 4xx

| window 1m

您可以使用控制台配置延迟峰值警报，或使用以下 MQL 配置延迟警报。

fetch edgecache.googleapis.com/EdgeCacheRouteRule

| metric 'edgecache.googleapis.com/edge_cache_route_rule/total_latencies'

| align delta(1m)

| every 1m

| group_by [resource.location],

[value_total_latencies_percentile: percentile(value.total_latencies, 95)]

| condition val() >= 1000 "ms"

您还可以使用这些 MQL 创建如下所示的监控仪表板，这将有助于您的监控团队主动监控趋势，并在发现任何问题时报告或提交支持案例。

识别

Media CDN 会将客户端和边缘之间的每个 HTTP 请求记录到日志服务中。 Media CDN 通过近乎实时地传送日志可以提供一些独特的优势。

• 您可以使用日志服务中浏览器功能以及查询语言来快速深入研究 Media CDN 日志以识别问题区域。

• 对于大量请求，您可能更愿意对日志进行采样而不是为每个请求捕获日志，并依赖指标进行主动监控和调查。

此外，如要在存储日志之前进行日志的过滤，举个例子：仅捕获相关字段以减少您需要存储和查询的总日志量，您可以配置日志排除规则，它允许您定义一个查询（过滤器），其中包括（或排除）存储前的字段。

您还可以设置多个过滤器——例如，捕获所有缓存未命中请求，或针对特定主机名的所有请求，并且仅对上述所有日志进行抽样。

解决

根据以往的经验，许多问题都与配置相关，好的工程与 DevOps 团队将会在内部解决这些问题。但是，拥有重大事件支持对直播活动也很重要，Google Cloud 的重大事件支持提供以下服务……

• 在活动开始之前，Google 技术专家会进行架构要点检查，以提前识别并解决例如配额或存储容量等潜在问题。

• 在活动期间，您会获得针对 P1 故障的快速响应，首次有意义的响应会在 15 分钟内完成。

• 在活动结束之后，您会收到一份绩效总结报告，其中包含云环境在活动期间表现的回顾性分析。该报告还将提供用于改善未来活动的一些建议。

请联系您的客户团队，以了解有关计划活动支持的更多信息。

测试回退计划并从细节着手

现在是进行端到端测试并从相对较小的直播活动开始上手的时候了。

在我们开始做这些小事情之前，首先来测试以下步骤并确保不会发生中断。

1. 逐一测试主链组件的故障转移，检查播放过程不会因为 Media CDN 的源站故障转移配置而导致中断。

2. 尝试从主编码器中删除最高比特率，这可能会导致一些 4xx 错误峰值，因为以前下载主清单的用户将继续尝试最高配置文件，得到 404 错误并尝试较低的比特率配置文件。（这需要播放器以优雅的方式处理）

Google Cloud 的 CDN 产品组合

Google Cloud 的端到端内容交付平台支持广泛的用例，例如网络加速、游戏、社交网络、教育、视频点播和直播等。Google Cloud 的内容交付平台也进一步提供了一些增强的附加功能，例如：

• HTTP/3, QUIC 协议

• 生态系统集成，例如 Transcoder API，或 Live Stream API

• 通过 Video Stitcher API 或使用 Google CDN 与 GAM 集成的动态广告插入

• 通过 Google Cloud Operations Suite 进行实时记录和监控

• Cloud Armor 提供的 WAF 安全性

Google Cloud 大型赛事直播案例分享

文章信息

相关推荐