使用Amazon RDS Proxy提升應(yīng)用程序可用性

Amazon RDS Proxy的最大優(yōu)勢，在于顯著縮短數(shù)據(jù)庫故障轉(zhuǎn)移之后的應(yīng)用程序恢復(fù)時(shí)間。RDS Proxy能夠同時(shí)支持MySQL與PostgreSQL引擎，但在本文中，我們將單純使用MySQL測試工作負(fù)載向大家展示RDS Proxy如何在故障轉(zhuǎn)移之后，將Amazon Aurora MySQL客戶端的恢復(fù)時(shí)間縮短達(dá)79%，并將Amazon RDS for MySQL的故障恢復(fù)時(shí)間縮短達(dá)32%。本文還將闡述RDS Proxy如何幫助客戶端擺脫讀取器終端節(jié)點(diǎn)-寫入器終端節(jié)點(diǎn)轉(zhuǎn)換問題，同時(shí)克服客戶端配置中的優(yōu)化不充分狀況。接下來，我們將討論在故障轉(zhuǎn)移期間閑置連接保留機(jī)制的支持下，RDS Proxy如何通過活動(dòng)連接監(jiān)控與客戶端連接池機(jī)制帶來更出色的計(jì)劃內(nèi)與計(jì)劃外故障轉(zhuǎn)移效果。最后，本文還將與大家分享一些關(guān)于客戶端配置的最佳實(shí)踐。

背景

RDS Proxy可以被放置在Amazon RDS for MySQL/PostgreSQL以及Aurora MySQL/PostgreSQL數(shù)據(jù)庫之前。它將幫助用戶管理應(yīng)用程序?qū)?shù)據(jù)庫的訪問，同時(shí)提供連接池、多路復(fù)用以及良好的故障轉(zhuǎn)移功能。除了進(jìn)一步擴(kuò)展數(shù)據(jù)庫的連接限制之外，RDS Proxy還能夠管理應(yīng)用程序的突發(fā)連接與請求。本文將著重介紹RDS Proxy在故障轉(zhuǎn)移層面的優(yōu)勢。

所謂故障轉(zhuǎn)移，就是當(dāng)主數(shù)據(jù)庫實(shí)例無法正常訪問時(shí)，由另一實(shí)例接管并提升為新的主實(shí)例的過程。故障轉(zhuǎn)移會(huì)斷開客戶端連接。對(duì)于由管理操作（例如滾動(dòng)升級(jí)）引發(fā)的故障轉(zhuǎn)移，我們將其稱為計(jì)劃內(nèi)故障轉(zhuǎn)移；而由于真實(shí)故障引發(fā)的故障轉(zhuǎn)移，則屬于計(jì)劃外故障轉(zhuǎn)移。無論如何，我們都需要盡可能縮短停機(jī)時(shí)間以最大程度減少客戶端中斷造成的影響。

Amazon RDS提供多個(gè)高可用性選項(xiàng)，RDS Proxy則為各個(gè)選項(xiàng)提供故障轉(zhuǎn)移恢復(fù)支持。Amazon RDS多可用區(qū)選項(xiàng)能夠在主配置與輔助配置之間實(shí)現(xiàn)同步復(fù)制。Aurora則提供兩種高可用性選項(xiàng)，最多支持15個(gè)異步副本、以及多主模式。全部Aurora副本都處于只讀訪問模式，大家可以選定其中的任何一個(gè)副本節(jié)點(diǎn)并將其提升為集群的新主節(jié)點(diǎn)，而無需擔(dān)心引發(fā)數(shù)據(jù)丟失。Aurora多主模式則可提供多條活動(dòng)寫入通道。

配合這些選項(xiàng)，在發(fā)生故障轉(zhuǎn)移時(shí)，客戶端需要首先檢測連接故障、發(fā)現(xiàn)新的主節(jié)點(diǎn)，并盡快與其重新連接。在RDS Proxy的協(xié)助下，應(yīng)用程序能夠擺脫與故障轉(zhuǎn)移相關(guān)的復(fù)雜性因素，從而實(shí)現(xiàn)更快的恢復(fù)速度（僅需3秒）。Aurora中的故障轉(zhuǎn)移機(jī)制速度更快，其中DNS的傳播延遲就成了影響整體故障轉(zhuǎn)移時(shí)間的核心因素。RDS Proxy會(huì)主動(dòng)監(jiān)控?cái)?shù)據(jù)庫實(shí)例，并自動(dòng)將客戶端接入正確的目標(biāo)。此外，它還會(huì)在數(shù)據(jù)庫故障轉(zhuǎn)移期間繼續(xù)保留閑置的客戶端連接（而非將其丟棄）。所謂閑置連接，是指那些不包含重要請求的連接。

Aurora故障轉(zhuǎn)移

經(jīng)過100次內(nèi)部測試執(zhí)行之后，我們將Aurora集群直連模式與通過RDS Proxy建立的Aurora集群代理模式進(jìn)行了故障轉(zhuǎn)移時(shí)間比較。

下表對(duì)結(jié)果進(jìn)行了總結(jié)，單位為毫秒：

使用RDS Proxy時(shí)的平均故障轉(zhuǎn)移時(shí)長為3.1秒，使用MariaDB驅(qū)動(dòng)程序進(jìn)行數(shù)據(jù)庫直連的平均故障轉(zhuǎn)移時(shí)長則高達(dá)24秒。改進(jìn)幅度高達(dá)87%。

對(duì)于關(guān)系數(shù)據(jù)庫來說，即使只是最基礎(chǔ)的基準(zhǔn)測試，只需3秒的故障轉(zhuǎn)移速度也著實(shí)令人驚嘆。而這一切，都是Aurora努力創(chuàng)新的成果。但顯而易見的是，即使是以往表現(xiàn)最佳的MariaDB Aurora驅(qū)動(dòng)程序（其中針對(duì)故障轉(zhuǎn)移進(jìn)行了優(yōu)化）也不足以發(fā)揮Aurora的所有優(yōu)勢。只有配合RDS Proxy，我們才能真正讓Aurora MySQL的故障轉(zhuǎn)移變得迅如閃電，突破驅(qū)動(dòng)程序本身對(duì)于數(shù)據(jù)庫恢復(fù)速度的限制。

DNS生存時(shí)間

大家可以采用多種不同方式調(diào)整客戶端驅(qū)動(dòng)程序。例如，MariaDB ConnectorJ驅(qū)動(dòng)程序就提供近100種配置選項(xiàng)。操作系統(tǒng)、JVM以及連接池框架中還包含更多配置選項(xiàng)。本文將只討論其中最重要的部分，首先自然是DNS客戶端緩存配置。

在客戶端使用DNS名稱接入數(shù)據(jù)庫時(shí)，首先需要通過查詢DNS服務(wù)器將該名稱解析為IP地址。客戶端隨后會(huì)將響應(yīng)結(jié)果保存在緩存當(dāng)中。根據(jù)協(xié)議，DNS響應(yīng)結(jié)果中指定了生存時(shí)間（TTL），即控制客戶端將該記錄緩存多長時(shí)間。RDS中的TTL設(shè)置默認(rèn)為4秒，但各類系統(tǒng)往往會(huì)在客戶端緩存中使用不同的設(shè)置，進(jìn)一步延長TTL。操作系統(tǒng)與JVM運(yùn)行時(shí)環(huán)境都存在這樣的緩存機(jī)制。JVM中的緩存設(shè)置因版本與操作系統(tǒng)而異，因此我們需要做出明確的設(shè)定。以下代碼所示，為建議設(shè)定值：

java.security.Security.setProperty("networkaddress.cache.ttl","1");

java.security.Security.setProperty("networkaddress.cache.negative.ttl","1");

這就縮短了JVM中的默認(rèn)DNS緩存生存時(shí)間，使驅(qū)動(dòng)程序能夠在故障轉(zhuǎn)移期間更快發(fā)現(xiàn)DNS名稱IP地址的變更。

配合客戶端優(yōu)化的故障轉(zhuǎn)移基準(zhǔn)

在下一項(xiàng)基準(zhǔn)測試中，我們將使用經(jīng)過DNS TL設(shè)置優(yōu)化的客戶端（如前所述）以及本文稍后將談到的其他推薦客戶端設(shè)置。在下圖中，我們比較了使用最佳設(shè)置的MariaDB驅(qū)動(dòng)程序與通過RDS Proxy接入Aurora MySQL時(shí)的故障轉(zhuǎn)移時(shí)間差異。

下表對(duì)測試結(jié)果做出匯總，單位為毫秒。

使用精心調(diào)優(yōu)的MariaDB客戶端，配合RDS Proxy時(shí)的平均故障轉(zhuǎn)移時(shí)間為2.9秒，而直連的平均故障轉(zhuǎn)移時(shí)間為13.8秒——RDS Proxy的改進(jìn)幅度為79%。請注意，具體恢復(fù)時(shí)間還與實(shí)際工作負(fù)載密切相關(guān)。

Aurora客戶端配置

在之前的測試中，我們使用了針對(duì)Aurora做出增強(qiáng)優(yōu)化的MariaDB COnnectorJ。具體來講，指向該數(shù)據(jù)庫的直接連接使用以jdbc:mariadb:aurora://<cluster-endpoint>開頭的連接URL。如此一來，MariaDB COnnectorJ驅(qū)動(dòng)程序就能夠使用Aurora中的專用系統(tǒng)標(biāo)簽快速發(fā)現(xiàn)主數(shù)據(jù)庫實(shí)例。

通過RDS Proxy的連接則使用常規(guī)驅(qū)動(dòng)程序，其中的URL為jdbc:mariadb://<proxy-endpoint>形式。盡管未使用任何特殊的客戶端配置，但RDS Proxy仍然取得了更好的故障轉(zhuǎn)移時(shí)間成績。更重要的是，其中的客戶端邏輯更加簡單，因此RDS Proxy將具有更好的普適性。

讀取器與寫入器角色轉(zhuǎn)換

一旦主實(shí)例出于某些原因而不再可用，Aurora會(huì)自動(dòng)執(zhí)行故障轉(zhuǎn)移。在故障轉(zhuǎn)移期間，主實(shí)例會(huì)由寫入器角色轉(zhuǎn)換為讀取器角色；與此同時(shí)，Aurora集群中的某讀取器節(jié)點(diǎn)將被提升為主實(shí)例。如果直連集群端點(diǎn)，由于DNS記錄可能被緩存，因此客戶端仍可能繼續(xù)接入舊的主實(shí)例。這時(shí)，即使建立起連接，由于舊的主實(shí)例角色已經(jīng)發(fā)生變化（轉(zhuǎn)換為只讀實(shí)例），客戶端將無法正常執(zhí)行寫入操作。RDS Proxy能夠消除此類錯(cuò)誤，保證客戶端永遠(yuǎn)只接入當(dāng)前的主實(shí)例。

主動(dòng)監(jiān)控與計(jì)劃外故障轉(zhuǎn)移

RDS Proxy并不依賴DNS傳播來執(zhí)行故障轉(zhuǎn)移，因此能夠改善整個(gè)轉(zhuǎn)移效果。RDS Proxy徹底消除了之前提到的Aurora集群客戶端讀取器-寫入器角色轉(zhuǎn)換的問題。它能夠主動(dòng)監(jiān)控Aurora數(shù)據(jù)庫集群中的各個(gè)數(shù)據(jù)庫實(shí)例，并在故障轉(zhuǎn)移期間快速調(diào)整客戶端的操作方式。

到目前為止，本文所涉及的都只是計(jì)劃內(nèi)/管理性故障轉(zhuǎn)移場景。對(duì)于Aurora，我們可以通過AWS管理控制臺(tái)、API或者AWS命令行界面（AWS CLI）根據(jù)需求調(diào)整實(shí)例大小，Amazon也可能根據(jù)用戶指定的維護(hù)計(jì)劃執(zhí)行集群調(diào)整，由這類操作帶來的都屬于計(jì)劃內(nèi)故障轉(zhuǎn)移。在這類情況下，在數(shù)據(jù)庫進(jìn)程未準(zhǔn)備就緒時(shí)，數(shù)據(jù)庫主機(jī)將正常關(guān)閉連接并拒絕創(chuàng)建新的連接。這意味著客戶端或RDS Proxy能夠輕松檢測到問題，并稍后執(zhí)行重試。

但在計(jì)劃外故障轉(zhuǎn)移的場景下，主機(jī)會(huì)毫無征兆地突然失去可訪問性。現(xiàn)有客戶端TCP連接仍然處于開啟狀態(tài)，而客戶端檢測到當(dāng)前連接因收不到響應(yīng)而造成死信。要應(yīng)對(duì)這類情況，我們需要遵循以下最佳實(shí)踐，包括配置套接字超時(shí)、連接超時(shí)以及TCP繼續(xù)活動(dòng)等。RDS Proxy也可以協(xié)助客戶端順利應(yīng)對(duì)這類計(jì)劃外故障轉(zhuǎn)移。

RDS Proxy會(huì)監(jiān)控每個(gè)數(shù)據(jù)庫實(shí)例，并在幾秒鐘之內(nèi)檢測到故障。一旦發(fā)現(xiàn)故障，RDS Proxy將停止將新查詢定向至存在故障的數(shù)據(jù)庫實(shí)例。在故障轉(zhuǎn)移期間，RDS Proxy還會(huì)保留各閑置客戶端連接，意味著存在非活動(dòng)連接的客戶端連接池也能夠更輕松地處理故障轉(zhuǎn)移，而無需重新創(chuàng)建每一條連接。如此一來，客戶端將節(jié)約下重建閑置TLS連接所帶來的開銷。另外，RDS Proxy還能夠主動(dòng)終止故障數(shù)據(jù)庫實(shí)例中那些未執(zhí)行完畢的事務(wù)，幫助客戶端快速重試（而不必等待超時(shí)）。

RDS Proxy始終接受新連接，并會(huì)延后轉(zhuǎn)發(fā)查詢，直到新的主實(shí)例恢復(fù)可用為止。如果沒有RDS Proxy，一旦發(fā)生故障轉(zhuǎn)移，客戶端只會(huì)檢測到主數(shù)據(jù)庫實(shí)例不可用，并可能立即嘗試重新連接。由于主數(shù)據(jù)庫仍在恢復(fù)當(dāng)中，這些重連嘗試往往不會(huì)成功。而一旦重新連接次數(shù)過多，主實(shí)例的恢復(fù)很可能因此而再次崩潰。結(jié)果就是，客戶端的重試邏輯反而加重了故障的嚴(yán)重程度。但在RDS Proxy的加持下，我們根本不需要建立這種復(fù)雜的重試邏輯。

Amazon RDS多可用區(qū)模式

Amazon RDS的多可用區(qū)模式，是一項(xiàng)有助于緩解計(jì)劃外故障轉(zhuǎn)移影響的重要功能。使用RDS MySQL中的多可用區(qū)配置時(shí)，主數(shù)據(jù)庫實(shí)例將位于某一可用區(qū)內(nèi)，而同步備用實(shí)例則位于其他可用區(qū)。此時(shí)，客戶端應(yīng)用程序?qū)⑹褂媚稠?xiàng)主機(jī)名稱指向數(shù)據(jù)庫的主實(shí)例。一旦發(fā)生故障，RDS服務(wù)將切換主實(shí)例與輔助實(shí)例之間的角色。此外，RDS服務(wù)還將變更數(shù)據(jù)庫主機(jī)名稱的基礎(chǔ)IP地址，確?？蛻舳藨?yīng)用程序無需變更自身連接設(shè)置即可在故障轉(zhuǎn)移期間直接接入新的主數(shù)據(jù)庫實(shí)例。

使用Amazon RDS多可用區(qū)模式，原始主實(shí)例在故障轉(zhuǎn)移期間不再需要關(guān)閉其TCP連接。故障轉(zhuǎn)移開始后，客戶端將不再從數(shù)據(jù)庫處獲取更多TCP流量，而是由客戶端自主判斷是否超時(shí)。這種精心設(shè)計(jì)的原始主數(shù)據(jù)庫實(shí)例硬防護(hù)機(jī)制，意味著客戶端能夠隨時(shí)從容應(yīng)對(duì)計(jì)劃內(nèi)與計(jì)劃外故障轉(zhuǎn)移。這樣做的最大好處在于，只需要通過Amazon RDS API或CLI進(jìn)行管理性故障轉(zhuǎn)移，即可輕松對(duì)現(xiàn)有系統(tǒng)的計(jì)劃內(nèi)與計(jì)劃外故障轉(zhuǎn)移效果做出測試。但需要注意的是，MariaDB驅(qū)動(dòng)程序以及多數(shù)操作系統(tǒng)中的默認(rèn)設(shè)置并不能夠很好地配合多可用區(qū)模式。在默認(rèn)情況下，MariaDB驅(qū)動(dòng)程序永遠(yuǎn)不會(huì)將響應(yīng)等待判定為超時(shí)，而某些操作系統(tǒng)的TCP活動(dòng)保持周期可能超過2個(gè)小時(shí)。但好消息是，RDS Proxy將徹底消除這些設(shè)置，現(xiàn)在主機(jī)名稱的基礎(chǔ)DNS配置（在本示例為中RDS Proxy）將永遠(yuǎn)不會(huì)變更。

RDS多可用區(qū)故障轉(zhuǎn)移恢復(fù)基準(zhǔn)

以下結(jié)果，為使用MariaDB驅(qū)動(dòng)程序直連數(shù)據(jù)庫與通過RDS Proxy連接時(shí)，對(duì)50次故障轉(zhuǎn)移的測試結(jié)果。表內(nèi)各項(xiàng)數(shù)值的單位為毫秒。

總之，將RDS Proxy與Amazon RDS多可用區(qū)數(shù)據(jù)庫配合使用，平均故障轉(zhuǎn)移周期約為25秒；而數(shù)據(jù)庫直連模式的停機(jī)時(shí)間則在37秒到40秒之間。

而且與Amazon RDS多可用區(qū)的25秒恢復(fù)時(shí)間相比，Aurora在db.r5.large實(shí)例上的恢復(fù)時(shí)間甚至可以做到3秒以內(nèi)。這主要是因?yàn)锳urora當(dāng)中包含多項(xiàng)創(chuàng)新功能，可在故障轉(zhuǎn)移之后加快數(shù)據(jù)庫的恢復(fù)時(shí)間。

總結(jié)

本文向大家介紹了RDS Proxy的以下幾項(xiàng)核心優(yōu)勢：

·在測試工作負(fù)載中，將Aurora MySQL的故障轉(zhuǎn)移時(shí)間縮短達(dá)79%。

·在測試工作負(fù)載中，將RDS MySQL多可用區(qū)的故障轉(zhuǎn)移時(shí)間縮短達(dá)32%。

·無需特殊的客戶端邏輯，能夠與多種不同客戶端驅(qū)動(dòng)程序良好對(duì)接。

·將客戶端與Aurora集群中的讀取方-寫入方角色轉(zhuǎn)換隔離開來。

·主動(dòng)監(jiān)控各數(shù)據(jù)庫，包括計(jì)劃外故障轉(zhuǎn)移跡象。

·在故障轉(zhuǎn)移期間不丟棄閑置連接，從而減少對(duì)客戶端連接池的影響。

·始終接受連接，使客戶端免受連接超時(shí)的影響。

RDS Proxy也非常易于上手。大家可以將任何MySQL或者PostgreSQL客戶端驅(qū)動(dòng)程序與RDS Proxy端點(diǎn)相對(duì)接，并立即享受由其帶來的便利。歡迎大家馬上開始體驗(yàn)RDS Proxy！