海量日志接入 Elasticsearch Serverless 应用降本70%以上

简介: 本文将探讨在日志场景下,使用阿里云Elasticsearch Serverless相较于基于ECS自建Elasticsearch集群的成本与性能优势,展示如何通过Serverless架构实现高达 70%以上的成本节约。

概述

随着互联网业务的快速发展,日志数据量日益庞大,传统的日志处理方式面临着成本高、扩展性差等问题。为了应对这一挑战,越来越多的企业开始转向更先进的解决方案——阿里云 Elasticsearch Serverless 。


本文将探讨在日志场景下,使用阿里云 Elasticsearch Serverless 相较于基于 ECS 自建 Elasticsearch 集群的成本与性能优势,展示如何通过 Serverless 架构实现高达 70%以上的成本节约。


特性对比

传统方案:基于 ECS 自建 Elasticsearch 集群

  • 资源利用率低:在非高峰时段,可能会出现资源浪费;而在高峰期,则可能出现资源不足的问题。
  • 维护成本高:除了硬件成本,还需投入大量的人力资源进行集群的日常运维,包括集群监控、数据备份、安全防护、版本升级等。
  • 扩展性差:面对突发流量或数据量激增时,通常需要手动调整集群规模,这不仅耗时且存在一定的风险。


阿里云 Elasticsearch Serverless 方案

  • 按需付费:仅需为实际使用的资源支付费用,无需预购大量固定资源,有效降低了初期投入成本。
  • 自动扩缩容:根据业务需求自动调整计算与存储资源,确保服务稳定的同时避免了资源浪费。
  • 免运维:阿里云负责底层基础设施的管理和维护,用户可以专注于业务逻辑的开发,无需担心复杂的运维工作。


场景模拟

本文将通过真实的日志业务数据,进行一天的日志写入场景模拟:

1、 集团内某应用对应的业务曲线压力曲线如下:(每日 12~13、22~23点高峰以每日为周期规律),写入用量:1.2k~5.4K 数据级 qps 的单 bulk 3MB 写入,不进行查询;

根据上述业务体量,如果通过基于 ECS 自建,按照 CPU 水位上限取 70%以上条件下,选型规格 ECS:24C48G/数据盘:2048 GiB ESSD PL1(50000 IOPS) 云盘,单小时价格 ECS:¥ 4.68/数据盘:¥4.3008(系统盘、LB 等在此不做计入) 6 节点 ES 自建集群单日价格:24*6*(4.68+4.3008)=1293.2352

若需对应其他规格,请自行计算费用比较;

ESSD PL0 承接以上写入吞吐有瓶颈,会导致自建集群在高压下写入队列堆积请求拒绝。吞吐上限见:

https://help.aliyun.com/zh/ecs/user-guide/block-storage-performance

以下为 PL1 云盘的吞吐监控


2、 当日自建 ES 所在某 ECS 负载如下:


3、现将同样的业务数据接入到 Elasticsearch Serverless 应用中,请求监控数据如下:

  • Serverless 应用在 02-09 0 点前后有写入计算资源增加是因为开启了数据整理功能(定期通过无损的 force merge 对索引进行整理,提升查询性能和优化存储空间,会带来额外的写入 CU 消耗

性能相比自建更稳定

下图为客户端写入请求指标图

  • 相同 qps、吞吐下,自建 ES 的请求响应即使在低压时也存在上下波动、不稳定的情况;
  • 22:30 写入压力到高峰时,自建 ES RT 上涨明显; Serverless ES 几乎不受影响;
  • 高压下自建集群出现请求失败情况,原因为写入线程池队列满集群拒绝新请求;




根据实际的业务请求,Serverless 应用能做到资源规划,贴合使用曲线

日志分析型集群主要体现在索引主分片数变化:

上图可见:

  1. 【point 1】在水位下降后会保持一段时间的高主分片数,原因是主分片数不影响资源消耗,预防突发流量,等一段时间后会降至这一段时间判断可降的最低值;
  2. 【point 2】在水位高于当前已有主分片数时,若在可控范围内,则会等一定时间后升高至这一段时间判断的所需值;
  3. 【point 3】若水位超出可控范围,则会加快分片数升高的速度;

预期主分片数:系统对当前写入水位做出的主分片建议数

当前主分片数:当前正在写入的索引主分片数


存储数据压缩率相比自建有显著提升,进一步节省了存储成本 80%以上

以上每日数据量总额达百亿级。可见,该数据集在 Serverless 日志分析型集群总存储空间占比约为自建 ES 集群的六分之一。



成本相比自建得到显著降低 70%以上

按照 Serverless 日志分析型应用的收费标准,每小时收费 CU 统计如下:

该场景测试未发起查询压力,Serverless 应用会默认按 5CU 查询进行最低查询资源计费

时段

serverless ES 日志分析型集群

(规格:自适应)

自建 ES 集群

(规格: 6 * 24C 48G)

ecs.c6.6xlarge 按需付费

读CU消耗

1.2087元/CU/时 

写CU消耗

0.4544元/CU/时

存储消耗

0.00021元/GB/时

小时价

单价*消耗数据之和

单 ECS 小时价:4.68 元/时

2T PL1 数据盘:4.3008 元/时

18:00-19:00

¥ 6.0435

¥ 7.2704

¥ 0.0067

¥13.3206

¥ 53.8848

19:00-20:00

¥ 6.0435

¥ 9.0880

¥ 0.0235

¥15.1550

¥ 53.8848

20:00-21:00

¥ 6.0435

¥ 10.2240

¥ 0.0428

¥16.3103

¥ 53.8848

21:00-22:00

¥ 6.0435

¥ 11.5872

¥ 0.0650

¥17.6957

¥ 53.8848

22:00-23:00

¥ 6.0435

¥ 12.7232

¥ 0.0900

¥18.8567

¥ 53.8848

23:00-24:00

¥ 6.0435

¥ 12.7232

¥ 0.1142

¥18.8809

¥ 53.8848

00:00-01:00

¥ 6.0435

¥ 8.6336

¥ 0.1327

¥14.8098

¥ 53.8848

01:00-02:00

¥ 6.0435

¥ 4.7712

¥ 0.1449

¥10.9596

¥ 53.8848

02:00-03:00

¥ 6.0435

¥ 3.4080

¥ 0.1535

¥9.6050

¥ 53.8848

03:00-04:00

¥ 6.0435

¥ 4.0896

¥ 0.1594

¥10.2925

¥ 53.8848

04:00-05:00

¥ 6.0435

¥ 2.7264

¥ 0.1649

¥8.9348

¥ 53.8848

05:00-06:00

¥ 6.0435

¥ 2.7264

¥ 0.1701

¥8.9400

¥ 53.8848

06:00-07:00

¥ 6.0435

¥ 3.1808

¥ 0.1758

¥9.4001

¥ 53.8848

07:00-08:00

¥ 6.0435

¥ 4.0896

¥ 0.1829

¥10.3160

¥ 53.8848

08:00-09:00

¥ 6.0435

¥ 5.4528

¥ 0.1924

¥11.6887

¥ 53.8848

09:00-10:00

¥ 6.0435

¥ 6.3616

¥ 0.2043

¥12.6094

¥ 53.8848

10:00-11:00

¥ 6.0435

¥ 6.8160

¥ 0.2175

¥13.0770

¥ 53.8848

11:00-12:00

¥ 6.0435

¥ 6.8160

¥ 0.2312

¥13.0907

¥ 53.8848

12:00-13:00

¥ 6.0435

¥ 10.2240

¥ 0.2483

¥16.5158

¥ 53.8848

13:00-14:00

¥ 6.0435

¥ 7.4976

¥ 0.2671

¥13.8082

¥ 53.8848

14:00-15:00

¥ 6.0435

¥ 5.6800

¥ 0.2800

¥12.0035

¥ 53.8848

15:00-16:00

¥ 6.0435

¥ 5.4528

¥ 0.2915

¥11.7878

¥ 53.8848

16:00-17:00

¥ 6.0435

¥ 5.6800

¥ 0.3031

¥12.0266

¥ 53.8848

17:00-18:00

¥ 6.0435

¥ 6.1344

¥ 0.3152

¥12.4931

¥ 53.8848

总计(元)

¥ 312.5778

¥ 1293.2352

等比大流量估算

以上为单日写入统计,日常场景会考虑长期数据存储如 3 天热数据 14 天冷数据存储等。结合此特点,Serverless成本仍有较大的压缩空间。而根据冷热存储大数据计费估算,ES Serverless 相对于 ES 自建节省约为 88.6 %

如何开通 Elasticsearch Serverless 服务

Step 1:开通服务

第一次使用 ES Serverless服务时需要开通服务。

  1. 登录 Elasticsearch Serverless 服务控制
  2. 在 ES Serverless 服务页面,单击立即开通


  1. 在服务开通页面,选中服务协议,单击立即开通,根据页面提示开通 ES Serverless服务。

Step 2:创建应用

  1. 进入创建 Serverless 应用的页面;

  1. 配置应用的基本信息;
  • 选择应用选型为检索通用型(参考),其他参数保持默认或自定义。
  1. 配置应用的访问设置;
  • 选择网络访问方式为公网访问(参考),在公网访问白名单中添加本地设备的 IP 地址,以便使用本地设备访问 Serverless 应用的 Kibana。

说明配置应用公网访问或私网访问,请参见配置 Serverless 应用公网或私网访问

  1. 输入用户密码,登录 Kibana 时需要。
  2. 单击立即创建。


您可以在应用管理页面查看已创建的应用列表。等待应用状态变为运行中,即创建应用成功,然后可根据个人需求,尝试体验更多功能。


相关实践学习
使用阿里云Elasticsearch体验信息检索加速
通过创建登录阿里云Elasticsearch集群,使用DataWorks将MySQL数据同步至Elasticsearch,体验多条件检索效果,简单展示数据同步和信息检索加速的过程和操作。
ElasticSearch 入门精讲
ElasticSearch是一个开源的、基于Lucene的、分布式、高扩展、高实时的搜索与数据分析引擎。根据DB-Engines的排名显示,Elasticsearch是最受欢迎的企业搜索引擎,其次是Apache Solr(也是基于Lucene)。 ElasticSearch的实现原理主要分为以下几个步骤: 用户将数据提交到Elastic Search 数据库中 通过分词控制器去将对应的语句分词,将其权重和分词结果一并存入数据 当用户搜索数据时候,再根据权重将结果排名、打分 将返回结果呈现给用户 Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索,具有接近实时的搜索,并支持多租户。
相关文章
|
2月前
|
存储 运维 监控
金融场景 PB 级大规模日志平台:中信银行信用卡中心从 Elasticsearch 到 Apache Doris 的先进实践
中信银行信用卡中心每日新增日志数据 140 亿条(80TB),全量归档日志量超 40PB,早期基于 Elasticsearch 构建的日志云平台,面临存储成本高、实时写入性能差、文本检索慢以及日志分析能力不足等问题。因此使用 Apache Doris 替换 Elasticsearch,实现资源投入降低 50%、查询速度提升 2~4 倍,同时显著提高了运维效率。
金融场景 PB 级大规模日志平台:中信银行信用卡中心从 Elasticsearch 到 Apache Doris 的先进实践
|
2月前
|
人工智能 自然语言处理 搜索推荐
云端问道12期实操教学-构建基于Elasticsearch的企业级AI搜索应用
本文介绍了构建基于Elasticsearch的企业级AI搜索应用,涵盖了从传统关键词匹配到对话式问答的搜索形态演变。阿里云的AI搜索产品依托自研和开源(如Elasticsearch)引擎,提供高性能检索服务,支持千亿级数据毫秒响应。文章重点描述了AI搜索的三个核心关键点:精准结果、语义理解、高性能引擎,并展示了架构升级和典型应用场景,包括智能问答、电商导购、多模态图书及商品搜索等。通过实验部分,详细演示了如何使用阿里云ES搭建AI语义搜索Demo,涵盖模型创建、Pipeline配置、数据写入与检索测试等步骤,同时介绍了相关的计费模式。
|
2月前
|
人工智能 算法 API
构建基于 Elasticsearch 的企业级 AI 搜索应用
本文介绍了基于Elasticsearch构建企业级AI搜索应用的方案,重点讲解了RAG(检索增强生成)架构的实现。通过阿里云上的Elasticsearch AI搜索平台,简化了知识库文档抽取、文本切片等复杂流程,并结合稠密和稀疏向量的混合搜索技术,提升了召回和排序的准确性。此外,还探讨了Elastic的向量数据库优化措施及推理API的应用,展示了如何在云端高效实现精准的搜索与推理服务。未来将拓展至多模态数据和知识图谱,进一步提升RAG效果。
|
4月前
|
存储 SQL 监控
|
4月前
|
自然语言处理 监控 数据可视化
|
4月前
|
运维 监控 安全
|
4月前
|
存储 监控 安全
|
4月前
|
存储 数据采集 监控
开源日志分析Elasticsearch
【10月更文挑战第22天】
85 5
|
1月前
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
38 5
图解MySQL【日志】——Redo Log
|
4月前
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
1339 31
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板

热门文章

最新文章

相关产品

  • 检索分析服务 Elasticsearch版