簡介：釘釘猛增40倍流量壓力 阿里云DBA如何應對

1.背景

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

2.對數據庫系統的挑戰

數據庫是釘釘業務系統運行的強依賴，在這種類似雙11的場景下，如何規劃部署數據庫成了穩定性中最重要的一環。但是這次的戰役來得突然，并沒有很多時間準備，因此面臨了非常多的困難與挑戰，總結下來有以下3點：
（1）系統所需要的容量是多少，無法預估
以消息模塊為例，在春節前，釘釘消息日常流量峰值不到千萬，第一次容量評估，大家給2月3號定的目標是日常峰值的3倍。隨著2月10號開課高峰的到來，又將2月10號的目標調整為10倍。之后又因為2月17號開學季的到來，再次將目標調整為40倍。所以總容量相比日常峰值翻了40倍！
（2）時間緊，擴容需求眾多，資源不足
疫情流量的猛增，給系統帶來的沖擊不亞于每年的雙11。電商會花半年時間準備雙11，但這次留給我們的時間只能以小時來計。另一方面，釘釘出于成本的考慮，資源池中基本沒有空余的機器，現有的資源部署密度也比較高，如何騰挪資源在較短的時間內為釘釘接近20個核心集群進行擴容是一個很大的問題。
（3）極限場景下如何保障系統穩定性與用戶體驗
在各種因素制約導致集群無法擴容且系統達已經達到瓶頸時我們能怎么辦？有哪些應急手段能用？是否存在一個平衡點，將對用戶的影響降到最低？

3.應對措施

3.1人員合理化安排

（1）數據庫團隊成立疫情期間釘釘業務保障小組
小組成員包含了數據庫團隊DBA/數據庫內核/CORONA/TDDL/DTS/精衛/NOSQL各產品線同學。根據釘釘業務線進行分工，每個DBA跟進一個業務線，參與高峰期的保障，及時播報線上系統狀況與水位，讓重保決策人員及時了解系統的狀況。對線上出現的問題緊急處理，保證問題在短時間內得到修復。對不合理的業務場景進行優化，保證已知問題只出現一次。參與系統的壓測，發現潛在風險點及時修正，對系統容量不夠的系統進行及時擴容，在資源滿足的情況下讓數據庫在高峰來臨之前已經具備足夠的容量。
（2）數據庫團隊與釘釘穩定性團隊緊密合作
由于前期資源有限，需要擴容的系統眾多，此時釘釘穩定性團隊主動站出來幫DBA分擔了大量的的壓力。他們將數據庫的擴容需求根據業務的重要性進行優先級劃分，統一擴容需求，DBA根據優先級順序，結合業務的目標容量進行判斷，在有限的資源下有條不紊地進行擴容，保證資源優先用在刀刃上，大大提升了擴容效率。

3.2資源緊急協調

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

3.3應急與優化

在系統高峰來臨之前，數據庫團隊內部已經準備好緊急預案：

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

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

3.4 DB容量預估及性能分析

業務上往往通過集群的CPU情況即可大概分析出系統的水位，但是對DB而言不僅是CPU，IO、網絡、SQL、鎖等等，任何一個組件的瓶頸往往都會成為最終容量的瓶頸。不同的業務模型，往往瓶頸不一樣，即使都是查詢量較大的業務，有些可能是CPU的瓶頸，有些可能是內存命中率不夠導致的瓶頸，有些則是索引設計不合理導致的瓶頸。更復雜的部分在于，有些瓶頸往往不是線性的，可能壓力提升2倍還沒什么問題，硬件能力都還有富余，但是提升到3倍就直接崩潰。在這種場景下我們如何比較準確地評估DB的容量呢？
以往我們都是通過經驗并和業務方一起進行全鏈路壓測進行DB容量（集群能支撐多少讀寫）的預估，這種方式有以下幾個問題：（1）壓測數據集和數據庫總量相比往往比較小，DB命中率基本100%，這對于分析有IO的業務模型存在較大誤差；（2）成本較大，需要打通上下游整個鏈路，需較多的人員參與，即使進行全鏈路壓測，真正壓到DB端的往往也只是核心的幾個接口，無法100%覆蓋線上所有的接口，而很多慢SQL往往都來自這些易忽略的接口。
解決這個痛點問題的方法很容易想到——只要把線上的業務流量全部采集下來回放一遍即可，但實現起來是非常復雜的。我們真正需要的其實是針對DB的一種通用的單鏈路壓測能力，并不依賴上游業務，DB層可以自己進行流量的生成、放大或縮小，甚至具備將事務比例更改后再次壓測的能力。從2019年開始，在DBA和達摩院數據庫實驗室科學家們共同的努力下，我們開發了ClouDBench實現了上述的需求，并在此次的戰役中幫助DBA進行容量的評估。效果如下圖所示：

圖1：ClouDBench容量評估效果展示

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

4.成果及思考

短短兩周內各數據庫系統具備了數倍到40倍以上的能力，其中不乏超大型數據庫集群，存儲空間超過1PB，所有這些都充分證明了阿里云數據庫的彈性能力。此次疫情帶來的爆發式流量對我們來說是毫無防備的，經歷過此役，經驗總結下來有以下幾點：

4.1人員組織

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

4.2技術架構

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

4.3應急手段

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

作者：章左中

阿里云智能數據庫產品團隊運維專家

阿里巴巴運維專家，從事數據庫領域十年以上，先后在甲骨文（中國）、網易等公司任職，在傳統行業和互聯網行業都有著豐富的經驗。目前在阿里云數據庫事業部從事專家服務相關工作，擅長數據庫優化、架構設計及異構數據庫之間的遷移等。

作者：陳榮耀

阿里云智能數據庫產品團隊運維專家

曾就職于烽火通信任職Oracle DBA，2015年加入阿里，現任阿里云數據庫運維專家，有豐富的Oracle、MySQL運維開發經驗，擅長數據庫故障診斷、性能調優、穩定性建設。目前主要負責數據庫性能壓測、流量回放（ClouuDBench ）等。

我們是阿里云智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用云、基于云構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上云、用好云，讓客戶云上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里云SRE技術學院釘釘圈子，和更多云上人交流關于云平臺的那些事。

原文鏈接：https://developer.aliyun.com/article/771485?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的钉钉猛增40倍流量压力，阿里云DBA如何应对？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。