前面幾篇討論了部署、監控與安全管理，現在換個角度：如果系統已經在公司的機房運作，並準備搬上 AWS，應該保留原本的架構，還是趁這次機會一起調整？
例如網站原本跑在虛擬機上，資料庫也是自行管理的 PostgreSQL，那可以先移到 EC2，也可以把資料庫改成 RDS，甚至將應用程式容器化。
每多改一項，就多一項需要驗證的差異，搬遷前要先確認：哪些改變能解決目前的問題，而且團隊有能力在期限內完成驗證？
AWS 的搬遷策略常以 7 Rs 分類，這篇聚焦在保留既有系統時，常見的三種選擇：
補充：AWS 搬遷策略的 7 Rs
- Rehost（直接搬遷）：保留應用程式架構，將既有主機搬到雲端，例如移至 EC2。
- Replatform（平台調整）：保留核心架構，調整部分平台元件，例如將自管資料庫改成 RDS。
- Refactor／Re-architect（重構／重新設計）：修改應用程式或架構，以改善擴展能力、效能或維護方式。
- Relocate（整體移轉）：沿用既有的平台或虛擬化環境，將工作負載整體移至相容的環境。
- Repurchase（重新採購）：改用其他產品取代原系統，例如從自建軟體改用 SaaS。
- Retain（保留）：暫時維持原環境，等需求、限制或搬遷條件改變後再評估。
- Retire（停用）：將已不再需要的應用程式或資源下線。
| 策略 | 主要改動範圍 | 核心判斷 | 驗證重點 |
|---|---|---|---|
| Rehost（直接搬遷） | 基礎設施，例如虛擬機移到 EC2 | 現有應用能否在 AWS 維持運作？ | 作業系統、網路、授權與相依服務 |
| Replatform（平台調整） | 部分平台元件，例如 PostgreSQL 改用 RDS | 換用受管服務，是否有明確的維運效益？ | 功能相容性、權限差異與資料搬遷 |
| Refactor／Re-architect（重構／重新設計架構） | 應用程式與架構，例如拆分服務 | 現有架構是否已無法滿足需求？ | 程式改動、整合測試與新架構的維運能力 |
三種策略可以用在同一套系統的不同部分，例如應用程式先移到 EC2，資料庫改用 RDS。
單體應用如果仍符合效能與開發需求，就沒有必要因為上雲而拆成微服務，Rehost 也不一定低風險：依賴固定 IP、本機檔案或特殊硬體的系統，仍可能需要調整。
可以先從三個方向判斷：
| 判斷方向 | 要確認的事情 |
|---|---|
| 改造效益 | 能否改善目前的故障、維運負擔或交付問題？ |
| 驗證成本 | 需要修改多少程式？是否有測試與熟悉工具的人員？ |
| 延後成本 | 先搬再改，是否會再做一次資料搬遷、停機或環境建置？ |
例如資料庫備份一直依賴人工操作，搬遷時導入 RDS 就有明確效益，但如果必要的擴充套件不受支援，或需要大幅修改資料庫操作，這次改造可能超出時程。
容器化也是，如果團隊已有容器部署流程，應用程式能順利打包並通過測試，就可以一起評估，但若還要同時學習平台、修改檔案儲存方式與重建部署流程，改動範圍就大得多。
搬遷前，除了確認有哪些主機，也要查清楚應用程式平常會用到哪些服務，例如訂單網站除了連接資料庫，可能還會呼叫庫存 API、讀取共享資料夾，或透過排程執行每日工作，這些連線與工作都要在搬遷後繼續正常運作。
假設網站已搬到 AWS，資料庫卻還留在公司機房，每次查詢就需要跨環境連線，如果網站頻繁讀寫資料庫，回應時間有可能變得更長，因此應用程式與資料庫可以先完成各自的搬遷準備，再安排一起切換，減少長時間分開運作的影響。
另外也要確認共享資料夾的路徑是否需要修改、排程要在哪裡執行，以及合作廠商是否只允許原本的 IP 連入，若搬遷後對外連線的 IP 改變，就需要提前請對方更新白名單。
搬遷期間的機房與 AWS 也需要穩定的連線，可以使用 Site-to-Site VPN 或既有的 Direct Connect，如果頻寬不足或連線經常中斷，資料同步就可能跟不上，影響預定的切換時間。
以下是一個假設情境：
本案例採用以下方向：
| 元件 | 選擇 | 判斷理由 |
|---|---|---|
| Java 應用程式 | 先移到 EC2 | 現有架構仍符合需求，保留執行方式可縮小驗證範圍 |
| PostgreSQL | 優先評估 RDS for PostgreSQL | 改善現有備份與維運流程，也避免日後再搬一次資料庫 |
| 容器化與服務拆分 | 延後 | 目前沒有足以要求同步改造的問題，團隊也需要準備時間 |
這次考慮將 PostgreSQL 改用 RDS，是希望減少人工備份與主機維護工作，但搬遷前要先確認原本使用的版本、擴充套件，以及管理資料庫的方式，在 RDS 上是否仍能正常運作。
不過 如果改用 RDS 需要大幅修改程式或維運工具，來不及在三個月內完成測試，就先將 PostgreSQL 搬到 EC2，繼續自行管理 ，同時要改善原本不足的備份流程，並實際測試資料能否還原。
因此本案例優先評估調整資料庫，Java 應用程式目前運作正常，則先保留原有架構，避免增加這次搬遷的改動範圍。
如果停止下單後，才開始匯出、傳輸與還原整個資料庫，30 分鐘可能不夠，因此可以在舊系統繼續服務時，先把既有資料搬到 AWS，再持續同步搬遷期間新增或修改的資料。
AWS Database Migration Service（AWS DMS，資料庫遷移服務） 可以透過「完整載入＋CDC」完成這件事：
圖：AWS DMS 先搬移既有資料，再持續同步來源資料庫的變更，讓大部分資料搬遷工作在正式切換前完成。
如圖所示，資料搬遷分成兩個部分：
例如，既有訂單搬到 AWS 後，舊網站仍會收到新訂單，也可能有人取消訂單，CDC 會持續同步這些變更，讓目標資料庫跟上來源的資料。
等到正式切換時，再暫停舊系統寫入，等待最後的變更同步完成，就能減少停機期間需要搬移的資料量。
不過 DMS 把訂單資料搬過去後，還需要確認三件事：
後續修改能不能同步？
例如訂單 1001 的狀態從「待付款」改成「已付款」，DMS 必須能讀到這次變更，並找到目標資料庫中的同一筆訂單，因此來源 PostgreSQL 要先開啟對應的複寫功能、授予 DMS 必要權限，資料表也要能明確識別每筆資料，例如使用不重複的訂單 ID 作為主鍵等等。
應用程式能不能使用新資料庫？
訂單資料已經出現在新資料庫，不代表原本的登入帳號與權限也都準備好了，例如訂單 API 使用的帳號，是否能登入、查詢及新增訂單，都需要另外確認，另外原本用來加快查詢的索引，也要確認是否已建立。
下一張訂單會拿到什麼編號？
假設搬過去的訂單已經有編號 1～1000，新資料庫卻仍從 1 開始發號，就可能因為編號重複而無法建立訂單。PostgreSQL 的 Sequence（序列） 可以想成自動發號器，而 DMS 持續同步資料時，不會自動同步這個發號器的位置，因此完成最後同步並停止複寫後，要確認並調整它的下一個編號，避免與既有訂單重複，再開放新訂單寫入。
來源與目標都是 PostgreSQL 時，也可以評估 PostgreSQL 原生的邏輯複寫，依版本支援與團隊熟悉程度選擇工具。
CDC 能縮短最後同步所需的時間，但能否在 30 分鐘內完成切換，仍需要實際演練 ，資料核對、應用程式切換，以及失敗時恢復舊服務所需的時間，都要一起算進去。
Cutover（正式切換） 的核心流程，是暫停舊環境寫入、完成最後同步、確認新環境狀態，再開放正式流量。
建立訂單、修改訂單，以及付款、物流等功能，應先在獨立的測試環境演練，正式切換時先暫停舊系統的所有資料寫入，包括下單、排程與付款通知等造成的更新，確認最後的變更已同步完成並停止複寫後，再依下表判斷是否可以開放新系統：
| 檢查項目 | 放行條件 |
|---|---|
| 資料同步:資料有沒有搬齊？ | 最後的變更已同步完成，沒有未處理的同步錯誤，並停止本次複寫 |
| 資料核對:新訂單編號會不會重複？ | 訂單筆數與關鍵交易內容符合預期， 已確認並調整 Sequence，下一個編號不會與既有訂單重複 |
| 功能驗證:新系統能不能讀取資料？ | 程式正常啟動、能連上資料庫，也能正確查詢訂單 |
| 剩餘時間 | 尚有足夠時間完成切換，若中止也能在停機窗口內恢復舊服務 |
中止時間要從 30 分鐘往回推，預留恢復舊服務所需的時間，不能等到第 30 分鐘才開始決定。
開放新系統後，再使用事先安排的測試帳號確認建立與更新訂單是否正常，持續觀察錯誤與回應時間。
如果這時發現問題，回復方式也以「是否已產生新的正式資料」為分界：
1001，舊資料庫卻只有到 1000，直接切回就會漏掉這張訂單，因此必須先依事前測試過的方法，把新增或修改的資料補回舊資料庫；若無法可靠地補回，就需要評估留在新系統修復。如果透過 DNS 修改網站入口，部分使用者可能暫時仍連到舊位置，因此切換後也要確保舊系統不再接受訂單或更新資料，避免新舊資料庫各自收到不同的交易。
本案例的 Java 應用程式目前運作正常，因此先保留原有架構，搬到 EC2，而資料庫則因為人工備份與主機維護帶來負擔，優先評估改用 RDS，確認相容性測試與切換演練都通過後，再正式搬遷。
如果條件不同，選擇也會改變，例如應用程式已經難以應付流量成長，團隊又有成熟的容器部署與測試流程，就可以評估在這次搬遷時一起容器化，反過來，如果來不及確認資料庫能否在 RDS 正常運作，就先搬到 EC2，繼續自行管理。
值得一起做的改造，應有明確效益、可控制的改動範圍，以及期限內能完成的驗證 ，其餘工作再安排後續階段，讓搬遷與改善都有清楚的完成條件。
這篇討論了哪些元件值得在搬遷時一起調整，以及資料同步與切換風險如何影響選擇。
下一篇會透過 AWS DMS 實作，示範 PostgreSQL 的完整載入與 CDC（變更資料擷取），觀察既有資料如何搬到目標資料庫，以及來源端後續的新增、修改與刪除如何持續同步。
iThome鐵人賽
看影片追技術