手机版
你好,游客 登录 注册 搜索
背景:
阅读新闻

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

[日期:2014-09-26] 来源:oschina.net  作者:鑫鑫鑫 [字体: ]

当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是一个证明。

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

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

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

本文永久更新链接地址http://www.linuxidc.com/Linux/2014-09/107226.htm

linux
相关资讯       Facebook  AWS  Instagram 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款