乾貨|上雲了，如何保障雲資料庫的高可用？

京東科技開發者發表於2019-11-20
資料庫
乾貨|上雲了，如何保障雲資料庫的高可用？

責任共擔模型

朋友和我吐槽，自從他負責的系統上雲後，在雲資料庫上經歷了好幾次故障，而事後的故障覆盤，居然都是他們自己的責任和問題，這讓他很被動。更尷尬的是，原想著上雲後，資料庫的問題都是公有云廠商負責，所以他們運維團隊中也沒有招聘DBA，當下沒有很好的最佳化思路，於是找我一起探討這個問題。
朋友的這個Case很典型，認為上雲就萬事大吉，上雲後一旦出現問題，又會覺得上雲各種不靠譜。在公有云廠商中，被大家廣為認可的觀點是“責任共擔模型“。在海外，亞馬遜AWS、微軟Azure均採用了與使用者共擔風險的安全策略。例如，AWS 作為IaaS+PaaS為主的服務提供商，負責管理雲本身的安全，業務系統安全則由客戶負責。客戶可以在AWS安全市場裡挑選合適的產品來保護自己的內容、平臺、應用程式、系統和網路安全。而微軟Azure也探討了IaaS, PaaS和SaaS使用者的“責任遞減”模式。在這裡，我們並不打算展開討論該問題，只是希望引入該概念，讓大家建立初步的認知：上雲後，依然是需要客戶和平臺雙方通力合作才能取得好的結果。

上雲後他經歷了什麼？

下面是朋友講述的故障，限於故障原因的重複，我刪減了一些Case，聽朋友講完後，我非常吃驚，心裡暗想，這和上雲有啥關係，這些問題，你不上雲照樣都會發生的，只能說你運氣好，發生在上雲期間，大家對於新事物多少有一些寬容，不然，後果不敢想啊。
  • 後端模組批次重啟，重啟時需要從資料庫載入業務資料，因併發重啟且該請求為慢SQL（幾十秒），雲資料庫負載快速升高，部分請求開始超時，然後請求失敗的模組無限重試，導致雲資料庫負載過大而崩潰，依賴該資料庫的其他業務也全部故障；
  • 在短時間大量併發請求資料庫，高峰期併發達到2200左右，導致資料庫出現大量慢SQL，進而資料庫效能急劇下降，多個業務頁面展現變慢，效能退化明顯；
  • 批次建立的任務，其執行時間完全一致，系統在瞬間對資料庫請求大量資料，連線數上漲，導致該資料庫上的所有業務均發生故障；
  • 一次秒殺活動，系統請求量劇增，峰值流量達到平時流量的30倍，遠超之前預估流量。部分功能大量請求資料庫，佔滿資料庫連結，導致資料庫崩潰，進而引起系統無法正常執行
  • 其購買的安全掃描產品，對介面進行了空引數請求，而介面對於空引數請求進行了資料庫的全表掃描，資料庫壓力飆升，陸續出現了慢SQL，資料庫CPU使用率持續在100%，導致該資料庫上的其他業務也全部故障；
  • 某服務訪問資料庫錯誤導致響應下游請求合法使用者列表的結果為空值，下游模組直接將所有使用者的許可權全部刪除，導致系統完全不可用；
  • 沒有專職DBA，雲資料庫的變更直接交由研發自己執行，研發多次資料庫修改出現異常，導致服務故障和資料丟失；
  • 研發懷疑資料庫效能惡化，因此就重啟了資料庫，重啟期間，有一個模組請求資料庫失敗，就直接崩潰了；
  • 在華南部署的一套業務系統，連到華北的資料庫，導致系統的響應時間長期居高不下，原因是一個頁面包含了非常多的資料庫請求，單個請求延時增加40ms，但幾十個請求序列執行，延時足足增加了2s以上。

故障原因分析

和京東雲平臺質量部的同學們對上述的Case進行分析後，我們總結了以下原因：


慢SQL

常態下系統中存在很多慢SQL，其執行時間少則15s，多則60s以上，如果慢SQL的執行次數增加，必然導致雲資料庫壓力上升，資料庫連線被佔用，處理其他請求的速率也慢了下來，直至連線數被耗光，導致服務異常，或者在連線數沒耗光之前，就因為資料庫CPU使用率100%而導致服務異常了。


高頻SQL

高頻SQL看似沒有問題，但延時一旦增加或者網路抖動，高頻SQL就可能變為較慢的SQL，基於其基礎足夠大，足以將系統拖垮。


複用

上面的多次故障都是因為某一個業務異常導致資料庫故障後，影響到了資料庫上的所有業務，這可能是源於期望降低運維複雜度，所以搞了一個最大規格資料庫的原因，確實，所有業務共用一個資料庫從管理角度肯定更簡單。


讀寫未分離

上述的Case，大部分都是讀請求導致的故障，突然間因為各種原因，導致請求上漲，而資料庫例項只有一個，沒有水平擴充套件，所以很容易被打掛。


資料庫連線數設定不合理

從故障描述中可以看到，隨便一個請求，都可以把資料庫的併發連線數打到2000+以上，進而導致其他業務不可用，沒有對不同業務進行合理的資源分配。


缺乏變更流程

研發直接到線上資料庫中修改資料，修改錯誤的原因有表的名字錯了，where條件錯了，或者是對較大的表結構進行調整，操作前不線上下進行測試驗證，操作前也不進行資料庫備份，很容易導致重大事故。


許可權管理混亂

多個CASE都是研發直接操作線上資料，這是許可權管理混亂的表現，也是很危險的事情。試想，人人都能修改資料庫，會有什麼後果大家應該都很清楚。如果修改了和交易資料相關的資料，或者是刪庫跑路，那就麻煩了。


不限流

多個CASE也都看到這個問題，所有的介面都沒有做限流，大家可以發起隨意量級的訪問，因此隨便一個使用者發起批次請求都足以將系統打垮。


雲平臺質量部的建議

結合該朋友的情況，雲平臺質量部的同學經過討論後，對資料庫的改進給出如下建議，而對於一些較為通用的問題，如系統異常後直接崩潰，空引數等等，則不在此進行討論，我們後續會有專門的文章進行說明

TOP-N的SQL限流

TOP-N的SQL分為兩種情形：
  • 慢SQL，也就是執行耗時的TOP-N
  • · SQL最佳化
  • · 合理設定資料庫連線數
  • · 執行耗時超過1s的SQL直接kill（對於部分場景可以進行自定義，如同步任務，寫SQL，重要性較高的SQL等）
  • · SQL問題較多的賬號進行緊急封禁
  • 高頻SQL，也就是執行頻次的TOP-N
  • · 透過業務層的快取功能減少高頻SQL


在京東雲上，提供了效能最佳化的功能，可以查詢到所有的慢SQL，一定要加以使用

乾貨|上雲了，如何保障雲資料庫的高可用？


最後提一句，一定要想辦法在叢集上實現自動化kill慢SQL的功能，而不要等遇到出問題後挨個找人來看能不能殺這些SQL，那就太晚了，經驗值，一旦走到這個地步，故障時長起步40分鐘。


隔離部署

核心業務必須使用獨立的資料庫例項，僅非核心業務可以考慮共用資料庫例項。從而避免單個使用者的問題影響到所有業務。但隔離不僅僅是基於業務角度進行隔離，還可以根據業務情況進行其他維度的隔離，例如將一些報表類業務從核心業務中剝離出來，類似的思路，業務運維的隔離方式有很多，可以參考《任務排程系統如何透過隔離提升可用性？》
從成本角度看，京東雲很好的考慮到了這點，兩個小例項的價格等於一個大例項的價格，因此拆分並不會增加費用，而管理成本的增加也非常低。
乾貨|上雲了，如何保障雲資料庫的高可用？
乾貨|上雲了，如何保障雲資料庫的高可用？


讀寫分離

京東雲的雲資料庫提供只讀例項，需要利用好該特性。簡單點就是新增幾個只讀例項將讀請求進行遷移，複雜點，可以將不同業務型別的讀請求分配到不同的只讀例項上，利用隔離的特性將故障控制在較小的範圍內，從而保障大部分功能的正常使用。


乾貨|上雲了，如何保障雲資料庫的高可用？



限流

限流不僅僅在資料庫層面透過連線數的方式進行控制，更需要前置在業務側進行，畢竟業務側的限流機制會更為靈活和定製化，更能滿足業務的需求。如何限流，可以參考《預案三板斧的限流大 法》。


資料備份

對資料庫的任何修改和調整，都需要進行備份，以免發生上述朋友的問題。京東雲提供了靈活的資料庫備份管理功能，需要好好的使用起來。這個地方的重要性，就不贅述了。


乾貨|上雲了，如何保障雲資料庫的高可用？


資料庫的監控

沒上雲之前，可能會有專門的DBA團隊來對資料庫進行監控，上雲後，如果沒有專職的DBA，那麼業務運維團隊就需要承擔起這個責任來。下面是從京東雲的監控中擷取的幾個關鍵指標，當然，還需要有對資料庫功能的監控。在這點上，雲平臺質量部有較為豐富的經驗，大家也可以參考《監控不到位，當機兩行淚》。


乾貨|上雲了，如何保障雲資料庫的高可用？
乾貨|上雲了，如何保障雲資料庫的高可用？
乾貨|上雲了，如何保障雲資料庫的高可用？


流程建立

對於變更和許可權管理等，都需要逐步建立起相關的流程，並儘量自動化起來。同時，針對各種高頻操作，還可以提供如操作手冊，checklist手冊等，儘量減少手工操作。

三板斧

我個人的習慣，任何問題，提供了多個解決方案後，最後都要透過三板斧來進行優先順序排序，便於大家抓住重點：
  • 隔離部署&&讀寫分離，利用京東雲的能力，可以快速搞定，所以放第一位；
  • TOP-N的SQL，找出來容易，最佳化則需要研發配合，因此放第二位，可以先從那些執行時間幾十秒的SQL開始下手；
  • 限流，或者在接入層進行，或者核心模組上進行開發，耗時略長，因此放第三位。


最後，感謝平臺質量部的多個小夥伴一起群策群力完成的上述方案。



參考文獻：

任務排程系統如何透過隔離提升可用
預案三板斧的限流大 法
監控不到位，當機兩行淚
責任共擔模型



點選“ 連結 ”瞭解雲資料庫 SQL Server更多詳情！
歡迎點選“ 京東雲 ”瞭解更多精彩內容。


乾貨|上雲了，如何保障雲資料庫的高可用？

乾貨|上雲了，如何保障雲資料庫的高可用？


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69912185/viewspace-2664961/，如需轉載，請註明出處，否則將追究法律責任。

相關文章