BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Evernote从自有数据中心到Google云的迁移-第1篇

| 作者 薛命灯 关注 24 他的粉丝 发布于 2017年3月31日. 估计阅读时间: 10 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

2016年底,Evernote对他们的服务进行了一次大规模的迁移。他们将Evernote服务从自有数据中心迁移到了Google Cloud Platform上。他们在短短的70天内完成了整个迁移过程,包括Evernote服务、存储数据和其他配套服务。参与这次迁移的工程师们在Evernote官方博客上分享了这次迁移的过程。文章包含了5个部分。以下译文已获得翻译授权。

第一部分:Evernote服务和迁移到Google云平台的可选方案

Evernote服务在2008年开始投入使用,我们一直维护着自己的服务器和网络。我们有很大的自由度来构建服务,但同时也面临着一些挑战:伸缩困难、升级缓慢、高昂的维护成本。虽然我们的基础设施在过去为Evernote提供了很好的支持,但在未来,我们需要更快的速度和更大的灵活性,而这些正是目前的基础设施所缺乏的。

迁移到公有云这一决定让Evernote的每一位员工都兴奋不已。在首次发布迁移声明之后,我们便在幕后启动了从物理数据中心到Google云平台(GCP)的迁移工作。经过70天日以继夜的奋战,我们完成了迁移。

可能有些人想了解我们的迁移过程,又或者想进行类似的迁移,所以我们决定把迁移过程分享出来。我们会告诉大家在迁移过程中我们都做了哪些事情,以及如何能够快速地完成迁移。这不是一个完整的迁移手册,不过它涵盖了我们做出的所有关键决策,以及我们是如何实现它们的。

先让我们来了解一下Evernote服务的概况。

Evernote服务

我们的服务由以下几个组件组成。

分片(NoteStore)

分片是Evernote服务的核心单元,用于存储用户的笔记。每个分片最多可以支撑30万个Evernote用户,并包含了如下几个组件。

  • 基于Tomcat的前端Web服务层:Evernote客户端会连接到这个层。
  • 数据存储层:用于存储用户笔记的MySQL数据库。
  • 搜索索引:基于Lucene的服务端搜索索引,用于搜索用户的笔记内容。

我们总共有762个分片,存储着2亿个用户账号和大约50亿个用户笔记。

UserStore

UserStore使用MySQL数据库来存储用户信息,包括他们的认证信息。因为数据库管理着所有用户的状态和认证信息,所以它是最为关键也是最为复杂的一个组件,在迁移过程中我们需要格外小心。

用户附件存储(资源)

我们有一个单独的文件存储层,用于存储50亿个用户附件(我们把这些附件称为资源)。这个层由206个自包含的WebDav服务器组成。每个用户附件有三个副本,其中两个分别被保存到本地的两个不同的WebDev服务器上,另外一个被发送到远程灾备数据中心的WebDav服务器上。

前端负载均衡

我们的高可用负载均衡器集群负责将用户请求路由到特定的分片上。

配套服务

我们还有200多台Linux服务器用于缓存和执行批处理任务,比如笔迹识别和文本识别。

我们的迁移可选方案

Evernote服务规模庞大,向云端迁移是一项复杂的工程,我们需要作出很多与依赖项有关的决策。我们希望能够尽快完成迁移,所以我们为关键性决策制定了一个草案。

我们要先理清楚需要做出哪些变更。我们知道,有些组件无法直接被简单地迁移到云端,所以我们把组件分为两类。

  • 转移:有些组件在CGP上能够找到几乎一样的替代品,分片、UserStore以及大部分配套服务都属于这一类。在我们的物理数据中心,这些组件都是基于Linux的,所以我们将会直接把它们迁移到云端的Linux虚拟机上。
  • 转换:在迁移过程中需要对用户附件存储、负载均衡层和识别服务(Reco)做一些重大的转换。对于这些组件来说,要么在云端找不到相应的替代方案,要么云端已经存在更好的替代方案。

迁移方法

接下来我们要开始计划如何进行迁移,我们有两种选择。

  • 一次性迁移:迁移项目里存在着一个分界点,跨过这个分界点就等于完成了100%的切换。对于自有数据中心和采用了单体架构的组织来说,这种方式会更适合(这或许也是唯一可行的方案)。
  • 阶段性迁移:这是一种分而治之的方法,根据类型或用户将服务分组,进行阶段性的迁移。采用这种方式可以在提交阶段性工作之前对其进行测试和验证。

从我们的情况来看,一次性迁移的方案并不适合我们。即使做了详尽的计划,一次性迁移完所有的组件仍然存在很大的风险。况且,我们的应用并非为多站点运行而设计的,尽管我们的环境在很早之前就已经支持多站点运行。

所以,我们需要在上述的两种极端之间找到一个折衷的方案,我们决定采取“增速阶段性切换”的方案。整个迁移过程要在短短的20天内完成,它包含了多个阶段,每个阶段的风险需要被降到最低。如果某些阶段的工作无法达到预期的效果,可以进行回滚。

第二部分:保护GCP上的用户数据

我们的安全团队负责保护用户数据的安全。在向云端迁移的过程中,我们要考虑如何保证用户数据的安全。我们面临两个主要的问题。

  1. 我们即将把数据交由Google来看管,他们是否拥有足够成熟的安控措施,能够避免给我们的服务带来新的风险?
  2. GCP是否提供了等价的或者更好的安控措施来保证数据的安全?
厂商信任

我们内部有一个厂商审查流程,由我们的法律团队和安全团队共同执行这个流程。我们在与新的服务提供商展开合作之前,会对相关的隐私和安全问题进行审查。

在厂商审查过程中,我们会检查60多项与隐私和安全有关的问题。这些内容与我们内部程序的结构保持一致,通过这些审查,我们就可以知道厂商是否符合我们的预期。审查内容可以被分为几类。

  • 组织层面的控制措施
  • 基础设施的安全
  • 产品安全
  • 物理设施安全
  • 与隐私有关的数据使用

我们和Google一起对他们的审计报告进行了评审,发现他们在各个方面都能够满足我们的预期。

接下来,我们将注意力放在他们是否提供了用于保护用户数据安全的安控措施上。

云安全控制措施

首先,我们对现有的所有用于保护用户数据的安全措施进行了评审。这些安控措施包括使用了双因子认证的远程访问VPN和提供了流量过滤功能的防火墙。还有其他一些物理安控措施,比如物理外围、生物技术认证、探头,以及用于防止物理数据被盗的警报系统。我们在安全主页上有很多关于基础设施安全防护的讨论。

我们列出了一个表格,记录了迁移过程中需要注意的安全问题,下面是一些主要内容。

  • 外围网络安全(向内流量和向外流量过滤)
  • 内部隔离
  • 多因子认证
  • 传输加密
  • 缺陷管理
  • 身份信息和访问控制
  • 诊断日志
  • 入侵检测
  • 变更监控

我们还需要考虑多租户云环境可能会出现新的威胁模型。内存和存储的使用方式与过去也不一样。我们还要考虑来自其他用户的威胁,这些用户与我们处在同一虚拟层上。好在Google已经考虑到了这些问题,他们在博客上就如何解决这些问题进行过讨论。

我们在GCP上为我们的大部分安控措施找到了等价的替代方案。我们还为静态数据加密找到了一种更好的替代方案。而对于其他一些安控措施,比如IP白名单,我们只能通过改造我们的架构,让它不再依赖传统的网络安控。我们使用包含了Google托管密钥的CGP服务账号来实现这一改造。

如何安全地使用GCP服务账号

迁移到云平台之后,原先的静态CIDR块被静态公共IP和动态公共IP的混合体所替代。维护IP白名单的成本非常高,而且在CGP的其他服务里并不存在这样的功能。

在我们的安控架构里,网络和用户数据之间包含至少两个安全层。内部服务全部被部署在一个安全的网络外围里,服务之间通过API密钥进行交互。我们以一种安全的方式来存储和分发这些密钥,不过仍然存在泄露或被盗的风险。如果真的发生泄露或被盗,我们还有第二个安全层。在我们的生产环境之外,秘钥失去了它们的作用,而要想进入生产环境使用这些秘钥,必须先通过双因子认证。

每一个GCP服务都是互联网服务,它们并没有提供面向用户的白名单安控机制用于访问Google计算引擎(GCE)项目里的主机。我们需要在密钥和用户数据之间添加另一个安全层。

我们使用GCP服务账号解决了这个问题。每个GCE项目都有一个默认的服务账号,在GCE中启动的实例可以通过这个账号来访问其他服务。Google提供了一组公钥/私钥对,密钥对每24小时自动翻转一次。对于自定义的服务账号,也会执行相同的操作。我们可以为每个主机角色创建一个自定义服务账号,并通过配置虚拟实例来使用这些账号。现在,那些运行在这些虚拟实例上的应用就可以使用内置的Google托管密钥。

我们的运维工程师没有必要访问这些密钥,因为Google每天都会自动翻转这些密钥。要想访问到这些密钥只能通过渗透我们的基础设施,不过我们目前已经具备了相应的防护能力。

总的来说,我们对云平台的安全充满了信心。我们还会继续加强平台的安全,把不断变化的安全威胁甩在身后。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT