部分迁移团队成员，左起依次是 Pedro Canahuati、Patrick Bozeman、Rick Branson、Nick Shortway、Chris Bray 和 Michael Gorven，照片：Ariel Zambelich/WIRED
Instagram 有 2 亿用户，上面保留有用户分享的 200 亿张照片。从 2010 年到今年春之前，这些照片一直存放在 Amazon 的 EC2（弹性计算云）上，但现在这些照片已经被 Instagram 的一只小型团队搬到了收购了他们的 Facebook 的数据中心上，但 2 亿用户对此却毫不知情，仿佛什么事情都没发生过一样。他们是怎么做到的呢？
Facebook 是在以 10 亿美元收购 Instagram 1 年后的 2013 年 4 月作出迁移决定的。整个迁移过程用时大约 1 年。尽管迁移工作量巨大，但实施迁移工作的却是一支非常小规模的团队，迁移开始时 Instagram 的维护团队只有 8 人，后来才逐步扩张到 20 人。实际的数据迁移工作只用的 1 个月时间，其余的时间完全都是用于迁移的准备工作。
搬迁工作的第一步，是要在 Facebook 的数据中心建立一套一模一样的软件。然后再把数据迁移过去。当然，这个过程要比你想象的要困难。在 Facebook 这一侧开通 Instagram 的照片共享服务之前，需要首先将 Instagram 搬迁至 Amazon 云的另一部分。换句话说，得搬两次。
第一次搬家是将服务从 Amazon EC2 搬迁至 Amazon 的虚拟私有云 VPC。通过 VPC，迁移小组可以建立起一个可拓展至 Amazon 以外地方（即 Facebook 数据中心）的逻辑网络。这一步很重要，因为 Facebook 可以对运行 Instagram 的机器的 IP 地址拥有完全控制权。而只有这样，在进行软件迁移时才不会出现无数的地址冲突问题。
但是，要想把 Instagram 从 EC2 搬到 VPC，首先还必须在两者之间搭建一个公用的网络。Amazon 本身没有提供这样的工具，因此为了暂时解决这个问题，Facebook 自己开发了一套网络工具 Neti。这一点说明了云计算的复杂性，对于任何想要跨云服务搭建自己应用的人来说，Facebook 的这一步都是一个最大的经验教训。
Instagram 一开始没有用 VPC 是因为 2010 年的时候 VPC 还没有出来。因此，现在的初创企业要是一开始就未雨绸缪的话，可以考虑在 VPC 上做自己的应用，这样就能省下这一步迁移工作。而且对于只想把部分设施搬迁到私有数据中心的人来说，用 VPC 也是明智之选。
而接下来的软件迁移工作，他们得靠一款越来越火配置管理软件—Chef。Chef 可以为软件 / 应用在大规模机器上的加载和配置编写出自动化的“食谱（recipes 或 cookbooks）”。比方说这种食谱可以自动把适当的软件加载在运行于 Amazon VPC 的机器上。然后，团队可以利用类似的食谱在 Facebook 数据中心内部的机器上加载相同的软件。为此，迁移小组编写了专门用于在各种 Instragram 数据库服务器上安装软件的食谱，然后又制作了用于配置缓存服务器（缓存服务器的用途是加速热门照片的提供）的食谱。
如此，到了 2014 年的 4 月，最后一部分的软件和数据也迁移到 Facebook 的数据中心上了。迁移后的 Instagram 效率是原来的 3 倍，而且数据提取时间减少了 80%。
此次搬迁的意义，对于 Instagram 来说，可以使用 Facebook 的计算工具，对于运营数据中心的工程师来说，此次搬迁是一个模板，也为广大的在云服务至上搭建 app 的技术社区提供了一个从公有云向私有云迁移的范例。
当然，Facebook 的迁移动作说到底只是相对少数。因为，对于大多数的中小企业来说，向公有云迁移才是大势。像 Facebook 这样将服务从公有云搬迁到自己私有云的只有财大气粗者才会这么做。我们也相信，随着 Docker、Mesosphere 等资源统一调度和部署管理工具的成熟，应用的迁移也会变得像即插即用一样的容易。
相关文章
