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

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

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

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

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

No.1

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

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

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

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

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

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

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

遷移前架構(gòu)

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

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

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

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

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

·可擴(kuò)展性——主節(jié)點(diǎn)負(fù)責(zé)填寫(xiě)只讀路由請(qǐng)求，同時(shí)標(biāo)記需要接入的輔助節(jié)點(diǎn)。盡管此功能能夠保證連接始終被路由至運(yùn)行狀態(tài)良好的輔助節(jié)點(diǎn)，但從可擴(kuò)展性的角度來(lái)看，主節(jié)點(diǎn)的存在本身即是最大的瓶頸。

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

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

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

遷移策略

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

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

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

Schema遷移

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

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

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

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

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

·日期/時(shí)間模式

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

·特殊字符存儲(chǔ)

·索引類(lèi)型

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

容量規(guī)劃

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

應(yīng)用程序遷移

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

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

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

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

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

遷移步驟

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

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

初始狀態(tài)

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

第一步

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

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

第二步

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

第三步

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

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

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

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

第四步

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

  ·ValidationPendingOverallCount

  ·CDCLatencySource

  ·CDCLatencyTarget

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

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

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

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

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

第五步

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

最終狀態(tài)

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

回滾步驟

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

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

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

性能比較

我們從遷移前與遷移后的讀寫(xiě)查詢(xún)中，捕捉到前10條查詢(xún)性能進(jìn)行比較。

下圖所示，為前10條讀取查詢(xún)的查詢(xún)性能?？梢钥吹剑珹mazon Aurora的性能表現(xiàn)相當(dāng)出色。

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

相關(guān)建議

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

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

·進(jìn)行多輪性能測(cè)試以實(shí)現(xiàn)SQL查詢(xún)調(diào)優(yōu)；SQL查詢(xún)?cè)诓煌臄?shù)據(jù)庫(kù)上會(huì)表現(xiàn)出不同的行為。

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

·盡可能設(shè)置警報(bào)機(jī)制，同時(shí)通過(guò)適當(dāng)監(jiān)控以分析遷移流程。

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

Autodesk案例小結(jié)

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

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

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

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

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

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

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

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

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

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

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

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