LINE Developer Meetup #6 開發者小聚 活動後分享

KKTIX 活動網頁:  活動網址

今年最後一場的開發者小聚,帶來的不是 API 的介紹;不是開發夥伴的經驗分享。而是要讓開發者們了解好的用 LINE 服務的背後,是有哪些有用的架構。並且我們有來自 LINE 日本的夥伴們帶來的精彩內容,分別是 LINE 福岡 Data Lab 與東京的 Verda Team 。當然也有台灣的 LINE NOW 團隊帶來的產品開發分享。

LINE 台灣與日本工作環境介紹 / LINE台灣 開發者關係與技術推廣部負責人, Benny Wu ; LINE福岡開發一室室長, 林康司

投影片: 網址

首先開場的就是開發者關係與技術推廣部負責人 Benny Wu 來簡介台灣辦公室。而遠道而來的福岡開發一室室長 林康司也介紹了 LINE 日本的相關資料。

首先講者先簡介了 LINE 日本所有的相關服務之外,更介紹了三個日本辦公室( 東京,福岡跟京都 )。當然所有開發者最在意的工作環境與公司所配置的硬體設備都有講解到。

最後也有提到身為 LINER (LINE 員工的自稱) 我們最在意的幾個精神就是

  • Take Ownership
  • Trust & Respect
  • Be Open

這些精神我們鼓勵著每一位 LINER ,我們也尋找跟我們有一樣精神的夥伴們。

Machine Learning Platform in LINE Fukuoka / LINE福岡 Data Labs, 立石賢吾

投影片: 網址

緊接著是來自於 LINE 福岡 Data Labs 的立石賢吾,他來介紹 LINE 裡面如何打造屬於 LINE 福岡的機器學習平台 ( Machine Learning Platform ) 。

首先先來介紹 Data Labs 的成立的原因,LINE 有提供給使用者許多的服務,而這些服務都會產生有價值的資料。但是這些資料都是分散式各個服務之中無法有效整合來處理。 LINE Data Labs 就是為了解決這樣的問題。

這邊也對於機器學習循環( Machine Learning Lifecycle )有一些初步的澄清。一般人都會以為就是建立一個預測模型,並且寫出一個演算法來增加準確度,如此反覆的優化即可。但是實際上卻沒有那麼簡單,舉凡從資料的搜集,儲存,資料的預處理 (Pre-processing) ,到最後的部署 prediction model 到 API 服務上都是機器學習循環的一環。

最後討論到 LINE 在福岡的機器學習平台架構圖。剛剛有提到機器學習循環之中,針對資料的 ETL (Extract-Transform-Load) 前處理與資料模型的部屬其實是相當重要的,也是最花時間的部分。所以 LINE 福岡的機器學習平台架構上特別有針對資料的處理上有著特別的設計。透 Drone CI 做出的持續整合 (Continues Integration) 使得機器學習的處理流程上相當的自動與完整。資料進來 HDFS 之後就會啟動資料的前處理流程,並且把資料放回 HDFS 。之後訓練流程就會啟動,將機器模型演算法計算出來。然後又會啟動機器模型的部屬流程。這裡將訓練結果的服務部署到 Kubernetes 上面。

最後講者總結了,什麼對於機器學習是最重要的? 除了訓練出來的機器模型與一些演算法參數之外,有著完整的機器學習平台也是相當重要的,因為一個好的機器學習平台可以讓整個機器處理流程快速,穩定並且更容易。

LINE NOW刮刮卡開發分享/ LINE台灣工程師, Julian Shen

投影片: 網址

接下來緊接著輪到了 LINE 台灣工程師 Julian Shen 來為我們分享一下 LINE NOW 刮刮卡的開發經驗。 LINE NOW 刮刮卡是一個在一個月裡面從無到有的新專案,講者分享了整個 LINE NOW 刮刮卡的架構,如何建置並且也分享了短時間裡面要完成這個專案所會遇到的一些問題。

 

首先先來介紹什麼是「 LINE NOW 刮刮卡 」,是一個在今年中秋節搭配著 “LINE推出刮刮樂中秋活動 總價值超過500萬等你刮!“的活動。是一個遊戲可以來讓廠商分配獎品的服務。使用者做完某些指定服務(購買貼圖)就會有刮刮卡,出現當使用者刮完可能會有一些稀有的獎品回饋給他。整個刮刮卡都是透過 LIFF 來建置的。然後在後台的建置上是透過 redis 來存放卡片,並且將抽出的卡片結果直接放在 Kafka 上面來做相關的兌獎處理。

 

那究竟在這個專案的建置流程遇到了哪些問題呢?

首先就是專案進行上,大家最容易遇到的就是專案需求範圍 (Scope) 的界定。由於 LINE 的工程師們都具有要求完美地個性,使得整個專案的範圍相當的限縮,許多時候東西會越做越多。只好在每天的 scurm 會議上面透過討論來減少專案範圍。再來就是開發上工程師遇到的問題,分別從前端,後端以及測試的方面來分享:

  • 前端的問題分別是:從如何減少流量,增加效能以及改善使用者體驗的方向。
  • 後端的問題分別是:界定可能的流量高峰的日子,改善後端處理效能,流量的計算上無法精確導致不容易做服務的擴展 (Scaling) 最後就是要處理錯誤的復原。
  • 測試的問題分別是:解決良好的刮刮卡產生方式,流量壓力測試(使用 k6 )還有要解決 Kafka connector 的發生錯誤時後的復原。

講者在最後的總結有提醒大家不論你有多少種測試與預防,最好還是準備幾個預備的機制。正式上線才能預防問題的發生。

LINE’s Private Cloud Meets Cloud Native World / LINE東京 Verda Team, 西脇雄基

投影片鏈結: 網址

最後壓軸的就是來自東京 Verda Team 的 Yuki Nishiwaki-san 所帶來的分享。分享了兩個專案一個是 Verda KAAS (Kubernetes As A Service) ,另一個是 Verda Event Handler 。

第一段分享的 Verda KAAS ,其實就是 LINE 內部能夠快速開發的幕後功臣:  LINE 的私有雲架構 (Private Cloud) 。原本在企業中,當專案的開發需要新的機器的時候,使用者需要填寫一堆麻煩的申請表來申請服務。或是要自行安裝一群機器集群。即便到了 Kubernetes 風行的時代,亦是如此。當使用者要申請新的機器集群,不是要透過繁瑣的申請流程來請專業人員重新建置,就是要自己搞懂所有相關的網路設定, DNS 設定與機器開啟設定來建立一個 Kubernetes 集群。

Verda KAAS 就是為了解決這個問題,透過這套系統使用者申請新的服務就變得相當簡單。透過一些必要的設定就可以自動部署好一套新的 Kubernetes 集群。真正落實將 Kubernetes 變成是服務一樣隨時可以申請。這個部分目前已經有第一版上線了,徵求一起努力的夥伴來讓他更好。

第二段系統是 Verda Event Handler ,簡單的講解就是讓所有的機器架構上的操作 (Operation) 流程變得更容易維護與操作。以往在企業中要做一些機器集群的操作會是維護其實是相當的分散的。舉個例子:可能將機器的開啟或是關閉寫在一個 API 伺服器上面,但是自動偵測機器使用過量的時候要開啟新的機器的邏輯又會寫在一個獨立的監測服務上。造成企業維運的商業邏輯被切割在許多服務之中,無法有一個統一的方式來管理與維護。

( 企業使用者,將為運邏輯服務切割在許多小服務上。難以管理與維護 )

( 透過邏輯的整理,可以將維運邏輯修改成”什麼時候要做” (When) 跟”要做什麼” (What) )

Verda Event Handler 就是為了解決這樣的痛點,將所有的問題透過邏輯的整理,可以將維運邏輯修改成”什麼時候要做” (When) 跟”要做什麼” (What) 。這樣透過事件提供者 (Event Provider) 與功能的執行者 (Function Executor) 就可以切割成兩個階段。透過這樣的方式來管理所有的邏輯。並且也可以統一將權限控管在功能執行者上面,服務的權限管理也就變得更有條理。

以上兩個專案是東京 Verda Team 正在做的有趣專案,是不是也想要一起來努力呢?

活動小結

本次的活動邀請了許多日本的 LINE 工程師來與開發者見面。由於主題有別於以往的 LINE 平台開發,而是分享給開發者們好用的 LINE 的服務背後所具有的兩個大架構。機器學習平台與 Verda KAAS 。並且也有台灣工程師分享如何透過 Verda KAAS 來快速開發 LINE NOW 刮刮卡的實際經驗分享。希望這些架構與經驗分享讓許多開發者能夠更了解 LINE 平台。 此外,這樣的平台也需要許多有能力的開發夥伴,也歡迎各位去 LINE Developer Careers (網址)  查看相關職缺,一起來加入我們。

立即加入「LINE開發者官方社群」官方帳號,就能收到第一手Meetup活動,或與開發者計畫有關的最新消息的推播通知。▼

「LINE開發者官方社群」官方帳號ID:@line_tw_dev

 

Related Post