2014 年，在 Instagram 加入 Facebook 两年后，Instagram 的工程团队将公司的基础设施从亚马逊网络服务 (AWS) 服务器迁移到 Facebook 的数据中心。Facebook 在美国和欧洲拥有多个数据中心，但直到最近，Instagram 仅使用美国数据中心。
Instagram 希望将其基础设施扩展到大洋彼岸的主要原因是我们在美国已经耗尽了空间。随着服务的持续增长，Instagram 已经到了需要考虑利用 Facebook 在欧洲的数据中心的程度。另一个额外的好处是：本地数据中心将意味着欧洲用户的延迟更低，这将为 Instagram 创造更好的用户体验。
2015 年，Instagram 将其基础设施从一个数据中心扩展到三个数据中心，以提供急需的弹性——我们的工程团队不想重温 2012 年 AWS 的灾难，当时弗吉尼亚州的一场巨大风暴几乎摧毁了其一半的实例。从三个数据中心扩展到五个数据中心是微不足道的；我们只是增加了复制因子并将数据复制到新区域；然而，当下一个数据中心位于另一个大陆时，扩展就更加困难了。
了解基础设施
基础设施通常可以分为两种类型
每个人都喜欢无状态服务——它们易于部署和扩展，您可以根据需要随时随地启动它们。事实是，我们还需要像 Cassandra 这样的有状态服务来存储用户数据。运行副本过多的 Cassandra 不仅增加了维护数据库的复杂性；这也是容量的浪费，更不用说跨越重洋的仲裁请求……太慢了。
Instagram 还使用 TAO，一种用于社交图谱的分布式数据存储，作为数据存储。我们将 TAO 作为一个分片一个主节点运行，并且没有从节点更新任何写入请求的分片。它将所有写入转发到分片的主区域。由于所有写入都发生在主区域（位于美国），因此在欧洲的写入延迟是难以忍受的。您可能会注意到我们的问题基本上是光速。
潜在的解决方案
我们能否减少请求跨越重洋所需的时间（甚至使往返行程消失）？以下是我们解决此问题的两种方法。
分区 Cassandra
为了防止仲裁请求跨越重洋，我们正在考虑将我们的数据集划分为两个部分：Cassandra_EU 和 Cassandra_US。如果欧洲用户的数据存储在 Cassandra_EU 分区中，而美国用户的数据存储在 Cassandra_US 分区中，则用户的请求将不需要长途跋涉来获取数据。
例如，假设美国有五个数据中心，欧盟有三个数据中心。如果我们通过复制当前集群在欧洲部署 Cassandra，则复制因子将为八，并且仲裁请求必须与八个副本中的五个副本对话。
但是，如果我们能找到一种方法将数据划分为两个集合，我们将拥有一个复制因子为 5 的 Cassandra_US 分区和一个复制因子为 3 的 Cassandra_EU 分区——并且每个分区都可以独立运行，而不会影响其他分区。与此同时，每个分区的仲裁请求都能够停留在同一大陆，从而解决往返延迟问题。
限制 TAO 写入本地
为了减少 TAO 写入延迟，我们可以将所有欧盟写入限制到本地区域。它看起来应该与最终用户几乎相同。当我们向 TAO 发送写入时，TAO 将在本地更新，并且不会同步阻止将写入发送到主数据库；而是将写入排队在本地区域中。在写入的本地区域中，数据将立即从 TAO 中获得，而在其他区域中，数据将在从本地区域传播后可用。这类似于今天的常规写入，它从主区域传播。
虽然不同的服务可能有不同的瓶颈，但通过关注减少或消除跨洋流量的想法，我们可以逐个解决问题。
经验教训
与每个基础设施项目一样，我们在此过程中吸取了一些重要的教训。以下是一些主要的教训。
不要匆忙进入新项目。在开始在新数据中心配置服务器之前，请确保您了解为什么需要在新区域部署服务，依赖关系是什么，以及当新区域投入使用时事情将如何运作。此外，不要忘记重新审视您的灾难恢复计划并进行任何必要的更改。
不要低估复杂性。始终在您的计划中留出足够的时间来犯错、发现计划外的障碍以及了解您不了解的新依赖项。您可能会发现自己走上了一条无意中重组基础设施构建方式的道路。
了解您的权衡。事情总是要付出代价的。当我们分区 Cassandra 数据库时，我们通过降低复制因子节省了大量存储空间。但是，为了确保每个分区仍然能够应对灾难，我们需要前端有更多的 Django 容量来接受来自故障区域的流量，因为现在分区无法彼此共享容量。
保持耐心。在启动欧洲数据中心的过程中，我不记得我们说了多少次“哎呀！”。但事情总会最终解决的。这可能比您预期的要长，但请保持耐心并作为一个团队一起工作——这是一次超级有趣的旅程。
Sherry Xiao 将在 LISA18（10 月 29 日至 31 日，田纳西州纳什维尔）上介绍跨大西洋：将 Instagram 基础设施从美国扩展到欧洲。
评论已关闭。