MaxCompute flighting —— Task灰度发布

2017/03/20 15:48
阅读数 27

前言

按照百科词条的解释:灰度发布是指在黑与白之间,能够平滑过渡的一种发布方式。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。降低发布上线的风险。

灰度发布的关键是选择合适的灰度策略,把符合策略的流量引入到新版本上。灰度策略的选择需要考虑待发布对象在链路或系统中的位置角色(如客户端、移动APP、服务后台等)、用户属性和发布需求目标等。本文将对MaxCompute的Task灰度发布系统进行介绍。

MaxCompute Task灰度发布

MaxCompute flighting(Sprint21)实现了MaxCompute框架和Task的解耦,MaxCompute框架和Task可以根据各自的研发规划进行独立的发布。同时对Task引入了版本化管理(大版本/小版本),MaxCompute框架支持同种Task的多个大版本并存且独立提供服务。这些特性为Task灰度发布提供了基础支持。
MaxComputer_framework
图 MaxCompute flighting 架构图 
MaxCompute目前支持SQL_RELATIVE_TASKS, PS_TASK等Task Package类型, Task的灰度发布便是对这些Task Package发布,希望:
1) 各Task Package独立进行灰,互不干扰;
2) 发布过程对用户透明;
3) 灰度范围、影响面和结果可控;
4) 具有快速可靠的灰度结果评估机制;
5) 操作简单,可自动化/半自动化运维;
6) 版本管理简单,易于进行版本维护;
7) 特殊场合,允许开发线上进行基于灰度测试;

MaxCompute Task灰度发布原理

在介绍MaxCompute的Task灰度原理前,先了解下其业务流程。用户提交作业后,请求首先到worker,worker为每个job创建instanceId,然后RPC到Executor进行TryRun,TryRun时由支持该taskType的Package处理,如果是同步Task,则直接处理并将结果返回,如果为异步Task则返回给Worker,Worker发送给Scheduler,在Executor轮训请求Task时发送给其并继续处理。如下图所示:
screenshot
图 MaxCompute flighting 请求业务逻辑
注:

  • 同步Task: 1 -> 2 -> 3
  • 异步Task: 1 -> 2 -> 3 -> 4 -> 5 -> 6

为了保证Task执行一致性,Worker向Executor发送请求前需要选定package的版本,并且后续请求(异步)也需要该版本package提供,绑定过程在第二步完成。考虑以上事实,可通过在Worker读取灰度流量配置,根据用户属性特征和流量配置决定执行Task的package版本选择结果。灰度原理图如下:
screenshot
图 Task灰度发布原理
灰度发布前,PE或者开发人员初始化灰度配置,灰度配置信息包含预进行灰度发布的版本、参与灰度的用户特征以及灰度时的流量分配,详见Task灰度元数据。准备工作完成后可进行灰度发布。在灰度发布过程中,Worker定时与OTS同步灰度配置并根据当前灰度配置,选取满足特征要求的用户请求参与灰度;按照灰度流量配置引导流量到灰度发布的Package版本上,在灰度发布过程中,PE或者开发人员根据灰度进展状况决定继续灰度还是停止灰度,决定将反应在灰度配置的修改。

Task灰度元数据

基于如上的考虑,MaxCompute设计了各Task独立的灰度发布流程,体现在独立的灰度元数据设计上,如下:

{
        "grayInfo": {
            "MaxComputeServiceTest1": {
                "reserved": {},
                "taskVersion": {
                    "defaultVersion": "default",
                    "flightingVersion": "flighting"},
                "tierGrayInfo": {
                    "DEFAULTTIER": {
                        "grayInfo": {
                            "defaultVersion": 100,
                            "flightingVersion": 0},
                        "reserved": {}
                    }
                },
                "MaxComputeServiceTest2": {
                "reserved": {},
                "taskVersion": {
                    "defaultVersion": "default",
                    "flightingVersion": "flighting"},
                "tierGrayInfo": {
                    "DEFAULTTIER": {
                        "grayInfo": {
                            "defaultVersion": 10,
                            "flightingVersion": 90},
                        "reserved": {}
                    }
                }
            }
        },
        "projectTier": {
            "DEFAULTTIER": [
                "admin_task_project",
                "algo_public",
                "algo_test"]
        },
        "reserved": {},
        "taskType": "SQL_RELATIVE_TASKS"
}

每种Task都有独立的用户特征分组信息(Tier);考虑MaxCompute的多控场景和各控制集群独立的包管理器方式,灰度配置信息上多加了一层控制集群维度,每个控制集群对Task灰度发布共享Tier分组信息,独享灰度配置信息;

Tier配置

Tier是MaxCompute灰度配置的最小粒度,可以对每个Tier设置不同的流量分流信息grayInfo和控制集群维度下的共享Mapping信息。grayInfo信息配置了流量在不同版本上的分流情况,所有隶属于该Tier的project的该种job都按照这个配置进行流量分流;Mapping信息设置了版本Tag到实际的Task Package version的映射,特别的,每个Tier也可以设置独立的Mapping信息,Load灰度配置时,优先使用Tier的Mapping信息。Tier的私有Mapping设置是通过保留字段进行扩展的,如下:

"tierGrayInfo": {
    "DEFAULTTIER": {
        "grayInfo": {
            "defaultVersion": 80,
            "flightingVersion": 20},
        "reserved": {
            "defaultVersion": "tom",
            "flightingVersion": "jerry"}
    }
}

升级/回滚

鉴于线上MaxCompute多控集群现状,且每个控制集群都有独立的包管理器,在升级/回滚时需要考虑MaxCompute框架和Task package的兼容性等问题,需要对灰度元信息进行一定的处理:

元数据 升级&回滚
Tier分组信息 保留
Tier流量分流 重置目标集群

版本管理

MaxCompute flighting解耦了MaxCompute框架和Task,理论上各功能块可独立管理发布,这给MaxCompute的发布管理带来了挑战, 考虑兼容性,MaxCompute对版本管理做了如下约定:
1) MaxCompute框架随Sprint大版本进行发布,并且在Sprint发布时强行进行一次与各Task的版本对齐,携带各Task Package的default版本;
2) 后发布的对兼容性负责;
3) 每种Task有两个正式大版本default和flighting,default随每个sprint发布,flighting在需要对Task进行灰度发布时发布;
4) 固定使用default记录Task发布历史,灰度发布成功的版本需要重新提交成default的一个新的小版本;

配套设施

MaxCompute Task灰度发布涉及到多个工具,包括Task Package的部署工具,灰度配置工具(Admin Task)以及灰度过程中衡量灰度结果的统计工具和监控报警工具。

包部署工具:

OPDS flighting开发了独立的Task Package部署工具package_util,可用于管理Task的控制集群包和计算集群包;通过它可对Task Package进行deploy & rollback等操作;

灰度配置工具:

OPDS的Task灰度配置元信息存储在OTS中,需要使用Admin Task命令实现对灰度配置修改的目的,目前支持的命令如下:

  • 初始化某类型的Task灰度配置;
  • Tier的CRUD;
  • 修改集群标签下的共享Mapping;
  • 修改Tier的流量配置;
  • 修改Tier特定的Mapping;
  • 升级/回滚时是否清楚灰度进度信息;

衡量灰度的指标和监控报警:
MaxCompute Task灰度发布的结果衡量有两个层面,一个是框架层面普遍一般的统计,如task的成功率/失败率,通过与default版本的对比,来进行评估;另一个是Task层面做的专业的评估。框架层面的评估会比较笼统简单,更专业、复杂的评估需要Task层面去进行。MaxCompute框架使用shennong”实时“的输出统计,如下:
screenshot
screenshot

灰度使用场景

Task灰度发布:

1) PE初始化灰度信息;对project进行Tier分组;制定灰度发布方案和应急回滚方案;
2) PE使用flighting版本,部署预进行灰度发布的Task Package;
3) PE按照方案操作更新Tier灰度配置,按部就班的实施灰度发布
4) 开发和PE通过统计和监控工具实时关注灰度进展,根据灰度结果判断继续灰度还是停止灰度;

线上灰度测试:

1) PE初始化灰度信息;创建灰度测试专用的Tier分组,制定测试方案和应急回滚方案;
2) PE部署预进行灰度测试的Task Package;
3) PE按照测试方案设置Tier灰度配置,包括Mapping,分流信息;
4) 开发通过统计和监控工具实时关注灰度测试进展,根据灰度结果判断测试继续还是停止灰度

开发环境可以使用set忽略灰度配置,指定使用固定版本

set MaxCompute.task.major.version=tom;

灰度信息使用:

MaxCompute MaxCompute_worker定时读取灰度配置到灰度判决cache中,间隔为1 min,当有job请求到MaxCompute_worker时,在向executor发出TryRun前使用灰度缓存中的信息判断该请求去往的具体Task package版本,使用规则如下:
1) 优先判断是否使用SET optin 设置task版本,如是使用指定版本进行后续请求;
2) 未使用SET,根据project所在的Tier,获取Tier的Mapping和分流信息,根据分流信息比例确定目标Task版本;
3) 如果目标版本未部署则会对到default

结语

MaxCompute 的Task灰度发布总的来说,配置灵活操作便捷,能够满足目前MaxCompute的Task的灰度发布需求,灰度元数据在设计上考虑了后续的扩展,保留了足够的扩展的能力;在MaxCompute Task灰度发布实践上,MaxCompute发布管理团队提出了流量桶的灰度发布方式,固定个Tier的流量配置信息,将需要灰度的project逐批次的修改归属的Tier,形象点就是将不同的project放入不同流量的桶中。MaxCompute 灰度发布的后续展望,希望开发能够在一定审核下自主的部署日常灰度测试的package,简化当前审批部署流程,提高效率。

 

欢迎加入MaxCompute钉钉群讨论

42559c7dde62e4d333c90e02efdf416257a4be27

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部