【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

  • 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:451579

评论 1 条评论

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

封仲淹:OceanBase开源技术生态全景解析

OceanBase 数据库

数据库 oceanbase

IBM Semeru Runtime 17.0.6.0 在 Linux 下的安装

HoneyMoose

浪潮inBuilder低代码平台分布式微服务架构事务一致性技术解析

inBuilder低代码平台

分布式事务 低代码

折叠屏时代的全新故事,由华为领启

脑极体

华为

Goerli测试币领不到了?还有这三个解决方法

加密先生

eth Goerli

新旧版本功能对比 | v1.5.0 全新升级

BinTools图尔兹

数据库 社区版 版本更新

OpenSea交易平台开发NFT系统部署技术

薇電13242772558

NFT

选择低代码,帮企业数字化转型提交一份满分答卷

加入高科技仿生人

软件开发 低代码 数字化 数字转型

关于 IDP 的五大认知误解

SEAL安全

IdP 平台工程

智慧公共厕所,重构城市公共服务的新模式@光明源智慧公厕

光明源智慧厕所

智慧城市

【论文解读】不和谐区域定位

合合技术团队

人工智能 图像识别 图像处理

苹果电脑软件应用打开出现意外退出、崩溃问题解决办法

互联网搬砖工作者

架构实战营模块 5 作业

白杨

面试还不懂Netty,看这篇文章就够了!

程序员小毕

Java 程序员 后端 Netty 架构师

面试官:谈谈分布式一致性机制

Java永远的神

程序员 分布式 微服务 后端 架构师

NLP专栏简介:数据增强、智能标注、意图识别算法|多分类算法、文本信息抽取、多模态信息抽取、可解释性分析、性能调优、模型压缩算法等

汀丶人工智能

人工智能 自然语言处理 深度学习 关系抽取 命名实体识别

​ 如何处理Xcode上传IPA文件后无法在后台架构版本中显示的问题?

雪奈椰子

智慧污水处理厂Web3D管理系统 把“污水洗白”

2D3D前端可视化开发

智慧水务 智慧污水厂 智慧污水处理 污水厂三维可视化 数字孪生污水厂

OpenTiny 的这些特色组件,很实用,但你应该没见过

Kagol

开源 前端 Vue3 组件库

王者荣耀商城异地多活架构设计

白杨

上传了ipa但在苹果App Store中没有看到构建版本的问题

“ONE”有引力,4月21日见!

博睿数据

智能运维 博睿数据 发布会 Bonree ONE

Drone CI 部署

流火

用户需求挖掘与分析,某新零售快消品电商系统成功交付的秘诀

L3C老司机

产品 产品设计 需求分析 产品管理 用户画像

PCB拼版对SMT组装的影响,华秋一文告诉你

华秋电子

阿里内部都在疯传!企业级Spring Boot 项目开发实战教程,我先肝了

程序知音

Java 微服务 springboot java架构 Java进阶

携多款产品亮相“深圳先进制造业集群展”,华秋积极探索发展机遇

华秋电子

华秋PCB生产工艺分享 | 第十一道之成型

华秋电子

Django笔记三之使用model对数据库进行增删改查

Hunter熊

Python django model 增删改查

阿里云可观测 2023 年 3 月产品动态

阿里巴巴云原生

阿里云 云原生 可观测

在生产环境中运行 grpc 服务所面临的挑战

黑客不够黑

golang gRPC

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