本文作者：清豆，阿里巴巴 Elasticsearch 高级开发工程师
简介：
弹性伸缩帮助用户根据定时/定量等策略，自动触发资源auto scaling，最大程度保证业务服务质量，并尽可能的减少低峰期的资源使用成本及人力运维负担。
行业痛点
自2017年商业化以来，阿里云Elasticsearch已经快速发展了3个年头，积累了大量的集群和业务。通过观察线上几千个集群的使用情况，我们发现大量的中高配集群存在资源浪费的现象。典型表现为一天24h中，仅有短短几个小时水位能够达到50%以上，其它时段仅保持在20%左右甚至更低的水平；这样就导致了大量的成本浪费。
而这个问题其实也很好理解。阿里云 Elasticsearch 提供独享性的 PaaS 实例，而大部分业务场景，类似直播、在线教育、物流等，本身就是有明显的高低峰期的规律的。所以为稳妥起见，用户在新购集群前，头部的业务都是按照高峰期预估的峰值流量来评估整体的集群资源，以保证峰值情况下的服务质量；中长尾或内部业务则退而求其次，选择使用单 Elasticsearch 集群做业务混部以节省成本。
如果有非预期的峰值流量到来，则需要人工手动在控制台进行扩容。而往往此时业务已经受到了影响，止血的效率完全取决于运维人员的手速。如果再遇上 ECS 资源库存不足，那真就是欲哭无泪。
对我们云平台来说，实现弹性伸缩能够帮助用户根据定时/定量等策略自动触发资源的 Auto scaling，在最大程度保证业务服务质量的同时，尽可能的减少低峰期的资源使用成本，同时还减轻了人力运维的负担。
为什么是现在来做？
取决于以下四个原因
1、数据搬迁效率提升——TB级索引搬迁从“小时”级到“秒”级
在去年团队推出了秒级弹性 Elasticsearch 计算存储分离架构，从引擎的角度，根本性的解决了弹性扩缩面临的最大问题：数据搬迁的效率问题。
原生ES引擎搬迁1TB索引耗时为小时级别，而云es计算存储分离搬迁TB级索引只需5秒。这是因为计算存储分离使得同一份数据能够被多个 ECS 计算节点共享，所以 ES shard的搬迁只是一份元数据的改动，无需进行任何的索引网络拷贝及磁盘io操作，从引擎的角度实现了秒级弹性的基础能力。
2、Eyou智能运维系统的成熟——分析用户集群历史流量规律，并作出规划
Eyou 智能运维系统不仅能够帮助用户计算高低峰期的资源需求，更能提前发现用户业务指标的异常，在高峰期到来前提前把资源扩上去，交付更高质量的 Elasticsearch 服务。
3、对接了云上 ElasticMonitor 服务——输出高精度业务指标给管控平台，对扩缩容中的异常针对性规避与优化
我们知道 Elasticsearch 原生自带的 Metric 精度是比较粗的，这也是为什么经常出现 Elasticsearch 服务抖动，却查不到任何线索的原因。所以高精度的 Metric 让我们更有底气和实力去帮助用户更好的做弹性这件事情。
4、更成熟的网络方案——规避 ECS 库存不足的问题
我们可以做到跨 AZ 去部署弹性服务，大大降低了库存不足问题出现的概率，保证高峰期能够买到充足的资源，而这一切对用户都是透明的。
![image.png]( "image.png")
可以很直观的看到，使用弹性伸缩后，大大节约了低峰期计算资源的消耗，在预留了buffer的前提下，总成本也很轻松的降低了近一倍。
从这个案例我们也能看出，弹性伸缩最适合的场景是高峰期时间短（8h以内），数据量不大（计算资源占成本的大头）的业务，对于成本的节省是最为友好的。
我们做了什么事情？
独立弹性角色组，保证易用性和灵活性
类似于资源组的概念，我们将弹性扩缩的能力对外暴露为实例内部的弹性角色组，与普通的数据节点角色并行存在。这个弹性组内的服务节点，我们会打上"elastic_type:data"标签，以帮助用户针对性的迁移弹性业务。用户只需要配置"index.routing.allocation.require.elastic_type": "data"在索引setting上，即可将存量的索引迁移到弹性节点上来，最大程度的保证了易用性；相应的非弹性的业务，可以配置 "index.routing.allocation.exclude.elastic_type": "data"，来保证这部分业务不会迁移到弹性节点上来，实现业务的隔离，避免弹性节点变更对非弹性索引产生影响。
数据管理机制
针对搜索和数据库加速场景，为提升服务的查询吞吐，一般会选择在计算资源横向scaling的基础上，同时增加索引的副本数；低峰期在缩掉计算资源的同时，相应也会把多余的副本缩回去。所以这件事情我们也帮助用户来完成，在配置弹性任务时，除了选择高低峰期的计算节点需求，还可以选择需要管理的业务索引，尽可能一站式的帮用户把问题全部解决掉，减少用户二次调整数据规模的负担。
缩容安全保障机制
由于都是在线的集群，资源的缩容相对来说比较复杂。如何尽可能避免缩容导致的服务震荡是我们花了比较多精力来解决的事情，最终确定分别由资源和业务两个维度的监控指标驱动，帮助我们做稳定的缩容保障。资源维度上，我们通过cpu、内存、磁盘资源的预估公式来计算目标节点能否放下全量的弹性索引，提前做好能否缩容成功的预判；业务维度上，通过队列堆积、慢查询比例等指标，智能探测到缩容过程中业务的服务震荡，有问题的话及时中止并回滚变更，保证兜底服务质量。
启发式灰度变更机制
这部分话不多说，直接上图
扩容过程
![image.png]( "image.png")
缩容过程：
![image.png]( "image.png")
未来展望
目前我们在公有云只开放了定时水平弹性的功能。后期我们会逐步向更加智能化的极致弹性方向演进，比如基于资源水位自动触发弹性扩缩、基于历史流量分析预测弹性需求、以及智能流控等功能都已经在规划之中。
![image.png]( "image.png")
【阿里云Elastic Stack】100%兼容开源ES，独有9大能力，提供免费 X-pack服务（单节点价值$6000）
相关活动
更多折扣活动，请访问阿里云 Elasticsearch 官网
阿里云 Elasticsearch 商业通用版，1核2G ,SSD 20G首月免费
阿里云 Logstash 2核4G首月免费
![image.png]( "image.png")
![image.png]( "image.png")
