Skip to main content
Elasticsearch

91APP 如何利用 ELK 處理系統巨量 Log

91APP 做為一個快速成長平台,在系統面也持續接受到各種挑戰,包括:瞬間巨量、海量資料、365 天 / 24 小時不中斷營運等等。本文著重在海量資料處理,並從「系統Log 檔處理」這個題目出發,與大家分享相關經驗。

91APP 系統架構

全雲端架構

91APP 服務全面架構於 Amazon Web Service (AWS) 雲端平台上。我們全面運用 AWS 虛擬化技術,包括虛擬主機 (EC2)、負戴平衡器 (ELB)、分散式儲存 (S3) 等,建構出一個完整電子商務服務系統。

High Availability (HA) 架構

為了達成服務全年不中斷,必須提高系統可用性,減少服務中斷時間。91APP 所有系統服務,包括網站伺服器、資料庫、批次處理服務等,都是採用 High Availability (HA) 架構:任一服務,至少會有二台以上伺服器同時存在。在一般架構上,伺服器Log 檔,通常會儲存在機器本機硬碟中。

異質服務

為了滿足不同需求,開發人員會利用最適架構來實作,如:Web 採用 IIS、搜尋採用 Elasticsearch。目前 91APP 系統中,有超過十種以上服務,會採用異質架構。不同服務邏輯、作業系統、記錄項目都不同,也造成產生出來的 Log 檔格式也完全不同。

挑戰 – 巨量 Log

需求:異常即時監控與報表產生

從商業與營運角度出發,必須分析 Log 的內容,才能滿足下列需求:

  • 攻擊事件分析:針對網路存取做分析處理,是資訊安全重要工作之一。常見做法為:定期分析所有服務 Log,檢視網路攻擊可能事件,如:大量異常 URL 存取等。透過營運人員不斷監控、回報、改善,才能提升系統安全。
  • 異常即時監控:當系統發生異常時,營運人員需要在第一時間快速通報。又或事後追查原因,都需要從 Log 檔分析著手。
  • 系統狀態與容量:管理階層需要基於統整系統狀態報表,做出對應決策。如:由系統使用率決定主機升級等。

要達成上述需求,對 91APP 系統會有以下挑戰

挑戰一:「各式」Log 散落「各處」

在 91APP 系統中,有大量異質服務產生出各種樣式 Log,且這些 Log 都儲存在系統中不同位置,有不同生命週期。再加上 HA 架構,需要統合所有機器才會有全服務的 Log。「各式」加上「各處」Log,是首要問題。

挑戰二:大量的 Log

目前 91APP 有超過上百台機器,所產生 Log 量每日將近 100GB,且每日資料量一直持續增加中。如此大量資料處理,會是另一大挑戰。

挑戰三:成本與效益

從商業觀點,Log 檔分析與處理,是屬於「系統防禦」一環,並無法直接增加公司獲利。但一旦有需要分析 Log,如:系統異常發生,又會是最迫切需求。Log 服務「成本」vs「效益」考量,一直是管理上重要議題。

什麼是 ELK?

91APP 在 Log 分析上,最終是採用 ELK 這個解決方案,架構出 「91APP Log Service」系統。

ELK是基於 Elastic Search (E)、LogStash (L)、Kibana (K),再加上 Shipper 這四個系統,處理大量資料,是 Big Data 的重要解決方案之一。

  • Shipper:Shipper 是安裝在各台主機上的 Agent,透過 Shipper,能把散落在各處 Log 轉送到單一平台。
  • LogStash:LogStash 可以把集中後各式 Log,分析並處理成有意義的資料結構,再匯入 Elastic Search 中。
  • Elastic Search:目前業界最佳搜尋引擎架構,可以基於關鍵字快速找出所需 Log,並提供 API 方便系統串接。
  • Kibana:可以基於Elastic Search API,快速產生圖表。

91APP Log Service

架構

  • Service 1~N:針對不同服務,採用適用 Shipper,將 Log 透過 ELB 轉送到 LogStash 處理。
  • LogStash1~3:處理、分類各式 Log,並將Log轉為 Elastic Search 格式後,透過 ELB 送到 Elastic Search。
  • Elastic Search Node:提供 Log 查詢服務。 Elastic Search 中節點可分為各種角色: Master Node (主節點)、Search Node (搜尋節點)、Data Node (資料結節),各有不同功能。
  • Kibana:提供易用網頁介面,方便相關人員查詢 Log。
  • AWS ELB:Log Service 本身,也需要達到 HA,我們透過 AWS 負戴平衡器 (ELB) 來達到這個目的。
91app_log_service_architecture
91APP Log Service 架構

成本考量

前面章節有提到,Log 系統成本,一直是管理上被關注的議題。我們使用以下方式來控制成本:

  • 資料的生命週期: 我們可以將儲存資料分為冷資料與熱資料。熱資料需要提供即時 (Real-time) 線上查詢及分析,而冷資料只需要備份以利可能追查,並不需要隨時儲存在系統中。透過 ElasticSearch  API,可將二週前 Log (冷資料) 儲存到 S3或是 glacier 上做永久保存,而 Log Service 中只保留二週內,也就是「最有可能」被查詢的 Log (熱資料)。
  • EC2 Spot Instance:我們使用 AWS 一般虛擬主機 (EC2) 來建立主要 Log Service,滿足 2 週內的 Log (熱資料)的即時搜尋。而當系統需要查詢二週前的 Log (冷資料) 時,則利用 EC2 Spot Instnace (拍賣型主機,可用低拍賣價使用,但當有更高出價時,會直接被回收),以原本 EC2 八分之一的價格使用相同規格主機,同時滿足需求並降低成本。

結語

伴隨公司成長,91APP Log Service 也一直持續演化中。未來的挑戰包括:更即時 Log 查詢、納入更多不同種類服務 Log、不同服務 Log 優化等,都是未來發展方向。

技術沒有好壞,只有適不適用。若一個小型系統,利用 ELK 來處理 Log ,很容易落入「殺雞用牛刀」的陷阱中。但面對一個快速成長、資料量大幅增加的系統,ELK 就會是一個好的解決方案。在 91APP,面對持續挑戰,我們一直保持高彈性、快速反應的心態。

歡迎大家分享經驗,也歡迎想接受挑戰的軟體工程師,一同加入我們

搶攻行動商機,現在就加入 7,000 家已在網路開店的品牌行列!
分享至:
林 大維
91APP 研發副總,擁有十多年軟體開發經驗,專注在軟體開發流程與技術管理。

掌握最新電商脈動,加入 91APP 品牌全通路學院!

免費獲得最新市場趨勢、行銷技巧與資源,直接送達您的信箱。

完全免費,可隨時取消。
搶攻行動商機,現在就加入 7,000 家已在網路開店的品牌行列!