雲原生時代的搜索服務算力管理
一、搜索服務算力管理綜述
1.1 搜索算力管理的發展歷程
算力管理的核心目標，是實現算力需求與算力資源的最優匹配。搜索服務算力管理的發展經歷了以下 3 個階段：
1）物理機部署階段
2014 年以前，搜索服務模塊都是直接部署在物理機上。這時物理機的 CPU、內存、SSD 等大小相對統一，個別空閒的機器會手工選擇一些模塊進行混部；夜間用戶流量低峯時候，會有 BVC 這樣離線計算框架，支持離在線任務混部，實現資源充分利用。
2）半自動混部階段
2014 年～2018 年間，搜索業務自研的 PaaS 實現了服務的半自動化的混部。半自動化體現於：混部策略由人工設計，執行過程爲命令式，容量管理由人工維護。這個階段，業務有項目上線，需要詢問容量專員，某些模塊的算力資源是否還有空閒，是否可以支持該項目消耗。對於大型項目，我們自研了全鏈路壓測技術，支持精確容量壓測，確保不出現系統級瓶頸。
3）雲原生混部階段
2018 年之後，搜索業務將服務託管至公司雲平臺上，利用雲平臺對服務進行自動伸縮、自動混部。業務上線前，不再需要詢問容量專員，直接在雲平臺提交擴容申請即可。這期間，我們把更重要的流量匹配到計算得更快的容器上，實現速度與成本兼顧。
1.2 搜索算力治理體系
搜索服務算力質量治理體系，分爲兩大部分：技術架構和運營體系。
1）技術架構
充分依託彈性容器實例、智能監控、Service Mesh 等公司雲平臺提供的技術產品，實現 quota 的智能管理，達到算力需求與資源更好的匹配。
2）運營體系
成立委員會制度，通過委員會驅動成本和速度相關的優化、運作業務項目預算審批流程，在全局維度實現開源節流。
二、搜索服務算力管理的業務特色
2.1 面向全時段優化
在用戶產品服務中，用戶流量是潮汐波動的，夜間用戶流量少了，利用率下降出現資源閒置，這時需要用雲的思想重新考慮這個問題。
1）潮汐伸縮
雲原生應用 12 要素中提到 “通過進程模式進行擴展”，意思是我們雲上的服務不應該是單點，而是由很多副本實例組成。低峯期並非利用率下降，而是需要的實例數減少了。所以，通過在夜間對實例縮容、白天高峯到來前擴容的潮汐方式，可以實現夜間賬單的下降。
2）窗口遷移
雲平臺的本質之一是市場化：夜間供給大於需求時，容器單價下降，例如網約車價格。搜索業務基於 cache 技術進行內容失效預測，可提前在夜間算力更廉價時啓動計算任務，用戶在次日高峯期可獲得相對較新的結果。這是通過計算任務時間窗口遷移，實現整體資源賬單的優化。
2.2 同時段深挖算力空間
在相同的時間點，通過對整個搜索服務集羣的計算任務分類，也存在可以挖掘優化的空間。具體任務類型包括：近線任務、異步任務、同步任務。
1）近線任務
在線計算需要控制複雜度以保障較低的響應延遲，我們可以把複雜計算後的 “好結果” 寫入近線存儲或者 cache 中，當用戶在線查詢相關請求時候，就可以得到更好的結果反饋。這個 best effect 方式，並不需要容器有特別高的穩定性，可以採用更廉價的可搶佔式容器，來提供近線算力資源。
2）異步任務
應用 cache 可以加速服務響應、降低 cache 後端資源成本。完整的 cache 時效性可以分爲三個級別：失效時立即更新；失效前在夜間提前更新；失效時立即發起更新，但不把更新結果同步用戶，異步更新給 cache。在第三種場景下，需要保證計算的效果，又不需立即返回，則可選用穩定性稍好、處理速度稍慢的容器。
3）同步任務
同步計算任務，需要立即計算結果並將結果返回給用戶。例如搜索業務的索引服務，大部分是用分片方式提供服務的。但在大規模分佈式場景下，分片多少會存在計算長尾，長尾分片可能索引了更復雜的文檔，或是文檔數量比平均值稍高。對於長尾分片，可以購買穩定性更好、速度更快、quota 更大的容器；對於普通分片，計算複雜度相對較低，可購買 quota 相對較少的容器。實現容器的差異化採購。
三、搜索服務算力管理的關鍵技術
3.1 應用性能管理
1）性能曲線
容器規格的設置需要考慮很多因素。在搜索服務中，計算任務存在大量內存訪問，減少實例數可以降低內存複製成本，同時單容器流量增加，帶來內存訪問壓力增大，對性能影響是非線性的，傳統模式下需要通過大量線下測試來觀察。在雲原生系統中，依託雲原生監控機制，將模塊的流量、響應時間、資源使用量關係充分關聯，通過大規模樣本聚合分析，可以得到更具統計意義的性能曲線。
2）vpa/hpa
性能曲線可以得到服務的基本性能模式，根據服務的任務類型（近線、異步、同步等）運行不同的 quota 管理策略，預測未來一段時間服務的理想資源 quota，最後產出伸縮事件，觸發 PaaS 進行調整。
3）流量縮容
性能優化項目上線後，會通過縮容釋放資源。傳統的方法，因線上穩定性要求，縮容需分批多次進行，效率低，且縮容到優化邊界時偏於保守，優化的成果不能充分釋放。在雲上使用新方法，即基於 Service Mesh 的能力，將縮容改爲切流，創建一個更小的調度集合，通過 mesh 切換和調度，大幅度縮短觀察週期和修復耗時，可以更充分地把優化成果釋放出來。
3.2 容器分檔
1）靜態分檔
我們考慮這樣一個場景，如下 trace 圖，某個服務並行訪問 A、B 兩個下游，A 的響應時間更長一些，所以提升 A 的性能可以縮短上層服務時間。但如果 B 中更快的容器（綠色）比 A 更多，則系統整體性能就不是最優的。這是通過增加 A 的快速容器讓 A 算得更快，可以縮短整體響應時間。
2）動態分檔
容器運行相同計算任務的速度，受宿主機硬件性能和硬件狀態影響。根據宿主機的硬件性能對容器運行計算任務的速度進行劃分，我們定義爲靜態分檔；根據容器宿主機的硬件狀態對容器運行計算任務的速度進行劃分，我們定義爲動態分檔。如下圖所示，部署在相同快速硬件型號上的 A1～A4 容器，A1 容器因宿主機資源較空閒，計算速度更快。
3.3 算力分佈
1）精細流量調度
完成分檔後，可通過更精細的流量調度，高效使用不同分檔的容器。我們將服務分爲高速單元和低速單元，高速單元部署在快速容器上，低速單元部署在低速容器上。處理請求時，首先進行流量類型識別，高優流量路由到高速服務單元上，再預估請求的計算複雜度，把更復雜的計算發送到更快容器上，進一步提升請求的計算速度。
2）智能 cache 預充
通過 cache 技術，可以在時間上實現任務計算窗口遷移，從而更好地使用容器。日間高峯期，將請求收集到請求數據中心；在夜間低峯期，預測 cache 失效的請求發送到請求隊列，經過請求代理重新計算更新 cache，降低高峯期的流量。
四、總結
以上，回顧了搜索服務算力管理的發展歷程，概覽了運營 + 技術的治理體系，重點介紹了技術架構側的近期業務特色工作，覆蓋時間和空間兩個方面。
時間方面，算力需求潮汐變化，傳統的方法供給按最大值購買。而基於雲原生技術，在低峯期可減少大量無效購買，增加適當購買廉價容器轉移高峯計算量。
空間方面，未經梳理的梳理需求看似雜亂無章，傳統的方法供給同樣是按最大值購買；基於雲原生技術，區分高低優先級的任務，用不同速度的容器來提供服務，可以達到更優的資源配置。
立足雲原生時代，搜索服務算力管理會進一步應用更靈活、更豐富的控制手段，保持對算力需求和資源更優配置的不斷追求。
作者：鼓鍾
來源：百度 Geek 說
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/xdboUHnynEXfMYspGsgZkw