8x8如何通过采用Ampere处理器节省成本并提升30%性能

挑战

2020年新冠疫情爆发期间，全球对8x8加密视频会议服务的需求呈指数级增长——在几周内从20台虚拟服务器激增至8000台。虽然8x8视频路由器的工作原理解释起来很简单，但实际上对CPU资源的需求非常高。

扩展系统意味着需要在云中部署更多服务器。8x8服务器在几小时内遇到的网络性能瓶颈数量，相当于工程师们预期一年内需要处理的问题总量。

“通常当出现问题时，机器会不堪重负，CPU需求过高，无法及时处理到达的数据包队列，“8x8的Emil Ivov解释道。这些问题导致延迟增加，用户能够明显感知到，更紧迫的是，云服务成本大幅上升。

为了降低成本，8x8投资了Oracle云基础设施（OCI）。OCI为8x8提供了基于Ampere® Altra® CPU的更具成本效益的Arm64实例。时间紧迫的情况下，8x8冒险开始为Jitsi进行重构，准备迁移到Arm64微架构——这一举措原本预计会充满困难和事故。

Jitsi的大部分关键代码都是用Java编写的，需要JNI接口连接到本地机器代码加密库和其他需要重新编译的库。

幸运的是，由于现有的Arm64库，将其所有Jitsi代码迁移到Arm64只需要开发人员最少的工作量，所有工作都在一天内完成。此外，启动新虚拟机实例的自动化脚本需要为Arm64实例重新调整——这又花费了几天时间。

迁移到基于Ampere的Arm64实例后，8x8实现了Jitsi达到或超过P95 1毫秒的目标。这意味着日常性能中数据包事务处理时间应少于1毫秒，P99为5毫秒。

从成本角度看，OCI的Arm64实例每个实例比之前使用的实例便宜高达30%。除此之外，基于Ampere的Arm64实例还提供了高达30%的性能提升——“这是一个非常显著的改进”。与迁移前相比，每个Ampere实例在相同规模下能够处理多20-30%的工作量。

虽然8x8视频路由器的工作看似简单，但实际上相当耗费CPU资源。就像电话交换机一样，服务器从一个套接字读取数据包，解密后重新加密，然后将加密的数据包复制到其他套接字进行转发。

“每周，我们都需要将托管Jitsi所需的基础设施翻倍，“Jitsi创建者、8x8产品副总裁Emil Ivov表示。“当事物呈指数级增长时，速度之快令人难以置信。”

当出现问题时，机器会不堪重负，CPU需求过高，无法及时处理到达的数据包队列。这些队列会变得越来越长，数据包离开队列、被处理、放入出站队列并发送所需的时间会增加，这种延迟对用户是可见的。

延迟会表现为数据包丢失，因为当向终端设备发送过多数据包时，可能会使路径上各种设备的队列过载。用户可能会看到视频质量差、音频噪音或中断。

Jitsi的关键代码主要使用Java编写，需要JNI接口与本地机器代码加密库交互。幸运的是，大多数重要库都已经提供了Arm64版本。

“这是一个支持非常好的架构，“Ivov指出。“每个有意义的项目都已经有Arm64的二进制文件，所以我们从未遇到过任何问题。”

8x8团队最初对从x86迁移到Ampere架构有些担忧，担心性能可能会受到影响。但令他们惊喜的是，整个迁移过程仅耗时两周。

“我们开启了新实例，价格便宜约20%到30%的机器却给我们带来了20%到30%的性能提升，“Ivov表示。当被问及8x8将其他平台迁移到Ampere和OCI的计划时，Ivov宣称这是降低成本的最简单途径。

“采用Ampere实例没有任何犹豫，“他说。“它们始终是我们首选的选项。”