Aurora Serverless v2 架構解析

作者:吳炳錫

        如果Aurora v1是數據庫中革命性一個版本,但在Aurora Serverless V2這裏也只能說是V1是一個實驗性的版本,V2纔算是真正的成熟。這裏從AWS Invent大會獲得的資料來解析一下Aurora Serverless V2。該架構感覺也是給數據庫行業揭開了一個新的篇章。

        官宣: Amazon Aurora Serverless v2 目前爲預覽版,可以在不到一秒的時間內完成擴展,瞬間將處理能力從數百個事務擴展到數十萬個事務。在擴展過程中,系統會以極爲精細的增量調整容量,從而確保恰好提供應用程序所需的數據庫資源量。您無需管理數據庫容量,並且只需爲您的應用程序使用的容量付費。與按照峯值負載來預置容量相比,您最高可以節省 90% 的數據庫成本。

Aurora’s architecture

        Aurora Serverless v2從架構上看有三個組件:RDS proxy , Query Layer 和Storage layer三層。三層服務相對獨立實現, 只有Query layer是基於第三方的開源代碼實現。

 

RDS Proxy

         RDS Proxy也可以說爲Router Layer。實現上非常輕量。Router Layer可以理解爲是一個Proxy但具備連接池和流控的作用。支持MySQL,PostgresSQL協議。 

         Proxy只是簡單的處理連接請求及把請求路由到正確的Query進程之外還有兩個目的:

        1. 從原始的數據庫中剝離出來,形成連接成的Serverless架構更易伸縮 。

        2. 會話保持後面的存儲節點或是Query層重啓,也可以保持客戶端的連接不斷開。

        路由層還可以跟蹤數據庫的連接分析數據庫的使用及性能情況以便實現自動擴容,這種對於Serverless架構把接入層獨立出來非常的重要。在一些版本中Aurora還支持通過HTTP Data API請求SQL,該設計就是基於router層來得的益處。

        對於寫操作,也可以直接通過Primary 節點處理,對於Primary節點就處於一種非serverless架構下(如果不經過Proxy可能最大的問題就是沒有寫節點的高可用保障)

 

Query層

        可以稱query layer爲數據庫層,這個是主要的事務處理及計算實現的組件。通過Router層和Query層相連,同時接觸Router層傳遞的SQL並執行,讀取寫入存儲層的的數據和索引。

        Query layer是直接借籤使用開源的PostgreSQL和MySQL的代碼,這部分代碼基本沒有變化,所以在使用Aurora時也要注意一下和那個版本的特性匹配(目前看MySQL是5.7的)在經典的software-as-a-Service的架構中一般是一個API支持多版本請求,但Aurora中只支持固定的版本對所有用戶服務(避免多版本,讓開發更輕鬆)。在自動擴展和自動故障轉移方面更多的和自已託管的開源數據庫方案一樣。

        在Aurora集羣中同時只有一個寫實例,可以支持多個read-only實例(目前支持15個)。和使用MySQL的Master/Slave一樣的。

        Query進程是跑在Vm中,所以選擇合理的配置,可以讓Query層獲得更好的性能。這點更加體現了Serverless架構設計中,把計算層重的地方單獨剝離出來,獨立部署的好處了。

 

 

Storage層

         Aurora中Storage層使用雲上高速S3塊存儲構建。存儲層使用Log-Structured  engine原生分佈式設計。 同個Region中6副本,至少保證寫4份纔算成功。

在Aurora中Storage層控制數據在Region中及多Region中複製,該複製通過存儲層實現的。這複製不同於傳統的OS RDS通過RDMS自身的Query處理。

         在Aurora中爲了保證數據的強一致性,不管在哪個Region中的讀寫事務(或是強一致性的讀),寫事務必須由路由到主進程處理。讀操作可以走其它Reader進程,讀取的數據最終都是一致的(從技術來講Aurora也可以做到Multi-primary的對外服務模型,但有可能破壞數據的一致性)

         由於這個限制,在Aurora中讀寫事務會隨着Client和主進程之間的物理離增大而變的響應時間增長。針對這個問題Aurora在設計上引入了process-to-process的轉發請求,儘可能的命中Local數據請求命中返回,但這個不能從根本上避免所有的強一致性的事務必須走主進程請求的性能問題。另外強一致的事務併發請求在主進程請求中也沒有隔離。

         爲了高可用,每個Aurora Region爲每個數據庫保持6個副本,每個AZ中保存2個副本。從而來減少故障對於應用的最小影響:

  • 在不同的AZ中總共丟掉兩個副本,用戶是感知不到的。

  • 在同一個AZ中丟失兩個副本,則該AZ的請求用戶會感知延遲增大,因爲在這個AZ的請求自動轉遷移到其它AZ中,但這個數據庫依然可以提供寫操作。

  • 如果丟失三個副本將會讓數據庫進入只讀模式,能寫入,但數據不會丟失。

  • 如果丟失4個副本整個集羣可能不可用,且有可能造成數據丟失

 

--------------------------------

      可能解析有誤,直接把油管地址放出來自取:https://www.youtube.com/watch?v=PQHZrtIgdiA 。歡迎交流。 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章