拍摄纸牌屋的Netflix为何要迁移数据库入云？
|
在新国家落地通常意味着会员数量的激增.我们也明白,为了确保数据中心不超载,还必须将现有的续订应用程序从数据中心搬入云中.因此对于通过云服务运行的6个新落地国家,我们编写了一个爬虫程序,可以每天一次遍历Cassandra中的所有客户,借此找出所有当天需要收费的会员. 这种“逐行迭代”的方法目前在这些国家很好用,但我们也清楚,在将其他国家,尤其是美国(目前我们的绝大部分会员都在美国)的数据迁移到云中之后这种方式将会失效.但我们想先行一步试试水有多深.这也是目前这一阶段唯一在云中运行的批处理应用程序. 为了能够在任何一个区域执行写操作,并将写操作快速复制到其他区域,我们选择用Cassandra作为数据存储.我们定义了一种数据模型,在其中使用customerId作为行,并创建了一系列复合的Cassandra列借此体现数据之间的关系性.下图展示了这些项之间的关系,以及我们是如何在Cassandra中使用单列族(Single column family)进行体现的.用单列族形式设计这样的关系使得我们能为相关项提供事务支持. 通过对应用程序的逻辑进行设计,只需要在任何操作开始执行时读取一次,随后即可在内存中更新对象,并在操作结束后将其以单列族的形式持久存储.在操作过程中读取或写入Cassandra的操作会被看作一种反模式(Anti-pattern).我们使用Astyanax(Netflix自行开发并已开源的Cassandra客户端)编写了自定义的ORM,这样就可以针对Cassandra读/写域对象. 我们通过这种方式将服务落地到新的国家,虽然遇到了几个小问题,但在迅速修复后整个系统运转很稳定.目前来说一切都挺不错的! 经过第1步工作后计费系统的体系结构如下图所示： 第2步 – 迁移所有应用程序,并将原有国家迁移至云中第1步成功完成后,我们开始考虑在不迁移数据库的情况下将其他应用迁至云中.大部分业务逻辑位于批处理应用程序中,多年来已经发展得极为成熟,但这也意味着必须深入到每个条件的代码中并花费大量时间重写.这些应用程序无法“照原样”直接搬到云中运行. 同时我们也借助这次机会尽量移除了所有不再使用的代码,将不同功能拆分为多个专用的小应用程序,并为了更好的扩展性重构了现有代码.这些遗留应用程序被我们设计为会在启动时读取磁盘上的配置文件,并使用了其他一些静态资源,例如从Weblogic队列读取消息,由于实例与生俱来的“短暂”本质,这些特征在云环境中都是反模式的. 因此为了让应用程序在云平台上顺利运行,只能重新实现这些模块.为了通过异步模式将消息穿过队列移动到不同区域,我们还更改了一些API,并在这些区域建立了到数据中心的安全连接. 云数据库工程团队为我们的数据需求搭建了多节点Cassandra集群.我们也清楚,在将所有Netflix会员的计费数据迁移到Cassandra之后,以前用来为最早的6个国家的客户提供续订服务所用的“全行(Row)式”Cassandra迭代器续订解决方案将无法很好地伸缩. 因此我们使用Aegisthus设计了一个系统,可从Cassandra SSTable拉取数据并将其转换为JSON格式的行,将其暂存在S3 Bucket中.随后我们写了一些Pig脚本,借此每天针对大量数据集运行Mapreduce作业,找出需要续订的客户清单并向他们收费. 我们还写了Sqoop作业以便从Cassandra和Oracle中拉取数据,并将其以可查询格式写入Hive,这样就可以将这两套数据集汇总至Hive,实现更快速的排错. 为了让DVD服务器能够连接云环境,我们为DVD设置了负载平衡端点(包含SSL客户端证书),DVD服务器可以通过云代理对所有调用进行路由,在迁移美国系统之前可以借此将调用重新发回数据中心.美国系统的数据迁移完成后,即可断开云和数据中心之间的通信链路. 为了对这一大规模数据迁移的结果进行验证,我们编写了对已迁往云中的数据,以及数据中心内部现有数据进行比较和验证的对比工具.反复运行该对比工具可找出迁移过程中可能存在的Bug,修复发现的问题,清理数据并再次运行. 随着运行结果愈发整洁,完全没有出现任何错误,这也进一步增强了我们对数据迁移工作的信心.对于针对各国数据进行的迁移工作我们感到十分激动.最开始我们选择了一个Netflix会员数量比较少的国家,并通过下列步骤将数据迁入云中：
在确认一切正常后开始迁移下一个国家.随后我们开始突击对所有类似国家一起进行迁移.最后迁移的是美国,因为美国的会员数量最多,并且还提供有DVD订阅服务.至此所有面向Netflix会员客户的数据都已通过云环境提供.对我们来说这是一个巨大的里程碑! 经过第2步工作后,我们的体系结构如下图所示： 第3步 – 再见,数据中心!至此还有最后(并且最重要)的一件事：数据中心内运行的Oracle数据库.Oracle中存储的数据集具有高度的关系性,我们觉得这些数据并不适合以NoSQL的方式进行建模. 这种数据不能像以前处理面向客户的订阅数据那样构造为单列族的形式,因此我们评估了Oracle和Aurora RDS这两种选项.但Oracle作为云数据库运行的许可成本,以及Aurora依然是Beta测试版这一现状使得则两种方式都不适合我们. 在计费团队忙于执行前两个步骤时,我们的云数据库工程团队正在创建用于将计费数据迁移至EC2上MySQL实例所需的基础结构.在开始执行第三步操作时,在他们的帮助下数据库基础结构部分已经就绪. 因为一些应用程序使用了不包含任何ORM的纯JDBC,我们还需要将批处理应用程序的代码基转换为兼容MySQL的格式.另外我们处理了大量遗留的Pl-sql代码,并重写了应用程序中的逻辑,同时尽可能去除了不再使用的代码. （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |