Amazon ElastiCache Well-Architected Lens 卓越營運支柱 - Amazon ElastiCache
OE 1：您如何了解和回應 ElastiCache 叢集觸發的警示和事件？OE 2：您何時以及如何擴展現有 ElastiCache 叢集？OE 3：如何管理 ElastiCache 叢集資源和維護叢集 up-to-date？OE 4：如何管理用戶端與 ElastiCache 叢集的連線？OE 5：如何部署工作負載的 ElastiCache 元件？OE 6：如何規劃故障因應措施及減少故障？OE 7：如何對 Valkey 或 Redis OSS引擎事件進行疑難排解？

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon ElastiCache Well-Architected Lens 卓越營運支柱

卓越營運支柱著重於執行和監控系統，以提供商業價值並持續改善流程和程序。重要主題包括自動化變更、回應事件，以及定義管理日常作業的標準。

OE 1：您如何了解和回應 ElastiCache 叢集觸發的警示和事件？

問題層級簡介：當您操作ElastiCache 叢集時，您可以選擇在特定事件發生時接收通知和提醒。 依預設 ElastiCache， 會記錄與資源相關的事件，例如容錯移轉、節點取代、擴展操作、排程維護等。每個事件都包含日期與時間、來源名稱與來源類型，以及說明。

問題難易度優點：只要能夠了解並管理觸發叢集產生警示的事件背後的基本原因，就能更有效地操作並適當回應事件。

  • 【必要】 在 ElastiCache 主控台ElastiCache 上檢閱 產生的事件 （選取您的區域之後），或使用 Amazon Command Line Interface （AWS CLI） describe-events 命令和 ElastiCache API。設定 ElastiCache 使用 Amazon Simple Notification Service （Amazon ） 傳送重要叢集事件的通知SNS。將 Amazon SNS與叢集搭配使用，可讓您以程式設計方式對 ElastiCache 事件採取動作。

    • 事件分成兩大類：目前事件和排定事件。目前事件的清單包括：資源建立和刪除、擴展操作、容錯移轉、節點重新啟動、快照建立、叢集參數修改、CA 憑證更新、失敗事件 （叢集佈建失敗 - VPC或 ENI-、擴展失敗 - ENI- 和快照失敗）。排定事件清單包括：排定在維護時段進行更換的節點，以及重新排定的節點更換作業。

    • 雖然您不需要立即回應其中一些事件，但務必先查看所有失敗事件：

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

      • ElastiCache：SnapshotFailed （OSS僅限 Valkey 或 Redis）

    • [資源]：

  • 【最佳】 若要自動回應事件，請利用 AWS 和 SNS Lambda Functions 等產品和服務功能。遵循最佳實務進行小量、頻繁、可恢復的變更，以程式碼形式隨著時間讓您的操作演進。您應該使用 Amazon CloudWatch 指標來監控叢集。

    【資源】：使用 AWS Lambda、Amazon Route 53 和 Amazon 監控 ElastiCache （Redis OSS） （停用叢集模式） 僅供讀取複本端點SNS使用 Lambda 和 的使用案例SNS。

OE 2：您何時以及如何擴展現有 ElastiCache 叢集？

問題層級簡介：正確調整ElastiCache 叢集大小是一種平衡行為，每次基礎工作負載類型發生變更時都需要評估。您的目標是讓您的工作負載在適當規模的環境下運作。

問題難易度優點：資源過度利用可能會導致延遲增加且整體效能降低。另一方面來說，使用不足可能會導致資源過度佈建，而以非最佳成本最佳化。只要適當調整環境的規模，您就能在效能效率與成本最佳化之間取得平衡。若要修復資源的過度或不足使用， ElastiCache 可以兩維擴展。您可以增加或減少節點容量來垂直擴展。您也可以新增和移除節點來水平擴展。

OE 3：如何管理 ElastiCache 叢集資源和維護叢集 up-to-date？

問題層級簡介：大規模操作時，您必須能夠精確找出所有 ElastiCache資源。推出新的應用程式功能時，您需要在所有 ElastiCache 環境類型之間建立叢集版本對稱性：開發、測試和生產。資源屬性可讓您針對不同的操作目標分隔環境，例如在推出新功能和啟用新的安全機制時。

問題難易度優點：將開發、測試和生產環境加以分隔，是最佳操作實務。在整個環境中利用充分了解並妥善記載的程序對叢集和節點套用最新的軟體修補程式，同樣也是最佳實務。利用原生 ElastiCache 功能，您的工程團隊可以專注於實現業務目標，而不是 ElastiCache 維護。

  • 【最佳】 在可用的最新引擎版本上執行，並在自助服務更新可用時立即套用。在您指定的叢集維護時段期間 ElastiCache 自動更新其基礎基礎設施。不過，叢集中執行的節點則會透過自助式更新進行更新。這些更新有兩種類型：安全修補程式或次要軟體更新。您務必了解修補程式類型的差異，以及套用的時機。

    [資源]：

  • 【最佳】 使用標籤組織 ElastiCache 資源。在複寫群組上使用標籤，而非在個別節點上使用。您可以設定在查詢資源時顯示的標籤，也可以使用標籤來執行搜尋和套用篩選器。您可使用資源群組輕鬆建立和維護擁有共同標籤集的資源集合。

    [資源]：

OE 4：如何管理用戶端與 ElastiCache 叢集的連線？

問題層級簡介：大規模操作時，您需要了解用戶端如何與 ElastiCache 叢集連線，以管理您的應用程式操作方面 （例如回應時間）。

問題難易度優點：選擇最合適的連線機制，可確保應用程式不會因為連線錯誤 (例如逾時) 而中斷連線。

  • [必要] 將讀取與寫入操作分開，並連線至複本節點來執行讀取操作。但是，請注意，當您將寫入與讀取區分開時，由於 Valkey 和 Redis OSS複寫的非同步性質，在寫入金鑰之後，您將失去立即讀取金鑰的能力。該WAIT命令可以利用 來改善真實世界的資料安全，並強制複本在回應用戶端之前確認寫入，且整體效能成本為 。使用複本節點進行讀取操作時，可以使用停用叢集模式的 ElastiCache 讀取器端點，在 ElastiCache （Redis OSS） 用戶端程式庫中設定複本節點。對於啟用的叢集模式，請使用 ElastiCache （Redis OSS） READONLY命令。對於許多 ElastiCache （Redis OSS） 用戶端程式庫， ElastiCache （Redis OSS） READONLY 預設會實作或透過組態設定實作。

    [資源]：

  • [必要] 使用連線集區。建立TCP連線在用戶端和伺服器端都有CPU時間成本，而集區可讓您重複使用TCP連線。

    為了減少連線額外負荷，建議您使用連線集區。有了連線集區，您的應用程式就可以「隨意」重複使用和釋出連線，而不會因建立連線而產生成本。您可以透過 ElastiCache （Redis OSS） 用戶端程式庫 （如果支援） 實作連線集區，並搭配適用於應用程式環境的架構，或從頭開始建置。

  • [最佳] 確實將用戶端的通訊端逾時設定為至少 1 秒 (相較於數個用戶端中的一般預設值「無」)。

    • 若設定的逾時值太低，可能導致伺服器負載較高時發生逾時。若設定的值太高，則可能導致您的應用程式花費很長的時間來偵測連線問題。

    • 藉由在用戶端應用程式中實作連線集區來控制新連線的數量。這可減少開啟和關閉連線所需的延遲和CPU使用率，並在叢集上TLS啟用 時執行TLS交握。

    【資源】：設定 ElastiCache （Redis OSS） 以獲得更高的可用性

  • [良好] 使用管道傳輸 (您的使用案例允許的話) 可大幅提高效能。

    • 透過管道，您可以減少應用程式用戶端與叢集之間的往返時間 （RTT），即使用戶端尚未讀取先前的回應，也可以處理新的請求。

    • 使用管道傳輸可一次將多個命令傳送至伺服器，而不需等待回覆/確認。管道傳輸的缺點在於，當您最後大量截取所有回應時，可能已有錯誤發生，但您直到最後才察覺到。

    • 當傳回錯誤而忽略錯誤請求時，實作方法來重試請求。

    [資源]：管道傳輸

OE 5：如何部署工作負載的 ElastiCache 元件？

問題層級簡介：ElastiCache 環境可以透過 AWS 主控台手動部署，或透過 APIs、CLI、工具組等以程式設計方式部署。卓越運作最佳實務建議您，盡可能透過程式碼自動化部署。此外， ElastiCache 叢集可以依工作負載隔離，也可以為了成本最佳化目的而合併。

問題層級優點：選擇最適合您 ElastiCache 環境的部署機制，可隨著時間改善卓越營運。建議您盡可能以程式碼形式執行操作，以便盡量減少人為錯誤並增加事件的重複能力、彈性和回應時間。

透過了解工作負載隔離需求，您可以選擇每個工作負載都有專用 ElastiCache 環境，或將多個工作負載合併為單一叢集，或其組合。了解當中的權衡，有助於在卓越運作和成本最佳化之間取得平衡

  • 【必要】 了解 可用的部署選項 ElastiCache，並盡可能將這些程序自動化。自動化的可能途徑包括 CloudFormation、 AWS CLI/ SDK和 APIs。

    [資源]：

  • [必要] 為所有工作負載決定所需的叢集隔離層級。

    • [最佳]：高度隔離 - 工作負載對叢集的對應為 1:1。允許對每個工作負載 ElastiCache 的資源存取、調整大小、擴展和管理進行最精細的控制。

    • [較佳]：中度隔離 - 依用途採 M:1 隔離，但可能跨多個工作負載共用 (例如，一個叢集專門用來快取工作負載，而另一個叢集專門用來傳訊)。

    • [良好]：低度隔離 - 所有用途均採 M:1 隔離，完全共用。建議用於可接受共用存取的工作負載。

OE 6：如何規劃故障因應措施及減少故障？

問題層級簡介：卓越營運包括透過執行定期的 "mortem 前期" 練習來預測失敗，以識別潛在的失敗來源，以便移除或緩解失敗。 ElastiCache 提供容錯移轉，API允許模擬節點失敗事件用於測試目的。

問題難易度優點：透過提前測試故障情況，您就可以了解它們如何影響您的工作負載。這樣就能安全測試回應程序及其有效性，並且讓您的團隊熟悉其執行過程。

【必要】 在開發/測試帳戶中定期執行容錯移轉測試。 TestFailover

OE 7：如何對 Valkey 或 Redis OSS引擎事件進行疑難排解？

問題層級簡介：卓越營運需要能夠調查服務層級和引擎層級資訊，以分析叢集的運作狀態和狀態。 ElastiCache 可以將 Valkey 或 Redis OSS引擎日誌傳送至 Amazon CloudWatch 和 Amazon Kinesis Data Firehose

問題層級優點：在 ElastiCache 叢集上啟用 Valkey 或 Redis OSS引擎日誌，可讓您深入了解影響叢集運作狀態和效能的事件。Valkey 或 Redis OSS引擎日誌會直接提供無法透過 ElastiCache 事件機制取得的引擎資料。透過仔細觀察 ElastiCache 事件 （請參閱先前的 OE-1） 和引擎日誌，從ElastiCache 服務角度和引擎角度進行故障診斷時，可以判斷事件順序。

  • 【必要】 確保已啟用 Redis OSS引擎記錄功能，該功能自 ElastiCache （Redis OSS） 6.2 及更新版本起提供。此功能可在建立叢集期間啟用，或是在建立後，藉由修改叢集來啟用。

    • 判斷 Amazon CloudWatch Logs 或 Amazon Kinesis Data Firehose 是否為 Redis OSS引擎日誌的適當目標。

    • 在 CloudWatch 或 Kinesis Data Firehose 中選取適當的目標日誌，以保留日誌。如果您有多個叢集，請考慮讓每個叢集使用不同的目標日誌，因為這樣做有助於在故障診斷時隔離資料。

    [資源]：

  • 【最佳】 如果使用 Amazon CloudWatch Logs，請考慮利用 Amazon CloudWatch Logs Insights 查詢 Valkey 或 Redis OSS引擎日誌以取得重要資訊。

    例如，針對包含 Valkey 或 Redis OSS引擎日誌的 CloudWatch 日誌群組建立查詢，這些日誌將傳回具有「WARNING」 LogLevel 的 事件，例如：

    fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"

    【資源】：使用 Logs Insights 分析 CloudWatch 日誌資料