Facebook如何将Instagram从AWS搬到自己的服务器

开发 项目管理
当Instagram在2012年加入Facebook,我们快速建立了大量的Facebook基础设施整合点,以加速产品开发,使社区更加安全。一开始我们通过使用ad-hoc端点在Facebook web服务之间有效传递来构建这些整合……

当Instagram在2012年加入Facebook,我们快速建立了大量的Facebook基础设施整合点,以加速产品开发,使社区更加安全。一开始我们通过使用ad-hoc端点在Facebook web服务之间有效传递来构建这些整合。不过我们发现这种方式可能稍显笨拙,还限制了我们使用内部的Facebook服务的能力。

2013年四月伊始,我们开始将Instagram的后端从Amazon Web Services(AWS)向Facebook的数据中心大规模迁移。这将缓和与其他内部的Facebook系统整合并允许我们充分利用为管理大规模服务器部署构建的工具。迁移的主要目标是在过渡中保持网站的完整服务,避免影响特性部署,最小化基础设施级别的改变来避免操作的复杂性。

起初迁移好像很简单:在Amazon的Elastic Compute Cloud(EC2)和Facebook的数据中心之间搭建一个安全的连接,一块一块地将服务迁移过来。简单。

不止如此。这个简单的迁移的主要障碍是Facebook的私有IP空间和EC2的私有IP空间冲突。我们只有一条路可走:先迁移到Amazon的Virtual Private Cloud(VPC),随后使用Amazon Direct Connect迁移到Facebook。Amazon的VPC提供了必要的伸缩寻址来避开与Facebook的私有网络冲突。

我们对这个任务望而却步;在EC2上运行着数以千计的实例,还有每天出现的新实例。为了最小化停工时间和操作上的复杂性,运行在EC2和VPC中的实例必须像是来自同一个网络。AWS没有提供分享安全群组的方法,也没有私有EC2和VPC网络的桥接。这两个私有网络通信的唯一方法是使用公共地址空间。

所以我们用Python开发了Neti—— 一个动态IP信息包过滤系统守护进程,由Hadoop的正式子项目ZooKeeper提供支持。Neti提供了安全群功能,并且为运行在EC2和VPC中的每一个实例提供单独地址。它管理着上千个本地NAT和每一个实例的过滤规则,允许使用独立的、平坦的"重叠"("overlay")地址空间进行安全通信。NAT规则在源实例和目标实例之间选择***效的路径。VPC和EC2之间的实例通信使用公共网络,内部通信使用私有网络。这对我们的应用和后端系统是透明的,因为Neti在每一个实例上应用了合适的IP信息包过滤系统。

构成Instagram栈的各式各样的组件从EC2到VPC环境的迁移不到三周,这让我们相信如果没有Neti,时间会长很多。在此过程中,没有出现过重大的服务停工,同时也让我们很快意识到这是有史以来最快的VPC规模迁移。

随着VPC迁移的完工,我们的实例运行在兼容的地址空间中,Instagram准备开始完成向Facebook数据中心的迁移。

一个围绕EC2构建的工具集已经存在多年,它管理着Instagram的产品系统,包括配置管理脚本,用来供应的Chef("大厨”),从应用部署到数据库master提升等广泛的操作任务使用的Fabric。这个工具集对EC2做出的假定在Facebook环境中已经不再适用。

为了让我们的供给工具更加轻便,Instagram特定的软件现在都运行在Facebook数据中心服务器上的一个Linux容器中(LXC)。Facebook供应工具用来构建基础系统,Chef运行在容器中安装并配置Instagram特定的软件。为了提供跨越EC2和Facebook数据中心的的基础设施,我们目前的Chef recipes("大厨配方“)就是否允许它们支持Facebook内部使用的CentOS平台一并支持在EC2中使用的Ubuntu的新逻辑展开争论。

用于基础任务的EC2特定命令行工具,例如枚举运行主机和Chef“knife"工具内的供给支持,被同一个工具替代。这个工具被设计成一个抽象层,向EC2中使用的工具提供相似的工作流,减少了人的压力,缓和了向新环境的技术过渡。

我们在工具和环境到位后的两周内完成了Instagram的产品基础设施从VPC到Facebook的数据中心的迁移。

这个分阶段的工作达到了工程开始时设定的主要目标,是一次巨大的成功。此外,在计划和执行迁移的阶段中,团队运送了接近两倍的诸如Instagram Direct的主要特性和我们的用户基数。我们恪守最小化改变的客观初衷,所以过渡对于我们的工程团队几乎是透明的。

回顾一下这个一年之久的工程的一些关键点(key takeaways):

  • 计划支持新环境的最小改变, 避免 “while we’re here.”的诱惑。

  • 有时,疯狂的想法是有用的——Neti是一个证明。

  • 投身于打造你的工具;执行这样的大规模迁移,你最需要的是出人意料的曲线球。 

  • 重用团队熟悉的概念和工作流以避免向团队掺杂通信改变的复杂。

这是多团队和诸多个体贡献者的通力协作。在接下来的几周,我们将提供这个迁移工作更深入的介绍,时刻关注这个空间。

英文原文:Migrating From AWS to FB

译文出自:http://www.oschina.net/translate/migrating-aws-fb

责任编辑:林师授 来源: 开源中国社区 编译
相关推荐

2015-11-25 10:52:25

AWSFacebook基础架构

2011-08-09 14:27:16

WindowsServ服务器ADDS

2019-03-20 09:00:00

MySQL数据库转移数据库

2015-03-20 13:40:17

2012-10-29 09:27:16

2012-11-12 14:22:17

Windows Ser

2020-05-25 07:00:58

Raspberry PWeb服务器

2012-04-10 09:18:06

2010-09-13 16:13:36

2019-04-05 16:44:39

2012-11-23 17:20:43

Linux服务器

2011-09-07 09:30:57

服务器虚拟机

2011-09-06 15:38:50

UbuntuUbuntu Serv

2018-08-21 10:35:18

NginxWeb服务器

2018-12-13 10:16:20

NginxWeb服务器

2014-03-06 09:23:19

Git服务器Github

2022-03-04 18:14:26

CentOSLinux

2020-03-31 09:22:05

软件x86鲲鹏

2010-07-29 13:11:37

2011-09-13 11:29:58

点赞
收藏

51CTO技术栈公众号