引言
iGraph是一个在线图存储和查询服务，从2015年年初正式上线到现在，已经平稳经历了3次双十一大促的历练。在这几年的发展过程中，我们持续改进用户接入体验、跟TPP推荐业务平台一站式集成、在线服务质量持续保持稳定，这一些长期投入让iGraph赢得了越来越多集团客户的信任，其中包括集团的核心搜索和推荐业务。随着支撑越来越多集团业务，iGraph已经发展成为集团在线服务架构中一个非常重要的基础服务设施。为了支撑iGraph业务的快速增长，今年上半年我们开发了AutoUmars基础管控组件，并基于此重构了iGraph管控系统。在刚刚过去的2017双十一大促中，iGraph系统的各项核心业务指标达到了前所未有的峰值。
下面我们分享一些今年大促中iGraph的相关业务数据：
- 在中美俄三地提供了万级别表数目的在线并发访问。
- Proxy峰值入口访问QPS 千万级别，Search访问QPS峰值达到亿级别。
- 双十一当天完成数万次索引构建，产出数千TB的索引数据，完成数据回流数万次。
为了能够高效稳定地支撑今年双十一，iGraph团队面临的问题非常具有挑战，但是我们就是喜欢解决具有挑战的问题，也非常乐此不疲。相信大家也对我们的问题和解决方案非常感兴趣。这也是我们写这篇文章的目的——介绍iGraph团队如何通过自动化流量预估和基于机器学习的智能数据调度来高效支撑2017双十一大促！
问题定义与挑战
1. 如何预估双十一iGraph的峰值访问量？
iGraph作为一个基础查询服务，流量预估跟一般的业务系统差异非常大——不能简单通过当前流量乘以一个系数得到大促流量，主要体现在如下方面：
- 如上图所示，iGraph调用方有上千个（仅仅TPP平台上场景的数目就超过上千个，这些场景几乎都是iGraph的调用方），并且每个调用方访问iGraph的流量特征都不一样（单次用户请求处理访问iGraph的次数、表的数目、以及每张表访问的消耗等），每个调用方的峰值QPS千差万别。
- 有一些调用方在大促期间查询逻辑和日常的查询逻辑不一样，无法简单根据日常访问流量进行放大得到大促流量。
- 对于一些大促常场景日常没有流量，只有大促当天才打开。
基于以上三点认识，我们就知道看似简单的流量预估对于iGraph来说并不简单。之前我们在业务体量较小的时候，是通过人肉进行跟业务方收集流量特征最终得出大促的峰值访问流量，这种出力不讨好的事情我们永远不会再这么干了，因为今年我们我们开发了自动化流量预估系统，高效自动化解决上述问题。
2. 如何将万级别表调度到不同星座，让这些星座的负载做到尽可能均衡并且兼顾业务隔离？
假设我们已经成功估算出iGraph峰值流量了，现在我们已经知道所有表的峰值QPS。但是新的问题出现了，如上图所示，那就是我们需要多少容器资源来支撑这些峰值QPS以及如何将这些表合理地部署到各个星座（在iGraph中，我们把一个小的容器矩阵称为一个星座）中。每个容器的资源是有限的，这些资源包括CPU、内存、磁盘、可以加载的表总数等等。如何将这万表调度到不同星座，使得每个星座的资源不会用超，并且尽可能让所有星座资源使用率均衡称为我们需要解决问题。这是一个带约束运筹优化问题，所幸的是我们有iDst同学（@康托，@李涛）的帮忙。iDST智能决策团队专注于与机器智能决策相关的深度学习、运筹优化技术的研究与赋能，目前已在集团内外，新零售、物流、数据中心、交通等多个行业领域得到应用。我们只要把表的相关指标信息、集群拓扑信息、当前表的部署信息提交给他们，他们就可以给我们算出一个最优的且数据迁移代价较小的新的数据部署拓扑。
当上述均衡分布的问题解决后，再来看下之前出现的业务隔离做的不好的问题：单个业务方访问异常时会导致加载在同一个星座中的其他业务都会受影响。我们做了以下几点，问题也就迎刃而解：
- 每份数据会根据所属业务方分配资源池标签，在计算分布部署时会考虑数据所带标签：相同业务线的数据迁移只会发生在自身的资源池内，这样既保证了数据端的资源隔离，也可以支持业务线拆分的自动迁移
- 在Proxy端，我们按照业务访问进行了流量入口划分，给业务方分配单独的访问入口
基于上述两点，从入口到数据层面都较好的实现了业务隔离。
这里需要特别提一下的是，今年我们初步探索出一套单请求消耗CPU的模型，在这个模型上线之前，我们都是假设每个请求消耗的CPU是同等的，而实际上不同请求的CPU消耗相差特别大（这和请求的特征紧密相关，比如请求查询的表类型、索引中查出来的结果数目、单条结果的大小、最终返回的结果数据等等），导致星座之间CPU利用率差异较大。上了新的模型之后，这个问题得到了很大的缓解，详情参见后面大促数据。
3. 如何自动化分析全链路压测iGraph指标？
如上两个问题解决之后我们需要检查上面两项工作的成果是否符合预期。我们是通过大促全链路压测的方式来验证我们的流量预估是否准确以及表的部署是否合理（不能出现数据部分星座访问过高或者过低的情况）。这需要把我们的预估和实际压测数据拿出来进行diff分析，包括表的QPS维度、星座QPS维度、星座CPU维度、场景QPS维度等。通过这个全面分析，我们一方面能够check我们的流量预估和部署是否合理，另外一方面能够找出压测过程周某些场景流量压多了或者压少了，以及流量成分发生变化的情况，然后反馈到调用方在下一轮压测中解决。
系统架构
既然问题已经定义清楚了，我们提出了如下图所示的系统架构来极大提升我们今年双十一大促准备工作的效率。整个项目由iGraph工程团队和iDST算法同学合作完成
下图是我们整体的系统架构。
下面介绍下各个组件的功能：
1.流量特征分析和预估
结合调用方自身QPS和iGraph中该调用方的各维度QPS信息，流量成分分析对每一个调用方分析出如下结果：
- 调用方一次请求处理需要访问多少次iGraph Proxy
- 调用方一次请求处理需要访问多少张iGraph表，以及访问每张表的次数
- 针对大促场景，由于平时没有流量，流量分析服务会在场景压测期间进行特征分析
- 针对部分日常场景在大促期间流量特征发生变化的情况，流量特征分析服务会分别记录日常流量特征和大促流量特征。在进行大促流量预估时，选择大促流量特征进行预估。
- 根据上游调用方流量峰值预估和iGraph中流量成分分析的结果就可以计算出每一种来源对iGraph Proxy峰值访问QPS和Search峰值访问QPS。
- 预估出所有场景的Proxy峰值访问QPS和Search峰值访问QPS之后进行叠加聚合，就可以得到iGraph服务Proxy层峰值访问QPS、Search峰值访问QPS以及每一张表的访问QPS。
2.指标收集与计算
指标收集
表级别相关指标（内存、磁盘、QPS、Latency）容器相关指标（磁盘、内存、CPU消耗）都是通过KMonitor获取，感谢Kmonitor同学为我们提供稳定metric系统支持，KMonitor是基于optsdb on druid架构的监控系统，支持api接口获取监控数据。 kmonitor作为统一的监控平台来支撑业务监控和智能运维的相关需求。 关于kmonitor的详细介绍可以参考Kmonitor监控平台。
容器相关的配置通过iGraph管控系统Autoumars获取
指标计算
表级别相关的计算指标我们重点收集了单表消耗内存、单表消耗磁盘、单表消CPU等指标，由于像内存、磁盘等指标是可以明确统计的，这里就不做过多赘述。对于单表单次访问的CPU消耗我们初步建立了一个计算的模型：单个容器的CPU消耗取决于容器内所有表的访问QPS、访问rt、以及容器本身的一些特性。
zoneCpuUsedi=F(TableQps,TableRT,Ci)
Ci表示自容器自身的特性影响
zoneCpuUsed=∑(TableQPSn∗TableRTn)∗zoneCpuWeight
TableCpuCostPerQuery=TableRTn∗zoneCpuWeight
zoneCpuUsed=∑(TableQPSn∗TableCpuCostPerQueryn)
根据上述的一些模型来计算单表单次访问的CPU消耗，结合预估的qps来计算单表CPU消耗。
策略控制
由于iGraph业务的特殊性，部分数据表是不能进行迁移
- 单列容器内表无法进行迁移
- 原始odps分区缺失数据无法进行迁移
- 部分容器只能迁出，无法迁入
- 预热期和正常大促期间数据会发生替换，这种需要做表映射保证表下线后负载仍较为均衡。
- ......
这些数据会打上一定的无法迁移的标签，在计算最佳分布逻辑时会考虑这些标签，进行策略控制
3.IDST算法产出调度计划
算法同学会根据之前产出的集群状态快照作为优化引擎的输入，优化引擎的输出则是最终需要执行的迁移序列。
4.调度执行
算法产出最终迁移序列之后，Autoumars将会自动扫描产出结果，解析完成后按照固定的批次顺序执行迁移任务：
解析完成的迁移plan：
具体的迁移任务：
大促效果
下面总结一下在今年大促期间的取得成果：
- 流量预估从原先的需要算法同学紧密配合，变成了算法同学无感知，并且一天之内就能出一个版本的流量预估报告。
- 成功进行多轮的负载平滑迁移，共计进行了数万次数据表迁移，将集群中各个容器的CPU平均负载提高20%左右，磁盘使用率和内存使用率稳定在较高水位，未出现各个资源使用不均匀的情况。
- 大促效果
- 调整前各个星座负载状态，单个柱状图表示了单项资源（内存、磁盘、cpu等）使用额度，标红部分就是当前资源使用已经超出最大限制，迁移之后所有星座的负载都均衡了。
- 实际迁移plan执行完毕后CPU消耗的变化，可以明显看出各个容器CPU消耗逐渐均衡
- 大促当天各个星座cpu负载基本均衡
未来改进
今年是iGraph数据部署调整第一次和算法配合一起进行大促的动态调整，仍有很多的不足之处需要后续持续改进：
- 1.单表CPU计算的模型过于简单，需要考虑searcher服务端多层cache对预估结果的影响，这种情况在压测集比较小的场景下影响较大。另外表增量更新部分的开销也需要考虑进来
- 2.在各轮压测完毕后对比分析压测情况和预估情况差异，目前这块还只有简单的工具完成，还未集成到整套管控中去，产品化做的不够好，需要不断完善。
- 3.由于iGraph自身容器迁移成本较高，目前还不能支持实时调度，这块也是后续的优化目标。另外如何用最小的迁移成本来达到平铺的效果需要和算法同学一起研究下。
