iT邦幫忙

2024 iThome 鐵人賽

DAY 27
0
生成式 AI

Local LLM infra & Inference 一部曲系列 第 27

Day27 - Infra篇PART2:針對服務的分散式系統

  • 分享至 

  • xImage
  •  

前言

先前在 Day10 講過了針對計算資源的分散式架構Ray ⚙️,也在 Day26 提到多個server組成cluster的概念 🌐,在這些clusters上每個ESXi都有許多VM,VM上面又有許多的APP,以及完善的HA機制 🛡️,然而,單靠VM作為基礎架構對於服務的彈性來說仍然不夠靈活

對於LLM服務來說,穩定性和擴展性是非常重要的 🌟,沒有人希望在面對硬體故障或不可預期的狀況時,服務突然中斷 ❌。因此,針對硬體HA的部分昨天提過了,接下來將探索從傳統的VM到容器技術、再到分散式系統的演化過程,並以kubernetes為例,探討其中的關鍵概念,以及它如何管理應用服務 🚀。

🔍 章節大綱

  • 電腦 / VM / Container 技術的演化 🧬
  • 對於 Kubernetes 的簡單介紹 🌍

因為kubernetes是超大坑,沒有辦法真的詳細介紹XD,只打算說明它針對服務管理有那些優點,以及稍微講一下怎麼跟昨天那個超大VMware infra架構圖接起來。

https://ithelp.ithome.com.tw/upload/images/20240928/20168115wvhV7tTG5e.png
(圖源: Medium,Docker Swarm也算另一種分散式架構)


🧬 電腦 / VM / Container 技術的演化

在設計分散式架構之前,首先需要了解計算資源管理技術的演化過程!從傳統的一台電腦到虛擬化、再到容器化,這大大地影響了服務部署和管理的靈活性。 🖥️ ➡️ 📦

https://ithelp.ithome.com.tw/upload/images/20240928/201681151OgZ43CArd.png
(圖源: redhat)

  • 傳統電腦 (Physical Machines) 🖥️

    • 最早期的服務部署往往依賴於單台實體機器,也就是說,每個服務都在專屬的硬體上執行。這種方法缺乏擴展性和容錯能力。一旦機器故障,服務就會完全中斷,且難以有效使用全部硬體資源。
  • 虛擬機器 (VM) 🖥️

    • 為了解決實體機器資源利用率不高的問題,虛擬化技術誕生了,VM允許在一台實體伺服器上運行多個VMs。
    • 對於一個服務來說,VM提供了更高的靈活性,但VM最大的缺點是資源花費較大,每次重啟VM都會耗費相當多的時間和資源
  • 容器 (Container) 📦

    • 隨著應用的複雜度增加,容器化技術成為更輕量且高效的選擇。Container比VM更節省資源,因為它們共享同一個操作系統核心,並能快速啟動和停止。
    • Docker容器允許我們更靈活地打包和部署服務,並能夠在不同環境中一致地運行。

這種從單機到虛擬化、再到容器化的演化過程,使我們能夠更有效率地去利用計算資源,同時為大規模的模型訓練和推理服務提供了穩定的基礎!


🌍 kubernetes (k8s)

先前 Day10 介紹計算資源的分散式架構時很常提到Node,這邊我們以kubernetes為例來提一下它是什麼。

https://ithelp.ithome.com.tw/upload/images/20240928/20168115h7UpQKWmnq.png
(圖源: kubernetes docs,先不用在意裡面的細節XD,cluster就是昨天那張圖的cluster,Node對應的就是VM!如果沒有VM,對應的就是電腦。)

  • Node的概念 🖥️

    • 在kubernetes中,每個節點可以是一台實體機器或一個虛擬機,而kubernetes當中會有一個Master Node(上圖的CONTROL PLANE),它的任務就是將pods分配到各個node上運作,並確保這些pod能夠可靠地提供服務。
  • Pod、Container、服務 🧳

    • Kubernetes中的服務會被放在pod中,pod是kubernetes的最小單位,裡面可能包含一個或多個container,container裡面就是user在用的服務,透過Kubernetes可以自動化地管理這些container在多個node之間的分配和負載均衡。
  • 高可用性和自我修復 🔄

    • 如果某個node發生故障,Kubernetes會自動將上面的pod移動到其他健康的node上,確保pod裡面的服務不會被中斷

⏳ 而這種自我修復的能力對於LLM推理這種需要長時間運作、以及會有大量requests的服務特別重要,至於它的缺點正如同 Day10 所說,它主要是針對服務的分散式架構,因此對於計算資源的分配搭配Ray使用會更好

註:雖然網路上有其他更好懂的圖,但亂貼好像不太好,所以這邊都放大公司的文件的圖。


章節總結

這一章中,我們更深入地了解了從VM到container的架構演化 🔄,以及kubernetes如何幫助管理分散式的應用服務 🛠️,將VM上面的結構又看得更清楚一些了,更深入了解從資料中心一路到APP的其中一種infra設計架構 🌐。雖然kubernetes仍有許多細節可以學習,但它提供的靈活性和高可用性讓其成為現代基礎設施設計中的核心工具。

BTW,筆者個人滿喜歡2022鐵人賽的從異世界歸來發現只剩自己不會 Kubernetes 系列,講得很簡單又好懂,同樣推推。 🌟

雖然文章中的架構看似簡單,但在實際部署中又是一個大坑 🔥。希望這些技術分享能讓讀者在探索分散式架構時有更多的靈感 💡,即使對於小公司來說並不需要這麼大規模的架構,這之中的經典架構仍值得一學 📚。

幫文章取名好難,而且寫infra篇會讓筆者做惡夢,今天半夜才夢到自己回infra時期的工作地方上班......明天就繼續往監控的地方做最後衝刺了!

https://ithelp.ithome.com.tw/upload/images/20240928/20168115DxcIRDBh4l.jpg
(圖源: Medium)


上一篇
Day26 - Infra篇PART1:多台server如何一起工作?
下一篇
Day28 - 從服務部署到維運:DevOps & 服務監控
系列文
Local LLM infra & Inference 一部曲30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言