尼克·普莱斯翻译
我目前正在研究一个大型日志记录项目，该项目最初是使用AWS Elasticsearch实施的。 与Elasticsearch大型骨干集群合作了几年，我对AWS实施的质量完全不知所措，无法理解为什么他们没有解决或至少改进它。
总结
Elasticsearch将数据存储在您显式创建的各种索引中，也可以在发送数据后自动创建这些索引。 每个索引中的条目分为一定数量的分片，然后在群集中的节点之间进行平衡（如果分片的数量没有平均地除以节点数，则应尽可能均匀）。 ElasticSearch中有两种主要的分片类型：基本分片和副本分片。 副本分片在节点发生故障时提供容错能力，用户可以为每个索引分别指定副本分片的数量。
标准Elasticsearch的工作
Elasticsearch-有弹性。 有时可能很挑剔，但是通常，您可以将节点添加到群集中或删除它们。 而且，如果在删除节点的情况下有足够数量的副本，Elasticsearch将分配碎片，甚至平衡集群中节点上的负载。 这通常有效。
完成昂贵的查询有时会导致节点等崩溃，但是大量设置有助于维护工作。 如果有足够数量的副本分片，则如果该节点掉落，则不会影响整个工作。
Standard Elasticsearch还提供了许多附加组件，包括X-Pack，审计功能，精细的ACL，监视和警报。 大多数X-Pack最近都免费提供，可能是为了响应新的Splunk许可政策。
Amazon Elasticsearch工作
像往常一样，亚马逊将Elasticsearch的一部分的开源代码进行了硬分叉，并开始将其作为自己的服务进行销售，并逐渐引入了自己的功能版本，这些功能多年来在Elasticsearch的主版本中一直可用。
亚马逊产品缺少很多东西，例如：RBAC和审计，这对我们来说尤其成问题，因为我们接受来自不同团队的日志，并希望将它们彼此分开。 目前，任何有权访问Elasticsearch的用户都具有所有访问权限，并且可以通过添加错误的索引模板来意外删除其他人的数据，更改其在节点上的复制方式并完全停止接收数据。
这令人沮丧，但这不是服务的最大问题。 重新平衡碎片-Elasticsearch的核心概念-在AWS实施中不起作用，这几乎抵消了Elasticsearch中的所有优点。
通常，将数据添加到节点时，一个节点可以比其他节点填满更多数据。 这是可以预期的，因为不能保证装入的记录大小相同，或者分片的数量始终始终均匀地分布在群集的所有节点上。 这不是至关重要的，因为Elasticsearch可以重新平衡节点之间的分片，并且如果一个节点确实已满，则其他节点将很乐意开始接收数据而不是填充数据。
Amazon不支持此功能。 一些节点可能比其他节点快得多。
此外，
在Amazon中，如果Elasticsearch集群中的一个节点没有足够的可用空间，则整个集群将停止接收数据 ，它将完全停止。 亚马逊的解决方案是让用户度过一个噩梦：定期更改索引模板中的分片数量，然后将先前创建的数据重新索引为新索引，删除先前的索引，并在必要时将数据反向索引为先前的结构。 这是完全多余的，并且除了需要大量的计算成本外，还需要将下载数据的未处理副本与分析记录一起保存，因为重新索引将需要未处理副本。 当然，这使AWS上“正常”工作所需的内存量增加了一倍。
“糟糕！ 我没有足够频繁地重新索引整个群集，并且节点已满！ 该怎么办？”
您有两个选择。 首先，删除所需数量的数据以使群集恢复正常运行，然后开始重新编制索引，以希望一切都不会崩溃。 您是否有要删除的内容的备份？
第二个选项是将更多节点添加到群集中，或将现有节点的大小调整为更大的实例大小。
但是，等等，如果无法重新平衡碎片，如何添加节点或进行更改？
亚马逊的解决方案是蓝绿色的部署。 他们启动了一个全新的集群，将先前集群的全部内容复制到一个新集群中，然后切换并销毁旧集群。
您可以想象，对于大型集群而言，这种调整大小的任务可能需要几天的时间，因此复制数万亿条记录可能需要一些时间。 这还会在现有群集上造成疯狂的负载（可能已经超出容量），并且实际上可能导致群集出现故障。 我在AWS的30多个集群上执行了几项类似的操作，仅一次观察到自动模式下的成功完成。
因此，您尝试调整群集的大小，但任务未完成。 现在呢
亚马逊互动
调整群集大小的任务已中断（因为您可能选择不处理此类文章的服务），因此您以最高优先级打开了获得AWS技术支持的门票。 当然，他们会抱怨您分片的数量或大小，并会添加指向您已经阅读500次的“最佳实践”的链接。 然后等待它修复。 等一下 等一下 我上次尝试调整群集大小时，由于群集被阻塞而导致严重的故障，因此花了七天的时间才将所有内容恢复为联机状态。 他们在几天之内恢复了群集本身，但是当一切停止时，很明显，运行Kibana的节点已经与主群集失去联系。 AWS支持人员又花了四天时间尝试修复某些问题，同时想知道Kibana是否正在工作。 他们甚至不知道他们是否已解决问题，我不得不检查他们是否已恢复自己系统之间的通信。 从那时起，我已停止执行任何其他操作，除非节点已满，否则删除数据。
我们组织在AWS上的成本巨大。 这使我们有机会定期与各个领域的专家会面，讨论实施策略并处理各种技术问题。 我们与Elasticsearch的代表进行了约谈，在会议期间，我大部分时间都在解释Elasticsearch的基本知识并描述其产品的怪癖。 专家完全震惊，当节点已满时，一切都会崩溃。 如果派遣的专家不了解其产品的基本知识，支持团队需要7天才能恢复生产集群也就不足为奇了。
最后的想法
在我接触过的测井项目中，我们目前正在处理一些架构错误和较弱的设计决策。 当然，我希望AWS Elasticsearch与原始产品有所不同。 但是，在AWS Elasticsearch中，许多基本功能被禁用或缺失，这加剧了我们遇到的几乎所有问题。
对于易于使用的小型集群，AWS Elasticsearch可以很好地工作，但是对于PB级的集群，这是一场无尽的噩梦。
我很好奇为什么Amazon的Elasticsearch实现无法平衡分片；为什么？ 这是相当基本的Elasticsearch功能。 即使与主要的Elasticsearch相比有局限性，但只要工作正常，它对于大型集群当然还是可以接受的。 我不明白为什么亚马逊会提供如此破烂的东西，以及为什么他们两年多来都没有纠正这种情况。
正如其他人所建议的那样，并且这似乎是合理的，这种行为是AWS实施的标志，该实施被设计为巨型多租户集群，试图提供隔离以使其看起来像最终用户的独立集群。 即使使用诸如静态加密数据和加密数据传输之类的选项，这似乎也是合理的。 也许它们的工具和配置只是更早的体系结构的遗产。
而且，正如我的朋友所说，当您无法在不增加新节点和传输所有数据的情况下从群集中添加或删除节点时，他们仍然称其为“灵活”非常有趣。
脚注：写这篇文章时，两年前我发现了一篇帖子，上面有很多类似的说法：
read.acloud.guru/things-you-should-know-before-using-awss-elasticsearch-service-7cd70c9afb4f