使用Amazon Graviton优化性能和成本

使用Amazon Graviton优化性能和成本

关键字: [Amazon Web Services re:Invent 2024， 亚马逊云科技， Honeycomb， Amazon Graviton Migration， Performance Optimization， Cost Savings， Observability Engineering， Serverless Architecture]

导读

了解Honeycomb如何将其工作负载迁移到亚马逊云科技 Graviton上运行，并从Graviton系列实例的代际改进中受益。本次会话主要关注使用Amazon EC2实例的Amazon EKS编排，同时还涵盖了Amazon Lambda、Amazon RDS和Amazon OpenSearch Service。会议将讨论如何重塑开发者工作流程，提高性价比，以及如何开始您自己的Graviton之旅或在整个企业中扩大其应用。

演讲精华

以下是小编为您整理的本次演讲的精华。

大家好!如果你们是来学习Graviton的，那你们就来对地方了。今天我想与大家分享一个故事，讲述Honeycomb是如何在所有数据100%迁移到Graviton的过程中进行大规模迁移的。这不仅仅适用于Graviton，对于任何类型的迁移都是如此。尽管我们认为Graviton非常出色。

想象一下，半夜时分你正在香甜地睡觉，突然被这样的情况惊醒，你会有什么感受?你会感到自信吗?会感到害怕吗?还是会感到完全不知所措?Honeycomb公司能够让软件开发人员更好地了解他们系统内部的运行情况，利用大数据分析。他们坚信，这不仅仅是存储数据那么简单，还要尽快为你提供洞见。当他们希望尽快获得洞见时，他们愿意花费相当大的代价，以确保那些信赖Honeycomb的开发人员能够尽快获得洞见并重新入睡。

在这种精神驱使下，Honeycomb坚信要保持99.5%的服务水平目标，即进入Honeycomb的查询在10秒内返回结果。因此，性能对他们来说一直非常重要。他们还认为，应该可以轻松添加数据，即使系统正在扩展，即使你正在添加越来越多你关心的重要事物，可能是构建ID，也可能是语言包，或者是某人使用的网络浏览器，你都应该能够理解这些，而无需提前进行预聚合，无需考虑“我是否需要为此定制指标，还是可以直接将所有内容一起存储在单一数据存储中?”

通过为人们提供这种洞见，Honeycomb能够非常迅速地帮助人们解决生产问题，从而减少修复故障的时间。这就是他们采用亚马逊云科技 Graviton的更广阔背景。他们的客户发现，Honeycomb能够以他们可以承受的价格提供真正快速的洞见，这是他们非常重视的。在引擎盖下，Honeycomb是一家纯亚马逊云科技商店，他们从亚马逊云科技以及人们的应用程序中获取信号，并使用自定义列式数据存储格式进行存储。

就亚马逊云科技服务而言，这实际上是什么样子的呢?你可能会认为Honeycomb已经扩大了20倍，当然他们在过去5年中的成本也增加了20倍，但事实并非如此，因为他们受益于亚马逊云科技 Graviton。5年前，Honeycomb每秒处理约30万个跟踪范围，而现在他们在高峰时每秒处理约550万个跟踪范围。5年前，每周他们为Honeycomb用户运行10万个查询，而今天每周运行的查询约有200万个。这就是Honeycomb如何在不崩溃的情况下扩展服务，并在此过程中使其变得更加高效的故事。

Liz Fong-Jones是Honeycomb的现场首席技术官，也是亚马逊云科技社区英雄，负责Graviton重点领域。这不仅仅是性能和成本问题，还涉及到他们团队的带宽。他们必须仔细考虑团队是否有足够的带宽来参与这个项目?他们是否愿意长期支持这个项目?当时，ARM是否会成为市场领导者还不是100%确定的，所以他们想知道是否会随着时间的推移最终统一架构，还是永远保持多架构。他们希望确保软件开发人员有一个可预测的体验，即如果代码运行并通过测试，那么它就会在生产环境中成功运行。

因此，他们必须仔细考虑最终统一一种架构而不是长期维护两种可能会分歧或偏离的独立架构的标准。一旦他们做出了初步判断并设定了实验参数，他们就必须考虑如何具体将软件移植到Graviton上运行。这项任务落在了作为该项目倡导者的Liz身上。他们需要做的是，从根本上生成一个为ARM架构构建的构建工件。这需要你有一个合适的基础来运行。无论你是使用Docker镜像，还是使用EKS，你都必须确保拥有正确的AMI。你必须确保拥有你的软件运行所需的一切，所有底层组件都与ARM兼容。

他们必须检查应用程序代码，确保它能够在新架构上成功构建，然后他们必须调整CI工具。他们必须更改CI工具，以生成不同的构建工件，因为在大多数情况下，你不能直接将运行在x86上的构建工件运行在ARM上。如果你试图将错误架构的Docker镜像传递给kubelet，它将无法启动，会抛出架构异常。

所以他们不得不做这项工作。但幸运的是，Honeycomb使用Go编程语言，Go编程语言的优点是它从一开始就支持在多个操作系统和架构上运行。只需设置一个环境变量GOARCH，他们就能够构建运行在ARM架构而不是x86架构上的二进制文件或构建工件。

如果他们使用Java或Python，可能会更容易，因为在这些情况下，除非你在JAR中使用本机扩展或在Python中使用C Python，否则你可能只是在运行时执行，如果运行时是操作系统的一部分，那么你可能一开始就可以运行。如果他们是纯C++空间，他们可能就不会做这个项目，因为C++有很多可能会做出特定于架构的事情，他们必须在那里解决。

不过，他们在构建Docker镜像时遇到了一个警告，那就是如果你试图在非本机架构上构建Docker镜像，比如在x86机器上构建ARM工件，你必须使用QEMU来执行Docker构建步骤，这可能会有点慢。但好消息是，从2020年开始，事情变得更加广泛支持，以至于你可以在GitHub Actions、CircleCI或Buildkite等平台上找到ARM工作程序。

一旦他们构建了构建工件，准备好了基础操作系统层，他们就可以开始进行A/B测试了。在进行A/B测试时，他们发现了以下一些情况。他们希望确保进行苹果对苹果的比较，并确保发送真实的流量流以模拟行为，他们还希望验证Graviton团队当时的说法，即m6g实例类型在价格性能方面将提高20%到30%。

为了测试这一点，他们只是在由Graviton 2驱动的架构上启动了一些机器，并将一定百分比的流量分流到那些新实例上。他们将20%的流量分流到那些新实例，看看它们的表现如何。让我们来谈谈性能目标。他们在寻找什么?首先，他们要看它是否正常工作。如果它无法返回正确的结果，那就是个问题。好消息是它确实返回了正确的结果，但其他因素是，我应该期望什么?我是否有足够的可观察性来了解发生了什么?

在这个特定案例中，他们在观察请求流经的延迟是否缩短了?他们是否能够在每台机器上处理更多的吞吐量?如果它崩溃并开始返回错误或变得非常缓慢，他们将如何知道?他们还想了解诸如是否可以减少机器数量之类的问题。当然，即使每个请求快了100毫秒，但如果他们仍然花费相同的金额，那又有什么意义呢?所以他们想看看能够推动到什么程度。

而且由于Liz来自可靠性背景，她会强调隐藏的风险。可能会出现很多问题，所以他们必须提前考虑，即使实验进展顺利，他们也要考虑最坏情况。我如何回滚?我能够多快停止这个实验?我们如何确保开发人员接受了培训并能够胜任这项工作?如果某些事情在x86上可行但在ARM上不可行，谁来调试构建问题?谁来让构建重新变绿?

他们不得不与供应商合作，因为在某些情况下他们使用的是专有软件，他们希望确保能够顺利迁移。这些事情在实验开始时可能并未列入清单，但他们希望确保为此留出了一些空间。此外，在过程中他们确实遇到了一些问题。Liz稍后会谈到这些问题，但他们确实遇到了一些小麻烦，每当出现未按计划进行的变更时，他们都会暂时停止该变更，给人们一些时间恢复，而不是强行推行变更，导致持续出现问题。这是可以接受的。他们希望确保系统运行在稳定状态，而不是准稳定状态。准稳定系统是最糟糕的，因为一旦稍有偏差，就很难恢复到正常状态。

因此，在投入生产之前，他们花费了大量时间进行测试和验证，因为他们希望确保充分考虑到了一切影响。在考虑进行大规模迁移时，如何真正完成这个项目是非常重要的。如果他们完成了99%，但还剩下1%，究竟是什么因素能够促使他们完成迁移，清除技术债务，从而只维护一种架构?

让我们谈谈推出策略。他们在2020年初评估了Graviton 2，并需要选择一个地方来运行，以便进行测试。他们可以说，Liz和她的老板Charity Majors因提出“在生产环境中测试”的理念而闻名，是的，他们认为无论你是否喜欢，无论你是否否认，每个人都在生产环境中进行测试，但这并不意味着不应该在临时环境中测试。他们确实有一个临时环境，称为Dogfood。他们每天都使用Honeycomb来了解Honeycomb。他们没有直接将Graviton推向生产集群，而是将Graviton推向了他们的Dogfood集群，该集群的规模约为生产集群的1/5，因此仍然有相当大的流量，如果出现问题，也只会影响到他们自己的员工，而不会影响其他人。

这就是他们进行实验的地方。然后，他们使用另一个名为Kimmel的环境来观察Dogfood，因为这有点像一个永无止境的循环。就像他们使用自己的软件来观察自身观察自身一样，以确保始终拥有正确的可控性和可观察性。就服务架构而言，他们还需要考虑在哪里插入这个实验。一般来说，他们有许多有状态组件和无状态组件。对于这个初始实验，他们希望选择一个可以轻松回滚的组件，即使出现数据损坏，也只会影响少量数据，而不需要重放大量数据来恢复。

因此，他们选择了接收OpenTelemetry格式的可观察性数据的数据摄入工作程序进行实验，因为它是一个无状态服务，他们已经确保它能够在滚动重启时存活，并将数据持久化到Kafka，因此它本身不会长时间保存数据。它还是他们每秒查询次数最多的服务，而且可以非常干净地进行扩展。它唯一关心的扩展维度是CPU利用率，因为它本质上是在接收协议缓冲区并将其输出到Kafka中。它正在执行验证和转换，但实际上并不保留数据。

在2020年进行测试部署后，他们的初步发现是，他们能够获得约20%的性能提升，而且每个核心的成本将降低10%，但他们需要获得更好的效果。你知道，每个核心的性能虽然提高了20%，但他们如何确定呢?

他们实际上减少了核心数量。Liz之前提到的关于x86指令集的一个有趣现象是，由于每个执行单元有2个解码单元，如果你真的无法使运行单一工作负载的x86系统的CPU利用率超过50%或60%，那么即使你尝试ARM并以50%到60%的CPU利用率运行，你也不一定能看到全部好处。他们实际上根据服务级别目标(即他们试图达到的性能目标)，决定减少实例数量。他们尝试以60%、70%、80%的利用率目标运行。他们发现，即使在比x86实例高出20%的利用率下运行，Graviton 2实例的延迟也没有降低，这就是部分成本节约的来源。不仅仅是每个核心更便宜。

还有一个方面是能够使用更少的核心，如果你不真正拉伸系统并运行到延迟开始降低，那么你会觉得“这有点令人失望”，因为你假设x86和ARM的行为完全相同，你只能将其饱和度提高到50%或60%。

代码移植非常简单。他们只需设置一个环境变量，就可以在链或CI中完成。这只花了几个下午的时间，但实际上在整个车队中推广，这是一个更加复杂的过程。当他们真正这样做时，他们发现中位延迟降低了约10%，但尾部延迟降低了很多，大约20%到30%。他们将其推向Dogfood环境，立即看到成本下降。然后他们将其推向生产环境，也看到成本立即下降。

另一个奇怪有趣的事情是，他们之前使用的是x86的现货实例，结果发现按需的Graviton实例在成本方面实际上优于x86的现货实例，现在Graviton也提供现货实例。这一切都是在原始EC2实例上进行的，而不是裸机，但在2023年，他们迁移到了Kubernetes并开始使用EKS，当然Graviton在EKS上也得到了完全支持。在进行这次迁移时，他们从部署压缩的二进制文件转为使用容器，并使用了集群自动扩缩器。他们在设置中没有使用Carpenter。这是他们的一个特殊之处，可能并不适用于你，但他们发现Kubernetes集群中的同质性对他们来说非常重要。

为什么会这样呢?好吧，每一代Graviton似乎都会获得大约30%的每核心性能提升。你可以想象，如果你在设置Kubernetes工作负载的CPU限制和请求量时，但有些核心的运行速度慢30%，或者有些核心的运行速度慢50%，因为你在运行两代之前的东西，这将严重影响你的自动扩缩。他们发现，当他们将集群限制在使用特定一代时，体验最佳。他们完全从x86迁移到Graviton 2，然后完全从Graviton 2迁移到Graviton 3和Graviton 4，但他们真的不喜欢混合使用这些Graviton代，因为较慢的实例会落后，并且会积累越来越大的流量积压，直到崩溃。

使用集群自动扩缩器并使用相同一代的实例，对他们来说比使用Carpenter来优化现货和优化成本最低的实例更有帮助，因为他们关注的是可预测性，而不仅仅是成本。

大约两年前，Graviton 3正式发布，由于Honeycomb已经投入了从x86迁移到Graviton 2的努力，他们基本上免费获得了Graviton 3的所有性能优势。他们只需将C6G更改为C7G，就能立即获得更高的吞吐量，从而能够使用相同数量的核心来服务更多流量，即使考虑到减少了核心数量，延迟也会更低。

当然，他们会测量这一点，并希望了解“好的，我们目前运行的是之前Graviton代与当前代的什么比例?”以便他们能够根据实验的成功程度调整实验参数，并尽快推进，因为正如Liz所描述的，运行不同配置的Graviton 3与Graviton 4或Graviton 2与Graviton 3存在挑战。

他们通过基础设施即代码的方式进行代码升级，因此只需更改一个数字就很容易完成，至少在编写代码方面是如此。但显然，在确信可以在整个环境中推广这种变更之前，还需要进行大量的性能工程和实战测试。

是的，他们不得不放弃使用现货实例，Liz认为这是亚马逊云科技正在解决的一个挑战。再次强调，她并不为亚马逊云科技工作，这是她作为客户的真实经历。他们在Honeycomb公司内部有一个关于被“赶出自己的Graviton实例”的笑话。所以你可能已经看到Graviton 4的发布，你可能会认为“太棒了，没有人在使用Graviton 4，我可以完全使用现货实例。”

他们曾经使用过Graviton 3，当时他们认为“Graviton 3非常棒，现货实例也很棒，让我们在迁移离开Graviton 2时尝试这两种方案。”但他们很快发现，一旦其他人也发现在配置中更改一个数字是多么容易，那些他们正在使用的Graviton 3实例就突然从现货池中消失了，因为它们被需要用于生产和按需使用。

目前，他们意识到由于每一代产品的价格/性能比都会提高约30%，因此为他们而言，预留或按需获取当前最新一代实例，而不是在使用现货实例时可能不得不回退到上一代产品，这种做法更加合理。

最近推出的Graviton 4对于他们的工作负载而言，性能比Graviton 3快约30%，但你的里程数可能会有所不同。但Liz认为亚马逊云科技在设计Graviton芯片时所做的最有力的事情之一是，他们不仅仅是在亚马逊云科技内部应用Neoverse的标准内核设计，还利用了来自真实亚马逊云科技客户的数据，了解亚马逊云科技客户执行的指令类型，然后设计芯片以满足亚马逊云科技客户实际遇到的最常见模式。

他们的经验是，性能不断提高，而这种提高并不一定会在基准测试中体现，因为他们不仅仅在运行基准测试，还在处理人们发送给他们的实际protobuf数据。他们的经验是，每次升级代码时，他们都能减少工作负载中的实例数量。

如果你对比一下去年和今年的情况。这是比较他们在2023年11月使用Graviton 3和2024年11月使用Graviton 4的经历。去年这个时候，他们使用了大约60个M.7G8X大型实例，现在正在切换过来。今年，他们运行了大约100个M8G8X大型实例，但服务的流量是去年的两倍，所以他们使用的实例数量增加了约50%，但服务的流量增加了一倍。

Liz认为，即使考虑到Graviton 4的每个vCPU小时成本比Graviton 3高出约10%，这种价格/性能的权衡还是相当不错的。如果你做个计算，大约是流量增加一倍、实例数量增加50%、每个实例成本增加10%。Liz认为这与亚马逊云科技提供的每一代产品价格/性能提高30%的数字非常吻合。

如今，他们使用EKS作为主要的扩展工作负载，使用M6G实例，但也有很多不是扩展工作负载的服务。Liz之前暗示过他们100%使用Graviton，那么他们如何迁移其他所有服务呢?

事实证明，对于RDS、OpenSearch Service以及任何需要告诉亚马逊云科技使用什么虚拟机类型的服务，你只需将M5或M6更改为M6G或M7G即可。当然，你应该进行自己的性能比较，当然你应该对工作负载进行自己的验证。但他们发现，只需切换那个数字，让亚马逊云科技替换他们的实例，就可以轻松完成迁移。

这就是他们获得免费性能提升的方式，因为在他们的情况下，他们没有运行太多不同的RDS数据库。他们只有一个大型RDS实例，用于存储客户发送给他们的数据的元数据。因此，它实际上只需要根据是4X大型还是8X大型实例来进行扩展。通过将数据库实例从M5迁移到M6G，他们避免了在很长一段时间内不得不将实例大小增加一倍，如果他们继续使用上一代Intel架构就不得不这样做。

这些是简单的情况。但让我们来讨论一下困难的部分。让我们讨论一下需要保留磁盘上数据的有状态工作负载，讨论一下可能需要原始NVMe性能而不是使用EBS的有状态工作负载。

他们的Kafka代理运行在I3M4GN上。Liz看到了关于I6G的公告，但他们还没有机会尝试。因此，他们目前使用的是I3M4GN，并将数据分层存储到Amazon S3。

让我们来讨论一下他们的Kafka集群是如何演进并最终100%运行在Graviton上，并获得大幅提升的价格/性能比。回溯到2020年，他们使用的是I3EN实例，而当时使用的I3EN实例在CPU方面实际上是非常低负载的。他们是一个存储受限的工作负载，因为他们希望有一个灾难恢复的安全网。他们希望确保在Kafka代理中保留48小时的客户数据，以防需要重放。因此，他们不得不运行越来越多的Kafka节点。最终他们运行了30个不同的工作节点，这些节点只是占用了磁盘空间，没有做其他太多工作。

在Confluent公司的帮助和合作下，他们能够使用大幅减少的基于Intel的I3EN本地SSD节点，因为他们将所有超过2小时的数据存储到S3上，并根据需求重放，只在磁盘上保留最近2小时的数据。这意味着他们从存储受限的工作负载转变为CPU和I/O操作受限的工作负载。

但在某个时候，他们的服务器基础设施中唯一运行Intel架构的就是Kafka代理，他们想，“为什么我们要维护两种架构?为什么我们不能简化为一种架构呢?”

他们曾短暂尝试使用C6GN实例和EBS，因为当时还没有Graviton实例的SSD存储变体。他们发现自己陷入了Liz所说的那种元稳定状态，他们会超出CPU限制、网络限制和EBS IOPS限制，系统会一直运行良好，直到突然被限制，然后就很难恢复过来。于是他们说，好吧，让我们暂时继续使用Intel，我们需要等待有合适的i3 en替代品出现。

两三年前，Im 4gn问世了，他们就能够无缝地将Kafka代理从i3 en一一替换为im 4gn。但这并不是一帆风顺的。当然，一开始它可以运行，但他们遇到了一些性能问题，导致他们不得不重新思考解决方案。特别是，事实证明，当你频繁地从S3读写数据时，由于Liz提到的分层存储，他们不再是存储受限的工作负载，为HTTPS请求到S3端点执行加密操作，这在Kafka代理上消耗了大量时间。他们在Kafka代理上花费了20%到30%的时间用于MD5或SHA-1哈希算法。

因此，他们不得不与Amazon Corretto团队和Confluent Kafka团队合作，找出如何优化这一依赖关系。事实证明，Confluent Cad附带的默认库没有包含ARM支持。这是一种情况，即存在特定于架构的手工汇编优化代码或已编译到jar中的C++工件，因此他们需要用Graviton-ARM优化的版本来替换。在做了这些改动之后，他们就能获得更好的价格/性能比，并继续推进这一迁移。

让我们讨论一下他们的其他有状态工作负载。他们有一个非常强大的索引引擎，可以ingress客户的所有数据，然后按列、按每个trace中的特定字段将其存储下来。这个工作负载是在本地SSD上运行的，他们最初使用的是Liz认为是i3实例，在2020年到2021年左右，他们在考虑如果能将其迁移到Graviton 2会怎样。

他们发现，他们能够从i3实例迁移到m6gd实例，而m6gd实例实际上比他们使用的可比i3实例的成本更高，以获得相同数量的本地SSD，但他们以相同的价格获得了两倍的核心数量，并且每个核心的性能提高了50%。支付10%的额外费用换取3倍的性能是非常值得的，因为这使他们能够停止燃烧SLO的性能下降，并且他们能够在不添加更多节点且不会降低延迟的情况下，实现大约1.5或2倍的扩展能力，这为他们扩展集群或随着使用量增长而不必扩展集群提供了很大的余地。

当然，当m7g推出时，他们也切换了过来。这只是改变了配置中的一个数字，加上进行了大量的性能测试，他们发现针对NVMe SSD执行的本地查询在从m6gd切换到m7gd时，运行速度提高了约20%。

如果你还记得Liz开始时所说的，你的寻呼机响了，你正在等待一个Honeycomb查询运行，对吗?他们能为你节省的每一毫秒，都意味着你的系统因为获得答案更快而停机的时间更短。这对他们来说并不一定是成本节约，但他们认为这是值得的，因为它能为客户提供更好的查询性能。

但是，如果速度还不够快，无法在本地执行所有查询怎么办?就像Graviton处理器一样，你知道它们在单个机器上的运行速度是有限的。如果他们能够将成千上万台机器投入到这个问题中，那不是很好吗?

答案是肯定的，因为他们正在将较旧的数据从检索索引节点传输到S3。他们实际上能够使用Amazon Lambda并行处理这些数据。再次说明，最初Lambda只提供x86配置，但后来Graviton 2推出，然后Lambda也支持了Graviton 2。

他们扫描60天数据(这些数据已经无法完全存储在单个检索节点的本地SSD上)的扩展问题的解决方案是将数据存储在S3上，使用Lambda工作程序检索数据，这使得小于10秒的查询时间成为可能。

事实上，与在EC2上持续运行相比，Lambda可能非常昂贵。他们的计算显示，在EC2上运行与在Lambda上运行相比，成本大约高出3倍，但其美妙之处在于，他们可以获得完美的利用率。然后，他们可以按使用的毫秒数为Lambda付费。

当他们从使用x86 Amazon Lambda切换到使用Graviton Amazon Lambda时，他们发现能够大幅降低运行这些Lambda工作程序的成本，因为Lambda大约占他们亚马逊云科技账单的30%或40%，这是相当可观的，但他们再次认为这是值得的。

这一过程最初并不是一帆风顺的，因为与他们在Kafka中遇到的情况类似，存在一些隐藏的程序集依赖关系。问题不在于无法编译，Go使得如果是x86就执行这个手写程序集，否则就让Go编译器自动完成变得非常容易。所以它能运行，但实际上运行速度相当慢，比x86的Lambdas慢10%到20%。

但是他们进行了分析，确定了需要更新手写程序集的依赖项，然后他们能够重新运行实验，并看到更好的性能。他们还不得不与Lambda团队进行一些容量规划，因为当他们将Lambdas提高到50%或100%时，他们开始与自己竞争，因为当时Graviton 2 Lambda的Graviton 2发货量还没有赶上x86 Lambda车队的容量水平。

但是通过与亚马逊云科技团队合作，他们能够获得足够的容量。他们能够优化需要移植到ARM上的那些手写程序集位，Liz还将指出另一个有趣的事情，你可能会看到这个图表，说等等，延迟是一样的，对吗?就像你为CPU毫秒付费一样，那么为什么我说它更便宜呢?

原因有两个:每个核心和每毫秒，Graviton 2 Lambda大约比x86 Lambda便宜10%，但另外，如果你看那张幻灯片的底部，你会看到他们为运行在ARM上的每个Lambda工作程序分配的vCPU和内存更少。事实证明，这是因为他们的工作负载实际上受到了网络限制，每个Lambda工作程序连接到S3的可用网络带宽是他们的限制因素。

因此，如果他们能够缩小Lambda的规模，因为它每个核心能够处理更快，那么他们就能够获得相同的吞吐量，并且支付更少的费用。这终于是他们开始看到Lambda账单降低20%到30%的时候。

从2022年4月开始，他们在服务器端已经100%使用ARM服务器，而对于Lambda，他们基本上也是100%使用Lambda。那里有一个星号，因为他们遇到了ARM Lambda的容量问题，所以他们故意保留了1%的Lambdas为x86，因为他们想确保，如果由于ARM Lambda短缺而需要运行x86 Lambda，他们不会出现这种情况。他们想确保持续验证x86 Lambda是否仍然可以工作，即使从价格/性能角度来看可能会更差。

但大约两个月前，Liz最终终止了所有x86 Lambdas，原因是他们实际上遇到了一次由x86 limb引起的中断，在这一点上，他们对Lambda团队的容量预测足够有信心，愿意继续运行。

他们是如何对Lambda团队的容量预测充满信心的呢?原来，当Lambda团队为你的ARM Lambdas提供双倍的并发能力时，你会说是的，并表示感谢，然后会说:哦?也许我不需要再回退到x86了。

Liz会把这个放大一点，也许使用对数刻度，这样你就可以看到基本上那1%的备用，占她流量1%的对数刻度，是在x86上运行的，然后她完全取消了这部分流量，只剩下健康检查，最后她销毁了Lambdas，现在她的Lambdas100%都是ARM了。

总之，亚马逊云科技真的使Honeycomb能够作为一家公司快速且精益运营，对环境产生更小的影响，提供更好的性价比，并为客户提供更快的结果。他们不必自己投资进行这种CPU研究 - Amazon Graviton团队已经完成了所有这些研究工作，因此Honeycomb只需在他们的亚马逊云科技配置中增加一个数字，就可以获得Graviton团队所做一切工作的好处。

如果我们将Honeycomb今天的状况与5年前进行比较，他们的性价比提高了约2.2倍，将第8代M6g实例与他们2019年之前使用的M5实例进行比较。他们在过去4-5年里扩展了20倍，但他们的亚马逊云科技账单只增加了大约13倍。如果你做个计算，基本上等于每条ingested trace的成本效率提高了约1.6倍。

这是因为他们的基础设施并非100%都是Graviton4。仍有Lambdas，它们是Graviton 2。还有一些东西，比如S3，显然不会直接受到Graviton定价的影响，但总的来说，Liz认为这是一个了不起的成果，能够将你的ingested量扩大20倍，而你的账单并没有以同样的速度线性增长。

他们看到的可靠性基本上是稳如磐石，与以前看到的一样可靠，实际上可能甚至更可靠，因为P99如此稳定，而不是突然达到一个拐点，如果运行过于饱和，你的P99就会变差。

如果你对这种架构及其在Graviton上的设计和运行方式感兴趣，Liz确实出版了一本书，他们现在正在着手第二版，这本书名为《Observability Engineering》，他们关于架构的工作在第16章“高效数据存储”中有介绍。

在此基础上继续前进，无论你是选择采用Graviton，还是考虑进行其他迁移。只要记住，你要设定一些试图衡量的目标，进行实验，然后利用该实验的数据为完成迁移制定商业案例，100%部署，然后摆脱维护两个系统并行运行的技术复杂性。

如果你有兴趣在会后与Liz交谈，可以现场提出问题。如果你想继续讨论这个话题，她会在会后前往Honeycomb展位，所以你可以在那里与她自由交流。

Liz今天要分享的就是这些。她最近也加入了BlueSky，所以她在lizthegrey.com上的BlueSky和LinkedIn上。非常感谢，她期待着回答你们的问题。

下面是一些演讲现场的精彩瞬间：

一个发人深省的问题，探讨人们在半夜被意外噪音惊醒时会有何种感受，是自信、恐惧还是不确定。

Honeycomb在他们规模为生产集群1/5的Dogfood分期环境中推出了Graviton 2，以便在部署到生产环境之前进行测试。

强调了数据摄入工作者的可扩展性和弹性，这是一种无状态服务，可以处理高流量并在持续数据到Kafka的同时生存滚动重启。

讨论了他们Kafka集群的演进过程，以及如何过渡到100%运行在Graviton实例上，从而实现了显著的成本性能改进。

亚马逊云科技透露了他们如何无缝地将Kafka代理从i3en迁移到im4gn实例，克服了与S3分层和加密交易相关的性能挑战。

通过迁移到m6gd实例，该公司以仅10%的成本提高了3倍的性能，使他们能够扩展而无需添加更多节点或遇到延迟降级。

演讲者邀请观众在演讲结束后与他们互动，或者访问Honeycomb展位进行进一步讨论。

总结

在一段引人入胜的叙述中，Honeycomb的现场首席技术官Liz Fong-Jones讲述了他们迁移到亚马逊Graviton处理器、优化性能和成本效率的非凡历程。Honeycomb是一家为开发人员提供对其系统洞见的公司，他们着手进行这一努力，目的是提供快速且经济实惠的洞见。

Liz生动地描述了最初围绕迁移的疑虑，就像在半夜被惊醒一样。然而，他们坚持将99.5%的查询在10秒内返回的服务级别目标作为动力。通过细致的测试和验证，他们发现Graviton实例不仅提供了正确的结果，而且在延迟方面也有了实质性的改善，尤其是在尾部延迟方面。

迁移过程虽然并非一帆风顺，但却证明了Honeycomb的弹性和适应力。Liz回顾了其中涉及的复杂步骤，从使其软件能够在ARM架构上运行，到优化其CI工具并解决供应商依赖性问题。这是一个渐进但有目的的过程，在每个阶段都经过了严格的性能工程和实战测试。

随着进程的推进，优势变得越来越明显。Graviton实例始终优于其x86对手，每一代新产品都能提供高达30%的更佳性价比。Liz分享了他们如何无缝地从Graviton 2过渡到Graviton 3，再到Graviton 4，在每次升级中获得更高的吞吐量和更低的延迟。

这个故事的高潮是Honeycomb实现了在其服务器和无服务器基础设施上100%运行在Graviton上的宏伟目标。Liz强调了这一非凡成果:在过去四到五年里，他们的数据摄入量增加了20倍，而他们的亚马逊云科技账单仅增加了13倍，这意味着每条摄入的跟踪的成本效率提高了1.6倍。

Liz引人入胜的讲述凸显了拥抱创新和不懈追求卓越的变革力量。她的结语鼓励其他人踏上自己的迁移之旅，以明确的目标、数据驱动的实验和坚定的决心完成过渡，摆脱维护多种架构的复杂性。

亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。做为全球生成式AI前行者，亚马逊云科技正在携手广泛的客户和合作伙伴，缔造可见的商业价值 – 汇集全球40余款大模型，亚马逊云科技为10万家全球企业提供AI及机器学习服务，守护3/4中国企业出海。