Gcp Preemptible Instance Requirement Distributed
我們以下幾個需求：
- 執行短期的 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 的技術規格，與大家實際討論。
