騰訊雲數據庫智能化海量運維的建設與實踐

時間 2020-01-30

標籤騰訊數據庫智能海量建設實踐欄目騰訊简体版

原文原文鏈接

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~數據庫

做者介紹：魯越，騰訊雲數據庫架構師團隊負責人，主要負責騰訊雲數據庫MySQL、Redis、Oracle等數據庫售前架構、運維、調優等工做，曾就任於網易和尼比魯。

騰訊雲數據庫海量運維的經驗，主要分爲如下三部分：後端

數據庫架構師團隊的組建
自動化運維平臺的建設
智能海量運維的實踐

數據庫架構師團隊的組建

組建原因

因爲數據庫產品的特殊性和複雜性，咱們在平時服務客戶的過程當中常遇到一些問題，例如：分佈在各行各業的客戶，他們會有不一樣的場景需求，這對於數據庫的應用來講存在有很是大的差異。而咱們的售前架構師可能沒辦法對各行各業在數據庫方面的應用、對不一樣客戶需求的架構都作到很是精通，所以沒法推薦出最優的架構。微信

另外一方面，咱們的客戶很是多，但可能咱們的一些售後服務工程師對於這麼複雜的數據庫產品並非很是精通，對於難度較大的問題不能作到徹底覆蓋，或是與客戶交流不夠平滑等，因此服務質量亟需提升。架構

基於以上兩大緣由，咱們組建了數據庫架構師團隊。運維

分工合做

架構師團隊組建起來後，咱們整個數據庫產品的服務體系就變成了如下這樣一個三層架構：第一層是運維，負責處理平臺穩定性相關的工做；第二層是架構師，負責在中間督促重難點的攻堅，包括數據庫的建設、運維工具的建設等等；第三層是一線服務工程師，負責處理主要的諮詢類、流程類的問題。工具

目前整個架構師團隊的工做包括四方面：性能

客戶運營：在進行數據運營的同時，與客戶作更多溝通，包括跟進客戶在使用數據庫時遇到的各類難題；
解決方案：包括基礎解決方案和行業解決方案；
服務體系：包括平臺運維和基礎產品運維；
平臺建設：包括客戶運營平臺、解決方案出口、支撐服務體系。

其中，在運營平臺建設方面，咱們作了一個CDB微信小助手，能夠實現主動推送和被動拉取，幫助咱們的一線同事更好地服務客戶。大數據

自動化運維平臺的建設

要更好地服務客戶、提升服務質量，光有數據庫架構師團隊和售後服務體系是不夠的，咱們還要有一個很是穩定的自動化運維平臺來支持環境。所以，爲何須要自動化運維平臺，這個問題的答案是顯而易見的。到目前爲止，咱們一共有10W+的實例、2W+的物理機，對於平臺的穩定性要求確定是很是高。優化

功能

資源管理：包括實例的象限上限、物理機的管理和部署等；
運維操做：包括升級、上限等功能；
監控：一方面是數據庫性能方面的監控，包括QPS、CPU相關的性能監控；二是可用性方面的監控。
自愈：自動發現數據庫的一些常見問題，好比發現了複製異常，平臺會主動對它進行恢復。

架構

自動化運維平臺的總體架構從下往上共分爲三層，其中最底層是APP的入口，即咱們的客戶端；中間層是客戶入口；最上層是平臺後端。ui

從客戶端鏈接到APP這一層，須要通過兩個架構，咱們MySQL的備份會存儲到集羣，而性能監控的數據會上傳到一個模塊來實時展現咱們的監控。在客戶端這一層，能夠經過官網或者API的入口進入到咱們的自動化運維管理平臺，能夠進行資源管理、實例管理、數據傳輸等系統性的操做。咱們的運維平臺，除了能夠進行這樣的一些操做之外，還能夠進行監控告警、運營報表、全息監控等操做。咱們整個平臺的任何一個操做的數據，都會彙總到運營數據庫裏，去支持咱們的後端作一些包括大數據方面的分析。

監控模塊

整個自動化運維平臺的模塊是很是多的，在此我將重點分享一下監控模塊。前面也說起到了，咱們的監控模塊分爲兩個部分，第一部分是性能方面的監控，第二部分是可用性方面的監控。

如上圖所示，咱們的監控模塊主要是經過兩面兩個主線組成，一個是DB master，一個是撥測Svr。若是監測到有異常的話，會把這個信息發送到DB master，收到反饋的實例異常的信息以後，會經過長連接，再去驗證是否真的異常。

CDB實例方面的性能監控，主要是經過cdb_report這個模塊去監控的，會實時拉取性能方面的監控，將數據、包括CDB告警都彙總到咱們的Apd Netman模塊，這是比較重要的一個組件。

在一個普通場景下，撥測Svr的操做比較簡單，但這樣的場景在海量實例的架構下，可能會有什麼問題？主要包括兩點，第一點是撥測Svr的性能問題，也就是每一次在有這麼多實例的狀況下，撥測請求是否可以成功發出、按時發出；若是這個撥測Svr的性能不太好，會直接影響到每一次撥測Svr的時間間隔。若是撥測Svr性能很差，只能被迫地去把撥測Svr的時間間隔調大，這樣對咱們發現實例的問題多是不及時的。第二點是撥測Svr自身的問題，若是撥測Svr是一個單點的話，萬一它掛掉了，整個實例的狀態對於咱們來講都是不可知的，將會是很是危險的狀態。

基於以上兩點緣由，咱們在海量場景下的撥測Svr設計會考慮到如下三點優化目標：

根據這三點優化目標，咱們作出了以下圖所示的撥測Svr架構。這個節點又會將這些實例發射到後面的pingSvr的節點，是實際去進行撥測操做的節點，這個節點在執行了撥測操做以後，會將撥測失敗結果存入DB中，會有一個alarmChecker去實時讀取，而後進行告警。不論是成功仍是失敗的請求，所有都會寫進去，會有模塊去拉取，並實時地存入數據庫中。在這些節點中，其實都有一個災備的部署。

智能海量運維的實踐

通過實踐和思考，發如今海量數據運維中，咱們的自動化運維平臺還不能解決如下這些問題：

定製化服務。不一樣行業的場景對於數據庫的應用有着很是大差別，其實咱們能夠根據不一樣的使用場景爲數據庫實現定製化和優化的服務。
數據庫問題自動診斷和調優。

所以，騰訊內部目前正在研發一個智能化的產品，能夠經過包括數據挖掘，或是架構師與客戶溝通等方式，對客戶的數據庫應用場景進行畫像，從而實現定製化服務。

定製化服務

從數據挖掘的結果以及日常與客戶的一些溝通來看，咱們把一些比較特殊的使用方法總結爲如下四種類型：

計算型應用：好比一個報表類的應用，可能會須要在一段時間內，頻繁地去獲取計算資源；
存儲型應用：好比一個歷史數據存儲的應用；
流量型應用：會拉取大量的數據；
熱點型應用：好比一個新聞類或紅包類的應用，可能在低峯和高峯的界限會很是明顯。

針對這四種特殊的使用方法，咱們其實能夠作一些定製化的服務，以下圖所示：

對於計算型應用，如BI報表類，它的業務特色是凌晨才執行，而整個機器在凌晨這個時間段內是比較空閒的，因此咱們就能夠針對這樣的計算型場景，進行一些容許閒時超用的優化。

對於存儲型應用，客戶可能比較關心的是整個容量的使用狀況，那麼咱們就能夠相應地提供自動加載、數據壓縮的壓縮引擎。

對於流量型應用，可能會對SQL的要求很是高，若是中間有一兩個性能不是特別好的SQL，就可能會影響到整個數據庫。因此對於這種應用，咱們能夠給客戶提供一個相似自助SQL優化的工具，幫助客戶把SQL作必定的優化。

對於熱點型應用，咱們能夠提供一個實例動態升降配的功能，在業務高峯前，快速地將這個實例升到一個較高的配置。

數據庫自動調優

針對前文提到的數據庫自動調優的問題，咱們能夠作一個實時分析和預測分析的工做，來分析實例的質量得分。

其中，預測分析是經過實例過去的歷史數據，來分析它在將來兩到三個月的走勢。其實這個分析也是能夠作定製化的，例如上文說起的計算型應用，若是客戶對CPU比較敏感，咱們在分析時就能夠把CUP使用權重的比例調大；若是是對存儲、空間利用率比較敏感，咱們能夠把存儲方面的一些指標相應調大。經過這樣的預測分析，再加上大數據、AI的一些模型，咱們就能夠得出一個實例得分的指標，並以此自動地優化數據庫，或是提出一些優化建議。