40

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

 5 years ago
source link: http://network.51cto.com/art/201810/585826.htm?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

【51CTO.com快译】2014年,Instagram加入Facebook两年后,Instagram的工程团队该将公司的基础设施从亚马逊网络服务(AWS)服务器迁移到了Facebook的数据中心。Facebook在欧美有多个数据中心,但直到最近Instagram才使用美国的数据中心。

ja26jyA.jpg!web

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获取,而在其他区域,数据将在从本地区域传播后可用。这类似今天的常规写入,数据从主区域传播。

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

经验教训

与每个基础设施项目一样,我们在此过程中汲取了一些重要的经验教训。以下是几个主要的。

  • 别急着搞新项目。开始在新数据中心配置服务器之前,确保你了解为什么需要在新区域部署服务、有什么样的依赖关系以及新区域投入使用时系统会如何运行。此外,别忘了反思灾难恢复计划,并进行必要的改动。
  • 别低估复杂性。总是在你的日程安排中留出足够的时间,因为要犯错误,要找出意外的阻碍因素,要学习你不了解的新的依赖关系。你可能发现自己无意中在重新设计构建基础设施的方式。
  • 明白取舍。成功总是要付出代价。我们对Cassandra数据库进行分区后,通过缩小复制因子,节省了大量存储空间。然而为了确保每个分区仍然准备好面对灾难,我们需要更多的前端Django容量,以接受来自故障区域的流量,因为现在分区无法彼此共享容量了。
  • 耐心一点。在开启欧洲数据中心的过程中,我不记得有多少次我们说过“哦,见鬼!”但事情总是最终得到了解决。可能比你预期的要更久,但要有耐心,整个团队要通力合作,这是超有意思的过程。

原文标题:How Instagram is scaling its infrastructure across the ocean,作者:Sherry Xiao

【51CTO译稿,合作站点转载请注明原文译者和出处为51CTO.com】


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK