客户在 Amazon OpenSearch 进程管道中的旅程 大数据博客
客户与 Amazon OpenSearch 数据处理管道的历程
by Navnit Shukla 和 Mike Mosher 于 2024 年 10 月 18 日 发表在 Amazon OpenSearch 服务， 分析， 客户解决方案永久链接评论 分享
本文由 Mike Mosher 和我共同撰写，Mike 是一家跨国金融信用报告公司的高级首席云平台网络架构师。
我们是一家跨国金融信用报告公司，提供信用风险、欺诈、精准营销和自动决策解决方案。作为 AWS 的早期用户，我们利用云端推动数字化转型。我们的云卓越中心CCoE团队运营着全球 AWS 登陆区，包含一个集中化的 AWS 网络基础设施。我们也是 AWS PrivateLink 准备合作伙伴，并提供我们的 EConnect 解决方案，让我们的 B2B 客户通过私密、安全和高效的连接方式与多个产品连接。
我们的 EConnect 解决方案是由多个 AWS 服务组成的平台，如 应用负载均衡器ALB、网络负载均衡器NLB、网关负载均衡器GWLB、AWS Transit Gateway、AWS PrivateLink、AWS WAF及第三方安全设备。所有这些服务和资源，加上平台上的大量网络流量，产生了大量的日志，我们需要一种解决方案来聚合和整理这些日志，以便我们的运营团队在故障排除时能够快速分析。
我们最初的设计使用了 Amazon OpenSearch 服务，选择它是因为它可以在几秒钟内从大量数据集中返回特定的日志条目。我们还结合使用了 Logstash，允许我们使用多个过滤器来丰富和增强数据，然后发送到 OpenSearch 集群，从而促进更全面和有洞察力的监控体验。
在这篇文章中，我们分享了我们的历程，包括我们面临的挑战、考虑的解决方案，以及我们为何选择 Amazon OpenSearch 数据处理管道，以使我们的日志管理更加顺畅。
关键内容
重点信息
我们在日志管理过程中遇到了一系列挑战，最终选择使用 Amazon OpenSearch 数据处理管道进行优化。最初的解决方案虽然灵活，却因为维护工作繁重、性能不佳而影响了我们的监控能力。通过与 AWS 团队的合作，我们优化了架构，极大地提升了性能和成本效益。初始解决方案概述
我们最初希望在 OpenSearch 集群中存储和分析日志，决定使用 AWS 管理的 OpenSearch 服务 Amazon OpenSearch 服务。我们还想用 Logstash 增强这些日志，但由于没有 AWS 管理服务，我们必须在 Amazon 弹性计算云Amazon EC2服务器上部署该应用。这种设置意味着我们必须对服务器进行大量维护，包括使用 AWS CodePipeline 和 AWS CodeDeploy 将新的 Logstash 配置推送到服务器并重启服务。我们还需要执行服务器维护任务，例如修补和更新操作系统OS和 Logstash 应用，以及监控服务器资源，如 Java 堆、CPU、内存和存储。
复杂性还包括验证 Logstash 服务器与 OpenSearch 集群之间的网络路径，包括对访问控制列表ACL和安全组的检查，以及 VPC 子网中的路由。超出单个 EC2 服务器的扩展引入了管理自动扩展组、Amazon 简单队列服务Amazon SQS队列等新考虑。保持我们解决方案的持续功能需耗费大量精力，使我们无法专注于平台的核心操作和监控。
飞跃加速器安卓下载下面的图示展示了我们最初的架构。
可能的解决方案
我们的团队考虑了多种管理该平台日志的选项。我们拥有一个用于存储和分析日志的 Splunk 解决方案，因此将其视为 OpenSearch 服务的潜在竞争对手。然而，由于以下几个原因，我们最终放弃了这一选择：
我们的团队对 OpenSearch 服务和 Logstash 更为熟悉，而非 Splunk。Amazon OpenSearch 服务作为 AWS 的管理服务，使日志传输过程相比于我们本地的 Splunk 解决方案更加顺利。而且，将日志传输到本地 Splunk 集群也会产生高昂的成本，消耗 AWS Direct Connect 连接的带宽，并增加不必要的复杂性。Splunk 基于存储 GB 的定价结构，对于我们计划存储和分析的日志量成本过高。初步设计 OpenSearch 数据处理管道解决方案
Amazon 团队联系我，介绍他们正在推出的新功能：Amazon OpenSearch 数据处理。这一功能为我们面临的 Logstash EC2 实例管理问题提供了一个良好的解决方案。首先，新功能移除了团队管理多个 EC2 实例的繁重工作，自动根据流量缩放服务器，并监控日志的引入及基础服务器的资源。其次，Amazon OpenSearch 数据处理管道支持我们当前解决方案中使用的大多数 Logstash 过滤器，这使我们得以保持当前方案的日志增强功能。
我们很高兴能够成为 AWS 测试计划的一部分，并跃升为其最早和最大规模的采纳者之一。我们的历程始于为我们的 Internet 入口平台引入 VPC 流日志，以及通过 Transit Gateway 流日志连接 AWS 区域中的所有 VPC。处理如此大量的日志是一项重大任务，单凭 Transit Gateway 流日志每天即可达到14 TB。随着我们扩展至 ALB 和 NLB 访问日志及 AWS WAF 日志等其他日志，解决方案的规模也带来了更高的成本。
然而，我们的热情在初期遇到了一些挑战。尽管我们尽了最大努力，却仍遭遇了域的性能问题。通过与 AWS 团队的合作，我们发现了我们设置中的一些错误配置。我们原本使用的实例对于我们处理的数据量而言规模不足，致使这些实例始终处于最大 CPU 容量，导致新来的日志积压。这一瓶颈进一步导致我们的 OpenSearch 数据处理管道不必要地进行扩展，即便 OpenSearch 集群也难以跟上。
这些挑战导致我们的集群性能不佳。我们发现无法及时分析流日志或访问日志，有时在日志创建后等了好几天。此外，与这些低效相关的成本远远超出了我们最初的预期。
然而，在 AWS 团队的协助下，我们成功解决了这些问题，优化了我们的设置以提升性能和成本效率。这一经历强调了适当配置和合作在最大化 AWS 服务潜力中的重要性，最终为我们的数据处理流程带来了更积极的成果。
优化后的 OpenSearch 数据处理管道解决方案设计
我们与 AWS 合作提升整体解决方案，构建一个高性能、成本效益高且符合我们监控需求的解决方案。该解决方案涉及在 OpenSearch 服务域中选择性引入特定日志字段，使用 Amazon S3 Select 数据处理管道作为管道源；备选的选择性引入还可以通过 管道内部过滤 实现。可以在你的接收器中使用 includekeys 和 excludekeys 来过滤被路由到目标的数据。我们还利用了内置的 索引状态管理 功能，去除预定义周期之前的日志，从而降低集群的整体成本。
在 OpenSearch 服务中引入的日志使我们能够获取汇总数据，提供对于整个平台趋势与问题的洞察。为了对这些日志进行更详细的分析，包括所有原始日志字段，我们使用 Amazon Athena 表格进行分区查询，以快速且经济高效地查询存储为 Parquet 格式的 Amazon 简单存储服务Amazon S3中的日志。
这一全面的解决方案显著提升了我们平台的可见性，降低了处理大容量日志的整体监控成本，加快了我们在故障排查平台事故时识别根本原因的速度。
下面的图示展示了我们的优化架构。
性能比较
下表比较了初始设计在 Amazon EC2 上使用 Logstash、原始 OpenSearch 数据处理管道解决方案和优化后的 OpenSearch 数据处理管道解决方案之间的性能。
指标初始设计Logstash 在 Amazon EC2 上原始数据处理管道解决方案优化后的数据处理管道解决方案维护工作高 该解决方案需要团队管理多个服务和实例，从而分散了团队对于平台管理和监控的注意力。低 OpenSearch 数据处理管理大多数不差异化的重负担，团队只需维护数据处理管道配置文件。低 OpenSearch 数据处理管理大多数不差异化的重负担，团队只需维护数据处理管道配置文件。性能高 EC2 上的 Logstash 实例可根据需要在自动扩展组中缩放。低 由于 OpenSearch 集群资源不足，数据处理管道始终处于最大 OpenSearch 计算单元OCUs，导致日志传递延迟了多天。高 数据处理管道可根据需要在 OCUs 中缩放。实时日志可用性中 为了从 Amazon S3 拉取、处理和传递大量日志，我们需要大量EC2实例。为了节省成本，我们运行较少的实例，导致日志传递到 OpenSearch 较慢。低 由于 OpenSearch 集群资源不足，数据处理管道始终处于最大 OCUs，导致日志传递延迟了多天。高 优化后的解决方案能够在近实时内将大量日志传递到 OpenSearch 进行分析。成本节省中 为了将日志发送到 OpenSearch 所运行多个服务和实例，增加了整体解决方案的成本。低 由于 OpenSearch 集群资源不足，数据处理管道始终处于最大 OCUs，增加了服务的费用。高 优化后的解决方案能够按需缩放数据处理管道的 OCUs，从而保持整体成本低廉。整体效益中低高结论
在这篇文章中，我们回顾了使用 OpenSearch 服务和 OpenSearch 数据处理管道构建解决方案的旅程。该解决方案使我们能够专注于分析日志和支持我们的平台，而无需再关注基础设施支持将日志传递到 OpenSearch。我们还强调了优化服务以提高性能和降低成本的必要性。
作为后续步骤，我们计划探索最近宣布的 Amazon OpenSearch 服务与 Amazon S3 的零 ETL 集成预览 功能。这一步旨在进一步降低解决方案的成本，并在引入日志的时间和数量上提供灵活性。
关于作者
Navnit Shukla 是一名专注于分析的 AWS 专家解决方案架构师。他热衷于帮助客户从数据中发现有价值的洞察。通过他的专业知识，他构建创新解决方案，帮助企业做出基于数据的明智决策。值得一提的是，Navnit Shukla 是《AWS 上的数据处理》一书的杰出作者。他可以通过 LinkedIn 联系到。
Mike Mosher 是跨国金融信用报告公司的高级首席云平台网络架构师。他拥有超过 16 年的本地和云网络经验，并热衷于在云中构建满足客户需求并能解决问题的新架构。在工作之外，他喜欢与家人共度时光，并回到科罗拉多州的山中旅行。