Amazon ElastiCache Well-Architected 的鏡頭營運卓越支柱 - Amazon ElastiCache (雷迪OSS斯)

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

Amazon ElastiCache Well-Architected 的鏡頭營運卓越支柱

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

OE 1:您如何瞭解並回應 ElastiCache 叢集觸發的警示和事件?

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

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

  • [必要] 在 ElastiCache 主控台 (選取您的區域之後) 或使用 Amazon 命令列界面 (AWS CLI) 描述-events 命令和. ElastiCache ElastiCache API 設定 ElastiCache 為使用 Amazon 簡單通知服務 (AmazonSNS) 傳送重要叢集事件的通知。將 Amazon SNS 與叢集搭配使用可讓您以程式設計方式在 ElastiCache 事件時採取動作。

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

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

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

      • ElastiCacheSnapshotFailed :( OSS 僅適用於 Redis)

    • [資源]:

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

    [資源]:使用 AWS Lambda、Amazon 路線 53 和亞馬遜監控 ElastiCache (RedisOSS) (叢集模式已停用) 僅SNS供讀取複本端點,以取得使用 Lambda 和SNS.

OE 2:何時以及如何擴展現有 ElastiCache 叢集?

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

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

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

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

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

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

    [資源]:

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

    [資源]:

OE 4:您如何管理客戶端與 ElastiCache 叢集的連線?

問題層級簡介:大規模運作時,您需要瞭解用戶端如何與 ElastiCache 叢集連線,以管理您的應用程式作業層面 (例如回應時間)。

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

  • [必要] 將讀取與寫入操作分開,並連線至複本節點來執行讀取操作。但是,請注意,當您將寫入與讀取分開時,由於 Redis OSS 複寫的非同步性質,您將失去寫入金鑰之後立即讀取金鑰的能力。您可以利用此WAIT命令來改善現實世界的資料安全性,並強制複本在回應用戶端之前確認寫入,而且需要支付整體效能成本。使用複本節點進行讀取作業,可以在您的 ElastiCache (RedisOSS) 用戶端程式庫中使用 ElastiCache 讀取器端點設定叢集模式停用。若要啟用叢集模式,請使用 ElastiCache (RedisOSS) READONLY 指令。對於許多 ElastiCache (RedisOSS)客戶端庫,默認情況下或通過配置設置實現 ElastiCache (Red READONLY isOSS)。

    [資源]:

  • [必要] 使用連線集區。建立TCP連接在客戶端和服務器端都有CPU時間成本,並且池允許您重複使用TCP連接。

    為了減少連線額外負荷,建議您使用連線集區。有了連線集區,您的應用程式就可以「隨意」重複使用和釋出連線,而不會因建立連線而產生成本。您可以通過 ElastiCache (RedisOSS)客戶端庫(如果支持)實現連接池,使用適用於您的應用程序環境的框架,或者從頭開始構建它。

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

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

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

    [資源]:配置 ElastiCache (RedisOSS)以獲得更高的可用

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

    • 使用管線,您可以減少應用程式用戶端與叢集之間的「來回時間」(RTT),即使用戶端尚未讀取先前的回應,也可以處理新要求。

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

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

    [資源]:管道傳輸

OE 5:如何為工作負載部署 ElastiCache 元件?

問題級介紹:ElastiCache 環境可以通過 AWS 控制台手動部署,也可以通過,工具包等以編程方式部署。APIs CLI卓越運作最佳實務建議您,盡可能透過程式碼自動化部署。此外, ElastiCache 叢集可以依工作負載隔離,也可以針對成本最佳化目的進行組合。

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

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

  • [必要] 瞭解可用的部署選項 ElastiCache,並儘可能自動化這些程序。可能的自動化途徑包括 CloudFormationSDK、 AWS CLI/和APIs。

    [資源]:

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

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

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

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

OE 6:如何規劃故障因應措施及減少故障?

問題級介紹:卓越運營包括通過執行定期的「驗屍」練習來預測失敗,以識別潛在的故障來源,以便將其刪除或緩解。 ElastiCache 提供容錯移轉API,允許模擬節點故障事件,用於測試目的。

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

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

OE 7:如何解決 Redis OSS 引擎事件的問題?

問題層級簡介:卓越營運需要能夠同時調查服務層級和引擎層級資訊,以分析叢集的健康狀態和狀態。 ElastiCache (RedisOSS)可以將 Redis OSS 引擎日誌發送到 Amazon CloudWatch 和亞 Amazon Kinesis Data Firehose。

問題層級的好處:在 ElastiCache (RedisOSS) 叢集上啟用 Redis OSS 引擎記錄可提供對影響叢集健康狀態和效能的事件的深入分析。Redis OSS 引擎記錄檔會直接從 Redis 引OSS擎提供資料,而這些資料無法透過 ElastiCache 事件機制取得。透過仔細觀察這兩個 ElastiCache 事件 (請參閱前面的 OE-1) 和 Redis OSS 引擎記錄檔,從ElastiCache 服務角度和 Red OSS is 引擎的觀點進行疑難排解時,就可以判斷事件的順序。

  • [必要] 確定已啟用 Redis OSS 引擎記錄功能,此功能可從 ElastiCache (RedisOSS) 6.2 及更新版本使用。此功能可在建立叢集期間啟用,或是在建立後,藉由修改叢集來啟用。

    • 判斷亞馬遜 CloudWatch 日誌或 Amazon Kinesis 資料防火管是否為 Redis OSS 引擎日誌的適當目標。

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

    [資源]:

  • [最佳] 如果使用 Amazon CloudWatch 日誌,請考慮利用 Amazon CloudWatch 日誌洞察來查詢 Redis OSS 引擎日誌以取得重要資訊。

    舉例來說,針對包含 Redis OSS 引擎記錄檔的日誌群組建立查詢,這些記錄檔將傳回具有 'WARNING' LogLevel 的事件,例如: CloudWatch

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

    [資源]:使用日誌深入解析分析 CloudWatch 記錄資料