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 的这一步都是一个最大的经验教训。
▲ 部分迁移团队成员，左起依次是 Pedro Canahuati、Patrick Bozeman、Rick Branson、Nick Shortway、Chris Bray 和 Michael Gorven，（照片：Ariel Zambelich/WIRED）
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 等资源统一调度和部署管理工具的成熟，应用的迁移也会变得像即插即用一样的容易。
[本文编译自：wired.com]
