數據庫

釘釘猛增40倍流量壓力,阿里云的DBA們是這樣應對的…

本文作者:阿里云數據庫運維專家箋一、奕信導讀

最近,由于受新型冠狀病毒感染的肺炎疫情影響,釘釘流量出現了飛躍性增長。

自2月3日以來,釘釘持續迎來流量高峰:遠超1000萬家企業使用釘釘在線辦公,總人數超過2億;全國20多個省份200多個教育局啟動了“課程直播”計劃,涉及2萬多個中小學在內的1200多萬的學生。持續的業務增長也讓釘釘出現了很多歷史性時刻

  • 2月5日釘釘躍居蘋果免費App Store排行榜第一,霸占至今
  • 2月6號釘釘上了中央電視臺,釘釘CTO接受采訪

此次疫情流量主要來源于釘釘遠程辦公和在線教育功能,從字面來看,好像只是釘釘的兩個業務功能,但在釘釘內部依賴模塊不下20個,主要有在消息/視頻會議/直播/家校/健康打卡等業務場景。如何保障超過20個業務在如此爆發式增長下的性能和穩定性,是對釘釘后臺系統、數據庫系統的一個很大挑戰。
本文會從數據庫DBA的視角來介紹下我們是如何打贏這場“戰役”的,在這個過程中我們究竟遇到了哪些挑戰,我們是如何組織我們的團隊,如何思考,如何真正利用技術克服這些挑戰,最后通過這場戰役,我們又沉淀了哪些經驗及技術。

對數據庫系統的挑戰

數據庫是釘釘業務系統運行的強依賴,在這種類似雙11的場景下,如何規劃部署數據庫成了穩定性中最重要的一環,但是這次的戰役來的太突然,我們并沒有很多時間準備,因此我們面臨了非常多的困難與挑戰,總結下來有以下3點:

1、 系統所需要的容量是多少,無法預估

以消息模塊為例,在春節前,釘釘消息日常流量峰值不到千萬,第一次容量評估,大家給2月3號定了個目標是日常峰值的3倍,隨著2月10號開課高峰的到來,又將2月10號的目標調整為10倍,之后又因為2月17號開學季的到來,再次將目標調整為40倍。所以總容量相比日常峰值,翻了40倍! 

2 、時間緊,擴容需求眾多,資源不足

疫情流量的猛增,給系統帶來的沖擊不亞于每年的雙11。電商會花半年時間準備雙11,但這次留給我們的時間只能以小時來計。另一方面,釘釘出于成本的考慮,資源池中基本沒有空余的機器,現有的資源部署密度也比較高,如何騰挪資源在較短的時間內為釘釘接近20個核心集群進行擴容是一個很大的問題。

3、 極限場景下如何保障系統穩定性與用戶體驗

在各種因素制約導致集群無法擴容且系統達已經達到瓶頸時我們能怎么辦?有哪些應急手段能用? 是否存在一個平衡點,將對用戶的影響降到最低?

應對措施

突然間猛增的業務流量也是對釘釘底層數據庫系統,數據庫團隊的一次全面檢驗。依托于底層成熟的管控,DTS,中間件系統,數據庫團隊和釘釘業務團隊緊密合作,通過專業的能力和成熟的產品將上述挑戰一一化解。

1 、人員合理化安排

1)數據庫團隊成立疫情期間釘釘業務保障小組

小組成員包含了數據庫團隊DBA/數據庫內核/CORONA/TDDL/DTS/精衛/NOSQL各產品線同學。
根據釘釘業務線進行分工,每個DBA跟進一個業務線,參與高峰期的保障,及時播報線上系統狀況與水位,讓重保決策人員及時了解系統的狀況。對線上出現的問題緊急處理,保證問題在短時間內得到修復。對不合理的業務場景進行優化,保證已知問題只出現一次。參與系統的壓測,發現潛在風險點及時修正,對系統容量不夠的系統進行及時擴容,在資源滿足的情況下讓數據庫在高峰來臨之前已經具備足夠的容量。

2)數據庫團隊與釘釘穩定性團隊緊密合作

由于前期資源有限,需要擴容的系統眾多,每個業務線owner都覺得自己的系統是最重要的,必須要優先擴容自己的數據庫,甚至有些owner拉自己的領導更甚至領導的領導來找DBA提擴容需求。
這給了DBA非常大的壓力,實在是僧多肉少,無力回天,DBA也因此受了不少委屈,這時候釘釘穩定性團隊主動站了出來,幫DBA分擔了大量的的壓力,他們將數據庫的擴容需求根據業務的重要性進行優先級劃分,統一擴容需求,DBA根據優先級順序,結合業務的目標容量進行判斷,在有限的資源下有條不紊的進行擴容,保證資源優先用在刀刃上,大大提升了擴容效率。

2、 資源緊急協調

疫情突然爆發,所有人都預期流量會增長,但漲多少誰也不知道,必須要早作準備。為了保證資源不成為系統擴容的阻力。DBA和云資源團隊進行合理規劃,短期內通過借用集團上云的機器,同時縮容其他BU數據庫集群,湊出400臺左右的機器,保證高優先級系統的擴容需求,同時協調云資源進行搬遷,在短短幾天內搬遷了300多臺機器到釘釘資源池,保證了釘釘所有數據庫的擴容需求。
資源到位后就是檢驗數據庫彈性的時候了,依托于PolarDB-X 三節點分布式的部署架構,我們可以較為方便的對原有集群進行在線升級和擴容,對用戶影響很低,并保證數據的一致性。有些場景用戶需要從原有集群將數據遷移到分庫分表更多的新集群,我們利用DTS搭配成熟的管控平臺也能較為流暢的完成。最終我們可以做到只要有資源,數據庫也能具有極致的彈性,滿足業務需求。3 、應急與優化在系統高峰來臨之前,數據庫團隊內部已經準備好緊急預案:

  • 參數降級,調整數據庫參數充分發揮數據庫能力,提高吞吐
  • 資源降級,調整資源限制,CPU隔離放開及數據庫BP大小緊急上調
  • 針對異常SQL,確認影響后緊急限流,或者 通過SQL Execute Plan Profile 進行緊急干預
  • 全集群流量備庫分流,依據壓力情況最大可 100% 讀流量切換到備庫
  • 準備數據庫弱一致腳本,在必要時進一步提高數據庫吞吐

同時結合業務的限流/降級預案保證了很多數據庫系統在未知高峰流量到來時的穩定運行。
但業務限流降低了很多用戶的體驗,之前業務限流值設置為30QPM/群,表示為每個群在一分鐘之內只能發送30條消息,很多時候在1分種的前20s甚至更短時間就已經發出30條消息,在剩下時間40s以上時間用戶的體驗就是無法使用釘釘,針對這種情況DBA建議減小限流窗口,將限流值30QPM改成30/20S,限流降低了97%,大大改善了用戶的體驗。
(紅色曲線是限流量)

4 、DB容量預估及性能分析

業務上往往通過集群的CPU情況即可大概分析出系統的水位,但是對DB而言不僅是CPU,IO,網絡,SQL,鎖等等,任何一個組件的瓶頸往往都會成為最終容量的瓶頸。不同的業務模型,往往瓶頸都不一樣,即使都是查詢量較大的業務,有些可能是cpu的瓶頸,有些可能是內存命中率不夠導致的瓶頸,有些則是索引設計不合理導致的瓶頸。更復雜的部分在于,有些瓶頸往往不是線性的,可能壓力提升2倍還沒什么問題,硬件能力都還有富余,但是提升到3倍就直接掛了。在這種場景下我們如何比較準確的評估DB的容量呢?

以往我們都是通過經驗并和業務方一起進行全鏈路壓測進行DB容量(集群能支撐多少讀寫)的預估,這種方式有以下幾個問題:

  • 壓測數據集和數據庫總量相比往往比較小,DB命中率基本100%,這對于分析有IO的業務模型存在較大誤差
  • 成本較大,需要打通上下游整個鏈路,較多的同學參與
  • 即使全鏈路壓測,真正壓到DB端的往往也只是核心的幾個接口,無法100%覆蓋線上所有的接口,而很多慢SQL往往都來自這些易忽略的接口

解決這個痛點問題的方法大家其實很容易想到–只要把線上的業務流量全部采集下來回放一遍即可,但實現起來是非常復雜的。我們真正需要的其實是針對DB的一種通用的單鏈路壓測能力,并不依賴上游業務,DB層可以自己進行流量的生成,放大或縮小,甚至將事務比例更改后再次壓測的能力。
從2019年開始,在DBA和達摩院數據庫實驗室科學家們共同的努力下,我們開發了ClouDBench實現了上述的需求,并在此次的戰役中幫助DBA進行容量的評估。
先展示下效果:

藍色是真實業務在某個時刻的性能曲線,綠色是我們采集DB端流量回放出來的性能曲線,可以看出兩條曲線在時序上高度擬合,特別是InnoDB內部的指標都非常接近,包括流量的波動。
當我們能夠比較真實的回放出業務的workload,我們即可以對壓力進行放大,以此來分析DB的容量,并分析出極限場景下的性能瓶頸,從而進行DB的優化及驗證優化效果。
ClouDBench目前已經在共有云數據庫自治服務Database Autonomy Service(DAS)中灰度上線,我們會在后續的文章中詳細介紹下ClouDBench的實現,敬請期待。

3

成果及思考

在2月17號第三波高峰時,釘釘各系統穩定運行,2月18號開始,我們從之前的全員重保變成日常維護,為什么我們有這個信心,因為我們對所有系統的數據庫都進行了擴容和優化,具有遠超當前系統容量的能力。
短短兩周內各數據庫系統具備了數倍到40倍以上的能力,其中不乏超大型數據庫集群,存儲空間超過1PB。所有這些都充分證明了阿里云數據庫的彈性能力,通過管控/DTS/CORONA各產品的完美配合,使阿里云數據庫在疫情洪峰流量面前戰無不勝。
此次疫情帶來的爆發式流量對我們來說是毫無防備的,經歷過此役,我們學會了很多,如果再次面臨這樣的問題,我們將游刃有余。經驗總結下來有以下幾點:

1、人員組織:

首先在人員組織上,業務和開發要對突發流量具備明銳的嗅覺,及時發現提早準備,由業務方穩定性負責人成立應急小組,梳理依賴業務以及對應后臺系統,將各業務線owner和后臺數據庫產品owner納入應急小組。由應急小組統一容量規劃、人力配備以及資源協調,實現業務方/后臺產品團隊/資源團隊聯動。

2、技術架構:

在技術架構上,一方面是要使用具有足夠彈性的數據庫產品,保證使用的數據庫產品有自由擴容和縮容的能力,既要保證流量來了之后能擴上去,也要保證日常流量時可以縮下來。管控等各個運維組件需要在實現自動化運維的同時,對于很多關鍵操作留有應急開關,確保在一些極端場景下,可以較方便的從自動駕駛切換成手動模式,確保任務平穩高效的運行下去。

3、應急手段:

在面對系統瓶勁時,在業務上和數據庫產品上都要提前做好預案,在業務上要有降級和限流功能,在系統無法承受壓力時,可以降級一部分非核心功能,限制一些次核心功能來保核心業務的正常運行。在數據庫產品上需要具有在不擴容的情況下,通過一些優化手段瞬間提升數據庫吞吐的能力,更重要的是這些能力需要有較好的兼容性,在不同的部署環境,不同的DB架構下都具有相應的工具和預案。
另一方面,我們需要有評估和檢測預案效果的手段,我們現在可以利用ClouDBench對DB進行容量的分析和預測,但是當前的使用成本還是過高,后續ClouDBench需要更加自動化,降低使用成本,將能力透傳給業務的owner,在大促之前,自動進行大量的DB單鏈路壓測,評估系統水位,發現性能瓶頸,優化DB參數,驗證預案效果。

最后祝福釘三多在阿里云數據庫的支撐下飛的更高飛的更遠!

我還沒有學會寫個人說明!

天秀!17歲高中生獨立開發全球疫情追蹤網站后火了...

上一篇

2020 Cisco Live亞太線上峰會亮點“搶鮮看”?

下一篇

你也可能喜歡

釘釘猛增40倍流量壓力,阿里云的DBA們是這樣應對的…

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
天津11选五开奖结果手 股票新手入门知识 分分彩赢彩计划 江苏快三开奖直播 湖北快三一定牛 新疆时时彩三星预测号 今天为什么股票下跌 辽宁11选5网上购买 趋势交易法精华图解 上海十一选五开奖时间 彩票幸运农场玩法