計算出正確的服務水平協議：探索 Composite SLAs 計算和架構設計
最近這幾周收到幾個想要做 SLA 99.999% 的案子，因涉及的服務眾多，所以故針對如何合理計算 SLA 和其架構設計先做一個紀錄，但這邊並不涉及資料最終一致性和對外網路的設計討論
TL;DR
- 相比單一服務 SLA 計算，複合 SLA (Composite SLA) 是更為合理的計算方式
- 複合 SLA (Composite SLA) 會隨認列範圍不同而有所變化，就算是同一張架構圖
- 若相依性服務越多，因可能失敗發生點多，則複合 SLA 會必然低於單一服務 SLA
- 單區域架構提供多個備援作法可小幅提升整體 SLA
- 多區域架構設計可以大幅提升整體 SLA，至少 2 個區域，至多 3 個區域
Kubernetes Communtiy Day Taiwan 2023 開放徵稿!!!
COSCUP 2023 將至，Cloud Native Taiwan User Group 跟歷年一樣我們也會於 2023/07/29 ~ 2023/07/30 內，舉辦 Kubernetes Communtiy Day Taiwan 2023
目前已正式開放徵稿，可於 COSCUP 投稿系統 進行投稿
- 正式投稿開始日期：2023 年 04 月 14 日
- 正式投稿截止日期：2023 年 05 月 22 日
- 通知講者社群軌投稿結果：2023 年 06 月 23 日
待投稿結果出爐後，我們也會將相關資訊同步發布至 KCD Taiwan 官方頁面
歡迎大家多多參加
單區域內的複合 SLA (Composite SLA) 計算
無論是哪一家廠商所提供給你的 SLA，都是基於一個限定範圍或特定產品內，所訂立的 SLA，但正常狀況下你不太可能只單獨使用一個服務就能撐起全部的對外服務
複合 SLA (Composite SLA) 主要就是將多個服務的不同層級的可用性進行混合計算，分為兩個場景: 有服務相依性和無服務相依性
1. AND: 服務之間有相依性
以上圖為例，若有個對外服務需要同時使用到 Azure Red Hat OpenShift 和 Azure Cosomos DB 存放資料，兩者服務缺一不可，則該 SLA 計算方式為兩者相乘即可，可得該圖 SLA 為 99.94900005%
- Azure Red Hat OpenShift: 99.95%
- Azure Cosmos DB: 99.999%
Composite SLA = 99.94900005% = 99.95% * 99.999%
2. OR: 服務之間無相依性
以上圖為例，若有個對外服務需要同時使用到 Azure Red Hat OpenShift 和 Azure Cosomos DB 存放資料，且多設定 Azure Service Bus 當作 Queue 來使用，即使連線不到 Azure Cosmos DB 時，對外服務還是可以正常運行，但 Azure Cosmos DB 和 Azure Service Bus 同時失效的時候，對外服務就會中斷。
- Azure Red Hat OpenShift: 99.95%
- Azure Cosmos DB: 99.999%
- Azure Service Bus: 99.9%
針對無相依性服務 Azure Cosmos DB 和 Azure Service Bus 需要優先計算 SLA，
Composite SLA = 99.999999% = 1 - 兩者同時失敗機率 = 1 - ((1 - 99.999%) * (1 - 99.9%))
其次再針對前面必要服務 Azure Red Hat OpenShift 進行相依性計算，故可得:
Total Composite SLA = 99.949999% = 99.95% * 99.999999%
小結
| 比較 | 無 Queue | 有 Queue |
|---|---|---|
| SLA | 99.94900005% | 99.949999% |
| Daily | 44s | 43s |
| Weekly | 5m 8.4s | 5m 2.4s |
| Monthly | 22m 10s | 21m 44s |
| Quarterly | 1h 6m 30s | 1h 5m 12s |
| Yearly | 4h 26m 1.9s | 4h 20m 49s |
透過新增 Queue 或其他備援服務，則可以小幅度提升 SLA 的數字
多區域內的複合 SLA (Composite SLA) 計算
如何大幅度提升 SLA? 簡單來說就是跨區域做高可用架構，分散單一區域崩壞風險
1. 計算單區域內的複合 SLA (Composite SLA)
- Azure Load Balancer: 99.99%
- Azure Red Hat OpenShift: 99.95%
- Azure Cosmos DB: 99.999%
- Azure Storage Accounts: 99.99%
Composite SLA for Japan East = 99.929011% = 99.99% * 99.95% * 99.999% * 99.99%
以單一區域服務來講，99.929011% 已經比常見基本要求 99.9% 來的好不少了，所以對於很多服務來說還算是可以接受的範圍，但如果對於要做出 99.999% 等級服務來講是有相當距離的，故下面來討論提升 SLA
2. 計算多區域內的複合 SLA (Composite SLA)
- Azure Traffic Manager: 99.99%
- Composite SLA for Japan East: 99.929011%
- Composite SLA for Japan West: 99.929011%
首先先計算應用程式在所有區域爆炸的機率
應用程式在多個區域合併 SLA 公式為 (1 - (1 - SLA) ^ R)
- R: 是區域數量
- SLA: 是單一區域的 SLA 協議數字
故可得知程式佈署在兩個區域時，可獲得下列 SLA 等級
Composite SLA for Azure Red Hat OpenShift in 2 regions = 99.9999% = (1 - (1 - 0.99929011)^2)
但因前面需要放置 Azure Traffic Manager 服務確保前置流量能夠兩邊導流，故還需計算，故可得
Totla Composite SLA = 99.9899% = 99.99% * 99.99%
這邊有需要討論的地方是有沒有要把 Azure Traffic Manager 列為 SLA 計算範圍內，因為它其實可以放在第三個區域，然後該服務特性，是做 DNS Query，實際上不會影響到，單一區域的運行，但這個因不同使用者認列範圍而異，不然以 Azure Red Hat OpenShift 本身運作下，透過第二個區域的建置，就可以來到 6 個 9 的等級，因高於常聽到 5 個 9，對於維運雙叢集 Kubernetes 運作為目標來講是相當足夠的
小結
| 比較 | 單區域 | 雙區域 |
|---|---|---|
| SLA | 99.929011% | 99.9999% |
| Daily | 1m 1.3s | 0.086s |
| Weekly | 7m 9.3s | 0.6s |
| Monthly | 30m 51s | 2.6s |
| Quarterly | 1h 32m 34s | 7.8s |
| Yearly | 6h 10m 18s | 31s |
透過新增一個區域的服務，則可以大幅度提升 SLA 的數字
以特定 SLA 為目標，單區域所需最低 SLA
以單一區域但不限於其單位 (如服務、個體數、AZ) 所需最低 SLA 計算方式如下:
單一區域所需最低 SLA = (1 - (1 - SLA)^(1/R))
- R: 是區域數量
- SLA: 是預期達到的 SLA 協議數字
Makrdown 版:
| Availability | Target SLA | 於 1 個 Region 之下，單 1 Region 最小 SLA 需 | 於 2 個 Region 之下，單 1 Region 最小 SLA 需 | 於 3 個 Region 之下，單 1 Region 最小 SLA 需 | 於 4 個 Region 之下，單 1 Region 最小 SLA 需 |
|---|---|---|---|---|---|
| 2 Nines | 99% | 99.0000000% | 90.0000000% | 78.4556531% | 68.3772234% |
| 3 Nines | 99.9% | 99.9000000% | 96.8377223% | 90.0000000% | 82.2172059% |
| 3 and a half nines | 99.95% | 99.9500000% | 97.7639320% | 92.0629947% | 85.0465122% |
| 4 Nines | 99.99 % | 99.9900000% | 99.0000000% | 95.3584112% | 90.0000000% |
| 5 Nines | 99.999% | 99.9990000% | 99.6837722% | 97.8455653% | 94.3765867% |
| 6 Nines | 99.9999% | 99.9999000% | 99.9000000% | 99.0000000% | 96.8377223% |
| 7 Nines | 99.99999% | 99.9999900% | 99.9683772% | 99.5358411% | 98.2217206% |
| 8 Nines | 99.999999% | 99.9999990% | 99.9900000% | 99.7845565% | 99.0000000% |
| 9 Nines | 99.9999999% | 99.9999999% | 99.9968377% | 99.9000000% | 99.4376587% |
彩色好讀版:
Q&A
Q1: 某某個服務超爛，一天會當機七小時以上，約 SLA 68.3772234%，是不是永遠達不到 2 nines?
A1:
以上面計算單一區域所需最低 SLA 計算來說，不考慮資料一致性及網路可達性，你只要在 4 個不同區域建立相同 SLA 68.3772234% 服務，最差還是可以拿到 SLA 99% 的等級
但...你應該要做的事情是研究一下為啥一個服務一天會噴掉七小時以上，而不是在這邊算數學
Q2: 為何使用者開頭都說請提供給我 5 個 9 的 SLA 架構設計?
A2:
SLA 99.999% 可接受停機時間如下:
- Daily: 0.86s
- Weekly: 6s
- Monthly: 26s
- Quarterly: 1m 18s
- Yearly: 5m 13s
主要是 Daily 這個數字是剛好低於 1s 的，所以普遍才會有這個理解，基本上要辦到就是一定要做到整體架構不能停機、異地抄寫、網路全球負載、CDN 都要拿出來用，想當然而成本會很高，白話來講就是，這個服務不能掉
Q3: 如果我跟終端客戶簽了一個 99.999% 的 SLA 協議，但我知道自家服務只有算出 99.929011%，這樣可以嗎?
| Target SLA | 99.999% | 99.929011% |
|---|---|---|
| Daily | 0.86s | 1m 1.3s |
| Weekly | 6s | 7m 9.3s |
| Monthly | 26s | 30m 51s |
| Quarterly | 1m 18s | 1h 32m 34s |
| Yearly | 5m13s | 6h 10m 18s |
SLA 只是一紙承諾，若已知中間這麼大的風險，簽下去當然就是得要自己扛的住，不然就是再投注成本把架構持續改善到接近目標
Q4: 有否 Azure 推薦的多區域架構說明?
Multi-region load balancing with Traffic Manager and Application Gateway
Multi-region N-tier application
Q5: 有否 Azure SLA 官方清單?
Q6: 除了 Azure 需要算出 SLA 以外，還有沒有什麼是需要自行考量的?
A6:
有，使用者自己應用程式的 SLA
正確你應該可以提供出去的 SLA 理論上是 Composite SLA = 應用程式 SLA * 基礎架構 SLA 而不是僅提供一方的 SLA 保證
如果程式寫得太爛，例如天天 OOM、Crash、Query 效能太差等等，按照責任劃分，這個是個別使用者應該要自己負責的，而非基礎平台能扛的