Copilot Studio 砍掉 2.9 億次快取寫入，搬上 Azure Managed Redis 省 72% 成本
Microsoft DevBlogs（Power Platform）· 2026-09-15
Microsoft 把撐著 Copilot Studio agent flows 與 Power Automate 工作流程的 Azure Cache for Redis（Classic）整組換成 Azure Managed Redis（AMR），用可叢集、多執行緒的 Redis Enterprise 架構取代原本容易被連線數卡死的單執行緒設計。這是 Power Platform 資深工程師 Sanket Achari 在 2026 年 9 月 15 日發布的遷移紀錄，遷移前歐洲區 Redis 伺服器負載長期落在 75%，美國區一度衝到 95%。
原本的問題
Copilot Studio agent flows 和 Power Automate 共用同一組地區型 Redis，七個服務應用程式擠在同一個快取上放中繼資料、環境資訊、存取結果、授權與協調狀態。光是一個環境對應（environment-mapping）快取，一天就打出2.9 億次 Redis 寫入，占整個地區操作量的 16%。
這些壓力反映到客戶端就是連線失敗：建立、儲存、啟用 flow 時偶爾直接噴錯，歐洲區擴大部署時更出現連線數被打爆的情況，連帶讓 request/reply 佇列有錯位風險。問題不是單一個修好就沒事的 bug，而是快取被當成單一垂直擴充的資源在用，讀寫又沒有分層。
採用的方法
團隊沒有直接跳去 AMR，先把不必要的流量砍掉。拿掉環境對應快取後，那 2.9 億次寫入直接消失；接著在服務前面補上命中率 95% 以上的本機（L1）快取，Redis 讀取只在 L1 沒命中時才發生；針對 flow 存取與帳務內容的讀取加上一分鐘 TTL 的顯式快取，連查無結果的負回應也一併快取，不必每次都打到後端。單靠這幾個改動，歐洲負載就從 75% 降到 15%，美國從 75%–95% 降到 40%。
客戶端同步升級：先上 StackExchange.Redis 2.13.17 強化連線失敗處理，再跳到重寫 I/O 核心的 StackExchange.Redis 3.0.0。加上長連線、序列化的連線管理與有節奏的重連機制，還有交握等待上限與 token 更新支援，連線失敗率才真正壓下來。
| 項目 | 2.13.17 | 3.0.0 |
|---|---|---|
| I/O、緩衝控制 | 依賴 System.IO.Pipelines | 函式庫自行管理 |
| 解析器 | DOM 式 | reader 式 |
| 預設協定 | RESP2 | RESP3 |
| LRANGE_600 基準 | 約 7,200 req/s | 約 17,200 req/s |
真正搬到 AMR 分五個階段：
- Prepare：驗證容量、身分驗證與客戶端相容性。
- Warm selected data：對選定中繼資料雙寫，同時仍從 Classic 讀取。
- Switch and restart：靠排定的重新啟動切換路由，因為路由決策是行程內快取的。
- Observe：用涵蓋錯誤率、快取未命中、尾端延遲、下游負載的健康門檻盯著。
- Retire：拿掉重複寫入，關閉 Classic 資源的建立。
遷移同時把身分驗證換成 Microsoft Entra，拿掉原本的靜態金鑰備援。歐洲區真正上線時還撞到一個舊包袱：繼承下來的身分驗證維護監聽器會發出根本沒在用的 Redis SUBSCRIBE 指令，在正式流量規模下打亂連線共用，修法是把這個訂閱行為關掉，只留身分驗證與快取本身要用的操作。
實際效果
遷移完成後，2026 年 9 月 6 日到 12 日這週的實際負載：
| 地區 | 平均讀取／秒 | 尖峰讀取／秒 | 平均寫入／秒 | 尖峰寫入／秒 |
|---|---|---|---|---|
| 歐洲 | 10,922 | 24,066 | 4,010 | 10,722 |
| 美國 | 10,263 | 21,512 | 3,678 | 7,955 |
成本結構也整個翻新：原本 100% 支出都在 Classic Redis Premium，遷移後 Classic 只剩 12%（降 88%），新的 AMR 部分佔 16%，兩者加起來從 100% 降到 28%，整體省了 72%。
這套順序對其他還在用 Azure Cache for Redis（Classic）、客戶端還停在舊版 StackExchange.Redis 的團隊有具體參考價值：先確認是不是也有「整包環境或設定映射表」被當成快取全量寫入，那類流量往往砍得掉；再檢查客戶端版本是否低於 2.13.17，決定要不要先做連線層強化再談搬遷；有用到 pub/sub 或身分驗證監聽器的架構，要特別留意監聽器有沒有殘留不必要的 SUBSCRIBE，這種問題只有在大流量下才會現形。
原始來源：From Redis pressure to a healthier service、StackExchange.Redis 3.0.0 Release Notes、StackExchange.Redis 2.13.17 Release Notes