【拥抱K8s、微服务和通用资料平台新架构】AI转型也得换体质LINE资料平台和IT架构双双大翻新

2021-02-16 06:03:40 来源：用户：

LINE打造了一个资料特徵服务（Feature as a Service）架构，将原始内容转换成不同特徵的向量数值，并且利用了混淆工程技术，来进行去识别化处理之后，才提供给ML团队进行分析之用。图片来源／LINE

从2017年全力冲刺AI转型之际，LINE也展开了IT体质的大改造。一来将发展多年的私有云Verda升级，不只引进Kubernetes和Knative，来发展云端原生架构的资源调度弹性，另外，LINE也展开了100PB大数据资料各丛集的整併工作，并开始打造新的资料工程平台资料特徵服务化（Feature as a Service），将资料去识别化变成基础预设功能，来兼顾隐私和庞大资料量分析的需求。LINE在东京开发者大会上，也揭露了这两大技术体质改造工程的细节。

强制改用云端原生架构，导Rancher让K8s维运管理自动化

LINE很早就用OpenStack建置了一朵私有云称为Verda，但随着LINE各式各样的服务快速成长，对于VM的需求也越来越大，今年6月时所承载的VM数达到3万5千个之多，其中光是过去一年就增加了2万个VM的需求。

在LINE原本的开发流程中，从AP的开发、部署到维运，都可以由AP工程师完成，唯有私云运算资源的準备，则由私有云服务自动调度。但是，LINE现有4千个专案，每个专案每次需要的运算资源规模大小不一，有些只是要执行一小段脚本程式，但还是得呼叫一个VM来执行，导致Verda中有6成伺服器的CPU利用率低于10％，仍有9成闲置算力，相当的浪费。

后来，维运团队决定导入Kubernetes，要求AP工程师，必须改採云端原生架构，将每一支AP的需求，都建立在AP配置描述档中，而运算需求较低的脚本程式，则改用Knative来提供无伺服器服务，让一个VM可以执行更多脚本程式，而不是每支脚本程式就占用一个VM。

LINE Verda平台开发团队经理Yuki Nishiwaki表示，连私云都强制要求採用云端原生架构有两大好处，AP工程师不用再担心基础架构的管理，而维运团队也不需要与AP工程师沟通了解所需资源的细节，才能进行优化调度。

LINE採用了Rancher来进行跨丛集的维运自动化管理，包括部署、更新和监控作业都可以自动化。目前只需要5个人就足以管理130个丛集的2千个节点。

不过，目前只能提供基础的运算需求调度，例如简单的HA丛集、外挂管理、维运自动化。LINE下一步，不只要支援更多种外挂，还希望可以开始考虑到AP效能来调度资源。

自行开发微服务框架，强化非同步通讯能力

除了改造基础架构资源来提高调度弹性之外，在应用程式架构上，LINE Messenger原本就按AP的特徵（Feature）来开发各自的专用、简单的App伺服器，方便扩充之用，例如授权机制有6支服务，贴图小舖有超过20个服务，LINE@帐号或Bot后端更有超过40支微服务，但几年发展下来，变成了一套庞大的微服务架构。目前LINE微服务架构上已有超过2,500个微服务。

採用微服务架构的好处是，可以加快开发速度，减少各服务间的功能冲突，但缺点是网路失效的频率增加了，服务配置档的管理複杂度越来越高，甚至潜在雪崩式错误的风险也越来越高，光是贴图小舖的微服务，就需要25个人力来管理。

负责LINE Messenger微服务架构的LINE Z部门团队成员Masahiro Ide指出，现有庞大複杂的微服务架构，需要增加三大功能，强化网路连接性、建立目录服务和强化路由能力。

后来，LINE决定自己打造微服务框架，称为Armeria，设计了自己的RPC分层架构，可提供非同步的RPC层通讯需求，也将基础通用功能，变成微服务框架的预设功能，来简化重複建置的工作，如Logging、用户端负载平衡、监控整合、追蹤、重试机制、健康检查等。另外，还针对文字类配置档，如JSON、YAML、XML，打造了一个储存库服务Central Dogma，可提供高可用性、版本控制和进阶查询机制，来强化配置档的管理，将这两项技术，与LINE自己用Erlang打造的事件派送闸道器LEGY（Line Event Delivery Gateway）搭配使用。LINE也将Armeria和Central Dogma两项技术开源释出。有了这两大武器之后，下一步，LINE就準备进一步细分拆解现有的微服务架构，从「按特徵拆解」细化到更小颗粒度的「按功能拆解」来设计新的微服务架构。

两阶段用丛集邦联串接庞大Hadoop丛集

除了基础架构体质改善之外，LINE的另一个大改造工程是资料基础架构。因为採取隐私优先政策，每一件与资料相关的事件，都需要进行隐私、安全的审查，但是跨不同子公司、不同系统的资料运用方式非常複杂，再加上LINE的资料量非常庞大，光是LINE Messenger一天的讯息就高达1兆笔，每天新增的资料就算压缩后仍多达390TB，各种资料处理查询任务，一天也高达7万个。其他服务的资料再加总起来的量更是庞大，如何兼顾隐私权和大量资料的挑战，Verda部门主管Yoshihiro Saegusa指出，有三大问题要解决，包括了资料可用性（Accessibility）、多人使用管理（Multi-tenancy）和资料品质（Data Quality）。

LINE的策略不是把现有的大数据丛集全部打掉重建，而是将几个主要丛集连结起来，建立了一个共用流程，透过单一登入服务，来控制谁可以使用哪些资料，让跨服务的工程师，就可以用到其他服务产生的资料。

更进一步来看，LINE用Hadoop来储存多达100PB的异质资料，包括了资料库、原始Log、前端Log、伺服器Log等资料。总共有超过10个丛集，节点总数达到2千个，其中最大一个丛集，甚至多达1,200个节点。LINE没有採取，先建立一个超大新丛集，再搬迁所有资料的作法，也不是直接对所有丛集进行整併，前者得準备一倍的伺服器，成本太高，后者不同Hadoop丛集所用的版本甚至不一样，直接整併丛集的複杂度太高，资料损失的风险也太大。

后来，LINE的作法是，先挑出几个重要的大型Hadoop丛集，将其他小型、次要的Hadoop丛集，整併到这几个大丛集中，再透过Hadoop的Cluster Federation功能，来建立跨丛集的通用管理层，并且透过单一个YARN资源管理系统，来管理这些串连后的Hadoop丛集。

建立资料特徵服务架构，用混淆工程去识别化来保护隐私

另外，LINE还将资料分成两大类，一种是原始资料，另一种是经过特徵抽取的资料，LINE打造了一个资料特徵服务（Feature as a Service）架构，先透过第一层的ETL工具梳理资料来减量，再透过特徵工程技术，将内容转换成不同特徵的向量数值，再结合用户行为和内容特徵，就会变成了用户个人的使用特徵Y Feature，并且利用了混淆工程技术，来进行去识别化处理。

因此，就算是跨团队的工程师拿到了一批资料，他们都无法知道用户真实是资料是什么，资料工程师只会看到一笔笔转换过后的特徵向量数据，各自对应着不同的内容类型或行为特徵的强度。

「透过这样的技术，就可以同时解决隐私和资料量的问题。」LINE台湾资深技术总监陈鸿嘉强调，不论是哪一种资料分析，都需做到合法、合情和合理才能用。IT基础架构和资料架构的体质大改造工程，正是LINE可以安心冲刺AI发展的关键。