TL;DR:
- Locally runs Manticore Search on Google Cloud as a core part of its production infrastructure
- Tens of thousands of queries per second across geo search, ecommerce search, aggregations, and vector search
- Migrated from Elasticsearch after long-term challenges with complexity, cost, and indexing speed
- Observed ~16× lower costs compared to equivalent Elasticsearch services
- Leverages GCP Compute Engine, Managed Instance Groups, and HAProxy for horizontal scaling
- Remains stable through peak seasonal traffic with minimal operational overhead
- Recommended by Ben Hirsch, CTO & co-founder of Locally
背景
本文基于Locally公司CTO兼联合创始人Ben Hirsch的直接输入。文章描述了该公司目前在Google Cloud上运行Manticore Search的生产环境情况，重点介绍架构决策、GCP服务集成、运营经验以及可能对其他团队在GCP上部署Manticore有帮助的教训。
创始人视角：搜索作为核心基础设施
对于 Locally 而言，搜索是核心基础设施。该平台为全球数万家零售商提供基于位置的电商体验，并直接位于许多高流量品牌和零售商网站的关键路径上。流量模式高度动态且具有强烈季节性，这对性能、可靠性和成本控制提出了严格要求。
从CTO兼联合创始人Ben Hirsch的角度来看，搜索决策是长期的基础设施选择。这些决策不仅影响查询速度，还影响运营成本、工程生产力以及在不增加不必要的复杂性的情况下扩展的能力。
Locally自2013年早期就在Google Cloud上运行Elasticsearch。随着时间的推移，团队发现操作开销、成本和大规模索引性能使得平台的高效演进变得更加困难。这促使他们在2024年初开始探索替代方案，包括Manticore Search。
最初作为内部实验，随后进展为生产环境的概念验证，最终演变为更广泛的迁移，所有这些都在其现有的Google Cloud基础设施内完成。
高吞吐量、多功能的搜索平台
如今，Manticore Search已深度集成到Locally的生产系统中，并支持多种工作负载。
“Locally在生产环境中每秒处理数万个Manticore查询。”
—— Locally CTO兼联合创始人Ben Hirsch
Manticore Search并非仅服务于单一目的，而是作为通用搜索层。它支持以聚合为主的查询、基于地理位置的查找、电商搜索以及向量驱动的自动补全功能。
正如Hirsch所解释的：
“我们以四种不同方式使用它：
- 作为常见聚合的高可用性索引，这些聚合在运行时从主关系数据库中查询的成本过高或速度过慢。
- 作为地理位置和库存数据的地理空间索引，用于数千个高流量品牌和零售商网站的关键路径。
- 为全球5万多家零售商提供丰富筛选条件、基于位置的产品可用性界面的电商搜索引擎。
- 使用向量嵌入为我们的广大客户和购物者用户群提供领域特定的、具备自然语言能力的自动补全体验。”
这种整合减少了对多个专用系统的依赖，并简化了搜索相关功能的构建和维护方式。在Google Cloud上运行Manticore使团队能够保持搜索基础设施与现有操作工具和云环境的一致性。
Locally为何远离Elasticsearch
Locally决定迁离Elasticsearch的决策基于十多年来的生产经验。虽然Elasticsearch满足了早期需求，但随着规模扩大，其高效运营变得越来越困难。
"然而，我们的工程师始终认为它难以接近，因此我们从未能在其上获得足够的开发势头。此外，Elasticsearch的托管和维护极其复杂且昂贵，而我们在该规模下的数据索引速度又太慢。"
当团队在2024年初开始评估Manticore Search时，索引性能立即脱颖而出，而查询性能则保持相当。
"我们在2024年初开始尝试Manticore，并立即意识到它的速度有多快——在运行时与Elasticsearch相当，但索引速度要快得多。"
在部署概念验证后，成本影响变得明显。
"随后我们部署了一个概念验证到生产环境，并注意到与等效Elasticsearch服务相比，成本降低了16倍。"
在这一点上，Locally决定将其剩余的Elasticsearch工作负载迁移到Manticore Search。
在Google Cloud上的部署
Locally的所有生产基础设施均运行在Google Cloud Platform上，这使其成为部署Manticore Search的自然环境。这使团队能够利用现有的云基础设施、监控工具和操作实践。
团队最初评估了在Google Kubernetes Engine（GKE）上运行Manticore。由于索引规模较大以及工作负载的性质，这种方法被证明是不切实际的。
"我们最初尝试将Manticore部署到GKE，但最终由于某些索引的规模过大而放弃了这一方法。"
Locally随后采用了基于Compute Engine的部署模型，围绕虚拟机、托管实例组和外部负载均衡构建。这种方法被证明更适合其大规模、有状态的搜索工作负载。
"现在我们使用Compute实例和多个具有自动扩展功能的实例组，以及HA Proxy节点来分配索引和读取负载。"
早期的部署包含一些操作挑战，但随着团队完善其部署和扩展策略，系统逐渐稳定。
“我们现在已经顺利度过了两个假期季节，几乎没有任何问题和停机时间。”
架构概览
在生产环境中，Locally的Manticore设置包括：
- 多个具有特定用途的 Manticore 集群，而不是单一的单体集群
- 使用 Google Cloud 管理实例组实现自动扩展和节点替换
- 在 Compute Engine 上运行的 HAProxy 节点，用于分配索引和查询负载
- 利用自动扩展功能结合 Manticore 的内置复制功能实现水平扩展，以提高冗余性
- 与监控系统集成的自定义 Grafana 仪表板，用于跟踪性能和系统健康状况
随着团队根据实际流量模式和数据增长调整架构，这种结构随着时间的推移不断发展，并充分利用了 Google Cloud 的基础设施自动化功能。
性能、稳定性与扩展性
从查询性能的角度来看，Manticore 在负载下始终保持一致的快速表现。
“查询性能一直非常出色且稳定。”
就稳定性而言，主要的学习曲线是理解系统在真实流量模式下的行为方式。
“就稳定性而言，我们花了一些时间来适应 Manticore 如何消耗资源。”
随着数据量和流量的增加，早期的架构决策被重新审视。最初，所有索引都位于一个集群中，但随着平台的增长，这证明是限制性的。单体方法导致新节点加入集群需要很长时间，并为许多生产服务创建了单点故障。
“然而，随着时间的推移，我们将单体拆分为多个具有特定用途的小型集群（使用 GCP 的实例组）。这使我们能够轻松应对数据和流量的增长。”
结合水平扩展功能和 Manticore 的内置复制功能，这种方法产生了一个更高效且具有弹性的系统，能够适应不断变化的工作负载。
日常运营
如今，运营 Manticore Search 大部分是自动化的。扩展、节点替换和负载分配通过托管的基础设施服务和内部工具处理，减少了对持续手动干预的需求。
正如 Hirsch 总结的那样：
“现在使用 Manticore 的日常运营非常省心且完全自动化。这要归功于 GCP 的管理实例组自动扩展、HAProxy 负载均衡器（我们开发了一个内部动态配置工具来监控 MIG 的变化），以及用于监控所有相关服务健康指标的自定义 Grafana 仪表板。”
这种基于 Google Cloud 自动化功能的运营模式，使团队能够更专注于产品开发，而不是维护搜索基础设施。与监控、日志和扩展服务的集成创造了一个连贯的运营体验。
结论：一项深思熟虑的基础设施选择
对于 Locally 来说，采用 Google Cloud 上的 Manticore Search 并不是为了追逐新技术。而是选择了一种与实际生产需求相匹配的基础设施：高流量、季节性波动、成本敏感性以及对运营清晰度的渴望——这一切都在其现有的云生态系统内。
从 Elasticsearch 迁移到 Manticore Search 带来了可衡量的结果：成本降低 16 倍，索引速度更快，查询性能相当。但更重要的是，它简化了运营，并为工程团队提供了一个他们可以自信开发和扩展的系统，同时利用 Google Cloud 的强大基础设施服务。
从 Ben Hirsch 作为 CTO 和联合创始人的角度来看，最重要的成果是系统在真实条件下的行为方式带来的信心。在超过十年的 Elasticsearch 生产运营之后，团队现在拥有了一个既强大又易于上手的搜索基础设施。
如今，Manticore Search 支持 Locally 平台上的多个关键工作负载，并继续在高峰期季节性需求下可靠运行。架构已从单一的单体集群演变为具有特定用途的小型集群，这表明 Manticore Search 与 Google Cloud 的结合可以根据需求增长进行调整。
“我绝对会向其他团队推荐这种设置，特别是如果他们希望从 Elasticsearch 迁移到一个更快、更容易扩展、且入门门槛低的系统。”
—— Ben Hirsch，CTO & 联合创始人，Locally
Locally 的经验展示了对基础设施的一种务实方法：仔细评估，随着系统增长调整架构，并投资于一旦部署就可靠运行的工具。他们的经验表明，当性能、成本和运营清晰度至关重要时，一个务实的搜索堆栈可以演变为长期的基础设施。