iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 11
1
DevOps

Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*系列 第 11

Day 11 - 先占節點 Preemptible Instance 實戰分享,需求分析下篇,在 kubernetes 上跑資料庫,或是分散式資料庫

本文同步刊登於個人技術部落格,有興趣關注更多 Kubernetes、DevOps 相關資源的讀者,請務必追蹤從零開始的軟體工程師之旅,喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論,技術方面諮詢免錢、需要動手做另計 XD。

曬貓


上篇,我們開始探討以下幾個需求:

  • 執行短期的 batch job
  • 執行長期的 user-facing API server
  • 執行長期的 stateful 資料庫、儲存庫

有人提出一個問題:該不該在 Kubernetes 上面跑 database?

TL;DR,如果你剛開始考慮這件事,通常的答案都是否定的

等等,我們這邊不是討論該不該上 Kuberentes,而是該不該使用先占虛擬機吧。

然而由於先占虛擬機節點的諸多限制,光憑先占虛擬機並不適合跑任何持久性的儲存庫。我們這邊仰賴 Kubernetes 的網路功能 (e.g. 服務發現),與自動管理 (e.g. health check,HPA,auto-scaler),基於先占虛擬機,建構高可用性的服務架構,來支撐高可用,且有狀態的的儲存庫。

應用是否適合部署到 Kubernetes 上,可以看這篇 Google Blog: To run or not to run a database on Kubernetes: What to consider,如果大家有興趣,再留言告訴我,我再進行中文翻譯。

文中針對三個可能的方案做分析,以 MySQL 為例:

  • Sass,GCP 的 Cloud SQL
    • 最低的管理維運成本
  • 自架 MySQL 在 GCP 的 VM 上,自行管理
    • 自負完全的管理責任,包含可用性,備份 (backup),以及容錯移轉 (failover)
  • 自架 MySQL 在 Kubernetes 上
    • 自負完全的管理責任
    • Kubernetes 的複雜抽象層,會加重維運工作的複雜程度

然而 RDBMS 的提供商,自家也提供 Operator

你就想,所以這些人是想怎樣,RDBMS 放 Kubernetes 上到底是行不行 XD。Google 的文章說明:如果應用本身並不符合 Kubernetes 的工作流程 (Pod life-cycle),可以透過上述的 Operator 來自動化許多維運的作業,降低維運的困難。

然而 DB 有千百種,除了 RDBMS 以外,還有另外一批 Database 天生就具有分散式的架構,這些儲存庫部署到 Kubernetes 上,並不會太痛苦 (還是要付出一定的成本XD),但是卻可以得益於 Kubernetes 的諸多功能。

底下我們先根據分散式的儲存庫做概觀描述,本系列文的最後,會根據時間狀況,做實例分享:Cassandra 或是 CockroachDB。提供各位一點發想,並根據需求去選擇需要的儲存庫

「行不行要問你自己了施主,技術上都可以,維運上要看看你的團隊有沒有那個屁股吃這份藥 XD」

施主這問題要問你自己了

Distributed Database

底下非常粗淺的簡介分散式儲存庫的概念,提供一個基準點,幫助接下來討論是否可以使用先占虛擬機。這邊要強調,儲存庫的類型千百種,底層的各種實作差異都非常大,底下的模型是基於 cassandra 但不會走太多細節。 cassandra 的規格有機會再細聊。

當後端應用已經順利水平拓展之後,整體服務的效能瓶頸往往都壓在後端 DB 上。這些不同的 DB 面向不同的需求,當需求符合時,可以考慮使用這些解決方法。

這邊要強調,不是放棄現有的 RDBMS ,完全移轉到新的資料庫,這樣的成本太高,也沒有必要性。更好的做法,是搭配既有的關聯性資料庫,將不是核心業務的資料處理抽出,移轉到合適的資料庫上。讓不同需求的資料儲存到更合>適的儲存庫,是這段話要強調的重點,關連式資料庫也不是唯一選擇。

分散式的資料庫有以下特徵

  • 分散式節點集群 (Cluster):資料庫是多個節點共存,而非 single master, multiple slaves 的架構
    • 配合共識算法 (consensus algorithm) 溝通節點之間的資訊
  • 無單點錯誤 (Single-point failure):e.g. 不會因為 master 錯誤導致整個服務失效
  • 高可用(High Availitility:可以承受集群中一定數量虛擬機故障,服務仍然可用
  • 資料 sharding 到不同節點上
  • 複本 (replica)
    • 節點複本 (node replicas):多個節點提供服務,提供流量的帶寬與可用性
    • 資料複本 (data replicas):在多個節點上儲存資料,提供資料的備份,同時也提供讀取帶寬與可用性

從以上特徵來說,使用此架構的服務可以承受先占虛擬機的不定時終止,或許可以使用。

實務上有非常多需要注意,需要依據各自服務的性質,各自處理。常見的問題舉例如下:

  • 應用可以容錯 (fault-tolerent),然而錯誤發生後,會需要消耗復原成本,例如重啟後需要花時間初始化,或是在多節點上進行 data rebalance。
  • 可以承受突然的錯誤,使用先占虛擬機,變成每日固定會承受必然的錯誤。這裡犧牲了部分算力,甚至造成隱性的維護成本,最後是否符合節省成本的需求。

都是需要仔細了解解決方案,並且分析需求,來評估是否有合乎成本。

GKE

以上分析了三種常見需求例子:從 batch job,user-facing service,與 distributed database。

明天會實際搬出 GKE 與 GCP Preemptible Instance 的技術規格,與大家實際討論。


有寫過鐵人賽的都知道 30 篇真的很漫長,一篇文章幾千字,都要花好幾個小時。我去年後半,真的都會看讀者的留言跟按讚,取暖一波,才有動力繼續寫。留言的人多就會多寫,留言的人少就會少寫,各位覺得文章還看得下去,請務必來我粉專按讚留個言,不管是推推、鞭鞭、或是有想看的文章來許願,都十分歡迎。有你們的支持,我才有動力繼續寫。

請大家務必以實際行動支持好文章,不要讓劣幣驅逐良幣。不然 iThome 上面之後只剩洗觀看數的熱門文章了 XD

當然,沒人留言我就會當作自己才是垃圾文 (自知之明XD),就會收一收回家嚕貓睡覺,掰掰~

我的粉專,等你來留言


上一篇
Day 10 - 先占節點 Preemptible Instance 實戰分享,需求分析上篇
下一篇
Day 12 - 先占節點 Preemptible Instance 實戰分享,配合 Kubernetes 自動化調度,使用先占虛擬機上篇
系列文
Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*30

尚未有邦友留言

立即登入留言