2019 LINE Dev Day 議程心得 Part2

前言

昨天主要分享 LINE Dev Day 當天開場的 Keynote 內容，而今天將針對我最想要了解的 Infrastructure & Cloud Native 議程來分享，因為自己在這方面技術比較有著墨，因此想一探究竟 LINE 團隊是如何建構這麼大規模的平台，也非常想了解他們在技術選型時，是如何考量，而當遇到問題時，又是如何去解決，以支撐這麼大量的服務與系統營運。

今天將先焦距在 LINE Verda Team 的私有雲部分，會以其私有雲部門主管 Yuki 桑的 Cloud Native Challenges in Private Cloud with K8s, Knative 議題來切入。

議程心得

本次 LINE 特別將 Infrastructure 作為重點放入 Keynote 分享，原因正是大多數 LINE 的服務與系統，都是由自家私有雲 Verda 所支撐，而其基礎建設 Verda Team 正是負責這項重責大任的團隊，因此可以看到關於 Infrastructure & Cloud Native 都是來自該團隊。

首先分享這個議題是因為該講者是 Verda Team 的私有雲主管 Yuki 桑，Yuki 在過去非常活躍於技術社區，尤其是在 OpenStack Summit 與 Cloud Native Forum 都有他分享技術的足跡，而 LINE 的許多系統會如此茁壯，很多也是歸功於他與團隊的技術選擇，他這次從私有雲上的挑戰來說明為何選擇 Cloud Native 技術，他們又該如何解決遇到問題與貧頸。

目前 Verda Team 維護著整個 IaaS、PaaS 上的所有服務，如下圖所示:

可以看出 LINE 許多服務都是自己實現與建制，而這些功能很多都建構在 OpenStack 之上，因此他們擁有很高的擴展性與可客製化性，這是由於 OpenStack 架構能夠讓人選擇樣安裝哪些元件來提供哪些服務功能，如 Nova 提供 VM、Cinder 提供 Block Storage 與 Neutron 提供 Networking 等等，而也能聽到 LINE 在這之上又提供了各種服務，如 DBaaS(Database as a Service)、VKS(Verda Container Service)、FaaS(Function as a Service) 等等。而為何要擁有這麼多元的功能與需求呢?這是因為 LINE 從去年六月開始快速的成長，有越來越多的服務與系統需要被執行，更有越來越的團隊需要開發與測試用環境，因此面臨如此挑戰。

那麼面對這樣的需求，LINE 是如何去解決的呢?

沒錯!就是他們擁抱 Cloud Native 相關技術。從 Yuki 標註的段落，可以了解 Cloud Native 旨在採用容器、服務網格(Service Mesh)、微服務、不可變基礎建設、宣告式 API 等等，來有助在雲端環境中，建構與執行彈性與可擴展的應用。且這些技術還擁有著良好的容錯性、易管理與松耦合系統等等特點，因此結合可靠自動化，將使工程師(系統管理員)能夠對當前系統做出頻繁與可預測的重大變更。

有種簡單說就是盡可能用 Kubernetes 來降低服務維運與運行的困難性，畢竟對於 CNCF 來說 Cloud Native 定義的本質，很多都是再講 Kubernetes 本身。

當導入 Cloud Native 時，可以讓他們更有效的控管不同團隊的資源狀況，而另外 Yuki 也說到未導入 Cloud Native 的服務開發遇到的問題，可以看到 LINE 很多專案的服務會開很多 VM 執行不同事情，比如說有些做為主服務執行用、有些執行週期性工作或者執行操作腳本等等，因為執行這些事情的都是 Application Engineers 在進行，因此無從得知哪些 VM 在幹什麼，又或者有沒有在使用，因此造成嚴重的資源浪費，像是這邊就提到他們有 60% 的機器 CPU 使用率落在 10% 左右。而為了解決這問題才導入 Cloud Native 來提升在服務開發週期中，能夠控管的資源範圍。

而他們究竟是怎麼解決的呢?實際上，Verda Team 實現了一個 Computing Resources 抽象層，用於描述應用被部署的形式，這樣 Infra Engineers 就可以識別哪些 VM 被執行哪種形式的程式，因此能夠對此做出資源的調整，這解決之前不知道資源狀況的問題，因此導致無法隨意調整 VM 資源。

另外 Yuki 也提到目前他們正在實現的新方式，就是採用 Kubernetes 與 Knative 來取代之前 VM 的形式，由於腳本服務，通常不太需要過多的資源來支撐，因此能夠以 Function 形式在容器中執行，除了有效的利用資源以外，更加快了交付的時間。

而 LINE 的 Kubernetes as a Service 主要基於 Rancher 實現而成，他們實現了一套 Verda APIs 用於管理多個 Kubernetes 叢集，一但有人呼叫建立叢集時，就以 Rancher 來自動化部屬 Kubernetes 叢集，而當發生不同叢集事件時，也會即時收到並執行 Rancher API 來解決對應問題，比如說節點掛了，就透過 Rancher 來開新節點，並取代掉。

這邊可能使用 Rancher 的 OpenStack Driver 在 IaaS 上面部署 Kubernetes 叢集。

而另外透過開發的 Add-on Manager 來維護與管理 Monitoring、Logging 等額外功能。

這邊目前 LINE 都是選用社區典型的工具，像是 Monitoring 使用 Prometheus + Grafana，而 Logging 則用 Elasticsearch + Fluentd + Kibana 來達成。

接著 Yuki 提到為何使用 Knative，這除了減少透過 VM 執行腳本作業問題外，也想用 Knative 的 Eventing 與 Function 功能來達到各種事件與執行程序的連動，比如說某台 VM CPU 快用滿了，就觸發一個 Function 來傳遞資訊到 Slack 上，已通知大家。

從這些內容來看，可以很明顯發現 LINE Infra 團隊正在努力地提升資源的利用率，以 Cloud Native 來確保不必要的資源浪費。

最後 Yuki 桑給出了他們希望提供的 Kubernetes 架構，我想這也是許多人常問的問題，到底是要用多叢集來區分服務，還是大叢集以 Namespace 切分服務?

我想這還是要依據應用情境來區別，因為每家公司對於服務分離的要求性不同。但是在 LINE 的服務有太多種了，因此兩者在他們部署情境是都會發生的。

結語

雖然這次到 LINE Dev Day 聽到這場非常類似 Cloud Native Forum 講的內容，但這是比較像是概觀與未來展望，因此沒有太多細節內容，不過扔然讓人感受到 LINE 團隊對於技術的選擇與發展，是真的很勇於嘗試，想想 Knative 剛出現也不就一年時間，他們已經開始在內部系統採用，真的讓人很佩服。

這邊想了解更多 LINE Verda 私有雲細節的話，可以看看 Yuki 桑在 Cloud Native Forum 分享的 Managed Kubernetes Cluster Service In Private Cloud 議程。

而除了 Yuki 桑的議題外，也有幾場關於 Cloud Native 議程，分別為以下，大家有興趣也可以看簡報了解:

• gRPC service development in private Kubernetes cluster
• Implementation of service mesh using Envoy and Central Dogma

Reference

• https://www.techbang.com/posts/73284-lines-first-expansion-will-be-held-on-november-20th-and-21st-for-two-day-line-developer-day-2019
• https://www.inside.com.tw/article/18162-line-dev-day