Instagram在如何越洋扩展基础设施?

Instagram想把基础设施扩展到大洋彼岸的主要原因是，我们在美国已没场地可用。随着服务不断增多，Instagram已到了我们需要考虑利用Facebook建在欧洲的数据中心的地步。另一个好处是：本地数据中心意味着对欧洲用户来说延迟更低，这有望在Instagram上打造更好的用户体验。

2015年，Instagram将基础设施从一个数据中心扩展到了三个，以提供急需的弹性：我们的工程团队不想重蹈2012年AWS灾难的覆辙，当时弗吉尼亚州的一场大风暴导致其近一半的实例瘫痪。从三个数据中心扩展到五个很轻松；我们只是增加了复制因子，将数据复制到新的区域;然而当下一个数据中心远在另一个大陆时，扩展起来会更难。

了解基础设施

基础设施通常可分为两种类型：

• 无状态服务通常用作计算，根据用户流量进行扩展(按需扩展)。Django Web服务器就是个例子。
• 有状态服务通常用作存储，必须在数据中心之间保持一致性。比如包括Cassandra和TAO。

每个人都喜欢无状态服务，它们易于部署和扩展，可以随时随地根据需要来启动。事实上，我们还需要像Cassandra这样的有状态服务来存储用户数据。运行带有太多副本的Cassandra不仅增加了维护数据库的复杂性，还浪费了容量，更不用说越洋传输仲裁(quorum)请求有多慢了。

Instagram还使用TAO(面向社交图的分布式数据存储)作为数据存储系统。我们将TAO作为每个分片(shard)的单个主系统(master)来运行，没有任何从属系统(slave)为任何写入请求更新分片。它将所有写入内容转发到分片的主区域。由于所有写入都在位于美国的主区域进行，所以欧洲那边的写入延迟无法忍受。你可能注意到我们的问题反馈基本上是光速。

潜在解决方案

我们能否缩短请求越洋传输的时间(甚至使往返传输消失)?有两种方法可以解决这个问题。

1. 对Cassandra分区

为了防止仲裁请求越洋传输，我们在考虑将数据集分为两部分：Cassandra_EU和Cassandra_US。如果欧洲用户的数据存储在Cassandra_EU分区中，美国用户的数据存储在Cassandra_US分区中，用户的请求就不必远距离传输来获取数据。

比如说，假设美国有五个数据中心，欧盟有三个数据中心。如果我们通过复制当前集群而在欧洲部署Cassandra，复制因子将是8，仲裁请求必须与8个副本中的5个进行联系。

但是如果我们可以找到将数据分成两组的方法，就会有一个复制因子是5的Cassandra_US分区和一个复制因子是3的Cassandra_EU分区，每个分区可独立运行，而不影响其他分区。与此同时，每个分区的仲裁请求能够保持在同一个大陆，因而解决往返传输的延迟问题。

2. TAO仅限于写入到本地

为了缩短TAO写入的延迟，我们可以将所有EU写入限制于本地区域。这在最终用户看来几乎一样。我们向TAO发送写入时，TAO将在本地更新，不会阻止同步向主数据库发送写入;相反，它会在本地区域将写入放到队列中。在写入的本地区域，数据可立即从TAO获取，而在其他区域，数据将在从本地区域传播后可用。这类似今天的常规写入，数据从主区域传播。

虽然不同的服务可能会有不同的瓶颈，但如果致力于减少或消除越洋流量这个想法，我们能逐一解决问题。

经验教训