雲端遷移是項非常繁瑣的過程，如何降低資料遷移困難與複雜度是企業最關注的重點之一。
傳統資料庫遷移方法相當複雜且曠日廢時，經常需要暫停資料庫運作長達數天甚至是數週，在這段遷移工作執行時對資料庫的操作都必須禁止，導致遷移工作需要耗費大量的時間與資源。
同質資料庫的轉移（例如 MySQL to MySQL）就需要消耗一定的時間成本，若為異質資料庫的轉移，對各種資料型態、索引、結構敘述資料及函數進行全人工的轉換，從而增加更多時間與資源的耗損。如果在遷移過程中有人工疏失，很有可能會導致前功盡棄，實在是所費不貲。
為此，AWS 提供了 Database Migration Services（DMS）的資料庫自動化遷移服務，能夠以自動化的方式遷移至同質資料庫（例如 MySQL to MySQL）或至異質資料庫（例如 MySQL to DynamoDB），甚至提供當次遷移任務後持續進行資料的遷移，持續讓來源及目標遷移資料庫保持同步狀態。
.png)
AWS Database Migration Service (AWS DMS)
Database Migration Services（DMS）異質資料庫遷移
演示之資料庫：
在地端：MySQL
AWS 端：DynamoDB
在這裡我們可以看到，我們所演示的遷移來源資料庫是 MySQL 的 dms_source 資料表，此資料表所需之遷移筆數共為 85621 筆。
這裡我們也能看到在 AWS 雲端，我們已經建立好 AWS端的 DynamoDB 資料表，準備執行 MySQL 至 DynamoDB 的異質資料表遷移任務。
在這邊我們只需要撰寫 MySQL 至 DynamoDB 的結構映射組態檔，就能夠執行異質資料庫的遷移轉換任務了！
由於複寫的動作需要有複寫伺服器實例來執行，故我們需要在 AWS DMS 服務下建立新的複寫伺服器個體：
指明複寫伺服器名稱及執行實例的專用運算型別（例如：dms.t2.medium）
指明遷移任務的伺服器實例儲存容量、VPC、Multi-AZ 及公開性
在這個階段我們需要將來源資料庫及目的資料庫之相關資訊，設定於 AWS DMS 之端點設定上，之後方能設定最後的遷移任務細節。
設定遷移的來源（MySQL）及目的（DynamoDB）資料庫端點資訊
AWS DMS 之遷移任務組態如複寫伺服器、來源端點、目標端點及同步設定
在此可以設定在遷移任務後，是否持續同步來源及目的資料庫的資料
任務建立完畢並開始執行，將開始等待遷移任務進行映射及載入
AWS DMS 任務完全載入成功且沒有發生錯誤
載入時間總計 514 秒（8 分 34 秒），平均一筆紀錄遷移時間為 6ms
可以看到所有資料列皆已被遷移至 DynamoDB 的 employees 資料表上，若是有更大型的資料或需要縮短遷移的時間，則可以考慮：
- 使用更強的運算型別
- 使用更大的實例儲存空間
- 使用 Direct Connect 專線，強化在地端與雲端的資料傳輸品質
定價部分為：
- 運算實例型別
- 實例儲存空間 GB 數
- 跨 Region 或 On-Prem 至 AWS 之資料傳輸費用
除了工具，您更需要透過合作夥伴進行完整遷移任務
AWS DMS 的自動化遷移能力，幫助我們大量降低遷移各種資料庫上雲時所需的時間與精神，減少人為介入所造成的影響同時也能夠直接使用 AWS 已經為我們考慮到的各種遷移功能。
CKmates 具有豐富的遷移經驗，我們也活用 AWS DMS 工具降低遷移的風險與時間成本，協助許多客戶成功遷移上雲。
從評估企業雲端準備程度、盤點營運系統、規劃遷移項目、遷移策略及順序等，規劃出完善的架構並執行遷移，搬遷完成後進行維運與優化等，CKmates 皆具有完整的遷移方法與知識。
遷移上雲後，享受各種雲端優勢，讓您能夠去除繁雜的 IT 維運及設施運作，專注於跟企業價值有關係的核心業務上，提升企業競爭力。
雲端遷移系列專欄
- Why migrate to the AWS Cloud?
- 想要雲端遷移？資深雲端架構師親自傳授遷移心法
- 影響雲端遷移成功的關鍵因子：「評估策略」與「完善計畫」
- 善用 AWS 原生遷移工具 使雲端遷移事半功倍
- 使用AWS Database Migration Service 快速協助異質資料庫遷移
- 剖析AWS原生遷移工具 MGN & SMS & VM Import/Export
