序言

我在 株式会社AbemaTV 的广告产品开发团队负责 SRE，我的名字是 kosaka。
除了 ABEMA 和 Ameba，还有几个团队在公司开发基于各媒体平台的广告产品和广告投放系统。我们有一个名为 PTA（发布者广告技术联盟）的联盟，将它们纵向整合起来，这个联盟由所属工程师和商务职位的成员们组成，定期举办关于广告投放技术和广告行业领域知识共享、研讨会和公开活动等。
这次，我想以 PTA 2022 年度的圣诞日历活动作为我的参与话题。

ABEMA目前主要使用GCP和AWS，但广告相关产品几乎全部在GCP上运行。虽然这不是什么值得欢迎的事情，但系统出现故障的时候我感觉有机会更详细地了解GCP的各种产品。在这篇文章中，我想总结一些我在过去几个月中对GCP的一些产品所学到的新知识。

预订

我们在广告产品中使用GKE运行微服务。为了预计到即将举行的大型现场活动将有大量同时观看，我们需要增加大量的GKE节点。这次是第一次使用区域资源预订。通过预订，可以指定机器类型、区域和区域来保证资源容量（即使用的确认）。目的是避免在尝试创建节点时因库存枯竭而无法进行扩展。

如果机器类型、区域和区域相匹配，则已经使用中的实例也将消耗此预订配额，因此需要注意预订的实例数量是运行中的实例数量+要额外添加的实例数量。此外，无论实际上在预订期间是否使用资源，费用都会产生。为了优化成本，需要进行精确的容量规划。

尽管稍微偏离了话题，我觉得组织和运营规模变大后对成本的直接意识会减少。ABEMA还没有实现盈利，所以我经常想起曾经在一家寻找盈利模式的初创企业工作时，当时的社长经常告诉我“我们手中现有的所有钱都是来自风险投资、投资者和股东的钱”。由于亲眼目睹了资金筹集是多么困难的经历，我认为减少不必要的成本也是作为工程师重要的视角之一。当然，应该大胆地在需要的地方使用资金。但是，不能轻易地用“用钱解决！”来解决问题，至少应该对是否有其他方法以及它是否真的是最佳选择进行讨论。

云存储

由于使用了CDN，因此几乎没有直接产生高负荷状态的机会，所以以前几乎没有进行故障排除。收到报告表示可能返回错误响应，因此检查了度量数据。发现有一定数量的请求返回了FAILED_PRECONDITION响应，因此进行了原因调查。经过数日解决，结果发现实际上是返回了304响应，但在度量数据上却被观测为FAILED_PRECONDITION错误，而在客户端端则只是普通的304 NOT MODIFIED。这是在对GCS对象执行具有Precondition Criteria中记录的标头的请求时的行为，返回为304或412响应代码，但被记录为FAILED_PRECONDITION的度量数据。

云消息推送

我们在广告分发的观看统计中使用了pub/sub。在直播活动的分发中，由于同时向大量观众发送广告，因此在特定的时间点会出现负载突增的趋势。因此，在pub/sub的扩展/预热能够跟上之前，我们可以观察到负载情况在高峰期之前就已经过去，导致发布者的延迟暂时恶化，并且在指标上出现了deadline_exceeded（超时）的情况。由于pub/sub SDK会对publish进行重试，因此最终会在重试过程中成功发布，但如果在重试期间pod崩溃，则不会发布，从而可能造成观看统计数据的丢失。（实际上，我们将相同内容另外输出到日志中，以便从中进行救援，以提供冗余性。）此外，由于没有达到预期的吞吐量，考虑到未来，我们认为需要进行架构更改。

原因是在广告不播放时，pub/sub主题的负载几乎为零，仅在广告时刻才发生突增，因此解决方法可能是始终保持一定负载状态，或者在临近时刻进行预热。目前我们将pub/sub专门用于直播活动，但也可以考虑将常规广播和点播分发的pub/sub与之整合，并在订阅者端进行处理分支。但是，这可能会导致单一故障点的出现，因此我们希望谨慎讨论。另外，是否在广告之前有意地发送不需要处理的消息也可能会有影响吗？

云数据流

针对上述的pub/sub订阅者。目前的情况是，为了准备处理突发事件，我们事先准备了一定数量的工作人员参与现场活动。但由于负载的变化与pub/sub的依赖有关，所以在负载较低的时间段，工作人员可能会浪费。考虑到观看记录处理不需要实时性，并且只要在pub/sub消息的持续时间内（默认为7天）进行确认就足够，所以我们打算调整工作人员数量以处理一定时间范围内的工作量，或者切换到尚未经验证和实施的自动扩容方案。

管理Prometheus

由于没有充分进行自动部署的Prometheus维护，我们正在进行向GMP的迁移，目前正在进行中。在自动部署中并没有太过在意，但是由于指标数量、Pod数量（指标的发射器数量）和抓取频率与监控成本成正比，因此我们将对未用于监控的指标进行过滤，或者对不需要实时性的指标降低频率等相应措施。为了确定每个指标的用途和来源，我们需要读取各出口程序的文档，有时还需要阅读源代码，因此到底要有多严格地进行过滤是一个值得考虑的问题。

同样，我们也在考虑将Alertmanager转移到GCP托管中。据说从GKE版本1.22及以后的版本可使用。然而，由于没有提供挂载自定义模板文件的方式，因此如果正在使用自定义模板，则需要进行修改以展开模板。

虽然需要自己部署GMP的Prometheus前端，但除了/graph界面以外的UI似乎无法使用。由于我们习惯在/alerts界面上确认超过阈值的警报以及警报设置，这个问题让我有些困扰。是否有任何解决方案呢？我考虑使用API…但是还没有完全调查清楚。

另外，我们也正在通过ConfigMap以YAML管理来切换Grafana配置，以取代通过API进行JSON管理的方法。

结尾评论

这几个月以来，我度过了以前从未有过的激动人心的时光。虽然有些压力，但我感到获得了新的知识和宝贵的经验。特别是在GCP的支持案例中，我非常感谢Google的各位。您能迅速解决我们自己无法彻底调查的问题，并且我们成功地克服了使用英语进行沟通和讨论的障碍，这使我比过去更加希望使用支持服务。
我也很期待未来的新功能和扩展。