當前位置:網站首頁>通過 Amazon CloudWatch 配合 Amazon ElastiCache for Redis 遵循監控實踐

通過 Amazon CloudWatch 配合 Amazon ElastiCache for Redis 遵循監控實踐

2022-01-27 19:53:04 亞馬遜雲開發者

在維持 Amazon ElastiCache 資源的可靠性、可用性與性能方面,監控一直是最為重要的手段之一。在本文中,我們將共同了解如何使用 Amazon CloudWatch 及其他外部工具維持健康運作的 Redis 集群,並防止其意外中斷。我們還將具體討論對擴展需求進行預測及籌備的幾種可行方法。

將 Amazon CloudWatch 與 Amazon ElastiCache

 配合使用的優勢

Amazon ElastiCache 與 Amazon CloudWatch 相結合,能够極大提昇資源相關核心性能指標的可見性。此外,Amazon CloudWatch 警報還能够幫助您設置指標閾值並觸發通知,確保在需要采取預防措施時及時做出提醒。

隨時間對趨勢加以監控,還可以幫助您檢測工作負載的持續增長。您可以為數據點設置最長達455天(15個月)的時間周期,在此窗口內觀察 Amazon CloudWatch 指標的擴展情况,據此預測資源的後續利用率與使用情况。

監控資源

Amazon ElastiCache Redis 集群的運行狀况由關鍵組件(例如CPU、內存以及網絡)的利用率决定。這些組件的過度使用可能導致系統等待時間延長以及整體性能下降。另一方面,過度配置則可能導致資源得不到充分利用,嚴重影響成本的優化效果。

Amazon ElastiCache 提供的指標使您能够監控集群;截至本文撰稿時,亞馬遜雲科技已經發布18項新的 Amazon CloudWatch 指標。

面向 Amazon ElastiCache 的 Amazon CloudWatch 指標主要分為兩類:引擎級指標(由Redis INFO命令生成)以及主機級指標(來自ElastiCache節點的操作系統)。這些指標以60秒為間隔對每個緩存節點進行測量並進行發布。盡管 Amazon CloudWatch 允許您為每項指標任意指定統計信息與檢測周期,但只有經過精心設計、相關組合才能真正服務於系統運行。例如,CPU 使用率中的“平均”、“最小”以及“最大”等統計信息非常重要,但“總和”信息則基本沒有任何實際價值。

CPU

Redis 可以使用不同的 CPU 執行快照保存或者UNLINK等輔助操作,但只能通過單一線程運行命令。換句話說,Redis 每次只能處理一條命令。

考慮到 Redis 的單線程屬性,Amazon ElastiCache 提供 EngineCPUUtilization 指標,用以提供對 Redis 進程本身負載情况的精確可見性,從而更好地幫助您了解 Redis 工作負載運行狀態。

不同的用例對於高 EngineCPUUtilization 的容忍度都有所區別,其中不存在通用性質的閾值。但作為最佳實踐,本文建議大家確保您的 EngineCPUUtilization  始終低於90%。

使用應用程序及預期工作負載對集群進行基准測試,可以幫助您將 EngineCPUUtilization 與系統實際性能關聯起來。我們建議您針對 EngineCPUUtilization 在不同層級上設置多項 Amazon CloudWatch 警報,以便在達到每項閾值(例如 WARN 為65%,HIGH 為90%)時,搶在集群性能遭遇實際影響前向您發出通知。

如果您集群的 EngineCPUUtilization 較高,則可以考慮以下補救措施:

  • 較高的 EngineCPUUtilization 指標很可能源自特定的Redis 操作。Redis 命令會使用 Big O 錶示法對時間複雜度進行定義。您可以使用 Redis SLOWLOG 幫助您確定完成命令所需要的時間。一大常見問題在於過度使用 Redis KEY 命令,請在生產環境中對這條命令保持高度關注。

  • 在 Redis 命令的時間複雜性方面,非最優數據模型也有可能給 EngineCPUUtilization 指標帶來不必要的壓力。例如,集合的基數可能為一項性能因素,而 SMEMBERS、SDIFF、SUNION 以及其他集命令的時間複雜度則由集內元素的數量所定義。哈希的大小(字段數)與運行的操作類型,也會給 EngineCPUUtilization 造成影響。

  • 如果您在包含多個節點的節點組中運行 Redis,則建議您使用副本來創建快照。在從副本創建快照時,主節點不會受到快照保存任務的影響,因此可以繼續處理請求而不會降低速度。請驗證該節點是否在使用 SaveInProgress 創建快照。在完全同步的情况下,快照應始終比特於主節點之上。

  • 大量操作同樣可能帶來較高的 EngineCPUUtilization 。請明確操作所對應的具體負載類型。如果高 EngineCPUUtilization 主要源自大量讀取操作,您可以在 Redis 客戶端庫中使用 Amazon ElastiCache 讀取器端點將其配置為禁用集群模式,或者使用 Redis READONLY 命令將其配置為集群模式。如果您只從讀取副本處進行讀取,則可以在副本組或者各個分片中添加其他節點(最多五個讀取副本)。如果寫入操作帶來較高的 EngineCPUUtilization ,則需要為主節點提供更强大的計算容量。您可以昇級至最新一代 m5 與 r5 節點類型,使用更强的處理器快速執行任務。如果您已經在使用最新一代節點,則應考慮將禁用集群模式切換至啟用集群模式。要完成切換,您可以為現有集群創建一套備份,並將另一套已經啟用集群模式的新集群內還原這些數據。在啟用集群模式之後,解决方案能够添加更多分片並進行橫向擴展。分片數量越多,您能够添加的主節點數量就越多,計算容量自然就越强。

除了使用 EngineCPUUtilization 指標監控 Redis 進程負載之外,您還應當注意其餘CPU內核的資源使用情况。通過 EngineCPUUtilization,您可以監控整個主機的 CPU 利用率百分比。例如,由於建立連接會帶來部分處理負載,因此大量新連接的湧入同樣有可能拉高 EngineCPUUtilization 指標。

對於 CPU 內核數量小於等於2個的小型節點,您還需要關注 CPUUtilization 指標。由於除了快照及托管維護事件等操作之外,您還需要保留一部分計算容量並與 Redis共享節點 CPU 核心,因此在 EngineCPUUtilization 發生變化之前,您的CPUUtilization 很可能先一步達到100%。

最後,Amazon ElastiCache 還支持 T2 與 T3 緩存節點。這些緩存節點提供基准水平的 CPU 性能,並可隨時突發峰值 CPU 容量,直到您的免費配額耗盡為止。如果您使用的正是 T2 或 T3 緩存節點,則應監控 CPUCreditUsage 與 CPUCreditBalance,這是因為在配額耗盡之後,其性能會逐漸降低至基准水平。

內存

內存是 Redis 中的一大核心要素。了解集群的內存利用率,有助於避免數據丟失並持續適應數據集規模的不斷增長。

Redis INFO 命令中的 memory 部分,提供關於當前節點內存利用率的統計信息。

其中最重要的指標之一為 used_memory,即 Redis 使用分配器所分配的內存容量。Amazon CloudWatch 提供名為 BytesUsedForCache 的指標,其衍生自 used_memory ,您可以使用這項指標確定當前集群的內存利用率。

隨著18項全新 Amazon CloudWatch 指標的發布,現在您可以使用 DatabaseMemoryUsagePercentage並根據當前內存利用率(BytesUsedForCache)以及 maxmemory 查看內存利用率百分比。Maxmemory 將設置目標數據集的最大可用內存量。您可以使用 Redis INFO 命令以及 Redis 節點類型特定參數中的 memory 部分調車集群的內存上限。其默認取值由需要保留的內存容量决定。因此在設定之後,您的集群 maxmemory 將有所下降。例如,cache.r5.large 節點類型默認最大內存為14037181030字節,但如果您希望默認保留25%的內存,則可用最大內存容量將為10527885772.5字節(14037181030 x 0.75)。

當您的 DatabaseMemoryUsagePercentage 達到100%時,Redis maxmemory 策略將被觸發,且根據所選策略(例如 volatile lru )决定是否進行數據逐出。如果高速緩存內沒有任何對外貿易可以進行逐出(根據逐出策略),則寫入操作將失敗,Redis 主節點隨後返回以下消息:(error) OOM command not allowed when used memory > 'maxmemory'

逐出並不代錶必然發生了問題或性能下降。某些工作負載在設計上就考慮到了利用逐出機制。要監控集群內的逐出量,您可以使用 Evictions 指標。此指標同樣可通過 Redis INFO 命令使用。但請注意,大量逐出同樣會拉高 EngineCPUUtilization 指標。

如果您的工作負載在設計中並未考慮使用逐出,則建議您設置 Amazon CloudWatch 警報以在需要執行擴展操作時,主動根據DatabaseMemoryUsagePercentage 指標的變化情况發出警報並擴展內存容量。對於禁用集群模式的場景,您可以擴展至更大的節點類型以獲取更高內存容量。而對於啟用集群模式的場景,橫向擴展以逐步增加內存容量才是最合理的解决方案。

控制數據集增長的另一種方法,是在密鑰當中使用 TTL (生存時間)。當生存時間到期之後,如果客戶端(以被動方式)嘗試訪問或 Redis (以主動方式)定期測試隨機密鑰,則該密鑰將不再提供起效並將被删除。您可以使用 Redis SCAN 命令來分析數據集內的某些部分,並放大被動方法以删除過期密鑰。在 Amazon ElastiCache 當中,密鑰到期可通過 Reclaimed AmazonCloudWatch 指標進行監控。

在執行備份或故障轉移的過程中,當將集群數據寫入至 .rdb 文件時,Redis 會使用額外的內存來記錄對集群的寫入操作。如果此額外的內存使用量超過了節點中的可用內存容量,則過度分頁及 SwapUsage 會導致處理速度變慢。因此,我們建議您預留一部分內存容量。預留內存屬於專為容納某些操作(例如備份或故障轉移)所預留的內存資源。

最後,本文建議您為 SwapUsage 建立 Amazon CloudWatch 警報。此指標不應超過50 MB。如果集群正在消耗 swap 空間,請在集群的參數組中驗證是否配置了充足的預留內存。

網絡

决定集群網絡帶寬容量的一大决定性因素,在於您所使用的實際節點類型。

我們强烈建議您在實際生產使用之前對集群進行基准測試,借此評估其性能錶現並在監控當中設置正確的閾值。您應以數小時為周期運行基准測試,借此反映臨時性網絡突發容量的出現頻率與潜在需求。

Amazon ElastiCache 與 Amazon CloudWatch 提供多項主機層級的指標以監控網絡利用率,類似於Amazon Elastic Compute Cloud (Amazon EC2)實例。NetworkBytesIn 與 NetworkBytesOut 分別代錶主機已經從網絡處讀取、以及發送至網絡處的字節數。NetworkPacketsIn 與 NetworkPacketsOut 則分別代錶在網絡上接收及發送的數據包數。

在定義集群的網絡容量之後,您可以借此映射並建立最高網絡利用率預期峰值。此峰值不應高於所選節點類型的網絡容量。每種節點類型都提供一定的突發容量,但我們建議您預留這部分額外容量以應對流量的意外增加。

根據您所定義的最高利用率,您可以創建 Amazon CloudWatch 警報,確保在網絡利用率高於預期或接近此限制時發送電子郵件通知。

如果您的網絡利用率持續增加並觸發了網絡警報,則應采取必要措施以添加更多網絡容量。要確保調整正確,您需要確定導致網絡利用率提高的因素。您可以使用Amazon CloudWatch 指標來檢測操作强度的變化,並在讀取或寫入操作類別中對這種波動進行分類。

如果網絡利用率的提高源自讀取操作,請首先確保使用一切現有讀取副本處理讀取操作。您可以在配置禁用集群模式下對 Redis 客戶端庫中使用ElastiCache讀取器端點,也可以在啟用集群模式下使用 Redis READONLY 命令。如果您已經在讀取副本中執行讀取操作,則可以在副本組或分片當添加更多節點(最多支持五個讀取副本)。

如果網絡利用率提高源自寫入操作,則需要為主節點添加更多容量。在禁用集群模式的場景下,您可以直接將主節點擴展為更大的節點類型。在啟用集群模式時,同樣可以執行這一縱向擴展操作。

另外,啟用集群模式時,您還可以使用另外一種讀取及寫入用例擴容方法。此方法將添加更多分片並執行橫向擴展,確保每個節點只負責數據集中的部分較小子集,由此保證每個節點的網絡利用率保持在較低水平。

盡管橫向擴展能够解决大部分網絡相關問題,但這裏還是要討論幾種關於高熱度鍵的極端情况。所謂高熱度鍵,是指訪問特別頻率、遠超正常比例的特定鍵或鍵子集,因此導致單一分片可能需要承受高於其他分片的流量規模。如果這些鍵保留在同一分片上,則會帶來很高的網絡利用率。在這類罕見示例中,如果不變更現有數據集,則向上擴展方法往往比較適用。當然,您也可以重構數據模型以重新均衡網絡利用率。例如,您可以複制字符串並拆分存儲有多個元素的對象。

連接

Amazon CloudWatch 為構建集群連接提供兩項指標:

  • CurrConnections – Redis 引擎所注册的並發連接及活動連接數。此指標派生自 Redis INFO 命令中的 connected_clients 屬性。

  • NewConnections – 在特定時段內,Redis 已接受的連接總數,包括所有處於活動狀態及關閉狀態的連接。此指標同樣源自 Redis INFO 命令。

要監控連接,我們主要需要關注 Redis 中的 maxclients 限制指標。Amazon ElastiCache 為該指標設定的默認值為65000。換句話說,每個節點最多可以使用65000個並發連接。

CurrConnections 與 NewConnections 指標均可幫助檢測並預防性能問題。例如, CurrConnections 的不斷增加可能快速耗盡65000個可用連接。這類指標增加可能錶示應用程序端出現了問題,且連接未能正確關閉,因此最終還是在服務器端占用了連接。除了調查應用程序的行為以解决問題之外,您也可以在集群中使用 tcp-keepalive 以檢測並終止潜在的死對等連接。在 Redis  3.2.4及更高版本中,默認的 tcp-keepalive 計時器時長為300秒。對於舊版本,默認情况下禁用 tcp-keepalive。您可以在集群的參數組中調整 tcp-keepalive 計時器。

對 NewConnections 的監控同樣非常重要。請注意,最大客戶端限制65000不適用於此指標,因為其衡量的是指定時間內創建的連接總數,而各項連接之間並不一定同時發生。在1分鐘的數據采樣期間,一個節點可能會收到10萬個 NewConnections,但從未達到2000個 CurrConnections(同時連接)。在此特定示例中,工作負載並未達到 Redhis 需要介入的連接限制風險。但是期間發生的大量連接快速開啟及關閉同樣可能會影響到節點性能。創建 TCP 連接需要耗費幾毫秒時間,這也屬於應用程序在運行 Redis 操作時經常出現的額外有效載荷。

根據最佳實踐的要求,應用程序應盡可能複用現有連接,以避免創建新連接並造成額外成本。您可以通過 Redis 客戶端庫(如果支持)使用適合當前應用程序環境的框架以建立連接池,也可以親手動手從零開始創建連接池。

更重要的是,由於 TLS 握手會帶來額外的時間與 CPU 使用率,因此在集群內使用 Amazon ElastiCache 傳輸加密功能時,請關注對新連接數量的控制。

複制

如果存在至少一個讀取副本,則主節點需要向讀取節點發送複制命令流。通過 ReplicationBytes 指標,您可以看到需要複制的數據量。盡管此指標代錶副本組上的寫入負載,但無法幫助我們了解副本運行狀况的具體見解。為此,您可以使用 ReplicationLag 指標。此指標提供一項非常便捷的錶示形式,用以錶現副本與主節點之間的延遲。從 Redis 5.0.6版本開始,此指標數據將以毫秒為單比特進行捕捉。盡管比較罕見,但您可以通過監控 ReplicationLag 指標以檢測潜在的問題,其中複制滯後的峰值將錶明主節點或副本無法及時處理複制操作。一旦發生這類情况,您可能需要對副本執行完全同步。完全同步代錶更為複雜的過程,需要在主節點上創建快照,並可能導致性能下降。您可以將ReplicationLag 指標與 SaveInProgress 指標確定完全同步嘗試。

嚴重的複制滯後趨勢,往往源自寫入操作過多、網絡容量耗盡或者基礎服務降級等問題。

對於禁用集群模式的單一主節點,如果您的寫入活動强度過高,則需要考慮啟用集群模式,借此將寫入操作分散到多個分片及其關聯的主節點之上。如果複制滯後源自網絡容量耗盡,則請參考本文“網絡”部分的步驟進行操作。

延遲

您可以使用一組 Amazon CloudWatch 指標來衡量命令的延遲,通過這些指標為每種數據結構計算總延遲。您可以使用 Redis INFO 命令中的 commandstats 統計信息計算出這項結果。

在以下圖錶中,我們可以看到 StringBasedCmdsLatency指標,代錶的是特定時間範圍之內運行的、基於字符串的命令的平均延遲(以微秒為單比特)。

此延遲不包含網絡與 I/O 時間,這些屬於 Redis 處理操作時耗費的時間。

如果 Amazon CloudWatc h指標指示出特定數據結構的延遲有所增加,則可以使用 Redis SLOWLOG 來確定哪些具體命令的運行時間較長。

如果您的應用程序遇到高延遲,但 Amazon CloudWatch 指標指示 Redis 引擎級延遲很低,則應主要關注網絡延遲。Redis CLI 提供一款延遲監控工具,適用於以隔離方式調查網絡或應用程序問題(min , max 以及 avg 皆以毫秒為單比特):

$ redis-cli –latency-history -h mycluster.6advcy.ng.0001.euw1.cache.amazonaws.commin: 0, max: 8, avg: 0.46 (1429 samples) — 15.01 seconds rangemin: 0, max: 1, avg: 0.43 (1429 samples) — 15.01 seconds rangemin: 0, max: 10, avg: 0.43 (1427 samples) — 15.00 seconds rangemin: 0, max: 1, avg: 0.46 (1428 samples) — 15.00 seconds range

min: 0, max: 9, avg: 0.44 (1428 samples) — 15.01 seconds range

最後,您還可以監控客戶端當中是否存在可能影響應用程序性能、或者導致處理時間增加的活動。

Amazon ElastiCache 事件與 Amazon SNS

與您資源相關的各類 Amazon ElastiCache 日志事件(包括故障轉移、擴展操作、計劃內維護等),皆包含日期與時間、源名稱、源類型以及描述。您可以在 Amazon ElastiCache 控制臺上、使用Amazon命令行界面(Amazon CLI)的 describe-events 命令以及 Amazon ElastiCache API 輕松訪問這類事件。

監控事件可以幫助您隨時了解集群的當前狀態,並根據事件采取必要的措施。盡管 Amazon ElastiCache 事件可以通過多種方式獲取,但我們强烈建議您在 Amazon ElastiCache 配置中使用 Amazon Simple Notification Service (Amazon SNS)發送重要的事件通知。

在將 Amazon SNS 主題添加至 Amazon ElastiCache 集群中時,與此集群相關的所有重要事件都將被發布至 Amazon SNS 主題當中,並可通過電子郵件進行發送。

在配合集群使用 Amazon SNS 時,您還可以通過編程方式對ElastiCache事件采取措施。例如,Amazon Lambda 函數可以訂閱 Amazon SNS 主題並在檢測到特定事件時自動運行。

總結

在本文中,我們討論了 Amazon ElastiCache Redis 資源監控方面的常見挑戰與相關最佳實踐。借助本文中提到的知識,您現在可以輕松檢測、診斷並維護 Amazon ElastiCache Redis 資源。

本篇作者

Yann Richard

Amazon ElastiCache 解决方案架構師

他的個人目標是在次毫秒級內完成數據傳輸,並在4小時之內完成馬拉松。

版權聲明
本文為[亞馬遜雲開發者]所創,轉載請帶上原文鏈接,感謝
https://cht.chowdera.com/2022/01/202201271953036921.html

隨機推薦