全球6大DC，日均10亿日志场景下的高可用实践

开篇语

近几年互联网服务安全事故的频发，使得越来越多的企业及开发者意识到数据备份、灾备等重要性，高可用性、高容灾性及高可扩展性的系统和架构建设工作也被更多地置于重心。

在这个过程中，基于公有云提供的基础设施实现高可用已成为多数技术团队的选择。

而面对跨区域+高可用需求时，许多开发者却犯了难，一方面业务场景的不同对架构设计提出了不尽相同的需求，基本上没有可完全复制的架构模版；另一方面是纳入考虑的因素在不断增多，数据延迟、成本开销、物理隔离、快速的恢复能力……如何能在加法的基础上做好减法，对技术团队创新能力提出了更高要求。

对此，InfoQ专访了FreeWheel架构师张磊及FreeWheel 首席工程师姜冰，对话在服务部署于全球6个数据中心，日均产生近10亿广告投放展示日志的场景下，如何做好跨区域高可用实践。

跨区域、高可用性实践背景

数据处理平台提出的多维挑战

作为美国Comcast旗下领先的视频广告管理和投放平台，FreeWheel的数据服务器来自于全球的6大数据中心（美国东西海岸各两大DC、欧洲两大DC），每天产生近10亿的广告投放展示日志，累计产生超3TB的数据，并且有至少18个月的数据需要持久化。

随着数据应用对实时性和可靠性要求的逐渐递增， FreeWheel根据其自身数据特点和应用需求，也在内部采用了一套以Kafka，Hadoop和HBase为核心的Lambda处理架构。

其中，各个数据中心的广告服务器实时地将广告数据传输到本地Kafka集群，中心化的Kafka MirrorMaker接着会将多数据中心的数据聚集到一个全局的Kafka集群。流式处理框架会从全局Kafka集群消费数据，处理之后一方面写回Kafka（为下游实时应用服务），一方面写入HBase，并由Hadoop离线作业将HBase的内容聚合转换成Parquet文件写入HDFS。OLAP服务会同时查询HBase和HDFS，对外提供数据的实时或批量查询（整体架构见下图）。

FreeWheel数据处理系统架构图

FreeWheel首先在6大DC部署了这一套数据处理系统，也很好地实现了设计目标。但随着数据量的不断增长和业务变化的需求，这种模式面临了如下挑战：

1. 可扩展性：越来越多的数据产品接入到新的数据平台，对OLAP服务的扩展性提出了严苛的要求。而在自建的数据中心，受限于规划和整体容量，很难方便灵活地扩展。 同时，传统DC在“超级碗”等大型赛事直播带来流量瞬时波动的场景下，也很难满足对容量的弹性需求。
2. 高可用性：虽然像Hadoop这样的大数据的基础设施本身可以保证一定程度的高可用性，但在遇到数据中心整体性故障时，依然会造成服务的中断。
3. 开发和测试效率：大数据平台开发和测试中，经常需要启停一整套端到端服务或者组件。但在自有数据中心里，受限于资源限制，很难做到及时满足需求。因而也降低了开发测试的效率。

理论上，上述挑战中的部分问题可通过在另一个数据中心部署一套数据处理系统解决或缓解，但考虑到规划、扩容所需时长以及问题根治性等因素，FreeWheel决定直接投入AWS怀抱。

在选择云服务商上，FreeWheel的考量因素主要包括成熟程度、数据监管、可用区（AZ）数以及原生服务的数量等。基于这些考量和相应的测试，其首选了AWS。

基于AWS原生服务的使用权衡

首先，FreeWheel在AWS上也部署了一套Kafka MirrorMaker，同步所有数据中心的数据。然后，再将数据处理平台基本原样搬到了AWS上。

但如何权衡是直接使用AWS原生服务，还是自己维护Kafka、HBase等基础设施？ FreeWheel也有一些思考。

张磊对此总结了两点。 一是需要从平台需求出发 ，例如AWS许多原生服务某种程度的确能带来开发和维护成本的降低，但对于基础数据平台这类业务，直接用其原生服务可能会带来不确定性的增加，乃至反而带来成本的扩增。 二是需要考虑开发者自身的技术熟练程度 ，当大家需要花大量时间投入新系统内部运作原理的学习时，不一定能降低相对应的时间和运维成本。

涉及到具体权衡与改造，姜冰也举例讲解了何时该选择自身维护：

以AWS原生服务Amazon EMR和Amazon Kinesis为例，映射到FreeWheel的数据处理系统中相应的是Hadoop Cluster和Kafka。基于FreeWheel以7*24小时流计算为主的业务类型，如果直接使用EMR及Kinesis，将面临如下问题：

• 原生服务开放程度较弱，因而开发者缺乏更多的机会维护和管理自身集群。例如从对外兼容性上看，Kafka下游接了多样的开源解决方案，与Spark、Flink有天然集成，但Kinesis是闭源的托管服务，下游集成由AWS主导，日志记录的更新和变化将受制于AWS内部研发。
• EMR适合批处理的工作模式，在全天候不间断的运行状态下，重构Hadoop Cluster更能应对流处理场景；

在上述场景下，FreeWheel并没有主动选择EMR或Kinesis原生服务，而是从成本、性能、开放程度、规模化和容错管理等维度与自身维护做了对比实践。但张磊也提到，在可接受的范围内，对于AWS的原生服务能用的FreeWheel会尽量使用， 这样才能更有效地满足高可用需求，降低一定投入。

截至目前，经过测试和调整，FreeWheel已逐步把面向客户的的所有产品都迁移到AWS环境中，目前自有数据中心里只有极少数对内的服务在运行。而最终它也会把所有的服务都迁移到AWS环境中。

高可用实践需求及实现方案解析

高可用性设计目标

一个完整的全系统高可用性设计通常会涉及五大层面：基础设施、服务器、应用程序、系统服务、区域。

在基础设施层，FreeWheel更多的是将AWS视为一项服务， AWS在保证其基础设施稳定性的同时，设计原则即是在假定问题出现情境下的指导设计。服务器层也是如此。

数据层，如果该数据存在于FreeWheel自身系统，其通常会借助于例如Kafka、HBase等天然的Replicate能力——设置多个Replicate提供数据容灾。

应用程序层，FreeWheel一般会将它做到无状态（Stateless），从而更容易实现恢复和实现高可用，无论是水平扩展还是垂直扩展都更方便。

服务层，FreeWheel采用的是Fail Over（故障转移）机制。即任务服务器设置多台，彼此之间通过心跳联系，（数据库、缓存、任务服务器等）任何位置出现瓶颈就只需增加服务器。目前，对于服务器的对等可替换性，主要有三种类型：Active-Active（双主机）、Active-Standby（主备）以及单Active。

• 在Active-Active模式下，FreeWheel通常会通过先绑定Amazon ELB，再注册到Amazon Route 53的方式，从而实现自动对APP无感知访问。
• 对于Active-Standby模式，FreeWheel通常会将相应的信息注册到ZooKeeper，由ZooKeeper实现Fail Over的分布式协调服务，从而实现Master的选举和对外服务发现。
• 对于单Active，一般是其内部ETL依赖于某种服务，FreeWheel会将其绑在AID或ELB中。

高可用的整体实现方案

无论是跨Region还是跨AZ，数据交换都将产生一定的成本开销。面对着庞大数据量和跨Region（AZ）间的数据延迟，在AWS多可用区实践过程中，FreeWheel针对数据平台开源系统对于高可用的需求及AWS自身高可用实践经验，采用了多种定制方式——主要对Hadoop-HBase、Kafka、Zookeeper及流式处理Pipeline实现了不同的高可用解决方案。

1. Hadoop-HBase多可用区

在设计之初，FreeWheel就已平衡了成本、性能甚至可用性之间的关系。但其后续发现，AWS上很多及其类型和存储类型都不尽相同，所以为提升HBase性能就采用了Instance Store这类本地存储。而相应的弊端也随之产生：一旦Instance出现异常，多台EC2实例就会出现终止，尤其是当其在同一AZ里维护时，即可能导致数据的直接丢失。

因此，FreeWheel也需要对HBase在多个AZ上实现高可用。

对于存储模块，FreeWheel选择两个可用区来部署，通过HDFS Storage Policy接口，实现数据块副本数在主可用区和次可用区的分布。 对于无状态的数据应用优先部署在与Hadoop/HBase主可用区同侧，并支持在次可用区快速部署。应用和数据优先同侧的策略，可以有效降低数据应用的因为跨可用区带来的数据延迟，并降低可用区之间网络传输的成本开销。借助AWS提供不同存储介质的IOPS和持久化特点，实现针对不同业务的工作负载灵活选择存储节点配置，并实现业务之间的物理隔离（原理如下图）。

其中，隔离思路主要是基于不同的工作负载选用不用的EC2实例或EBS实例。这样也可根据自身的业务特点，在AWS中选择不同的硬件、实例类型或EBS类型来满足需求。此外，FreeWheel也可以在AWS Hadoop上实现一组机器的上线及下线，而且只把相应keyboard上、下线，而不影响到其他数据。

2. Kafka多可用区

Kafka Topic内每个Partition有多个副本，多可用区部署，需保证在不同可用区的副本个数的划分。姜冰提到，在正常情况下每个Partition里可设置多个Replica，如果要保证高可用，意味着需要将多个Replica同时被部署到同一AZ上，但同时，这样做的弊端是无法保证AZ级别高可用，如果一个AZ宕机将导致整个Partition不可用。

于是，考虑到跨可用区带来的数据延迟以及成本开销，FreeWheel针对数据应用和规模实现了不同的策略。

一种策略是，对于用于ETL流程的Kafka Topic，在次可用区仅部署Partition副本中的Follower。应用程序和Kafka主可用区同侧，读写数据的流量全部在同一可用区完成，这样在主从可用之间，仅有Leader和Follower之间的网络传输开销。在主可用区发生故障时，从可用区的Follower切换成Leader对外提供服务（原理如下图）。

在这种情况下，Kafka Consumer只会在同一可用区消费，从而避免跨AZ间因网络传输带来的成本消耗，同一AZ间的延迟性也大大降低。

而对于以在线服务为主的数据，为了提供更快速的恢复能力，Kafka采用3可用区对等部署的方案，且无差别的对外提供服务：每一个Partition的Leader和Follower以公平的策略随机分配到不同的可用区，在AWS出现可用区级别的故障时，Kafka借助Leader和Follower之间的切换，保证服务的高可用（原理如下图）。

放在FreeWheel的具体业务场景中，为保证广告主预算与广告竞价间反馈回路的可用性高且延时性低，避免出现广告超量投放或投放价格与预算偏差等问题，FreeWheel即需采用上述第二类这种解决方案。

3. Zookeeper多可用区部署方案

Zookeeper Cluster是由1个leader和n-1个follower组成，这n个节点被部署到3个AWS可用区。应用通过名字注册服务将主工作服务（Active）注册到Zookeeper。在可用区发生故障时，应用Active／Standby角色根据Zookeeper名字服务状态变化进行切换，并注册最新的Active的服务到Route53（原理如下图）。

4. Pipeline高可用部署方案

目前FreeWheel DIP（Data Ingestion Pipeline）架构由两部分组成，一是流处理工作类型，二是上下游以小时为级别的批处理工作类型。

流处理消费一次来源于Kafka，同时会和HBase交互，所以就DIP来说，如果能解决数据和状态高可用，其本身是属于一条无状态的数据处理Pipeline。反观，这也是为什么FreeWheel会花更多功夫在Kafa、Hadoop-Hbase和Zookeeper高可用部署上的原因，从而进一步确保DIP数据处理状态和高可用。

FreeWheel DIP主要通过Hadoop YARN部署，采用AutoScaling Group做Scale Out/In以及采用AutoScaling Group绑定同一YARN队列的方式来保证Pipeline的高可用性。

对于批处理工作类型的解决方案，FreeWheel也有比较好的Fail Over方案应对Crash或异常状况下的自我修复。总的来说，利用Pipeline分布式的天然架构，FreeWheel可以通过监控措施很快地对其进行恢复。

感知故障层实践经验

当AZ级别需切换时，一般的终极目标是希望能做到让用户无感知。但目前如果需从主区域切换至备用区域情况下，FreeWheel当前的设计方案是让用户有感知，也就是针对这种场景允许有一定的宕机时间。

因为通过对有状态数据（诸如Kafka、HBase、Zookeeper）实现多AZ，从底层向上的各个业务可形成自我恢复的能力，即使在发生故障时，也已能在极端的情况下为用户无缝提供完整服务。

当跨AZ级别切换时，FreeWheel更多贯彻的是DevOps理念，即不用专职的运维人员，通过监控和脚本自动化的 工具 和方式保证服务高可用。目前在FreeWheel内部受重视的一种模式是Moniter Alerts实现的Code化，即通过相应的框架实现Moniter Alerts，用Code做管理，而非以往那种在站点上做简单配置的方式。

对于Moniter Alerts，FreeWheel用到的主要工具包括Datadog及开源工具如TerraForm和Salts等。

Datadog的工作方式是在每一台需要监控的服务器上运行它的Agent。FreeWheel主要用Datadog实现EC2级别监控，这样可以基于机器类型、用途等，分门别类对其服务进行监控，一是实现系统级别（如CPU、Memory、Desk、网络I/O）的相关监控，二是实现基于 APB级别的监控。

另外，TerraForm（类似于AWS CloudFormation）会应对Launch资源、Scale Out/In和权限配置之类的场景，从而实现AWS资源Config配置。Salts主要是针对分布式执行和跨机器的Poster Check。

高可用实践收效及未来规划

张磊在采访中提到，伴随着高可用实践，FreeWheel也获得了业务的高弹性。对于“超级碗”及世界杯这类大型体育赛事开始时，整个架构会有更好的Scale Out能力应对突发流量，帮助其在AWS上实现高度的动态扩展性。

未来，FreeWheel一方面会尝试将这套系统走向容器化。当然，对于HBase、Hadoop如何更好地结合K8S或利用Amazon EKS等工具，FreeWheel还需要下一阶段的调研及实验。

另一方面，针对更大范围的高可用、数据安全等问题，FreeWheel还将探索Pipeline或数据处理系统怎样在多个Mutiple Region进行Launch，同时提供服务乃至提供快速的Disater Recovery（灾难修复）的能力。

采访嘉宾

张磊 FreeWheel架构师，现负责公司数据平台和数据产品的整体技术把控。

姜冰，FreeWheel 首席工程师，现全面负责大数据平台的架构和研发工作。