Amazon ElastiCache Well-Architected Lens 卓越運作支柱 - Amazon ElastiCache
OE 1：如何了解及回應 ElastiCache 叢集觸發的警示和事件？OE 2：何時及如何擴展您現有的 ElastiCache 叢集？OE 3：如何管理 ElastiCache 叢集資源並讓叢集保持最新狀態？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 產生的事件。將 ElastiCache 設定為使用 Amazon Simple Notification Service (Amazon SNS) 傳送重要叢集事件的通知。使用 Amazon SNS 搭配您的叢集，就可透過程式設計的方式對 ElastiCache 事件採取行動。

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

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

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

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

    • [資源]：

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

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

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

問題難易度簡介：將 ElastiCache 叢集調整成適當規模是一種平衡動作，只要基礎工作負載類型發生變更就需評估該動作。您的目標是讓您的工作負載在適當規模的環境下運作。

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

OE 3：如何管理 ElastiCache 叢集資源並讓叢集保持最新狀態？

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

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

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

    [資源]：

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

    [資源]：

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

問題難易度簡介：大規模操作時，您需要了解用戶端如何與 ElastiCache 叢集連線，以便管理應用程式操作層面 (例如回應時間)。

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

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

    [資源]：

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

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

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

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

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

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

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

    • 使用管道傳輸可減少應用程式用戶端與叢集之間的往返時間 (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：如何規劃故障因應措施及減少故障？

問題難易度簡介：卓越運作包括執行定期的「預先檢測」活動來預測故障情形，以找出可能的故障來源，有利於及早將其移除或緩解。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 引擎記錄功能已啟用，該功能自適用於 Redis OSS 和更新版本的 ElastiCache 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 Log 群組建立查詢，該日誌將傳回 LogLevel 為「WARNING」的事件，例如：

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

    [資源]：使用 CloudWatch Logs Insights 分析日誌資料