转转微服务容量管理实践

狼啸

1背景2容量管理的目标3发展阶段4容量管理4.1容量水位4.2资源容量优化4.3集群容量4.4压测指标4.5压测标准5扩容、缩容6总结1背景随着转转业务的不断发展和用户不断增长，公司持续增加对硬件和基础设施的投入，用于满足业务发展的需要，然而资源的使用率却逐步下降。因为最初的目标是发展业务，实现功能，随着业务的发展成熟，逐步更加关注服务的稳定性，性能、冗余、灾备等方案，这样更会增加资源成本。那么如何在保障服务质量和确保服务性能的前提下，同时降低运营成本提高资源利用率呢？容量管理就是其中必不可少的一环。2容量管理的目标在解释容量管理目标之前，先来看一下容量管理的含义。百度百科的定义：容量管理致力于在恰当的时间以一种经济节约的方式为数据处理和存储提供所需的容量。在我看来，容量管理的本质是风险和成本之间的平衡，即在保障业务服务稳定的前提下，以最低的成本保证最优的服务质量。所以容量管理的目标有两点：成本控制：容量管理保证服务的容量和性能以最节约成本的方式满足既定业务需求，并对资源进行最有效的使用。业务支撑：容量管理结合当前服务质量（SLA），保证服务提供连续的服务水平;容量管理结合容量规划，指导业务规划所需的费用成本规划和调整。3发展阶段转转的服务容量管理主要经历了3个阶段。第一阶段：无容量管理，服务全部混合部署到物理机和KVM虚拟机上，单台设备运行几十个服务，物理资源共享，造成服务间的互相影响。第二阶段：分析服务的可用性和性能数据配合运维的服务管理经验来降低服务混部比例，下线KVM虚拟机，调整服务配置，提升资源利用率，从而减少服务器数量，达到降低服务资源成本的目标。第三阶段：随着服务稳定性和性能指标数据的不断完善，服务进入云时代，加之压测标准和资源利用率标准的制定，进一步完善了容量管理的基础，成本和服务质量得到了有效的平衡。第二阶段完成后，IT相关资源成本节约了约50%，第三阶段相较于第二阶段，IT相关资源成本进一步降低约50%。对于公司的降本增效的目标起到了关键性作用。那么下面我们讲讲具体怎么做到这样的成果的。4容量管理4.1容量水位容量水位是当前实际消耗的资源（包括裸金属物理机、云资源和其他依赖的SaaS服务）占用当前总体可用资源的比例。例如，B服务有4个云实例，但实际上只使用了2个云实例，另两个实例并未加入分组提供线上服务，所以该服务的资源使用率只有50%，故当前的容量水位是50%。只有获取当前的容量水位，才可以依此进行各种判断和规划。后续进行容量分析时也是基于容量水位的元数据进行多维度数据整合分析并进一步优化。服务容量水位所需要收集的元数据如下表：云主机：CPU内存磁盘网卡应用服务：JVM内存应用线程GC频率QPS响应时间如下图所示，可以看出，对于转转的用户习惯，访问量分布基本是在白天，晚上20:00-23:00用户访问量会逐步增加达到高峰。我们更要关注的是这个时间点上业务服务的容量是否能支撑系统的稳定运行，后续的容量规划也需要按这个峰值的对应的容量水位来估算。4.2资源容量优化了解了容量水位后再对比我们线上服务的资源使用情况发现很多的资源浪费是容量水位偏低造成的。每月服务相关资源的费用也是一个不小的数字，此时容量优化的意义和价值就会凸显出来，这也是我们第二阶段和第三阶段做的事。1、服务配置缩减A服务CPU为4核，内存为8G。如下图所示，单日最高CPU使用率为8%（上限400%），内存使用率72%，在保证服务资源冗余30%的情况下，我们会把服务的CPU配置缩减为2核。B服务容器内存为8G，根据内存公式，服务的JVM内存为6G，此时容器内存缩减到7G比较合理（由于业务场景不同，对于内存的使用需结合业务需要调整，避免引起GC异常或OOM）。内存公式JVM总内存=heap内存+线程stack内存(XSS)*线程数+启动开销（constantoverhead）2、混合部署/策略在线业务和离线业务混合部署，晚间业务低峰期开启离线业务计算任务，有效地利用CPU，实现峰谷轮动。把低等级负载较低的服务或对服务可用性要求不高的服务与高等级或容量水位高的业务服务进行混合部署，充分地利用硬件或云主机资源。例如：A服务是管理后台服务，资源利用率约为10%；B服务为搜索服务，资源利用率约为40%，我们把两个服务混合部署，充分利用主机资源。4.3集群容量单纯的依靠容量水位去评估服务容量只是利用服务管理经验的服务监控数据控制资源成本。更精确更合理的方案是利用压测结合容量水位确定服务集群的准确容量。获取集群容量的方式通常有两种，一种是通过日志回放，模拟线上流量对单实例压测或者通过TCP-Copy的方式，把线上机器的流量拷贝对单实例进行压测,转转初期就是使用这种方式压测。另一种是对整个集群进行压测，通过获取集群的最大容量，再除以集群内实例数量来获取服务单实例容量。从经验和数据来看，采用集群压测的方式更适合一些，因为这种方式完全使用线上真实业务场景进行压测，获取的数值更准确。所以我们现在的单实例容量都是通过集群压测的方式获得。4.4压测指标压测指标通常关注两类指标，一是系统类指标，二是服务类指标。系统指标：CPU使用率内存使用率磁盘I/O使用率网卡带宽服务指标：接口响应耗时耗时分位错误率慢速比4.5压测标准通常情况下，资源使用率并不简单地等于CPU利用率、CPU负载，也包括内存、I/O、服务相关配置不合理造成的瓶颈等等。所有这些资源的瓶颈最终都会表现为响应时间和错误率的增加，所以不论服务有多少资源，我们需要找到一个触及系统资源瓶颈的临界点（如下图所示），在这个点之前，应用的性能表现和访问量是呈线性关系的，一旦访问量超过这个临界点，应用的性能就会明显下降。基于此，我们压测的标准如下：Error%（错误率）：A级服务压测请求错误比例=2倍，注意分析耗时长的接口慢的原因。这个标准中可以看出，响应耗时方面，我们对于不同的百分位请求耗时有着不同的要求。比如A服务的压测QPS为1000，TP50为100ms，TP90为300ms，TP99为800ms，很明显服务的长耗时比较多，服务的性能下降严重，此时的压测数据并不能代表服务的真实容量。所以我们基于现有的服务耗时数据结合服务性能目标，对服务的响应耗时规定了明确的浮动范围。压测目标值配置和达标报告示例:压测获取的服务容量数据会统一记录到服务信息管理平台。5扩容、缩容如下图：基于服务容量数据，在公司的促销活动中，我们实现了定时扩缩容功能；对于日常服务质量保障，我们将利用服务容量数据实现服务容量弹性伸缩功能。随着日常服务压测的流程和规范不断完善，服务的容量数据也日趋完善，这些数据不仅对服务的扩缩起到指导作用，更是对服务稳定性提供了保障。6总结容量管理是一个复杂的系统工程，方式和方法多样。不仅要在策略、方法、方式上进行定义、明确和落地，还需要在规范、流程上不断细化和完善，这样才能达到降本增效的目的。同时容量管理的重要性不言而喻，它是服务稳定性保障、资源成本控制的基石。随着智能化运维技术的逐渐成熟，我们要朝着更低的成本更优的质量目标前进。关于作者张磊，转转应用运维负责人。主要负责业务系统的可用性、性能、容量、运维自动化平台等SRE体系建设。