丨容量預測下為不同服務提升準確性

在上一講所提到的特征選取過程中，我比較“草率”地將服務的TPS和依賴服務的TPS作為輸入，與CPU利用率建立模型。但實際情況下，CPU利用率可能不僅僅受TPS制約，下圖展示了TPS和CPU利用率的可視化映射關系，通過左圖可以看到，兩者的關聯(lián)是非常緊密的，這說明除TPS以外，其他因素對CPU利用率幾乎沒有什么影響，這是比較理想的情況；而右圖則出現(xiàn)了不緊密的映射關系，甚至一個TPS會對應多個CPU利用率，很明顯還有我們沒有考慮到的因素在影響著CPU利用率，這會導致模型擬合不佳，那么如何TPSCPU那怎么做相關度的定量分析呢？在統(tǒng)計學中，皮爾遜相關系數(shù)（Pearsonproduct-momentcorrelationcoefficient）XY值介于-1和1之間。我們可以對TPS和CPU皮爾遜相關系數(shù)的絕對值介于0.5-1之間，為強相關0.1-0.50-0.1針對強相關的場景，意味著CPUS的影響，這時直接建立S和利用率的模型就可以比較好的擬合出結果了。而不相關的場景，一般是一些批處理服務或任務型的服務，這些服務沒有外部流量，可以特殊處理或直接過濾掉。我們重點來看一下弱相關的場景如何處理。弱相關的場景下，CPU利用率不僅僅受TPS制約，還伴有其他因素。我提供兩種思路解決這個問題：第一，找出所有影響CPU利用率的特征，對服務進行，即針對每個服務選TPSCPU概率表，選取出現(xiàn)概率最大的CPU利用率值作為特征。下面我具體展開這兩種思路的做法?；诘谝环N服務的思路，我們需要考慮特征，從中選取對CPU利用率影響最大的一個/些去建模，或篩去一些無關的特征不去建模，以下是幾種常見的方式：：將所有特征做歸類，如果一個特征能從另一個特征推導出來，我們就叫它多余特征，無需考慮。如下圖中，我們假設理想情況下內(nèi)存、帶寬、連接數(shù)等指標的變化最終都會反映到服務S上，那么服務S過濾法：每次選擇若干特征或者排除若干特征，進行模型評優(yōu)，直到選擇出最佳的子集。這有點像是排列組合，去尋找一個最佳的特征組合，最準確的預測CPU利用率。嵌入法：ark中的featuremportanc就是一個典型的嵌入法實現(xiàn)。服務的關鍵點是，對PU利用率影響較大的特征必須都包含在我們的選擇范圍內(nèi)則只能是巧婦難為無米之炊，但有時候我們確實很難找全所有的特征，這時候可以換第二種思路，通過建立概率表的方式去解決問題。具體做法是，建立一個S映射U利用率的概率表，根據(jù)概率表找出某個S區(qū)間內(nèi)，CPU利用率出現(xiàn)頻率最高的值，供建模使用。下圖展示了一個概率表的實例，通過左下角的圖可以看到，SCPU，這就是我們要找的值；通過右邊的表格能夠更直觀的看到，標注為紅色的行就是對應SCPU利用率出現(xiàn)次數(shù)最多的值，在建立模型時只需要考慮這幾行的數(shù)據(jù)即可。解決了容量預測準確性的問題，我們進入下一個問題，前面談到過，代向前的，這也就意味著服務是不斷變化的，很有可能一次發(fā)布就會導致之前的預測結果失效，這就要求容量預測也要進行迭代，及時校準。容量預測迭代和校準的一個點在于，由于服務變更前后的容量并不是遞進的關，因（發(fā)布、修改配置、擴縮容等）里，該能夠方式個很弊端它沒慮服變更他服務容量的影響，僅僅對該服務重新進行建模，沒有解決其他服務的容量預測準確性問在實踐中，我們考慮換一種思路，在某個時間窗口內(nèi)對所有服務重新建模，而不是一有服務變更就這么做，這個窗口期可以跟隨服務發(fā)布期以滑動窗口的形式設置，窗口的大小根據(jù)容量結果的時效性進行設置。比如說，我們規(guī)定每周三為服務發(fā)布期，容量時效性為3天，可以設置一個跨度為3天的滑動窗口，在第4天需要再進行一次重新建模，窗口每次這套模式在阿里本地生活經(jīng)過近1頻率，也沒有過多犧牲容量預測的時效性，同時，擴展性比較好，例如服務在每周有兩個發(fā)布窗口，那就設置兩個滑動窗口就可以了?？紤]容量風險會隨流量增高而放大，在進行容量預測時，我們一般會使用期的據(jù)進行建模，主要針對的也是期的業(yè)務場景。這里就引出了一個問題，如果在未來段時問題的解法就是我之前講到的全鏈路壓測，通過對特定場景進行壓測的法是先在業(yè)務期選取一個時間點，獲取這個時間點下所有服務的TPS，它們之間的比例關系稱之為“快照”。接下去，我們可以在保持比例不變的情況下，不斷增加每個服務的TPS值，并將其輸入每個服務的模型進行預測，得到各自的CPU利用率，直到某一個關鍵服務的預測CPU利用率超過閾值（如90%），這時就觸及了整體系統(tǒng)能承載的最大容量，所有服務對應的預測CPU利用率由高到低排序輸出，就能得到一份高危服務的列表，如下表所示。將這份列表中各服務的預測CPUSCPU行比對，若差距過大，則檢查全鏈路壓測場景是否有失真，這就完成了容量預測校準全鏈路壓測的工作。測后再次壓測，壓測過程中的數(shù)據(jù)指標輸出給模型重新學習，這樣就完成全鏈我首先給出了“相關系數(shù)這個工具，對服務S和CPU利用率之間的相關度行，提升預測準確率；如果特征非常難找，那么可以依靠概率表的方式曲線。在“業(yè)務場景變化”這部分的講解中，我提到了系統(tǒng)整體容量預測的過程，在建立快照后，保持比例不變并不斷增加每個服務的S這個過程可以理解為不斷向上試探的過程，不過如果增幅太大，可能會出現(xiàn)同時有很多服CPU想，有沒有更好的策略