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發展的關鍵。

 相關報導  LINE全面進攻AI


Advertisement

更多 iThome相關內容