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