Infor 的 Amazon OpenSearch 服务现代化：搜索速度提升 94，成本降低 50

撰文者：Allan Pienaar Arjan Hammink 和 Gokul Sarangaraju，发表于 2024 年 10 月 22 日在 Amazon OpenSearch 服务、客户解决方案 和 技术如何操作永久链接 评论

关键要点

Infor 利用 Amazon OpenSearch 服务进行现代化改造，通过以下方式获得显著成果：

在此文中，我们将探讨 Infor 如何成功转型其搜索能力，以及实现这一转型的关键技术和优势。

Infor 的企业业务云软件中，强大的存储和搜索能力至关重要。Infor 的 智能开放网络 (ION) OneView 平台为客户提供实时报告、仪表板和数据可视化，帮助他们访问和分析组织内的信息。为了增强 ION OneView 的搜索功能，Infor 使用了 Amazon OpenSearch 服务，以改善其软件产品并为客户提供更好的服务，从而实现实时可见性。通过现代化改进 OpenSearch 服务的使用，Infor 实现了客户搜索性能提升 94 和存储成本降低 50的双重成果。

Infor 的起点

Infor 的 ION OneView 是基于 Elasticsearch v5x 在 Amazon OpenSearch 服务上构建的，托管在八个 AWS 区域中。这种架构使用户能够从统一视图中跟踪业务文档，使用多种条件进行搜索，并依据用户角色查看内容。随着时间的推移，Infor 的功能扩展至“丰富”和“存档”功能，增加了复杂性。丰富过程通过聚合相关事件来构建可搜索消息，要求不断更新 OpenSearch 索引中的文档。随后，存档过程将这些消息和事件移动到 Amazon 简单存储服务 (Amazon S3)，同时使用 deletebyquery 删除 OpenSearch 服务中的相应文档。这些读更新写删除的工作负载，加上超出 100GB 的大规模索引，导致了 高删除文档量 和迅速的数据增长，系统难以跟上需求。为了应对日益增长的性能需求，Infor 不断横向扩展其 OpenSearch 服务域。

面临的挑战

Infor 面临的主要挑战凸显了更可扩展、弹性和高性价比搜索能力的迫切需求，并能够无缝集成到他们的云环境中。这些挑战包括由于高数据处理速率导致的无效存档，升级和恢复时间延长。增加的成本以及为启用新功能而需的自定义开发，给运营带来了巨大负担。此外，Infor 的搜索延迟不断增加，CPU 利用率达到 75，并偶尔超过 90如下面图示所示，显示了现有基础设施的性能限制。这些问题共同推动了 Infor 对现代化搜索解决方案的需求。

现代化前的搜索延迟

现代化前的 CPU 利用率

Infor 的搜索现代化之旅

为了应对 ION OneView 的挑战，Infor 与 AWS 合作，进行全面的现代化改造。这包括优化运营流程、存储配置和实例选择，同时还升级到 OpenSearch 服务的后续版本。

运营审查与改进

Inpr与AWS 紧密合作，完成了 Infor 的 OpenSearch 服务集群的全面运营审查。通过分析 慢日志 和调整 日志阈值，能够识别出耗费 CPU 资源最多的长时间运行查询和存档过程。Infor 重新编写了使用高基数字段的长查询，从而减少了平均查询时间。

接下来，团队着手重新设计 Infor 的存档过程，以减轻 CPU 的负担。我们不再使用单一大型索引，而是根据客户许可证类型实现独立索引。这样可以通过使用索引别名对旧索引进行分割，改善删除性能。我们还将 deletebyquery 方法替换为直接传递文档 ID 的标准删除方法，因为所有要存档的文档 ID 在事前都是已知的。这减少了往返时间和相较于 deletebyquery 进行的顺序搜索请求所带来的 CPU 压力。接着根据工作负载要求优化了 刷新间隔，从而改善了索引性能、内存及 CPU 的利用率。

存储优化

团队从 GP2 存储 切换到 GP3 存储，仅在需要时储备额外的输入/输出每秒 (IOPS) 和吞吐量。这导致大多数 Infor 工作负载的存储成本下降了 9。在所有 IOPS 成为瓶颈的用例中，团队能够使用 GP3 独立于卷大小提供更多 IOPS 和吞吐量，进一步降低了 Infor 的存储费用。此外，我们实施了基于 shard 大小的轮换策略，根据节点数量对总 shards 进行分割，从而将 shard 的大小减少到 建议不到 50 GiB。这样可以确保每个索引的数据和工作负载在节点之间均匀分配，性能改善后发现增加 vCPU 会有助于解决线程池队列和延迟问题。基于新的存储需求选择合适的主节点和数据节点实例类型。为了支持重索引过程，团队还暂时扩展了存储和计算资源。

OpenSearch 服务升级

在根据最佳实践优化存储和计算配置后，Infor ION 团队将注意力转到利用 OpenSearch 的最新功能 上。由于 shard 现已调整到合适边界，内存和 CPU 的利用率达到合理水平，团队能够顺利从 Elasticsearch 版本 5x 升级到 6x，再升级至 OpenSearch 服务的 7x 版本。每一次主要版本升级都需要经过仔细测试，并根据需要更改客户端代码，以确保使用兼容的客户端库。团队在每次升级后花费必要时间全面验证系统，为 Infor 的客户提供平滑的过渡。这种对系统化升级流程的承诺使得 Infor 能够利用 OpenSearch 服务的新特性，例如 Graviton 支持、性能改进、bug 修复和安全性提升，同时将对用户的干扰降到最低。

选择实例以优化性能

在与 AWS 团队的合作下，Infor 仔细评估了用于 ION OneView 搜索集群的本地非易失性内存高速缓存 (NVMe) 实例类型，比较了 i3 和 R6gd 实例 以平衡内存、延迟和存储要求。对写密集型工作负载而言，团队发现使用 NVMe 存储能够提供比 Amazon 弹性块存储 (Amazon EBS) 卷 更好的性能和价格，原因在于工作负载对高 IOPS 的要求，使得他们不再过度依赖外部堆内存使用。通过选择最合适的实例类型，ION OneView 搜索集群得以减少 63 的数据节点数量，同时仍实现了更高的吞吐量和较低的延迟。始终使用最新的 AWS 实例系列也是主要考虑因素，团队在建立了良好的性能和计算消耗基准后，通过 购买保留实例 进一步优化了成本，折扣在 30 到 50 之间，具体取决于承诺期限。

成果

以下图表示了现代化后的改进效果。

新索引的正 碗大面积 shur，而对应的 shard 数量则随之增加。

更新的 shard 策略与版本升级相结合，导致流量增幅十倍和高效存档。

以下图示显示了 SearchRate 的提升。

接下来这张图展示了 CPU 的增长与流量增长相比几乎不明显。

最后这张图清楚地显示了在采用新索引和 shard 策略后执行的 SearchLatency 降低情况。

下面的图展示了过去四个季度中两款 Infor ION 产品的月支出情况。

结论

通过对 OpenSearch 服务基础设施的精心现代化改造，Infor 实现了基础设施成本降低 50 的同时，集群性能提升 94。优化过的集群现在更加健康和弹性，促进了更快的蓝绿部署，以处理更大数据量。

这次成功的转型是 Infor 与 AWS 团队紧密合作的成果，利用深厚的技术专业知识和最佳实践来加速优化过程，释放 OpenSearch 服务的全部潜力。Infor 的 OpenSearch 服务现代化使得公司能够以显著较低的成本为客户提供更高效能的搜索体验，为其 ION OneView 平台的持续增长和成功奠定了基础。

每个工作负载都是独特的，具有其自身特定的特性。虽然 Amazon OpenSearch 服务开发者指南 中概述的最佳实践非常有价值，但最重要的步骤是部署、测试并持续微调自己的域，以找到最适合您特定需求的最佳配置、稳定性和成本。

作者介绍

Allan Pienaar 是 AWS 的 OpenSearch SME 和客户成功工程师。他与企业客户紧密合作，以确保运营卓越、保持生产稳定并使用 Amazon OpenSearch 服务优化成本。

Gokul Sarangaraju 是 AWS 的高级解决方案架构师。他帮助客户采用 AWS 服务，并在 AWS 成本和使用优化方面提供指导。他的专业领域包括使用 AWS 服务和工具构建可扩展和高性价比的数据分析解决方案。

Arjan Hammink 是 Infor 软件开发的高级总监，在软件开发和团队管理方面拥有超过 25 年的经验。他目前负责 Infor ION，这是自 2010 年作为软件工程师参与以来一直扮演重要角色的项目。Infor ION 是一款强大的中间件，旨在简化软件集成，是 Infor OSInfor 的云技术平台的关键组成部分。

标签：Amazon OpenSearch、优化