面对无声数据损坏的Facebook架构师

无声但致命：没有比数据损坏更具破坏性的数据了，它们无法被硬件甚至软件中的各种错误捕获工具捕获，在感染整个应用程序之前很难发现它们。

这在Facebook规模上尤其具有毁灭性，但是这家社交巨头的工程团队已经发现了防止局部问题走向全球的策略。单个硬件根源的错误在以超大规模乘以Facebook的情况下成倍增加时，可能会成为一个大问题，要制止这一问题需要结合硬件弹性，生产检测机制以及更广泛的容错软件体系结构。

Facebook的基础架构团队开始努力了解2018年无声数据损坏的根源和修补程序，以了解整个机队范围内的修补程序的外观以及这些检测策略可能在开销方面造成的成本。

工程师发现，许多级联错误是生产中的CPU造成的，但并非总是由于辐射或合成故障注入的“软错误”引起的。相反，他们发现这些可以以可重复的方式在CPU上随机发生。尽管ECC很有用，但它专注于SRAM中的问题，但其他元素也容易受到影响。报道了这些问题的Facebook工程团队发现，由于其他模块中未进行纠错，CPU静默数据损坏实际上比软错误要高几个数量级。

CPU复杂性的增加为更多错误打开了大门，而在超大规模数据中心级与日趋密集的节点配合使用时，这些大规模问题只会变得更加棘手且分布广泛。在硬件级别，问题的范围可能是一般的设备错误（布局和布线问题可能导致信号的到达时间不同，例如导致比特翻转），并且仍然出现更多以制造为中心的问题，例如蚀刻错误。此外，设备的早期使用寿命故障和现有CPU的性能下降也可能带来难以检测的影响。

例如，当您执行2×3时，在某些微体系结构条件下，CPU可能会静默给出5而不是6的结果，而不会在系统事件或错误日志中指示任何错误的计算。结果，利用CPU的服务可能不知道计算精度，并不断消耗应用程序中的错误值。

Facebook基础架构团队的成员解释说：“静音数据损坏是大规模运行的数据中心应用程序中的真实现象。” “了解这些损坏有助于我们深入了解硅器件的特性；通过复杂的指令流及其与编译器和软件体系结构的交互。存在多种检测和缓解策略，每种策略都会为大型数据中心基础架构带来额外的成本和复杂性。”

Facebook使用了一些参考应用程序示例来突出显示大规模静默数据损坏的影响，其中包括一个Spark工作流示例以及一个每天运行数百万次压缩/解压缩计算的FB压缩应用程序，该工作流程每天运行数百万个字数计算。 。在压缩示例中，Facebook观察到一种情况，该算法为单个文件返回了“ 0”大小值（假定为非零数字），因此该文件未写入解压缩的输出数据库中。结果，数据库缺少文件。丢失的文件随后传播到应用程序。保留压缩文件的键值存储映射列表的应用程序会立即发现，压缩后的文件不再可恢复。依赖关系链导致应用程序失败。”很快，查询基础结构就会报告严重数据丢失的情况。从这个例子可以清楚地看出问题所在，想象一下它是否大于压缩或字数统计（Facebook可以做到）。

数据损坏在整个堆栈中传播，并表现为应用程序级别的问题。这些类型的错误可能导致数据丢失，并且可能需要数月的调试工程时间……随着硅密度和技术规模的提高，我们认为学术研究人员和行业应投资于应对这些问题的方法。

调试工作很艰巨，但这仍然是Facebook处理这些无声数据损坏的方式的核心，尽管直到声音足够大才能被听到为止。 “要调试一个无声错误，我们必须先了解执行了哪些机器级指令，然后才能继续前进。我们要么需要针对Java和Scala的提前编译器，要么需要一个探针，该探针在执行JIT代码时提供所执行指令的列表。” 5.2中详细介绍了它们用于静默错误调试的最佳实践。

一套全面的容错机制也是Facebook策略的关键。这些包括软件级别的冗余，但是当然，这会带来成本。 “冗余的成本直接影响资源；体系结构越冗余，重复资源池的需求就越大”，即使这是概率容错的最确定的途径。处理容错的开销较小的方式还包括依赖容错库（特别引用了PyTorch），尽管这也不是“免费的”，但对应用程序性能的影响是显而易见的。

“这项工作需要在硬件静默错误研究社区和软件库社区之间进行密切的握手。”

就这种握手而言，Facebook公开呼吁数据中心设备制造商了解其最大客户的期望值更高，尤其是考虑到硬件衍生错误的级联广域网影响。

“在大型基础架构中，无声数据损坏不仅限于百万分之一的事件。这些错误是系统性的，没有像机器检查异常之类的其他故障模式那么容易理解。”基础架构团队补充说，有几项研究评估了降低处理器内软错误率的技术，这些经验教训可以纳入类似的，可重复的SDC中，而SDC的发生率可能更高。

Facebook说，设备制造商应该承担很大一部分责任。这些方法在制造商方面，可以包括增强设备上的模块，以使用自定义ECC提供更好的数据路径保护，提供更好的随机测试，了解增加的密度意味着更高的错误传播，最重要的是，通过“与使用大规模设备的客户紧密合作，以了解静默错误的影响。”这将包括发生率，生产中的故障时间，对频率的依赖性以及影响这些错误的环境问题。

“在过去的18个月中，Facebook基础设施已经实现了上述硬件检测和软件容错技术的多种变体。量化上述每种方法的收益和成本，已使基础架构对于Facebook系列应用程序而言是可靠的。”基础架构团队计划发布一个后续版本，其中详细介绍了当前方法的各种权衡和成本。

您可以在此处找到更多详细信息，包括Facebook的软件容错最佳实践以及围绕潜在硬件故障的架构。

直接从我们到您的收件箱，包括本周的重点摘要，分析和故事，之间没有任何内容。