案例研究: 解密AWS增長最快最賺錢的雲服務Aurora

摘要： 今年8月9日，在京召開的亞馬遜AWS中國技術峰會上，亞馬遜AWS全球副總裁、大中華區執行董事容永康宣佈，AWS 歷史上使用者數量增速最快的雲服務Amazon Aurora登陸中國，並在由西雲資料運營的AWS中國（寧夏）區域率先提供服務。

與此同時，AWS在北京區域和寧夏區域一併推出了資料庫遷移服務，在幫助客戶從傳統資料庫快速遷移到Aurora平臺的同時，快速搶佔市場。

眾所周知，資料庫服務是粘性最強的雲服務之一，一旦客戶被吸附，轉投其他雲的可能性就微乎其微。

如今3個月過去了，因為沒有官方資料，所以，這3個月到底有多少中國企業選擇並遷移到Aurora之上不得而知。不過近期，AWS官方部落格釋出了3篇與Aurora相關的文章，其中有2篇是國外使用者遷移到Aurora之上的案例， 1篇是幫助使用者如何從Oracle資料庫遷移到Aurora PostgreSQL的教程。

透過對這2個案例研究，我們或許可以發現Aurora到底憑什麼成為AWS增長最快的雲服務的一絲端倪。

先來看看這2家國外企業：

InfoScout 建立於2011年，總部位於舊金山，透過一共一系列的APP，幫助使用者拍照上傳購物小票，換取各種獎勵。而 InfoScout則將這些購物資訊彙總分析形成報告，提供給零售商、代理商、大眾消費品企業。

Autodesk國內的朋友應該不陌生，設計圈內大名鼎鼎的AutoCAD，就是這家公司的產品。知名的二維和三維設計、工程與娛樂軟體公司，創立於 1982 年。

InfoScout目前獲取的資訊佔美國購物交易的 1/500，每天傳輸 300000 張收據影像。隨著業務增長，InfoScout開始遇到資料庫效能問題。高流量期間有兩個重大問題爆發出來。

首先，是查詢執行時間的總體效能不佳。在高峰負載下，高併發請求，導致讀取速度下降，頁面超時，作業失敗。

其次是儲存問題。Amazon RDS for MySQL 當時的最大儲存容量為 6 TB（現在最高支援 16 TB），而當時，InfoScout的資料庫已經達到了 5 TB。

Autodesk的瓶頸得先從Autodesk Access Control Management (ACM)說起。

儘管ACM 的架構允許 Autodesk 擴充套件和平衡應用程式的負載，但瓶頸很快就轉移到資料庫。比如，應用程式連線單個 RDS MySQL 資料庫例項，限制了可用的擴充套件選項。一個方法是增加資料庫例項的大小。這種方法仍然受到可以預置的資料庫例項的最大型號制約。ACM 很快就超出了最大可用例項的容量限制。

下一個選項是增加 RDS Read Replica 例項的數量以解除安裝主例項的讀取流量，從而橫向擴充套件資料庫容量。Autodesk 希望複製延遲能低於一秒，從而為所有 ACM 使用者提供穩定的體驗。與只讀副本有關的複製延遲取決於主例項和只讀副本例項的工作負載壓力。

除非重新設計 ACM 的架構，將資料跨多個 MySQL 資料庫進行分拆，Autodesk 不得不對應用程式進行控制，限制指向資料庫的負載以減少複製延遲。但這種方法是不可持續的。

遷移到 Aurora 後，InfoScout發現，收據引擎狀態計算機中的一個關鍵步驟的時間減少了 10 倍。此任務負責複製影像並驗證最近提交的收據。

下圖顯示了收據管道中的一個關鍵非同步作業的執行時間。可以看到執行時間下降了 10 倍，從 4 秒縮短至 400 毫秒。

除 AWS 監控工具外，InfoScout還使用 New Relic 等生產級的服務來進行深度效能監控。透過提取了這些報告，可以看到響應時間縮短了 3 倍！

在InfoScout使用MySQL 時，完成手機客戶端向後端發出的標準網路呼叫需要 600 毫秒，部署 Aurora 後，這一延遲已經縮短至 200 毫秒以下。

下圖為遷移之前和之後的延遲，能看到效能明顯提升。

遷移到 Aurora 後的 ACM 應用程式架構：

在此架構中，Aurora 叢集包含一個寫例項和最高四個 Aurora 副本。Aurora Auto Scaling 將會啟用以根據 CPU 利用率自動調整 Aurora 副本的數量。

下圖顯示了遷移之前和之後的 CPU 利用率。Autodesk 的 CPU 利用率下降了 10 倍，從使用 MySQL 時高達 100% 的峰值水平降至使用Aurora後不到 10%的水平。

MySQL

Aurora

下圖顯示了遷移之前和之後的應用程式響應時間。 Autodesk 的響應時間縮短了 2 倍。

MySQL

Aurora

遷移到 Aurora 後，Autodesk 發現資料庫的效能超出預期，應用程式的擴充套件性提高了 20 倍，應用程式的響應時間縮短了 2 倍，並且 Aurora 支援的資料庫連線數量增加了 7 倍。

透過這兩個案例，我們可以總結出Aurora的四個亮點，也是對在用MySQL企業的四大誘惑，而這或許就是為什麼Aurora能成為AWS使用者增長最快的雲服務之一的原因。

1、 完全相容MySQL，意味著即插即用，即使用者在無需修改程式的前提下，可以直接遷移。

2、 效能增強，效能是MySQL的五倍，意味短期內無需對資料庫進行分割槽或自建叢集，使用者擁有了更大的空間來滿足未來業務增長的需要。

3、 自動儲存擴充套件，Aurora採用分散式、容錯型、自我修復式的儲存系統，可自動最高擴充套件至 64 TB，無需手動擴充套件資料庫的儲存容量。

4、 低複製延遲以實現讀取擴充套件，最高可配置 15 個低延遲的 Aurora 副本，提高了可用性並支援讀取擴充套件，典型的複製延遲在100毫秒以下。

當然，這2個案例只是針對MySQL的遷入，但這並不意味著Aurora只能替代MySQL，另外一篇Oracle遷移到Aurora PostgreSQL的教程很說明問題，Aurora的目標還有Oracle資料庫。