产品战略专家梁宁确认出席AICon北京站,分享AI时代下的商业逻辑与产品需求 了解详情
写点什么

云上如何不停机更换关键大数据服务?

  • 2022-05-30
  • 本文字数:4853 字

    阅读完需:约 16 分钟

云上如何不停机更换关键大数据服务?

大家在日常工作中可能会经常遇到系统更新迭代与集群重建等需求,不可避免会涉及到服务的迁移更换操作。针对不同场景和诉求,具体的处理方式会不太一样,但大致的思想和方法还是具有一定的普适意义。本文主要想和大家分享一下团队最近经历的在保障大数据高并发、低延时、高吞吐读写的同时,如何不停机地在 AWS 上更换关键大数据服务的实践,供感兴趣的同学参考。



类似在飞机高速运行的过程中完成更换关键引擎这个高难度动作


背景与挑战


笔者就职于 FreeWheel,是一家拥有完整广告管理解决方案,为客户提供互联网视频广告的投放、监测、预测、增值等关键服务的公司,目前正在被 90% 以上的美国主流电视媒体和运营商使用。


这次涉及集群重建的关键大数据服务是 Aerospike, 它是一个高性能、可扩展、可靠性强的 NoSQL 解决方案,作为 KV 存储支持 RAM 和 SSD 存储介质,并专门针对 SSD 有相应的特殊优化,目前广泛应用于实时竞价等实时计算领域。它在 FreeWheel 要求高并发、高性能、高可靠性的广告实时投放阶段扮演着重要的角色。由于公司业务场景的需求且数据服务原有的 XDR 功能 (类似 replica sync 的功能) 耗时长、成本高、无法支持数据服务的版本升级等现状,所以我们需要在 AWS 的多个 region 上重建整个 Aerospike 集群, 线上重要的业务服务(广告投放、预测与用户画像实时服务的所有流量)需要全部切到对应的新集群上。


重建和更换过程正值美国疯狂三月各种赛事阶段,面临如下挑战和需求


  • 对 Aerospike 实时并发百万级的读与写操作需求;

  • 旧集群已有的上百亿条的记录和几十 T 数据量;

  • 更换过程中不能有数据服务停机时间(停机会极大影响平台线上广告投放);

  • 新集群的数据不能有错漏;

  • 更换时间越短越好,节省双集群并存带来的成本。

如何设计不停机的更换方案?

总体设计


那么如何设计这样一个关键大数据服务不停机无缝切换的方案呢?


通常对于非大数据场景,非常直接的想法就是,在 backup 和 restore 数据到新集群的过程中,暂停写入(Ingestion)端数据的写入,当新集群数据 restore 结束后再打开 Ingestion 端的写入,并且直接写入到新集群,然后用新集群来服务线上即可。


但这个思路对于大数据场景就不太适用了。由于旧集群的数据量大,据 SRE 同学以往的操作经验,backup + restore 这部分数据到新集群大约需要一个星期左右,而 Ingestion 端数据也在每秒百万级写入的量级。直接停掉 Ingestion 端、试图减少新旧集群数据的变化和干扰的方法看上去不太现实,因为会严重影响关键业务数据在线上的使用,对客户的业务和广告实时投放产生影响。


所以我们需要在同时保障数据服务大量写入和读请求的情况下另辟蹊径,以下是我们的思考和设计:



持续双写 + 主从集群灵活切换


在集群数据开启 backup 的那一刻开始,到新集群经历 restore,对齐新旧集群的数据至切换完成,再到旧集群最终下线,一直持续向新旧集群双写(图上① ② ) Ingestion 端进入的数据。


另外在 Ingestion 端写入数据时,业务上需要先从集群中读取旧数据然后进一步和新数据 merge 后再写回集群,所以在持续双写过程中,会存在主从集群的角色转换,其中主集群负责线上的写入与读取,而从集群主要是保持数据的同步:


  • 阶段 1:在数据对齐前,由旧集群担任主集群角色,新集群进行快照的 restore 和同步写入;

  • 阶段 2:两个集群的数据对齐后,由新集群担任主集群角色,而旧集群继续保持数据的同步写入。


对齐后依然持续双写可以从流程上保证两个集群的数据都不会丢,且系统一直拥有快速切换到旧集群的能力,来保证数据服务高可靠和切换过程中的永远的 Plan B 准备。

充分利用数据服务特性


在数据写入过程中,可以充分利用数据服务特性保证 Ingestion 端的数据拥有高优写入覆盖权限。之所以这么做是因为 Ingestion 端写入同一个 key 的数据版本相对于 backup 和 restore 的数据一定是较新的版本,所以需要确保较新版本的数据不会被 restore 的快照里较旧的数据覆盖。


这时可以充分利用 Aerospike 在 restore 过程中 unqiue 特性:“如果 key 在 Aerospike 里已经存在那么 restore 就不再向集群中写入该条数据”, 来保证 restore 的数据不会覆盖 Ingestion 端的最新数据版本。

加速新旧集群的数据对齐


首先我们看一下新旧集群数据不一致的区间发生在哪里,下面是一个集群切换的大致时序图:



由时序图可直观看到,数据不一致的区间会发生在:开启双写(T1)->开始 backup + restore (T2) -> 结束 restore(T3)-> 暂停写入,开始对齐数据(T4)。


如果需要记录旧集群在这一区间内所有数据变化,那么以 Ingestion 端每秒百万级的写入,可想而知,在进行 restore 和 backup 的这一周积累的数据记录有多大。这样一来通过重放数据来对齐新旧集群的时间势必会拉长。


有没有可能缩短这部分数据对齐的时间呢?


经过仔细分析,只记录 delete key 的数据变化就可以加速新旧集群的数据对齐。


在 Ingestion 端的写入场景下,由于 delete key 数据变化占整体数据写入的比例不到 1% , 所以该优化可大大减少需要用来对齐差异的数据量,加速数据对齐的过程。大家可能会疑惑,数据服务写入涉及增删改,为什么只记录 delete keys 并且后期只 replay delete keys 就能保证新旧集群最终数据对齐了呢?我们可以一起分析一下原因。


  • 分析


在对齐前,这个数据变化区间里涉及到的旧集群的 keys 有如下几种情况:



通过对以上各种场景的分析可见,delete key 部分相对特殊,可能会存在 Ingestion 端去在新集群中执行删除后的 key 再次被 restore 阶段写回(执行删除操作的时刻早于 restore 的操作),因此会带来新旧集群的差异。而其他场景的最新数据状态已经如实反映在新集群里,无须记录和对齐。


  • 技术选型


技术选型部分考虑用临时的 Aerospike 小集群来记录 delete key,主要考量点有以下几个方面:


  • Replay 阶段对于服务 scan 的性能要求较高,期望可以在较短的时间内完成,因此对于技术栈的高性能读写具有较高的要求;

  • Ingestion 端有大量写入 delete key 的请求以及删除已记录的 delete keys 的请求(比如该 key 后期又重新写回集群)下,因此也对技术栈读写的性能有极高的要求;

  • KV 存储结构可以减少 Key 的冗余,可以减少存储的大小。


在对比了 AWS S3,MySQL,Aersopike 后,综合读写高性能要求(Aeropsike 可以保证 800k 每秒的 QPS)和实现维护及 cost 成本,Aerospike 是一个 ROI 更高的选择。

分布式共享配置 + 灰度切换


Etcd 是用于共享配置和服务发现的分布式、一致性的 KV 存储系统。我们通过 etcd 来控制关键流程和灰度切换,比如是否要开启双写、是否开始记录或者停止记录 delete key、 切换 Aerospikey 主从集群、灰度切换线上服务用哪一个 Aerospike 集群等等,只需要修改相应的 etcd 配置即可,无需再修改代码升级上线,使得整个操作更方便、可控,也为随时停止操作切回原有的 workflow 的 Plan B 带来更多的灵活性。

数据验证 + 关键业务指标监控


在做完新旧集群的数据对齐后,我们通过再一轮的数据验证保证数据的准确性。考虑到数据量的大小,同时为了避免验证对线上集群和 Ingestion 的影响,以及由于对比过程是一个非原子性的操作,新旧集群的数据在高 QPS 写的场景下可能会取到不同版本的数据,所以我们采用以下三个维度来做数据验证保证数据的一致:


  • 新旧集群的 object count 需要一致;

  • 对 1% 的数据进行抽样对比,数据差异需要控制在 1‱之内;

  • 对于可能检测到的非常少量的差异数据,需要再一次验证新旧集群保证这些“差异”数据完全一致,彻底消除非原子性操作带来的误判。


监控部分由业务模块加上相应的关键指标,比如 Aerospike 里的 hit ratio(有多少发送到 Aerospike 的 key 并且该 key 能在 Aerospike 里找到对应的记录,即 hit_ratio = key_hit_counts / key_query_counts),就可以从另一个侧面监控新旧集群的数据质量是否一致。此外,监控部分也有对 Aerospike 本身的读写性能、QPS 等等的报警指标,帮助时刻关注对线上服务的影响和性能变化。

具体迁移更换步骤


1. 新集群构建、前期设计开发及环境监控指标等准备


按照总体设计开始双写、数据对齐、验证、监控等相关开发工作,与此同时,SRE 同学帮忙准备新集群及临时辅助集群环境,并进行初步的新集群性能测试,保证新集群的性能满足业务需求。


2. 打开双写,设置旧集群为主集群,并记录变化的 delete keys


通过 etcd 打开 Ingestion 端的双写以及记录 delete keys 的相关配置。



3. 开始旧集群数据的 backup 和 restore 过程


开始 backup 旧集群数据,backup 完成后新集群通过 unqiue 特性进行快照数据 restore。与此同时由于持续双写,所以新集群也同步写入 Ingestion 端的数据。整个过程 AWS 上每个 region 的 backup + restore 耗时大约一个星期。



4. 根据 delete 的 keys 通过 replay 对齐数据


通过记录 delete 的 keys 来进行 replay 对齐新旧集群的数据。在进行 replay 的阶段,会暂停 Ingestion 端的数据写入,防止误删后续新加入进来的数据。基于临时 Aersospike 集群的高性能,几个 region 分别根据 delete keys 重放两次的情况下(第二次重放是为了进一步保证数据都彻底删干净),存储的约五亿个 keys 的处理时间总共大约只需一个小时左右。其中由于并不是所有记录下的 delete keys 都真的需要对集群里数据进行实际操作(可回顾“加速新旧集群的数据对齐 ”里对于 delete keys 的情况分析,有一些记录的 delete keys 已经并不存在新集群里了)。实践中实际处理的数据约五千万,命中率约 9%。所以对于 Ingestion 暂停的影响非常小,后续可以通过加大 Ingestion 速率来快速追赶这一个小时的数据。


执行 replay 操作结束后,会通过 Aerospike 记录的上次 Ingestion 暂停时写入的 Kafka offset 来保证数据写入的连续性,并重新恢复 Ingestion 的写入。



5. 数据验证


对齐数据后,分 batch 对新旧集群进行 sampling scan 对比,对比结果需满足设计阶段对于数据验证的要求。


6. 下游线上服务切换至读新集群


数据验证通过后下游线上服务可放心切换至读取新集群的数据。


7. 双写切换新集群为主集群,仍持续进行双写


切换新集群为主集群角色,同时响应线上的服务读取请求和 Ingestion 端的写入请求,并持续通过业务监控指标及报警观察新集群的性能和数据质量。切换后双写依然持续写入,以防极端或者未考虑的场景发生,平台仍具有 Plan B 能力可以迅速切回旧集群。用来辅助数据对齐的 delete keys 模块及临时集群此时可以下线收回。



8. 关闭双写,下线旧集群, 清理环境和代码


持续观察一到二周,线上一切正常,那么可通过 etcd 优雅地关闭双写,并下线旧集群,清理不需要的代码。


成果与体会


这次关键大数据服务的集群更换在较短的时间里圆满完成,整个过程比较平稳,0 事故发生。同时在更新的过程中统一了公司所有的 Aerospike 版本且都升级到最新的 5.x,另外也打开了 Rack Awareness 功能等等,使得广告平台上这个重要的大数据服务在 AWS 上的多 Region、多 AZ、高可用、可扩展和高性能的能力得到进一步保障。


由衷感谢团队小伙伴们通盘地考量、准备、详细的设计和快准稳的付出,以及 SRE、广告投放和预测团队的通力配合,让这个高难度操作的完美交付成为可能!


面对线上关键大数据服务要求不停机地进行更换且不允许出现一丁点儿差错的场景下,前期的设计如何仔细全面都不为过,而永远有灵活且快速的 PlanB 方案 stand by 也是可以让你沉稳地面对线上各种突发状态,并且夜晚也能安然入眠的实用利器。


作者介绍:


肖红梅,毕业于北京大学,曾任职于微策略、美团、Pegasus 大数据公司,具备丰富大数据开发与调优、大数据产品分析、数据仓库 / 建模、项目管理及敏捷开发的经验。现担任 Comcast FreeWheel 数据 Identity 团队高级经理。


目前 Identity 团队主要负责广告生态里关键的受众定向这一环节, 基于 FreeWheel、客户及第三方数据管理平台(DMP)生成的数亿用户画像,在海量数据中通过数据整合、机器学习、数据挖掘、图分析等挖掘出有价值的信息来赋能业务,实现基于数据的用户精细化广告投放运营和精准营销,为客户提供业务决策提升服务质量,并最大化数据的价值与核心竞争力。

2022-05-30 15:452003

评论 1 条评论

发布
用户头像
十分优秀!太有收获了
2022-06-02 13:51
回复
没有更多了
发现更多内容

如何使用PHP开发API接口?

科普小能手

php API php扩展 API接口 API 测试

公链数字钱包开发与加密钱包App原生开发

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 公链开发 代币开发

区块链NFT项目开发流程

区块链软件开发推广运营

交易所开发 dapp开发 链游开发 公链开发 代币开发

Python 如何根据给定模型计算权值

不在线第一只蜗牛

Python 深度学习

比 Copilot 快两倍以上!在我的开源项目 AI Godot 桌宠中用通义灵码解决问题

阿里巴巴云原生

阿里云 云原生

更经济实惠的SD-WAN组网

Ogcloud

SD-WAN 企业组网 SD-WAN组网 SD-WAN服务商 SDWAN

揭秘!Vue3.5响应式重构如何让内存占用减少56%

EquatorCoco

Vue

GitLab 出现 500错误怎么解决?

极狐GitLab

gitlab

快递鸟物流跟踪API代码参数接入流程

快递鸟

快递物流

业务、技术、管理,谁才是指标平台的用户?

Aloudata

数据仓库 数据分析 指标管理 指标平台 指标开发

尝鲜智能体,今年双十一“快递100”用上混元大模型

Geek_2d6073

淘宝订单信息获取接口,淘宝订单信息获取API

tbapi

淘宝API接口 淘宝店铺订单接口 天猫店铺订单接口 淘宝店铺订单API

语音 AI 革命:未来,消费者更可能倾向于与 AI 沟通,而非人工客服

声网

海外网络加速的技术手段有哪些?

Ogcloud

网络加速 企业组网 海外网络加速 企业网络加速 CDN网络加速

极狐GitLab如何禁止从 UI 上下载代码?

极狐GitLab

gitlab

【问卷调研】HarmonyOS SDK开发者社区用户需求有奖调研

HarmonyOS SDK

【JIT/极态云】技术文档--模型事件

武汉万云网络科技有限公司

比 Copilot 快两倍以上!在我的开源项目 AI Godot 桌宠中用通义灵码解决问题

阿里云云效

阿里云 云原生

快递鸟单号识别API接口代码操作流程

快递鸟

快递

怎么在线画用户旅程图?分享10个用户旅程图模板!

职场工具箱

职场 产品经理 在线白板 绘图工具 用户旅程图

瞧瞧别人的Controller,那叫一个优雅!

快乐非自愿限量之名

Java 前端

八招解决 Golang 性能问题

俞凡

golang

百度发布 AI 眼镜:全球首搭中文大模型,支持边走边问;OpenAI 联合创始人宣布回归,主抓重大技术创新丨 RTE 开发者日报

声网

Serverless 微服务治理神器: 阿里云 SAE 全链路灰度揭秘

阿里巴巴云原生

阿里云 Serverless 云原生

《实力见证,卓越前行 ——伊克罗德信息荣获 Amazon Redshift Delivery 认证》

伊克罗德信息科技

大数据 Amazon

【JIT/极态云】技术文档--审批事件

武汉万云网络科技有限公司

2024年AI办公工具API:优化工作流程的智能解决方案

幂简集成

API

南京大学 鲲鹏昇腾科教创新孵化中心揭牌,引领高校科研生态新模式

Geek_2d6073

MES系统助力中小企业数字化转型

万界星空科技

数字化转型 生产管理系统 mes 万界星空科技 中小企业数字化转型

2024-11-13:求出所有子序列的能量和。用go语言,给定一个整数数组nums和一个正整数k, 定义一个子序列的能量为子序列中任意两个元素之间的差值绝对值的最小值。 找出nums中长度为k的所有子

福大大架构师每日一题

福大大架构师每日一题

覆盖30个省市自治区万余家医疗机构,原生鸿蒙助力打造智慧医疗便利体验

最新动态

云上如何不停机更换关键大数据服务?_语言 & 开发_肖红梅_InfoQ精选文章