2019 LINE Dev Day 議程心得 Part3

前言

昨天分享了 LINE Infrastructure 團隊為何導入 Cloud Native 的原因，從中可以看出 LINE 面臨服務開發的資源需求快速增長問題，因此必須更加有效的利用資料中心的資源，而 Cloud Native 的導入對他們來說是個關鍵點，利用容器、服務網格(Service Mesh)、微服務、不可變基礎建設、宣告式 API 等等技術與概念來提升交付時間，並更加有效的利用與控管資源。然而 LINE Infrastructure 團隊不僅僅只是導入 Cloud Native 技術來解決面臨問題，在不同層面上也有非常多的著墨，如網路與儲存這種基礎建設最關鍵的部分也考慮的很多，且服務團隊也會基於應用選用 Cloud Native 專案來達到需求。

今天就是要針對 gRPC service development in private Kubernetes cluster 這個議程來分享心得，該議程講者是 LINE Live 成員，他們為了服務能支撐直播高峰值的問題，因此導入了 Kubernetes 與 Envoy。

議程心得

這個議程主要分享 LINE Live 團隊為何使用 Kubernetes 的原因，大體上 LINE Live 團隊需要一個辦法，來因應直播服務的流量峰值變化，因此需要擁有能快速 Scale In/Out 的能力，然而過去他們都服務都執行於 VM 之上，並且採用手動方式來進行擴展，比如說開個 VM 實例，然後用 Ansible 跑腳本來部署等等流程，而這樣過程無法應付瞬間爆量的狀況，因為 VM 交付與應用部署時間過久，因此導致無法快速達到需求。有鑒於上述問題，LIEN Live 團隊才選擇使用 Kubernetes 作為服務運行的平台。

從當天聽到的內容，可以了解 LINE Verda 團隊會提供自研的 VKS(Verda Kubernetes Service) 平台，來讓 Service 團隊自助部署基於 OpenStack 之上的 Kubernetes 叢集，當 Service 團隊需要更多資源時，就可以以 VKS 來快速增減節點，或是利用 Kubernetes Deployment 特性來建立多個副本以支撐流量等等。

接著講者介紹到團隊的服務架構，他們為了確保溝通的請求率，而以 gRPC 作為服務溝通的協定，更利用 Envoy 來協助轉換不同協定成 gRPC。

這邊有趣的是他們在 Mobile App 與服務交互時，採用了非常多層的 Load Balancer，像是 Mobile App 經由網際網路跟 LB 溝通時，會接著經由 Kubernetes NodePort 方式轉發到各節點上(這邊可能是 Envoy 的 Kubernetes Service)，然後再透過 Envoy 以 DNS 輪詢方式(利用 Headless service 來發現所有 Pod IP)轉發到 Spring 服務上。

其實我覺得 NodePort 那一段怪怪的…。

而由於他們內部服務有很多是 gRPC 協定在溝通，但如果以 Kubernetes Service(kube-proxy) 作為彼此路由的話，將會因為其是 TCP/IP(L4) LB 的關析，而無法達到 gPRC/HTTP2 協定的好處。因為這樣只能讓 gRPC 在每次建立連線時，有負載平衡效果，而之後每次 RPC 請求都保持原本連線，並跑到同一個 Pod 上。所以 LINE Live 團隊才會選擇 Envoy 來達到每次 RPC 請求都根據我們策略路由到合適 Pod 上。

而另外他們提到不使用 Istio 是因為 Spring 已經擁有一些相同功能，因此不需要用到整個 Istio 方案，只需要 Envoy 來處理 gPRC 轉發與轉換。至於效能問題，是他們無法容忍使用 Istio 帶來的延遲增加問題，因為他們是直播類型，所以延遲過高會影響服務品質。

關於 Istio 效能可以參考這篇 Performance and Scalability

接著講者提到 Kubernetes Pod 存取 MySQL 的 ACL 問題，因為過去無法應付 Cluster autoscaler 長出來的新節點，因此導致該節點上的 Pod 都會被阻擋存取，所以 LINE 團隊開發了一個 ACL Manager 來動態更新。基本上 ACL Manager 就是去觀察連接 DB 的 Pod 座落在哪些節點上，然後在動態調整 MySQL ACL

而在 Monitoring 部分，他們採用 Verda Team 提供的 Add-ons Manager 來部署 Prometheus，該 Prometheus 以 StatefulSet 形式運行在當前 Kubernetes 叢集中(這是目前典型的做法)，而不是透過外部 Prometheus 方式來拉取 Metrics，增加了叢集的安全性。當然這樣做法還是要依據應用來進行，並且要很好的規劃叢集節點的角色，若沒定義好相對的 Affinity 的話，就可能影響到正式服務的容器。

另外他們覺得用 Kubernetes 的 Persistent Volume 來儲存 Prometheus TSDB 很難使用，因此透過 Remote storage 來跟自家開發的 TSDB - Flash 整合。至於在視覺化部分，就是採用 Grafana 來處理 Prometheus 資料。

在 Spring 應用部分，Metrics 會透過 Spring Boot Actuator 與 OpenCensus 來提取，其中 OpenCensus 還能用於對 Metrics 進行分散式追蹤(Distributed tracing)，以確保團隊在遇到問題時，能更快的解決，甚至是提前預防問題發生。

最後部分講者分享了該團隊的 Logging 系統，可以看出類似 Monitoring 一樣直接採用 Verda Team 提供的 Add-ons 形式部署 EFK(Fluentd, Elasticsearch and Kibana) stack 架構在 Kubernetes 叢集上來收集 Logs，另外透過 IMON 來實現 Log 的告警。

結語

從這個議程可以看出來 LINE 在技術採納並不是隨便就使用，完全是對症下藥。另外 LINE 團隊在 Monitoring 跟 Logging 的軟體選擇都是目前 Kubernetes 社區典型部署方案，雖然在一些細節可能有額外開發東西，但是不難看出公司採納的架構比較偏向社區方案，或許是希望藉由社區的力量來加快平台的迭代，一方面也利用社區貢獻者力量來解決遇到問題吧。

總之 LINE 團隊正在全面導入 Cloud Native 技術，利用這些技術來解決各種問題!!

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