剖析Amazon、Autodesk等遷移上云的成功案例，看 AWS 數(shù)據(jù)庫遷移的創(chuàng)新之處

數(shù)據(jù)庫遷移上云？你是否還在為千頭萬緒不知從何處開始而煩惱呢？別擔心，小編今天告訴你一個數(shù)據(jù)庫遷移的獨家秘籍！

在數(shù)據(jù)庫領(lǐng)域，過去的幾十年里，客戶不得不與具有高鎖定性和懲罰性許可條款的商業(yè)數(shù)據(jù)庫廠商打交道，付出高昂的成本。同時，我們看到許多客戶試圖盡可能地遷移到開源數(shù)據(jù)庫，然而往往需要面對實現(xiàn)企業(yè)級性能和擴展的挑戰(zhàn)?？蛻粝Ｍ麙昝撌`，實現(xiàn)成本的節(jié)約，從而專注于發(fā)展和創(chuàng)新。

在轉(zhuǎn)向開放源代碼數(shù)據(jù)庫的客戶要求我們以客戶友好的策略、開放源代碼數(shù)據(jù)庫的自由性和可移植性來實現(xiàn)商業(yè)級數(shù)據(jù)庫的性能。這就是為什么我們構(gòu)建了Amazon Aurora，一個與MySQL和PostgreSQL兼容的關(guān)系數(shù)據(jù)庫，它是為云構(gòu)建的，將高端商業(yè)數(shù)據(jù)庫的性能和可用性與開源數(shù)據(jù)庫的簡單性和成本效益結(jié)合在一起。Amazon Aurora的性能是標準MySQL的5倍，是標準PostgreSQL的3倍，具有商業(yè)級數(shù)據(jù)庫的安全性、可用性和可靠性，成本是標準PostgreSQL的1/10。

現(xiàn)在的你是不是對Amazon Aurora充滿好奇呢？那就快來跟著小編一起看看在AWS上進行業(yè)務(wù)數(shù)據(jù)遷移的客戶案例吧~

No.1

企業(yè)核心業(yè)務(wù)

數(shù)據(jù)庫遷移之路

案例一：Autodesk的核心業(yè)務(wù)數(shù)據(jù)庫遷移之路

作為全球軟件解決方案的領(lǐng)導(dǎo)者，Autodesk始終關(guān)注中國制造業(yè)的痛點與發(fā)展需求，借助人工智能、數(shù)據(jù)庫以及相關(guān)技術(shù)，幫助制造廠商挖掘設(shè)計的更多可能性，提升生產(chǎn)的可預(yù)判性，旨在讓制造商無需高額的資金和人力成本即可實現(xiàn)輕松生產(chǎn)。

Autodesk公司多年之前就已經(jīng)啟動了自己的云計算現(xiàn)代化之旅，著手將工作負載從本地數(shù)據(jù)中心遷移至Amazon Elastic Compute Cloud(EC2)及其他AWS服務(wù)當中。Autodesk之所以積極推進現(xiàn)代化改造，自然是為了獲取必要的靈活性與可擴展性，支持業(yè)務(wù)的預(yù)期增長。2019年，該公司將其關(guān)鍵任務(wù)單點登錄（AutodeskSSO）應(yīng)用從Amazon EC2上的自托管SQL Server中遷移至全托管Amazon Aurora MySQL。此項服務(wù)需要應(yīng)對全球各地超過1.42億用戶的身份驗證請求，每分鐘API請求響應(yīng)數(shù)量超過14萬5千次。此外，該應(yīng)用還整合了300多種用于實現(xiàn)身份驗證與授權(quán)操作的產(chǎn)品及服務(wù)。

此次遷移有助于簡化Autodesk SSO服務(wù)的管理與彈性、優(yōu)化運營成本并降低基礎(chǔ)設(shè)施的維護開銷。根據(jù)初步成本分析結(jié)果，該公司在使用Amazon Aurora MySQL之后每月總體數(shù)據(jù)庫成本可下降約40%至50%。

通過本文，我們將探討Autodesk公司如何在盡可能縮短停機時間的前提下，對關(guān)鍵任務(wù)數(shù)據(jù)庫進行遷移。以下各章節(jié)將分別介紹遷移前架構(gòu)、遷移策略、遷移步驟以及性能比較等相關(guān)議題。

遷移前架構(gòu)

下圖所示，為Autodesk以往使用的SQL Server架構(gòu)。該數(shù)據(jù)庫以自托管形式在Amazon EC2實例之上運行，且跨越多個可用區(qū)與另一區(qū)域內(nèi)的單一節(jié)點建立起Always On機制，借此實現(xiàn)災(zāi)難恢復(fù)能力。

隨著時間推移，Autodesk團隊發(fā)現(xiàn)現(xiàn)有配置中存在以下挑戰(zhàn)：

·中斷——以往發(fā)生的諸多中斷事件，正是由于這套復(fù)雜的自找托管數(shù)據(jù)庫基礎(chǔ)設(shè)施所導(dǎo)致。整個體系中涉及多個采用Amazon Elastic Block Store(EBS)加RAID 10存儲配置的Amazon EC2實例，結(jié)果就是Windows Server故障轉(zhuǎn)移集群（WSFC）、存儲以及IOPS等眾多元素構(gòu)成極為復(fù)雜的分層體系。更重要的是，運營團隊越來越難以對事件根源進行分析與追溯。

·備份——管理備份也帶來可觀的開銷，特別是在跨區(qū)域設(shè)置層面。盡管我們使用了自動化腳本，但整個備份流程仍然需要人為介入與嚴格監(jiān)控。

·補丁修復(fù)——由于Autodesk公司擁有多個環(huán)境（包括測試環(huán)境、暫存環(huán)境與生產(chǎn)環(huán)境），因此補丁修復(fù)消費了管理員們大量寶貴的時間。

·可擴展性——主節(jié)點負責填寫只讀路由請求，同時標記需要接入的輔助節(jié)點。盡管此功能能夠保證連接始終被路由至運行狀態(tài)良好的輔助節(jié)點，但從可擴展性的角度來看，主節(jié)點的存在本身即是最大的瓶頸。

·副本數(shù)量——SQL Server最多允許設(shè)置8個輔助副本，而Amazon Aurora MySQL最多可支持15個副本。

·成本——原本的總體擁有成本，達到遷移至Amazon Aurora之后新體系的兩倍。

·彈性——對基礎(chǔ)設(shè)施進行規(guī)模伸縮需要耗費大量時間。

遷移策略

我們從概念驗證起步，借此確定需要完成的應(yīng)用程序變更、數(shù)據(jù)庫變更、腳本自動化以及各類預(yù)創(chuàng)建服務(wù)。更重要的是，我們還借此確定遷移至Amazon Aurora這一舉措能夠有效解決前面提到的種種挑戰(zhàn)。

在實施必要的變更之后，我們制定了計劃，以分階段方式遷移至不同環(huán)境。以此為基礎(chǔ)，我們對策略進行微調(diào)，逐步明確了在不同環(huán)境上運行遷移時所帶來的相應(yīng)停機時間。我們的目標是在最少的停機時長之內(nèi)完成遷移。為了在不同環(huán)境間靈活高效地實現(xiàn)遷移，我們利用Terraform自動執(zhí)行數(shù)據(jù)庫創(chuàng)建與AWS DMS配置等步驟。當然，大家也可以使用AWS CloudFormation實現(xiàn)相同的自動化效果。

在以下章節(jié)中，我們將具體探討遷移過程中的各注意事項。

Schema遷移

AWS Schema轉(zhuǎn)換工具是一款出色的schema遷移工具，能夠?qū)⑦w移工作量控制在最低水平。但在本示例中，由于存在大量定制化需求，我們只能放棄效率、選擇更適合的schema轉(zhuǎn)換方法。

作為schema轉(zhuǎn)換流程中的一部分，我們首先為數(shù)據(jù)庫選擇了最佳字符集。如此一來，我們的數(shù)據(jù)庫體積將縮減到原始大小的三分之一左右。對數(shù)據(jù)庫的成功“瘦身”，將在遷移過程中帶來巨大助益。

在確定目標數(shù)據(jù)庫的最終架構(gòu)之前，我們需要全面評估以下因素：

·字符集與排序規(guī)則

·數(shù)據(jù)類型選擇

·日期/時間模式

·多字節(jié)字符存儲

·特殊字符存儲

·索引類型

這些注意事項不僅有助于數(shù)據(jù)遷移，同時也將避免因引入特殊數(shù)據(jù)集而導(dǎo)致的各類遷移后問題。

容量規(guī)劃

我們對容量規(guī)劃進行了廣泛測試，包括迭代運行工作負載以確定合適的實例大小與對應(yīng)容量。此外，我們還比較了來自各類監(jiān)控工具（例如Amazon CloudWatch、New Relic以及MonYog）的關(guān)鍵指標、分析慢查詢?nèi)罩荆ΜF(xiàn)有生產(chǎn)工作負載/流量及未來數(shù)據(jù)增長做出預(yù)測。

應(yīng)用程序遷移

應(yīng)用程序遷移將以無縫化形式進行，因為我們使用NHibernate（ORM）進行數(shù)據(jù)訪問。ORM生成約80%的查詢比例，因此我們可以在應(yīng)用程序內(nèi)以最少的ORM配置變更生成MySQL查詢。這里也建議大家首先觀察應(yīng)用程序通過ORM生成了多少查詢，并據(jù)此估算轉(zhuǎn)換其余查詢所需要的具體工作量。

我們在SSO應(yīng)用程序中開發(fā)了一項功能，用于支持按需數(shù)據(jù)庫連接切換并進一步實現(xiàn)對讀取/寫入流量的控制。以此為基礎(chǔ)，我們能夠在整個遷移計劃中實現(xiàn)連續(xù)部署與跨環(huán)境執(zhí)行。最后，這項舉措還有助于最大程度減少數(shù)據(jù)庫切換操作所帶來的停機時間。

之前，我們使用的是完整NET框架，遺憾的是帶有NHibernate的NET完整框架中的MySQL驅(qū)動程序并不支持Amazon Aurora MySQL故障轉(zhuǎn)移功能。換句話說，我們的應(yīng)用程序?qū)o法自行實現(xiàn)故障恢復(fù)。為此，我們提出了一項自定義解決方案，針對NET中MySQL驅(qū)動程序缺失的問題為Amazon Aurora MySQL故障轉(zhuǎn)移提供新的支持方法，確保應(yīng)用程序能夠在遷移過程中繼續(xù)正常支持業(yè)務(wù)流量。

數(shù)據(jù)遷移

數(shù)據(jù)遷移與驗證是整個遷移流程中的重要一步。我們使用AWS Database Migration Service（DMS）以實現(xiàn)安全且經(jīng)濟的遷移效果。關(guān)于更多詳細信息，請參閱AWS DMS上手指南。

遷移步驟

下圖所示，為遷移中的各項狀態(tài)與具體步驟。圖中為前滾遷移模式，各個步驟將幫助大家快速理解與遷移進度相關(guān)的情況。在下面幾個章節(jié)中，我們將就每種狀態(tài)及其內(nèi)容做出說明。

只要可能，我們都會提前創(chuàng)建服務(wù)與基礎(chǔ)設(shè)施。例如，在開始遷移之前，我們的Amazon Aurora MySQL數(shù)據(jù)庫、SQL服務(wù)回滾數(shù)據(jù)庫以及AWS DMS實例都已經(jīng)準備就緒。

初始狀態(tài)

即SQL Server服務(wù)的初始狀態(tài)。

第一步

在這一步中，我們將正式開始從SQL Server到Amazon Aurora MySQL的全加載遷移。所謂全加載遷移，實際上是一套時間點快照副本，DMS負責將數(shù)據(jù)從源數(shù)據(jù)庫復(fù)制到目標數(shù)據(jù)庫。

從數(shù)據(jù)庫的約束角度來看，要想獲得最佳全加載性能，理想的作法是在導(dǎo)入全加載前僅部署各主鍵。在全加載之后，我們再逐步添加其他約束元素，例如外鍵。由于AWS DMS會從多個表處并行加載數(shù)據(jù)，因此復(fù)雜的外鍵關(guān)系可能會減慢加載過程。在Amazon Aurora MySQL上，最好只包含寫入節(jié)點。而在SQL Server回滾設(shè)置中，理想的作法是在主節(jié)點中創(chuàng)建回滾數(shù)據(jù)庫。另外，在單一節(jié)點上創(chuàng)建索引會進一步提升速度，特別是在表體積很大的情況下。

第二步

在完成從SQL Server到Amazon Aurora MySQL的全加載創(chuàng)建后，下一步是從Amazon Aurora MySQL到SQL Server回滾數(shù)據(jù)庫創(chuàng)建全加載副本。任務(wù)完成后，我們即在源數(shù)據(jù)庫、Amazon Aurora MySQL以及SQL Server回滾數(shù)據(jù)庫之間完成了全加載數(shù)據(jù)同步。

第三步

在這一步中，我們將向Amazon Aurora MySQL與SQL Server回滾數(shù)據(jù)庫添加索引與外鍵，向Amazon Aurora MySQL添加讀取節(jié)點，并將回滾數(shù)據(jù)庫添加至Always On數(shù)據(jù)庫。通過這些操作，我們的全加載性能將有所提升，同時保證數(shù)據(jù)庫在切換完成之前始終處于高可用性狀態(tài)。

大家當然可以在全加載期間啟用驗證，但如果您接下來打算使用變更數(shù)據(jù)捕捉（CDC），這里提醒大家在CDC階段再啟用驗證效果更好。AWS DMS負責對整體數(shù)據(jù)進行驗證，其中包括全部全加載組成部分的遷移數(shù)據(jù)。AWS DMS提供一項特殊功能，允許用戶在其中設(shè)置定制化驗證功能。我們會大量使用此項功能以驗證各特殊字符與Blob數(shù)據(jù)類型。

作為質(zhì)量檢查（QA）流程中的一部分，我們對部分重要工作流者做了驗證。我們在全加載后進行了一輪示例數(shù)據(jù)驗證，希望確保關(guān)鍵工作流能夠按預(yù)期正常運作。此項示例數(shù)據(jù)驗證以DMS驗證為基礎(chǔ)。經(jīng)過全面測試之后，我們開始進入CDC階段，將全加載之后累積的增量變更從源數(shù)據(jù)庫傳輸至Aurora MySQL，再將Aurora MySQL傳輸至SQL Server回滾數(shù)據(jù)庫。

在此期間，AWS DMS會將遷移指標發(fā)送至Amazon CloudWatch。若需了解更多詳細信息，請參閱監(jiān)控AWS DMS任務(wù)。

第四步

在CDC執(zhí)行期間，我們一直在密切監(jiān)控Amazon CloudWatch中的以下幾項指標：

  ·ValidationPendingOverallCount

  ·CDCLatencySource

  ·CDCLatencyTarget

在ValidationPendingOverallCount達到低值，而源數(shù)據(jù)庫與目標數(shù)據(jù)庫之間的CDC延遲最低時，我們即可著手執(zhí)行數(shù)據(jù)庫切換。數(shù)據(jù)庫切換同樣分幾個步驟，我們首先需要停止應(yīng)用程序的寫入流量、等待掛起記錄得到全部驗證，而后切換應(yīng)用程序中的標記以使其指向Amazon Aurora MySQL。

上述指標的最佳數(shù)值，取決于您的實際用例與變化速度。大家可能需要通過多輪測試以確定具體數(shù)值。

以下示例圖為ValidationPendingOverallCount指標。大家可以看到初始掛起行數(shù)很高，之后逐漸減少。

以下示例圖為CDC LatencySource指標，它顯示的是源數(shù)據(jù)庫最后捕捉到的事件與AWS DMS實例當前系統(tǒng)時間戳之間的間隔（單位為秒）。如果因任務(wù)作用域?qū)е挛茨軓脑磾?shù)據(jù)庫處捕捉到任何變更，則AWS DMS會將此值設(shè)置為0。

以下示例圖為CDC LatencyTarget指標，它顯示的是Amazon Aurora MySQL上首個等待提交的事件時間戳與AWS DMS實例當前時間戳之間的間隔（單位為秒）。如此出現(xiàn)此值，則意味著存在Amazon Aurora MySQL無法處理的事務(wù)。因為如果所有事務(wù)都得到正常應(yīng)用，那么目標數(shù)據(jù)庫延遲應(yīng)該與源數(shù)據(jù)庫延遲相同。目標數(shù)據(jù)庫延遲不得低于源數(shù)據(jù)庫延遲。

第五步

在本步當中，我們的應(yīng)用程序已經(jīng)指向Amazon Aurora MySQL并保持良好運行。我們的團隊對應(yīng)用程序進行了端到端測試，旨在確保所有功能都可正常工作。整個回滾設(shè)置共運行數(shù)天，幫助我們觀察其實際運行狀態(tài)。

最終狀態(tài)

在這一步中，我們刪除了回滾設(shè)置。下圖所示為我們構(gòu)建完成的遷移后架構(gòu)。

回滾步驟

在這一步中，我們的目標是在最糟糕的情況下制定備份計劃。由于數(shù)據(jù)庫在關(guān)鍵任務(wù)服務(wù)中扮演重要角色，因此我們必須引入完善的回滾機制以從最壞的情況中恢復(fù)正常。

如果在發(fā)生故障時仍必須使用當前數(shù)據(jù)庫，我們的計劃是首先停止向Amazon Aurora寫入流量，等待掛起記錄得到驗證，而后將應(yīng)用程序切換至回滾數(shù)據(jù)庫SQL Server Always On）。如此一來，我們就可以在不丟失任何數(shù)據(jù)的前提下還原至舊有設(shè)置。

當然，要保證回滾設(shè)置正常起效，我們必須對其進行充足的測試與驗證。我們在測試環(huán)境中使用生產(chǎn)規(guī)模的數(shù)據(jù)以執(zhí)行測試，并確保當應(yīng)用程序從Amazon Aurora MySQL切換至回滾數(shù)據(jù)庫時，不會導(dǎo)致任何數(shù)據(jù)丟失問題。

性能比較

我們從遷移前與遷移后的讀寫查詢中，捕捉到前10條查詢性能進行比較。

下圖所示，為前10條讀取查詢的查詢性能?？梢钥吹?，Amazon Aurora的性能表現(xiàn)相當出色。

下圖所示為前10科寫入查詢的查詢性能。Amazon Aurora MySQL在這里的性能表現(xiàn)同樣勝過MSSQL，執(zhí)行時長也遠低于MSSQL。

相關(guān)建議

除了之前章節(jié)中提到的方法，我們還為大家整理出以下建議：

·充分規(guī)劃運行測試，這樣您才能總結(jié)出適合現(xiàn)有數(shù)據(jù)庫的遷移策略。絕不存在百試百靈的策略，因此請務(wù)必拿出自己的配置思路并逐步做出優(yōu)化。

·進行多輪性能測試以實現(xiàn)SQL查詢調(diào)優(yōu)；SQL查詢在不同的數(shù)據(jù)庫上會表現(xiàn)出不同的行為。

·最大限度提升遷移流程的自動化水平。在實踐中，我們使用Terraform實現(xiàn)自動化，從而快速重復(fù)多輪測試并總結(jié)出統(tǒng)一的遷移執(zhí)行流程。

·盡可能設(shè)置警報機制，同時通過適當監(jiān)控以分析遷移流程。

·為了預(yù)留充足的時間以處理意外錯誤，理想的作法是至少在計劃切換的一天之內(nèi)實現(xiàn)數(shù)據(jù)庫切換點（詳見遷移步驟中的第四步）。

Autodesk案例小結(jié)

異構(gòu)數(shù)據(jù)庫的遷移工作往往困難重重，但憑借AWS DMS的協(xié)助以及妥善規(guī)劃，Autodesk仍然順利從SQL Server遷移到了Amazon Aurora MySQL。通過此輪遷移，該公司不斷顯著提升了運營效率，同時也對基礎(chǔ)設(shè)施的成本與性能做出優(yōu)化。

Autodesk以及其他眾多企業(yè)已經(jīng)開始享受Amazon Aurora MySQL帶來的種種助益，包括Amazon電商也利用AWS實現(xiàn)了數(shù)據(jù)庫自由。除此之外，中國支線航空商業(yè)模式的引領(lǐng)者和踐行者——華夏航空也通過AWS完成了核心數(shù)據(jù)的遷移，跟著小編一起看看吧。

案例二：Amazon電商利用AWS實現(xiàn)數(shù)據(jù)庫自由

Amazon電商在遷移過程中面臨兩項關(guān)鍵挑戰(zhàn)。一是如何解決大規(guī)模的項目管理問題，因為這對于帶動多樣化、全球分布的團隊開展項目和跟蹤進度非常必要。二是遷移涉及高度技術(shù)復(fù)雜性。要想成功完成該項目，很明顯，公司的業(yè)務(wù)線需要集中協(xié)調(diào)、培訓(xùn)和技術(shù)支持。

為了克服這兩項挑戰(zhàn)，Amazon電商一開始就創(chuàng)建企業(yè)項目管理辦公室(PMO)，設(shè)定明確的業(yè)績要求，并且對每個服務(wù)團隊進行周度、月度、季度審查，以跟蹤和報告項目進度和狀態(tài)。

AWS技術(shù)核心團隊，由經(jīng)驗豐富的解決方案架構(gòu)師和數(shù)據(jù)庫工程師組成，這也是項目成功的關(guān)鍵。該團隊就哪些AWS服務(wù)最適合于從Oracle遷移過來的Amazon電商數(shù)據(jù)的每一個類別提出了建議。

Amazon電商還仔細考慮了如何以最佳方式，幫助Oracle數(shù)據(jù)庫管理員走上現(xiàn)行的新職業(yè)發(fā)展道路。其中一個選項是，幫助他們獲得轉(zhuǎn)型成為AWS解決方案架構(gòu)師所需的必要技能。另一個選項是，在基于Oracle的傳統(tǒng)環(huán)境和AWS云環(huán)境之間搭建橋梁的過程中，給予管理角色，在此角色下，Oracle背景很有幫助。

案例三：華夏航空選擇AWS將核心數(shù)據(jù)遷移上云

華夏航空股份有限公司成立于2006年，是中國支線航空商業(yè)模式的引領(lǐng)者和踐行者。截至2018年底，公司在飛航線123條，其中國內(nèi)航線120條，國際支線航線3條，獨飛航線114條，占公司航線比例達93%；通航城市107個，其中國際航點城市2個；公司支線航點占全部國內(nèi)支線機場比例達41%。

2018年華夏航空開始具體地實施遷移上云工作。按照規(guī)劃，華夏航空將全面采用由西云數(shù)據(jù)運營的AWS中國（寧夏）區(qū)域構(gòu)建云基礎(chǔ)架構(gòu)，到2020年左右把絕大部分應(yīng)用都遷移上云。

華夏航空的上云順序是這樣規(guī)劃的。第一步，讓華夏航空的中轉(zhuǎn)系統(tǒng)2.0上云；第二步，遷移營銷、內(nèi)部管理以及相關(guān)的業(yè)務(wù)系統(tǒng)，2018年總共完成十幾個這樣的系統(tǒng)上云；第三步，核心業(yè)務(wù)運行和保障系統(tǒng)上云，這一塊比較龐大，計劃在2019年做遷移。第四步，到2020年，把飛行管理、安保管理、安全管理以及一些周邊的業(yè)務(wù)管理，盡可能都遷移上云。

根據(jù)華夏航空的估算，業(yè)務(wù)應(yīng)用上云后，可以節(jié)省成本20%~30%，有的應(yīng)用甚至可以節(jié)省50%以上的成本。對一些應(yīng)用，如果加以改造、優(yōu)化后上云，可以節(jié)省更多成本。例如，把原來的Oracle數(shù)據(jù)庫改成MySQL數(shù)據(jù)庫，省去商業(yè)數(shù)據(jù)庫軟件昂貴的授權(quán)及持續(xù)的高額服務(wù)費用。