本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Amazon ElastiCache Well-Architected Lens 可靠性支柱
可靠性支柱著重於執行其預期函數的工作負載,以及如何從失敗中快速復原以滿足需求。關鍵主題包括分散式系統設計、復原規劃和適應不斷變化的需求。
主題
REL 1:您如何支援高可用性 (HA) 架構部署?
問題層級簡介:了解 Amazon 的高可用性架構 ElastiCache 可讓您在可用性事件期間以彈性狀態運作。
問題層級優點:建構ElastiCache 叢集以適應故障,可確保 ElastiCache 部署的可用性更高。
-
【必要】 判斷叢集所需的可靠性層級 ElastiCache 。不同的工作負載具有不同的彈性標準,從完全暫時性工作負載到關鍵任務工作負載都有。為您操作所在的每一種環境 (例如開發、測試和生產) 定義需求。
快取引擎: ElastiCache (Memcached) vs ElastiCache (Redis OSS)
-
ElastiCache (Memcached) 不提供任何複寫機制,主要用於暫時性工作負載。
-
ElastiCache (RedisOSS) 提供下列討論的 HA 功能
-
-
【最佳】 對於需要 HA 的工作負載,請在叢集模式下使用 ElastiCache (Redis OSS),每個碎片至少有兩個複本,即使是只需要一個碎片的小型輸送量需求工作負載也是如此。
-
若叢集模式已啟用,則會自動啟用多可用區。
多可用區可在進行任何規劃或意外的維護工作以及減少可用區域故障時。藉由自動從主節點容錯移轉至複本的方式,將停機時間降至最低。
-
對於碎片工作負載,由於 Valkey 或 Redis OSS叢集通訊協定需要大多數主要節點才能達到數量,因此至少有三個碎片可在容錯移轉事件期間提供更快的復原。
-
在整體可用性中設定兩個或多個複本。
若有兩個複本,就能在其中一個複本進行維護的情況下,改善讀取可擴展性以及讀取可用性。
-
使用以 Graviton2 為基礎的節點類型 (大多數區域中的預設節點)。
ElastiCache (Redis OSS) 已在這些節點上新增最佳化效能。因此,您可以獲得更好的複寫和同步處理效能,進而改善整體可用性。
-
監控和調整大小以處理預期的流量峰值:在繁重負載下, ElastiCache (Redis OSS) 引擎可能會變得無回應,這會影響可用性。
DatabaseMemoryUsagePercentage
BytesUsedForCache
是記憶體用量的良好指標,而ReplicationLag
是根據您的寫入速率的複寫運作狀態指標。您可以使用這些指標來觸發叢集擴展。 -
在生產容錯移轉事件 API之前
,使用容錯移轉進行測試,以確保用戶端恢復能力。
[資源]:
-
REL 2:您如何透過 達成復原點目標 (RPOs)ElastiCache?
問題層級簡介:了解工作負載RPO,為 ElastiCache 備份和復原策略的決策提供資訊。
問題層級優點:擁有就地RPO策略可以改善災難復原案例的業務連續性。設計備份和還原政策可協助您滿足 ElastiCache 資料的復原點目標 (RPO)。 ElastiCache (Redis OSS) 提供儲存在 Amazon S3 中的快照功能,以及可設定的保留政策。這些快照會在定義的備份時段拍攝,並由服務自動處理。如果您的工作負載需要更精細程度的備份,您可以選擇每天最多建立 20 個手動備份。手動建立的備份不受服務保留政策的約束,可以無限期保留。
-
【必要】 了解並記錄 ElastiCache 部署RPO的 。
-
請注意,Memcached 不提供任何備份程序。
-
檢閱 ElastiCache Backup and Restore 功能的功能。
-
-
[最佳] 備妥通訊良好的程序來備份叢集。
-
視需要啟動手動備份。
-
檢閱自動備份的保留政策。
-
請注意,手動備份將無限期保留。
-
將自動備份排程在低使用量的期間進行。
-
針對讀取複本執行備份操作,以確保對叢集效能的影響降到最低。
-
-
【良好】 利用 的排程備份功能 ElastiCache ,在定義的時段期間定期備份您的資料。
-
定期測試從備份還原的程序。
-
-
[資源]:
REL 3:您如何支援災難復原 (DR) 要求?
問題層級簡介:災難復原是任何工作負載規劃的重要層面。 ElastiCache (Redis OSS) 提供多種選項,可依據工作負載彈性需求實作災難復原。使用 Amazon ElastiCache Global Datastore,您可以寫入一個區域中的 ElastiCache (RedisOSS) 叢集,並可從其他兩個跨區域複本叢集讀取資料,從而實現跨區域的低延遲讀取和災難復原。
問題難易度優點:了解各種災難情境並規劃因應措施,就可確保業務連續性。災難復原策略必須在成本、效能影響和可能的資料遺失之間取得平衡。
-
【必要】 根據工作負載需求開發並記錄所有 ElastiCache 元件的 DR 策略。 ElastiCache 在部分使用案例中,完全短暫且不需要任何 DR 策略,而其他則位於頻譜的另一端,且需要非常強大的 DR 策略。所有選項都必須針對成本最佳化加以權衡,也就是說,彈性越大,所需的基礎設施數量也越多。
了解區域層級和多區域層級可用的災難復原選項。
-
建議採用多可用區部署來防範可用區域故障。請務必在多可用區域架構中啟用叢集模式進行部署,其中至少 3 個AZs可用。
-
建議使用全域資料存放區來防範區域故障。
-
-
[最佳] 針對需要區域層級彈性的工作負載啟用全域資料存放區。
-
制定計劃,以在主要區域降級時容錯移轉至次要區域。
-
在生產環境中進行容錯移轉之前,先測試多區域容錯移轉程序。
-
監控
ReplicationLag
指標,以了解容錯移轉事件期間資料遺失可能造成的影響。
-
-
[資源]:
REL 4:您如何有效地規劃容錯移轉?
問題層級簡介:使用自動容錯移轉啟用多可用區域是 ElastiCache 最佳實務。在某些情況下, ElastiCache (Redis OSS) 會取代主要節點,作為服務操作的一部分。範例情況包括規劃的維護事件,以及少見的節點故障或可用區域問題。成功的容錯移轉取決於 ElastiCache 和用戶端程式庫組態。
問題層級優點:搭配特定 ElastiCache (Redis OSS) 用戶端程式庫,遵循 ElastiCache 容錯移轉的最佳實務,有助於減少容錯移轉事件期間的潛在停機時間。
-
[必要] 若叢集模式已停用,請使用逾時,如此用戶端就能偵測出是否需要與舊的主節點中斷連線,並使用更新的主要端點 IP 地址重新連線至新的主節點。若叢集模式已啟用,則用戶端程式庫會負責偵測基礎叢集拓撲中的變更。這最常透過 ElastiCache (Redis OSS) 用戶端程式庫中的組態設定來完成,這也可讓您設定頻率和重新整理方法。每個用戶端程式庫都提供自己的設定,如需詳細資訊,可參閱各自對應的文件。
[資源]:
-
檢閱 ElastiCache (Redis OSS) 用戶端程式庫的最佳實務。
-
[必要] 容錯移轉成功與否,取決於主節點和複本節點之間是否有運作狀態良好的複寫環境。檢閱並了解 Valkey 和 Redis OSS複寫的非同步性質,以及主要節點和複本節點之間複寫延遲要報告的可用 CloudWatch 指標。對於需要更大資料安全的使用案例,請利用 WAIT命令強制複本在回應連線的用戶端之前確認寫入。
[資源]:
-
【最佳】 使用 ElastiCache測試容錯移轉 定期驗證容錯移轉期間應用程式的回應能力API。
[資源]:
REL 5:您的 ElastiCache 元件是否設計用於擴展?
問題層級簡介:透過了解擴展功能和可用的部署拓撲,您的 ElastiCache元件可以隨著時間調整,以滿足不斷變化的工作負載需求。 ElastiCache 提供 4 向擴展:進/出 (水平) 以及上/下 (垂直)。
問題層級優點:遵循 ElastiCache 部署的最佳實務可提供最大的擴展彈性,並符合水平擴展的 Well Architected 原則,以將失敗的影響降至最低。
-
[必要] 了解叢集模式已啟用與叢集模式已停用的拓撲之間的差異。幾乎所有情況下都建議您在叢集模式已啟用時進行部署,因為這樣就能隨著時間提供更高的可擴展性。叢集模式已停用的元件會在藉由新增讀取複本進行水平擴展的能力上受到限制。
-
[必要] 了解擴展的時機和方式。
-
如需更多 READIOPS:新增複本
-
如需更多 WRITEOPS:新增碎片 (橫向擴展)
-
如需更多網路 IO:使用網路最佳化的執行個體,縱向擴展
-
-
【最佳】 在啟用叢集模式的情況下部署 ElastiCache 元件,偏向更多、更小的節點,而不是更少、更大型的節點。這樣做可有效地限制節點故障的影響範圍。
-
[最佳] 在叢集中包含複本,以增強擴展事件期間的回應能力
-
【良好】 對於停用的叢集模式,請利用僅供讀取複本來提高整體僅供讀取容量。 ElastiCache 已支援停用叢集模式最多 5 個僅供讀取複本,以及垂直擴展。
-
[資源]: