AWS Re:cap 06: Amazon Aurora HA 與 DR 的全球韌性設計模式 (DAT442)

影片： https://www.youtube.com/watch?v=TNURufOhu_A

Aurora 的效能方法

為提升效能而加入複本

● 將讀取流量卸載至複本，降低對主要寫入器的影響。

● 將複本專用於特定工作負載（例如分析），可隔離吵雜鄰居。

● 最多可加入 15 個複本，以精細管理效能。

● 儲存空間擴展：

● Aurora 中的儲存容量與效能會自動擴展，不需要手動佈建。

● 執行個體擴展：

● 可加入不同大小的執行個體（例如 16XL、8XL、4XL），以進行容錯移轉與效能管理。

● DB 執行個體具有彈性，可從 0 擴展至 256 個 Aurora capacity units。

● 定義容錯移轉層，以根據大小與容量管理執行個體容錯移轉順序。

● 彈性執行個體有助於管理工作負載尖峰，且不會產生長期成本影響。

挑戰：Aurora 中的連線管理

● 管理多個執行個體的連線，尤其是識別用於交易的寫入器。

● 技巧：

● 為每個 DB 執行個體建立連線集區並限制連線數，避免重新連線。

● 驅動程式架構：

● Spring 與 JDBC 等標準作法可能無法有效處理叢集資料庫。

Aurora 端點

寫入器端點

● 一律指向目前的寫入器節點，以利一致地路由交易。

● 讀取器端點：

● 指向讀取作業的執行個體集區，使用 DNS 循環配置進行粗略的負載平衡。

● 自訂端點：

● 可為特定使用案例（例如分析）建立自訂端點。

AWS Advanced Wrapper Drivers

快速驅動程式

● 對叢集狀態有深入瞭解的強化驅動程式，可加快容錯移轉。

● RDS Proxy：

● 用於管理連線與縮短容錯移轉時間的額外工具。

● 外掛程式：

● 強化容錯移轉、重寫分割、藍綠部署。

多區域韌性

● 挑戰：如果區域故障或與網路中斷連線，如何確保業務持續運作。

● 解決方案：在另一個區域維護一份副本，以最低成本使其保持最新狀態，並將其用於各種用途。

● 使用 Aurora Global Database 實現多區域韌性：

● Aurora Global Database 允許 AMS 與 APG 最多使用 10 個次要區域。

● 內部複寫伺服器處理區域間的非同步實體複寫。

● 頭節點不會參與，避免邏輯複寫所帶來的效能負擔。

● 組態與效益：

● 區域 A：具有複本與儲存空間的主要區域。

● 區域 B：最初僅有儲存空間的次要區域，可加入唯讀執行個體供本機讀取。

● 可採用非對稱組態；次要區域中的執行個體不需要與主要區域相符。

● RPO 延遲通常約為 1 秒，視區域配對距離而定。

● 全域端點與容錯移轉：

● 全域端點管理主要區域的識別。

● 區域 A 發生故障時，會管理容錯移轉至區域 B；由於採用非同步複寫，可能會遺失資料。

● 使用 Route 53 資料平面重新指向全域端點，以快速重新導向。

● 切換：

● 在兩個區域都健康時執行切換。

● 通知區域 A 停止作為主要區域，並由區域 B 成為主要區域。

● 可在區域間快速轉換而不造成中斷。

● 切換程序：

● 將特殊日誌記錄（標記日誌記錄）插入日誌記錄串流。

● 另一端會識別該標記，並在指定的日誌時間成為主要區域。

● 區域 A 會同時停止作為主要區域，確保順暢交接。

● 結果是 RPO 為零，且 RTO 非常低（約 30 秒）。

維護與升級

● 版本升級（例如 PostgreSQL 16 至 PostgreSQL 17）與 OS 修補程式不可或缺。

● 自行管理的系統需要停機、建立用於復原的快照、相容性測試及效能測試。

● Aurora 為次要版本與修補程式升級提供全受管且自動化的體驗。

● 現已提供滾動式作業系統升級，可提高可用性。

● 維護動作可定義在指定時段內執行，或由 Aurora 自動管理。

● AWS Health Dashboard 提供維護通知。

● 強烈建議選擇加入維護自動化。

● AWS Organization 的升級推出政策：

● 用於管理開發、QA 與生產環境中多個 DB 叢集升級的新功能。

● 簡化 DB 叢集機群生命週期管理的自動化。

● 可根據 AWS organization 內多個資源的標籤設定升級政策。

● 範例：

● 標記為 Prod 的資源最後升級；dev 資源最先升級。

● 預設行為：沒有可辨識標籤的資源第二順位升級。

● 升級推出包括將政策指派給資源、決定升級順序，然後在維護時段內分批進行。

● 若在維護時段內偵測到問題，可彈性停止升級。

● 就地升級：

● 若主要升級與開放原始碼不相容，則執行就地升級。

● 包括建立資料庫叢集的複製、升級複製，並使用應用程式進行測試。

● 驗證完成後，捨棄複製，並將升級套用至生產叢集。

● 藍綠部署：

● 對主要升級、結構描述變更或靜態參數變更而言更具彈性的方法。

● 建立新環境（ Green ），同時使用邏輯複寫使其與舊環境（ Blue ）保持同步。

● 可先在綠色環境中測試升級，再將其提升至生產環境。

● 切換時重新命名資源以維持一致性，最快只需一分鐘即可完成。

● 藍綠部署現已適用於跨多個區域的全域資料庫。

● Aurora APG 與 AMS 功能摘要：

● 加入複本以提高可用性並啟用容錯移轉。

● 使用 AWS Advanced Rapid Drivers，讓容錯移轉程序更順暢。

● 使用 Global Database，在最多 10 個次要區域中提供耐久性與可用性。

● 低延遲的本機區域讀取，以及透過全域端點簡化端點管理。

● 受管且自動化的叢集整體升級、快速複製，以及用於維護的藍綠部署。

Aurora DSQL 簡介

● Amazon Aurora DSQL 是適用於永遠可用應用程式、速度最快的無伺服器分散式 SQL 資料庫。Aurora DSQL 提供速度最快的多區域讀取與寫入。它讓客戶能輕鬆擴展以滿足任何工作負載需求，且不需要管理基礎設施，維護也不會停機。

● 結合關聯式資料庫、分散式資料庫架構與無伺服器服務的各項優點。

● 專為執行複雜查詢、向外擴展及提供按用量付費定價而設計。

● DSQL 架構概觀：

● 與在 EC2 上執行的自行管理 PostgreSQL 比較。

● DSQL 每個連線使用一個查詢處理器，類似 PostgreSQL 後端程序。

● 讀取查詢會直接傳送至 DSQL 儲存引擎。

● 寫入會緩衝在查詢處理器的記憶體中，直到提交為止。

● 提交時，交易會傳送至 Adjudicator 進行並行控制，再傳送至 Journal 以確保持久性，並複寫至至少 2 個 AZ。

● Journal 用於更新儲存空間，類似傳統 PostgreSQL。

● DSQL 是主動-主動式服務，允許任何連線隨時讀取或寫入資料。

● 查詢處理器 (QP) 可在不同主機或可用區上執行。

● DSQL 中的可用性：

● 資料庫節點故障時，查詢處理器 (QP) 會偵測故障，並將流量轉移至健康的複本。

● 複本可位於相同或不同的可用區。

● 進行中的作業可能因重試而略微增加延遲。

● DSQL 會持續備份資料並自動替換故障節點。

● 替換節點會連線至 Journal，以追上最新資料。

● 流量會轉移回本機複本，以獲得最佳效能。

● 並行控制與持久性：

● Adjudicator 處理並行控制與衝突解決。

● 單一 Adjudicator 不需要網路協調，即可快速解決衝突。

● 其他可用區中會維持待命 adjudicator，以進行容錯移轉。

● 發生故障時，待命 adjudicator 會執行領導者協定以選出新的領導者。

● 查詢處理器會針對新的領導者 adjudicator，重試進行中的提交。

● 此程序順暢無縫，不需要應用程式採取任何動作。

DSQL 中的高可用性

● DSQL 的設計沒有單一故障點。

● 主動-主動式架構提供立即可用的高可用性。

● DSQL 的設計可自動擴展以處理增加的負載。

● 並行控制協定：

● DSQL 使用開放式並行控制，假設交易很少發生衝突。

● 衝突會導致序列化失敗錯誤，並要求用戶端重試交易。

● 應用程式應處理重試及開放式並行控制問題。

● 建議建立輔助函式，或將處理機制納入最低層的應用程式層。

● 避免不必要的衝突：

● 設計應用程式時盡量減少不必要的衝突，以降低重試次數。

● 更新不同行的交易可同時提交而不會發生衝突。

● 內部分片與擴展：

● DSQL 會自動在內部進行分片，以處理 adjudicator 與 journal 上增加的負載。

● 查詢處理器會將提交導向適當的分片。

● 最佳化的兩階段提交可確保跨多個分片的不可部分完成交易。

● DSQL 會使新節點上線，並在複本間平衡負載，自動向外擴展。

● DSQL 中的複本一律具備強一致性，可順暢擴展。

● DSQL 中的一致性：

● DSQL 透過時間型同步協定確保強一致性。

● 使用 EC2 Time Sync Service 取得微秒準確度的時間戳記，並使用 Clockbound library 校正測量誤差。

● 保證提供可線性化的時間戳記，且一律晚於任何先前提交的時間戳記。

● 儲存空間會先等待 journal 的更新，再傳回資料列，以確保一致性。

兩階段提交 (2PC) 協定概觀

● 2PC 是一種分散式系統協定，可確保交易的所有參與者一起提交或中止。

● 它包含兩個階段：準備與提交/中止。

● 階段 1：準備階段：

● 協調器會向所有參與節點傳送「prepare」請求。

● 每個參與者都會執行交易工作、取得必要的鎖定，並將「prepared」記錄寫入其交易日誌。

● 參與者將「yes」或「no」票傳回協調器。

階段 2：提交/中止階段

如果所有參與者都投「yes」

● 協調器將「commit」記錄寫入日誌，並向所有參與者傳送「commit」訊息。

● 參與者提交交易、解除鎖定，並向協調器傳送確認。

● 如果任何參與者投「no」：

● 協調器將「abort」記錄寫入日誌，並向所有參與者傳送「abort」訊息。

● 參與者復原交易並解除所有鎖定。

● 主要考量：不可部分完成性：

● 2PC 保證交易不可部分完成，不是在所有節點上完成，就是在所有節點上完全失敗。

● 一致性：

● 確保多個節點的資料一致性，但可能因封鎖及等待決策而影響可用性。

● 故障處理：

● 包含從故障復原的機制；協調器故障可能導致「in-doubt」狀態，需要手動介入。

DSQL 中的連線管理

● DSQL 的連線由工作階段路由層管理。

● 即使網路事件造成波動，也能確保連線快速可用。

● 維持已暖機的查詢處理器 (QP) 集區，可立即使用。

● 要求連線時，DSQL 會從集區指派可用的 QP。

● 處理連線故障：

● 發生連線故障時，應用程式必須偵測故障並重試。

● 開放式並行控制一節中的重試處理常式適合用於此用途。

● 應用程式應針對連線錯誤實作重試邏輯，以維持可用性。

● 與儲存空間及 adjudicator 故障不同，應用程式必須手動重新建立失敗的連線。

● DSQL 強制連線的生命週期上限為 1 小時，以鼓勵正確管理連線。

● 連線管理最佳實務：

● 使用具有運作狀態檢查及連線存留時間上限的用戶端連線集區程式庫（例如 Java C3PO）。

● DSQL 本身已包含連線集區，因此不需要伺服器端集區（例如 PG Bouncer、RDS Proxy）。

● 建議連線至相同可用區中的 QP，以降低延遲。

● 如果目前的可用區無法使用，DSQL 會自動容錯移轉至健康的可用區。

DSQL 中的多區域叢集

● DSQL 藉由在兩個區域中建立叢集，並將第三個區域指定為見證區域，以支援多區域叢集。

● 見證區域保有一份 journal 副本，以利針對區域故障執行以仲裁為基礎的協定。

● 應用程式可在不同區域中保持作用中，兩個區域都能處理讀取與寫入。

● 以仲裁為基礎的協定

● 是分散式系統用來確保資料一致性、容錯能力與可靠性的方法，要求至少一定數量的參與節點（仲裁數）同意某項作業，該作業才會視為有效。

● S3 以仲裁為基礎的協定：

● 在分散式系統中，「Quorum」意指「構成會議所需的最低成員人數。」

● Quorum 機制是一種投票演算法，用來確保 Amazon S3 等分散式儲存系統中的資料備援與一致性。

● 核心概念與術語：

● 讀取仲裁數 (Vr)：最低讀取票數

● 寫入仲裁數 (Vw)：最低寫入票數

● 總票數 (V)

● 運作原理：

● 假設分散式系統中有 V 個資料複本。

● 為確保資料一致性，讀取與寫入作業必須取得節點確認的「quorum」。

● 核心規則：

● Vr + Vw > V：確保不會同時讀取及寫入相同資料，避免讀寫衝突。

● Vw > V / 2：確保資料修改序列化，防止兩個寫入作業同時修改資料。

● 調整 Vr 與 Vw，可讓系統在讀取與寫入效能之間取得平衡。

● 關於 Amazon S3：

● Amazon S3 於 2020 年宣布，所有 GET、PUT 與 LIST 作業都具備強一致性。

● 寫入的資料可立即讀取為最新版本，簡化巨量資料工作負載。

● S3 透過其架構保證高度耐久性與可用性，該架構會將資料複本儲存在至少三個可用區。

處理區域故障

● 發生區域故障（例如區域 B 故障）時，見證區域有助於釐清故障，並投票將故障區域排除於仲裁之外。

● DSQL 會自動重新設定 journal 以排除故障區域，確保叢集在健康區域（區域 A）中保持可用。

● 不會遺失資料，且交易會繼續複寫到至少一個其他 AWS 區域。

● 故障區域（區域 B）重新上線時，DSQL 會偵測該區域、將其更新至最新狀態，並還原多區域組態。

● 建議模式：在兩個區域中，將應用程式與叢集一同部署，以實現主動式備援。

● 主動式備援的效益：

● 將應用程式與叢集一同部署至多個區域，可提供低延遲，並持續驗證應用程式功能。

● 使用全域端點（例如 Route 53 DNS record），將流量導向最近且可用的健康區域。

● 使用全域端點處理區域故障：

● 發生區域故障時，資料不會遺失，且 DNS 會自動將流量導向健康區域。

● 持續驗證可確保健康區域正常運作。

● DSQL 中的維護：

● DSQL 是全受管服務，不需要客戶進行維護。

● 查詢程序會定期替換為更新版本，確保使用最新 OS、安全性修補程式、效能改善與功能。

● 客戶不需要執行任何維護工作。

● 重點：

● Aurora 提供三種引擎：PostgreSQL、MySQL 與 DSQL。

● 所有引擎預設皆提供 3 AZ 耐久性。

● 擴展選項各異：APG 與 AMS 針對寫入向上擴展、針對讀取向外擴展；DSQL 則提供免手動操作的自動擴展。

● 多區域考量：APG 與 AMS 可測試容錯移轉而不遺失資料；DSQL 支援跨區域主動-主動。

● 所有引擎都提供輕鬆的維護方式，包括自動化安全性更新與次要版本升級。