SageMaker 自動擴展遇上 AWS CDK 必須協調的部署限制
AWS 發布了一套適用於 SageMaker 自動擴展的解決方法，處理端點在擴展設定仍維持註冊時更新失敗的問題。該方法使用 AWS CDK——一個以程式碼定義雲端基礎設施的框架——協調原本需要人工介入的變更。其重要之處在於填補了一個落差：宣告所需的基礎設施，未必能表達實現該目標所需的操作次序。
10 月 23 日的文章介紹一個可重用建構，即封裝好的基礎設施元件；它會暫時移除擴展註冊，並在端點更新後重新還原。AWS CloudFormation——根據範本佈建資源的服務——仍然負責部署。自訂資源，即執行應用程式專屬佈建邏輯的擴充功能，則負責處理該更新前後的轉換。
對平台工程師而言，核心衝突是宣告式設定與營運操作排序之間的矛盾。範本可正確描述端點及其擴展設定，但兩者的關係仍可能令更新受阻。AWS 的示例將這種關係納入部署工作流程，但團隊仍須評估復原能力、容量及責任歸屬。
SageMaker 自動擴展揭示設定與執行之間的落差
這項變更是已發布的協調模式，而非取消 SageMaker 原有的更新限制。
AWS 顧問 Lauren Eterno 在一個端點更新建構中介紹這個方法。它以端點變更前後的自訂佈建步驟，取代原生擴展資源。AWS 表示，這讓端點設定及擴展參數可在同一次部署中變更。
這個分別相當重要，因為「擴展會阻止端點更新」這種概括說法需要補充說明。SageMaker 的端點更新規則明確指出，當模型仍維持註冊時，變更執行個體類型會導致更新失敗。規則亦容許變更已設定擴展的變體模型。一個變體是端點內用於提供模型服務的設定。
這個例外避免人們對公告作出過度廣泛的解讀。團隊不應假設每次模型發佈都需要拆除擴展註冊。關鍵問題是哪些資源屬性有所變更，以及這些變更是否觸及文件所述的限制。部署策略應依循這項區別。
試想一個假設的推薦服務，將其模型轉移至另一種執行個體類型。模型本身或許維持不變，但基礎設施更新跨越了由擴展註冊保護的界線。只檢視新端點設定的工程師，可能會忽略這項先決條件。
因此，這個示例處理的是生命週期問題，也就是建立、更新及移除資源所需的有序轉換。它並沒有引入另一種擴展演算法。其價值在於協調既有操作，讓部署程序理解當中的先決條件。
這是評估這項消息時一條有用的界線。新的建構應按其是否能令基礎設施變更具備可重複性及可復原性來衡量。至於提升推論品質、加快模型執行或改善擴展效率的說法，則需要獨立證據支持。
這篇文章亦為維護私有解決方法的團隊提供具體檢視目標。他們可把自己的指令碼與 AWS 撰寫的參考實作比較，而非只根據錯誤訊息推論。但這並不代表該參考實作自然適合所有生產環境。
眼前壓力主要落在那些假設有效範本必然保證有效更新路徑的發佈團隊身上。這個示例顯示，路徑本身也值得檢視。目標狀態與轉換行為應納入同一場工程討論。
平台團隊承擔人工介入的後果
若預期的擴展行為尚未恢復，即使端點變更成功亦不算完整。
最重要的營運疑慮，是基礎設施設定與實際運行行為之間的距離。一個端點可以回應請求，卻缺少其擁有者預期的擴展安排。若發佈審查只聚焦於應用程式回應，便無法證明基礎設施仍準備好應對需求變化。
AWS 描述了人工取消註冊的情況，當中可能令擴展設定缺失，或導致後續資源更新失敗。這些示例揭示不同問題。明顯的部署失敗會立即需要處理；相反，缺少擴展功能則可能逃過只檢查應用程式是否仍有回應的審查。
無論哪種情況，當值工程師都要承擔後果。總有人需要判斷哪些變更已完成、哪些資源存在，以及下一次部署將嘗試甚麼。若沒有共同紀錄，復原程序便要依靠重建正常發佈工作流程以外採取過的行動。
對平台團隊來說，這既是責任歸屬問題，也是工具問題。應用程式開發人員可能負責模型行為，而基礎設施工程師則負責部署控制。橫跨兩者的工作流程，需要明確定義完成標準，而任何一方都不能單獨滿足該標準。
該定義應涵蓋服務設定及預期的容量控制，亦應區分註冊與政策附加。可擴展目標，即容量可變更的已註冊資源，及其擴展政策，是最終狀態中相互關聯但彼此獨立的部分。
實際含義是需要更全面的發佈驗收檢查。團隊應確認端點使用預期設定，且其容量控制符合已批准的變更。應用程式健康狀況仍然必要，但它回答的是另一個問題。
當硬件變更伴隨經修訂的擴展設定時，這點尤其重要。該次發佈同時改變請求如何執行，以及其後容量如何回應。若孤立地檢視其中任何一項變更，便會忽略兩者的互動。
可重用元件可以集中這項責任。平台團隊不必要求每個應用程式團隊記住整個次序，而可維護一套共用實作。其效益取決於團隊是否把該元件視為需要維護的基礎設施，並具備清晰的責任歸屬和已記錄的復原程序。
文件需要保存決策，而不只是指令。工程師調查日後事故時，需要知道為何存在暫時取消註冊，以及哪些假設支持該做法。一個可搜尋的工程知識庫可將這些決策與部署證據一併保存。
業務上的含義是發佈可預測性。經常需要專家介入的基礎設施變更，會為每次受影響部署帶來協調工作。把操作次序納入程式碼，有機會減少這些工作，前提是操作人員仍能理解故障。
這項前提將有用的自動化與隱藏的複雜性區分開來。目標應是能清楚說明自身狀態的部署。單純把人工指令移入函數，並不能確立這個結果。
此建構令排序與就緒狀態變得明確
該機制結合有序依賴鏈，以及確認每個先決條件確實可供使用的檢查。
這個示例實作遵循既定次序：取消註冊擴展、更新端點、註冊目標，以及附加政策。註冊階段會等待端點進入 InService，即其準備就緒的運作狀態。政策階段則會等待已註冊目標可被查詢。
這些檢查處理不同的界線。端點必須準備好才可註冊，而註冊必須變得可見才可附加政策。分別處理這些條件，會比假設已接受請求便代表每項相依操作均可繼續，更容易檢視整個工作流程。
Application Auto Scaling——AWS 用於調整支援資源容量的服務——記錄了這種可見性落差。其註冊 API 警告最終一致性，即成功的變更可能需要時間才會在後續請求中出現。因此，就緒檢查是對已記錄行為的回應。
示例使用非同步完成機制，這種模式把啟動操作與檢查操作是否已完成分開。CDK provider framework 會重複呼叫完成處理常式，直至成功或逾時。這避免把整段等待綁定在單一次函數調用上。
參考實作設定每 30 秒檢查一次。它容許目標註冊最多等待一小時，附加政策最多等待 15 分鐘。這些數值說明實作的等待上限；它們並非承諾的部署時長，亦不是典型生產效能的證據。
設定觸發條件同樣重要。ConfigHash 屬性，即代表相關設定的值，會在端點或擴展設定變更時改變。這為 CloudFormation 提供一個已變更的自訂資源屬性以供處理，從而令協調流程重新納入更新作業。
這正是該模式超越依賴排序之處。單憑排序規則，並不會令未有變更的自訂資源再次執行。工作流程既需要有執行理由，也需要在執行開始後具備強制排序。
更廣泛的 CDK 行為可見於其自訂資源框架。CloudFormation 會向 provider 發送生命週期事件，而該框架支援為耗時操作進行完成檢查。處理常式出錯或等待期屆滿時，它亦會回報失敗。
對審查者而言，這些是不同責任。設定觸發條件決定何時需要執行工作；依賴關係決定何時可開始；完成檢查決定何時可繼續後續工作。復原邏輯則須處理進度在這些界線之間停止時會發生甚麼。
與按次序提交請求並假設立即就緒的部署指令碼相比，這種設計更為明確。然而，明確性不應與正確性的證明混為一談。參考實作提供了一套可供檢視的機制，團隊可按自身營運要求評估。
受管理推論仍將部署協調責任留給營運者
更廣泛的比較關乎平台如何呈現生命週期責任，而非哪家供應商提供自動擴展。
Google Cloud 同樣記錄了已部署預測模型的可設定擴展功能。其推論自動擴展設定包括最小及最大複本數量；複本是為模型提供服務的運行副本。該文件亦在支援的設定中區分部署成功與完整容量就緒。
這項比較提供了背景脈絡，但並未建立供應商排名。設定相似並不代表更新限制、故障處理或部署語義完全相同。AWS 的例子並不足以證明其他平台可避免所有同類協調問題。
對企業買家而言，有用的比較不應只看是否具備擴展能力。他們應詢問硬件變更如何影響容量控制、就緒狀態如何呈報，以及發生故障後由誰還原設定。這些問題把產品能力與實際營運所需的工作連繫起來。
同樣的區分亦適用於 AWS 環境。在 CDK 中定義基礎設施雖然為開發人員提供程式設計介面，但最終部署仍遵循 CloudFormation 的行為。用來描述資源的語言不會消除服務層面的前提條件。
因此，這個例子值得關注的地方不只在於其具體實作。它把基礎設施程式碼中的一項營運依賴關係顯示出來。這讓審查者有位置檢視一段原本可能分散於發行說明、指令碼及個人經驗之間的流程。
更新可用性與擴展可用性之間亦存在界線。SageMaker 的端點更新 API 說明如何將流量轉移至新的機群，同時淘汰原有機群。這項服務轉換本身並不代表既定的擴展政策已經還原。
因此，團隊可為請求服務與容量管理訂立不同的驗收條件。應用程式必須在變更期間保持正常，而部署完成時亦應具備預期的擴展控制。兩項條件都不應取代另一項。
這種分隔亦有助改善事故分析。若請求失敗，工程師可調查服務轉換；若容量不再隨需求調整，則可檢查擴展狀態。能區分這些結果的部署紀錄，會為應變人員提供更清晰的起點。
對正將推論基礎設施標準化的機構而言，選擇在於是否將這項協調工作納入共用元件。另一種做法是讓每個團隊自行負責理解同一個生命週期界線。共用元件可帶來一致性，但亦會集中維護責任。
這項取捨應有明確負責人。必須有人審查元件變更、維持與現有部署的相容性，並判斷其假設何時不再適用。只有維護模式同樣可重用時，可重用性才會創造組織價值。
取消註冊令復原成為設計的一部分
還原目標固然必要，但生產驗收必須涵蓋取消註冊所移除的一切。
deregistration API 指出，移除可擴展目標會刪除其相關的擴展政策及排程動作。排程動作是在指定時間設定的容量變更。即使原意只是暫時處理，這亦令取消註冊成為具破壞性的生命週期操作。
這種行為會立即為既有端點帶來相容性問題。若機構使用排程動作或額外政策，審查者應確認這些設定如何回復。具備目標追蹤政策——即把容量調整至選定指標值的政策——並不能解答這個問題。
範例所記錄的流程，重點在於註冊目標並附加其已設定的政策。團隊不應推斷端點原有的每一項擴展配置都會被發現及重建。更廣泛的還原要求需要明確檢查及驗證。
擴展空檔亦值得注意。移除註冊不代表端點已被刪除，但其原有的自動容量控制已不復存在。營運人員應評估服務機群在該段期間必須承受多少需求。
這是按工作負載而定的評估。穩定的內部服務與面對不可預測需求的公開應用程式，會有不同的驗收條件。該參考資料未有提供量度證據，證明任何一種情況都有可接受的中斷時間窗口。
硬件變更後，容量設定需要另行審查。保留原有政策設定，並不能證明它仍適合不同的執行個體類型。團隊應在具代表性的需求下評估結果行為，才可把還原視為營運成功。
故障測試應遵循轉換邊界。審查者應檢查端點更新失敗、註冊失敗及政策附加失敗。每種情況都會留下不同問題：實際狀態是甚麼，以及需要採取甚麼行動來復原。
回復，即失敗後朝原有設定返回的過程，亦需要與正向部署同等的重視。自訂資源透過其處理常式參與這個生命週期。它的存在並不保證每一項部分完成的操作都能乾淨地逆轉。
CDK 文件明確指出，即使底層操作在技術上已成功，資源操作仍可能失敗。這項區別在解讀日誌時十分重要。出現錯誤報告時，應先檢查實際資源狀態，再假定操作從未發生。
資源身分是另一個審查重點。CloudFormation 使用供應商的實體資源識別碼來區分更新與替換。修改範例的團隊，應在更改識別碼格式或清理邏輯前理解這項行為。
這些考量不會否定此方法，而是界定了負責任採用它所需的證據。編排元件應令故障狀態可見、保留足夠的復原背景，並避免在預期結果尚未存在前報告完成。
現有發布內容是一份技術操作指南，而非獨立的可靠性研究。它未能證實生產環境採用情況、事故量度降幅，或普遍適用的復原保證。它最強的貢獻，是提供一項明確設計，讓營運人員可以測試，而非自行重建。
下一步證據應來自更新、復原及原生支援
最有用的訊號是可觀察的工程結果，而不是對自動化作出更廣泛的宣稱。
第一個訊號是可重複進行設定更新，並在其後還原擴展功能。在未來數個月，採用者應尋找涵蓋硬件變更及擴展設定變更的證據。若能成功重複執行，將加強此元件能持續捕捉預期依賴關係的論據。
證據應說明最終狀態，而非只顯示部署指令已完成。審查者需要確認端點正以預期設定運行，並且預期的目標及政策均存在。即使服務仍然正常，若未能還原，這種模式的實際價值便會減弱。
下一個訊號是在注入故障時的已記錄行為。一項具說服力的評估會指出工作流程在哪裏停止、哪些項目仍然活躍，以及如何進行復原。清晰的復原證據比又一次成功的初始部署更能加強信心。
相反，需要未有記錄的主控台介入才能處理的故障，會反映營運工作尚未完成。這不會抹殺自動化排序的價值，但會改變採用決定。團隊需要在其發布流程中考慮這些餘下工作。
最後一個訊號是原生生命週期支援的進展。應留意 SageMaker、CloudFormation 及 CDK 文件中影響端點更新與擴展註冊的變更。若原生處理這項前提流程，便可減少由應用程式維護編排的需要。
在這類支援出現之前，該參考資料為平台工程決策提供了具體依據。它把 SageMaker 自動擴展納入端點部署生命週期，而非把還原當作獨立的營運人員工作。是否採用它，取決於這個明確工作流程能否在實際運行環境中表現得可預測。
考慮採用這個 construct 的團隊，應先從一個已了解其更新歷史及擴展設定的端點開始。檢視所產生的基礎設施、找出取消註冊會移除的每項設定，並指定復原責任人。然後在擴大採用前，進行一次具代表性的更新及一次受控故障測試。把所得證據保留在元件的操作文件中，讓日後發布不只繼承程式碼，亦繼承相關理據。發布審查要問的問題十分具體：端點變更後，團隊能否確認服務、擴展及復原行為均符合其要求？應以此標準評估 SageMaker 自動擴展編排，並要求部署證據作出回答。
