fbpx

打造穩定的雲服務 - 高可用架構

如何建立穩定的雲端服務系統?服務高可用架構

穩定的雲端服務由兩個方向來實現,分別是「服務高可用」與「資料保存」兩個面向,今天先介紹服務高可用架構。

雲算與資料服務高可用架構

高可用就是常常聽到的 HA (High Availability) 機制,建立的 SaaS 雲服務要高可用,首先第一件事情就是要具備容錯能力,避免一時的故障影響到系統運作。

我們相信什東西都會壞,特別是過某些衰人經手的軟體或硬體 (笑),乖乖過期或者放錯口味也是很重要的因素。系統發生錯誤無可避免,但我們要建立機制的是當發生「單點故障 (SPOF)」時,不足以癱瘓整個服務的一種技巧。

要實現 HA 目前有三種常見的機制,分別是 Master Slave Mode (MS)、Active Active Mode (AA) 與由 AA 進化變形的分散式架構 (Decentralized Architecture)。我們來介紹一下這三種不同的架構有什麼樣的特性:

MS 容錯模式 (Master/Slave Mode)

就是常說的主備切換,架構上會有一台 Master 提供服務,另外搭配多台 Slave 進行預備,有一些資料庫架構會讓查詢工作分散到 Slave 上,實現讀寫分離降低 Master 的壓力。會用這樣的機制通常是因為系統無法進行分散式處理,只能垂直擴充,像是傳統 RDBMS 為了實現 ACID 所受到的限制。當然 RDBMS 也是可以透過一些 Shard 技巧實現 AA Mode,這個以後我們會談到。

AA 容錯模式 (Active/Active Mode)

就是同時在線模式,提供兩個以上的節點提供服務,彼此之間服務與資料互相備援。這樣的模式下兩個節點同時都可以提供服務,大多數的情況透過非同步的方式同步資料,由於是非同步作業,這樣的機制有可能會違反資料庫 ACID 的設計,資料同步不是即時的,但是在某些業務流程下是可以接受極短時間的資料同步問題,目前來說 RDBMS A/A 的機制已經算是成熟的應用技術。

以上兩種高可用架構,我們可以發現其實都時透過資料冗餘 (Data Redundancy) 來來實現高可用。此外,其實還有第三種模式,就是分散式備援架構,這種模式更為複雜,但是可以同時解決計算能力與資料能力的水平擴充,複雜性更高也更強大。

分散式容錯模式 (Decentralized Architecture)

分散式架構最迷人的地方就是動態水平擴充,這樣的分散式系統同常除了運算可以分散,也可以實現資料分散。相對於前面提到的 MS 與 AA 架構,在低服務請求量的場景下,分散式系統通常沒有辦法發揮功效,殺雞用牛刀速度也比不上單節點的架構,但是一旦需要應付大量服務請求,分散式系統就能提供最佳的解決方案。

目前大型的系統常常會出現這樣的架構,隨著業務需求量的增加來動態擴增節點,增加整體服務的吞吐量。但是這樣的系統在資料處理上常常需要「平衡演算法」來支撐,維護性與複雜度也會比較高,在選用技術的時候一定要更加小心。

透過 DNS 分散入口實現高可用的 Load Balance 架構

除了上述服務執行的高可用架構以外,此外還有一些可以輔助實現的高可用技巧。

使用網路雲端服務第一個接觸的就是網址,因此我們從網址開始談起。由於 DNS 本來的設計就是高可用,除了區域分流CDN (Content Distribution Network) 之外,基本上不需要多做設計,只要 Domain 正確能夠解析到 IP Address 即可,目前的 DNS Master, Slave Server 已經足夠使用。在 IP 可以靈活配置的 IaaS 環境下,DNS 設定時記得 TTL 別設太短或太長,多餘高頻的 DNS Query 會造成些許的服務等待時間,可以的話盡量避免。

當 Domain 正確解析到 IP Address 之後,再來就是建立 TCP/IP 連線了,能夠承載大量在線使用者的系統,入口的 IP 都不是實際執行服務的主機,這些 IP 會對應到的一個 (或多個) 用來派送服務的 Load Balance 系統。雖然 Load Balance 很重要也不太會出問題,但只要是東西就會壞,為了不讓單一 Load Balance 造成 SPOF 我們可以將提供服務的 Domain Name 同時設定多組 A Record 來分散流量,相當於一組 DNS 解析到一群 IP Address,至少在 Load Balance 或 HTTP Proxy 故障的時候 (或者乖乖過期) 不至於造成毀滅性的服務中斷,只會影響部份服務區域或使用者,也可以替維運爭取一些故障排除時間。

今天先介紹概念,後續會提到更多實現的技巧,如果您已經大量使用 PaaS, BaaS 這樣 Server-less 的服務來打造系統,在服務高可用的實現上已經由底層的廠商實作,就不必大費心力自行建置。但如果您需要自行打造高可用系統,可以選擇適合的高可用架構進行實作,讓您的系統穩定性更高。