本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 線上遷移至 Amazon Keyspaces：策略和最佳實務
如果您需要在從 Apache Cassandra 遷移至 Amazon Keyspaces 期間維持應用程式的可用性，您可以實作本主題討論的關鍵元件，以準備自訂線上遷移策略。透過遵循線上遷移的這些最佳實務，您可以確保在整個遷移過程中維持應用程式可用性和read-after-write一致性，將對使用者的影響降至最低。
設計從 Apache Cassandra 到 Amazon Keyspaces 的線上遷移策略時，您需要考慮下列關鍵步驟。
1. **寫入新資料**
+ **Amazon Keyspaces 遷移的 ZDM Dual Write Proxy** – 使用 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) 上提供的 ZDM Dual Write Proxy，從 Apache Cassandra 到 Amazon Keyspaces 執行零停機時間遷移。ZDM Proxy 執行雙寫入，無需重構現有應用程式，並執行雙讀取以進行查詢驗證。
+ 應用程式雙寫入：您可以使用現有的 Cassandra 用戶端程式庫和驅動程式，在應用程式中實作雙寫入。指定一個資料庫做為領導者，另一個資料庫做為跟隨者。對跟隨者資料庫的寫入失敗會記錄在[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 中進行分析。
+ 訊息層雙寫入：或者，您可以設定現有的訊息平台，使用其他取用者將寫入傳送至 Cassandra 和 Amazon Keyspaces。這會在兩個資料庫之間建立最終一致的檢視。
1. **遷移歷史資料**
+ 複製歷史資料：您可以使用 AWS Glue或自訂擷取、轉換和載入 (ETL) 指令碼，將歷史資料從 Cassandra 遷移到 Amazon Keyspaces。使用輕量型交易或時間戳記等技術來處理雙寫入和大量載入之間的衝突解決。
+ 使用Time-To-Live(TTL)：對於較短的資料保留期間，您可以在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免上傳不必要的歷史資料。隨著 Cassandra 中的舊資料過期，並透過雙寫入寫入新資料，Amazon Keyspaces 最終會追上進度。
1. **驗證資料**
+ 雙重讀取：實作來自 Cassandra （主要） 和 Amazon Keyspaces （次要） 資料庫的雙重讀取，以非同步方式比較結果。差異會記錄或傳送至 DLQ。
+ 範例讀取：使用 Λ 函數定期取樣和比較兩個系統的資料，將任何差異記錄到 DLQ。
1. **遷移應用程式**
+ 藍綠策略：切換您的應用程式，在單一步驟中將 Amazon Keyspaces 視為主要資料存放區，並將 Cassandra 視為次要資料存放區。監控效能，並在發生問題時轉返。
+ Canary 部署：先逐步將遷移推展到一部分的使用者，逐步增加 Amazon Keyspaces 作為主要使用者的流量，直到完全遷移為止。
1. **停用 Cassandra**
一旦應用程式完全遷移至 Amazon Keyspaces 並驗證資料一致性，您就可以根據資料保留政策計劃停用 Cassandra 叢集。
透過利用這些元件規劃線上遷移策略，您可以順暢地轉換到全受管 Amazon Keyspaces 服務，並將停機時間或中斷降至最低。以下各節會更詳細地介紹每個元件。
**Topics**
+ [在線上遷移期間撰寫新資料](migration-online-dw.md)
+ [在線上遷移期間上傳歷史資料](migration-online-historical.md)
+ [驗證線上遷移期間的資料一致性](migration-online-validation.md)
+ [在線上遷移期間遷移應用程式](migration-online-app-migration.md)
+ [線上遷移後停用 Cassandra](migration-online-decommission.md)
# 在線上遷移期間撰寫新資料
線上遷移計畫的第一步是確保應用程式寫入的任何新資料都存放在兩個資料庫、您現有的 Cassandra 叢集和 Amazon Keyspaces 中。目標是跨兩個資料存放區提供一致的檢視。您可以將所有新的寫入套用至兩個資料庫來執行此操作。若要實作雙寫入，請考慮下列三個選項之一。
+ **ZDM Dual Write Proxy for Amazon Keyspaces Migration** – 使用 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) 上提供的 ZDM Proxy for Amazon Keyspaces，您可以將 Apache Cassandra 工作負載遷移至 Amazon Keyspaces，而不會造成應用程式停機。此增強型解決方案實作AWS最佳實務，並擴展官方 ZDM Proxy 功能。
+ 在 Apache Cassandra 和 Amazon Keyspaces 之間執行線上遷移。
+ 在不重構應用程式的情況下，同時將資料寫入來源和目標資料表。
+ 透過雙讀取操作驗證查詢。
解決方案提供下列增強功能，以使用 AWS和 Amazon Keyspaces。
+ **容器部署** – 使用來自 Amazon Elastic Container Registry (Amazon ECR) 的預先設定 Docker 映像進行 VPC 可存取的部署。
+ **基礎設施即程式碼** – 使用 AWS CloudFormation範本部署以自動設定AWS Fargate。
+ **Amazon Keyspaces 相容性** – 使用 Amazon Keyspaces 的自訂調整來存取系統資料表。
解決方案透過 Fargate 在 Amazon ECS 上執行，根據您的工作負載需求提供無伺服器可擴展性。網路負載平衡器會將傳入的應用程式流量分散到多個 Amazon ECS 任務，以獲得高可用性。
![\[實作 ZDM 雙寫入代理，將資料從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **應用程式雙重寫入** – 您可以利用現有的 Cassandra 用戶端程式庫和驅動程式，在應用程式程式碼變更最少的情況下實作雙重寫入。您可以在現有應用程式中實作雙寫入，或在架構中建立新的 layer 來處理雙寫入。如需詳細資訊，以及顯示如何在現有應用程式中實作雙重寫入的客戶案例研究，請參閱 [Cassandra 遷移案例研究](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/)。
實作雙重寫入時，您可以將一個資料庫指定為領導者，將另一個資料庫指定為跟隨者。這可讓您繼續寫入原始來源或領導資料庫，而不會讓後續的寫入失敗，或目的地資料庫中斷應用程式的關鍵路徑。
您可以使用 Amazon Simple Queue Service 在[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 中記錄失敗的寫入，而不是重試失敗的寫入至追隨者。DLQ 可讓您分析對追隨者的失敗寫入，並判斷為什麼在目的地資料庫中處理未成功。
如需更複雜的雙寫入實作，您可以遵循使用 [saga 模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html)設計一系列本機交易的AWS最佳實務。saga 模式可確保如果交易失敗，saga 會執行補償性交易，以還原先前交易所做的資料庫變更。
使用雙寫入進行線上遷移時，您可以依照 saga 模式設定雙寫入，以便每次寫入都是本機交易，以確保異質資料庫之間的原子操作。如需使用建議的 設計模式來設計分散式應用程式的詳細資訊AWS 雲端，請參閱[雲端設計模式、架構和實作](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction)。
![\[從 Apache Cassandra 遷移至 Amazon Keyspaces 時，在應用程式層實作雙寫入。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **訊息層雙重寫入** – 您可以使用現有的訊息層對 Cassandra 和 Amazon Keyspaces 執行雙重寫入，而不是在應用程式層實作雙重寫入。
若要這樣做，您可以將其他消費者設定為您的簡訊平台，將寫入傳送至這兩個資料存放區。此方法使用訊息層提供簡單的低程式碼策略，在兩個資料庫之間建立兩個最終一致的檢視。
# 在線上遷移期間上傳歷史資料
實作雙重寫入以確保即時將新資料寫入兩個資料存放區後，遷移計劃的下一個步驟是評估您需要多少歷史資料才能從 Cassandra 複製或大量上傳至 Amazon Keyspaces。這可確保在您遷移應用程式之前，新資料和歷史資料都可以在新的 Amazon Keyspaces 資料庫中使用。
根據您的資料保留需求，例如，您需要根據組織政策保留多少歷史資料，您可以考慮以下兩個選項之一。
+ **大量上傳歷史資料** – 歷史資料從現有 Cassandra 部署遷移到 Amazon Keyspaces 可以透過各種技術實現，例如使用 AWS Glue或自訂指令碼來擷取、轉換和載入 (ETL) 資料。如需使用 AWS Glue上傳歷史資料的詳細資訊，請參閱 [離線遷移程序：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。
規劃大量上傳歷史資料時，您需要考慮如何解決新寫入嘗試更新上傳過程中相同資料時可能發生的衝突。大量上傳預期最終會一致，這表示資料最終將到達所有節點。
如果因為新的寫入而同時發生相同資料的更新，您希望確保不會被歷史資料上傳覆寫。為了確保即使在大量匯入期間仍能保留資料的最新更新，您必須將衝突解決方法新增至大量上傳指令碼或應用程式邏輯中，以進行雙重寫入。
例如，您可以使用 [輕量型交易](functional-differences.md#functional-differences.light-transactions)(LWT) 來比較和設定操作。若要這樣做，您可以將代表修改或狀態時間的額外欄位新增至資料模型。
此外，Amazon Keyspaces 支援 Cassandra `WRITETIME`時間戳記函數。您可以使用 Amazon Keyspaces 用戶端時間戳記來保留來源資料庫時間戳記，並實作last-writer-wins衝突解決方案。如需詳細資訊，請參閱[Amazon Keyspaces 中的用戶端時間戳記](client-side-timestamps.md)。
+ **使用Time-to-Live(TTL)** – 對於少於 30、60 或 90 天的資料保留期，您可以在遷移期間在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免將不必要的歷史資料上傳到 Amazon Keyspaces。TTL 可讓您設定一段時間，之後資料會自動從資料庫移除。
在遷移階段，您可以設定 TTL 設定，讓歷史資料在舊系統 (Cassandra) 中自動過期，同時僅使用雙寫入方法將新寫入套用至 Amazon Keyspaces。隨著時間的推移，使用舊資料持續在 Cassandra 叢集中過期，並使用雙寫入方法寫入的新資料，Amazon Keyspaces 會自動追上 ，以包含與 Cassandra 相同的資料。
這種方法可以大幅減少要遷移的資料量，進而產生更有效率且簡化的遷移程序。您可以在處理具有不同資料保留需求的大型資料集時考慮此方法。如需 TTL 的詳細資訊，請參閱 [使用 Amazon Keyspaces 的存留時間 (TTL) 過期資料 （適用於 Apache Cassandra)](TTL.md)。
請考慮下列使用 TTL 資料過期從 Cassandra 遷移至 Amazon Keyspaces 的範例。在此範例中，我們將兩個資料庫的 TTL 設定為 60 天，並顯示遷移程序在 90 天期間如何進行。在此期間，兩個資料庫都會使用雙寫入方法來接收相同的新寫入資料。我們將查看遷移的三個不同階段，每個階段為期 30 天。
遷移程序在每個階段的運作方式會顯示在下列影像中。
![\[從 Apache Cassandra 遷移至 Amazon Keyspaces 時，使用 TTL 使歷史資料過期。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. 在前 30 天之後，Cassandra 叢集和 Amazon Keyspaces 一直收到新的寫入。Cassandra 叢集也包含尚未達到 60 天保留的歷史資料，由叢集中 50% 的資料組成。
超過 60 天的資料會在 Cassandra 叢集中使用 TTL 自動刪除。此時，Amazon Keyspaces 包含存放在 Cassandra 叢集中的 50% 資料，由新寫入減去歷史資料組成。
1. 60 天後，Cassandra 叢集和 Amazon Keyspaces 都包含過去 60 天內寫入的相同資料。
1. 在 90 天內，Cassandra 和 Amazon Keyspaces 都包含相同的資料，並以相同的速率過期資料。
此範例說明如何使用過期日期設定為 60 天的 TTL 來避免上傳歷史資料的步驟。
# 驗證線上遷移期間的資料一致性
線上遷移程序的下一個步驟是資料驗證。雙重寫入正在將新資料新增至 Amazon Keyspaces 資料庫，而且您已完成使用大量上傳或資料過期搭配 TTL 遷移歷史資料。
現在，您可以使用驗證階段來確認兩個資料存放區實際上都包含相同的資料，並傳回相同的讀取結果。您可以選擇以下兩個選項之一，以驗證兩個資料庫都包含相同的資料。
+ **雙重讀取** – 若要驗證來源和目的地資料庫是否包含相同的一組新寫入和歷史資料，您可以實作雙重讀取。若要這樣做，您會從主要 Cassandra 和次要 Amazon Keyspaces 資料庫讀取，類似於雙重寫入方法，並以非同步方式比較結果。
來自主要資料庫的結果會傳回給用戶端，而來自次要資料庫的結果會用來驗證主要結果集。找到的差異可以記錄或傳送至[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 以供日後調校。
在下圖中，應用程式正在從主要資料存放區 Cassandra 執行同步讀取），並從次要資料存放區 Amazon Keyspaces 執行非同步讀取。
![\[在從 Apache Cassandra 線上遷移至 Amazon Keyspaces 期間，使用雙重讀取來驗證資料一致性。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **範例讀取** – 不需要變更應用程式程式碼的替代解決方案是使用 AWS Lambda函數，定期並隨機從來源 Cassandra 叢集和目的地 Amazon Keyspaces 資料庫取樣資料。
這些 Lambda 函數可設定為定期執行。Lambda 函數會從來源和目的地系統擷取資料的隨機子集，然後執行取樣資料的比較。兩個資料集之間的任何差異或不相符都可以記錄並傳送到專用[無效字母佇列 (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) 以供日後調校。
下表說明此程序。
![\[使用範例讀取來驗證從 Apache Cassandra 到 Amazon Keyspaces 的 和線上遷移期間的資料一致性。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# 在線上遷移期間遷移應用程式
在線上遷移的第四階段中，您要遷移應用程式，並轉換為 Amazon Keyspaces 做為主要資料存放區。這表示您將應用程式切換為直接從 Amazon Keyspaces 讀取和寫入。為了確保對使用者的干擾降到最低，這應該是妥善規劃和協調的程序。
提供兩種不同的應用程式遷移建議解決方案：藍色綠色切入策略和金絲雀切入策略。下列各節會更詳細地概述這些策略。
+ **藍色綠色策略** – 使用此方法，您可以切換應用程式，將 Amazon Keyspaces 視為主要資料存放區，並在單一步驟中將 Cassandra 視為次要資料存放區。您可以使用AWS AppConfig功能旗標來控制整個應用程式執行個體中主要和次要資料存放區的選擇。如需特徵標記的詳細資訊，請參閱在 [中建立特徵標記組態描述AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html)檔。
讓 Amazon Keyspaces 成為主要資料存放區後，您可以監控應用程式的行為和效能，確保 Amazon Keyspaces 符合您的需求，且遷移成功。
例如，如果您為應用程式實作雙讀取，在應用程式遷移階段，您將主要讀取從 Cassandra 轉換為 Amazon Keyspaces，次要讀取從 Amazon Keyspaces 轉換為 Cassandra。轉換後，您可以繼續監控和比較[資料驗證](migration-online-validation.md)一節中所述的結果，以確保在停用 Cassandra 之前兩個資料庫之間的一致性。
如果您偵測到任何問題，您可以透過還原至 Cassandra 做為主要資料存放區，快速復原至先前的狀態。只有在 Amazon Keyspaces 符合您作為主要資料存放區的所有需求時，您才能繼續遷移的停用階段。
![\[使用藍色綠色策略，將應用程式從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **Canary 策略** – 在此方法中，您會逐步將遷移推展到使用者或流量的子集。最初，您應用程式流量的一小部分，例如 5% 的所有流量會使用 Amazon Keyspaces 做為主要資料存放區路由至版本，而其餘流量則會繼續使用 Cassandra 做為主要資料存放區。
這可讓您使用實際流量徹底測試遷移的版本，並監控其效能、穩定性和調查潛在問題。如果您未偵測到任何問題，您可以逐步增加路由到 Amazon Keyspaces 的流量百分比，直到它成為所有使用者和流量的主要資料存放區為止。
此階段推展可將廣泛服務中斷的風險降至最低，並允許更受控制的遷移程序。如果在 Canary 部署期間發生任何重大問題，您可以使用 Cassandra 作為受影響流量區段的主要資料存放區，快速復原至先前的版本。只有在您驗證 Amazon Keyspaces 可如預期處理 100% 的使用者和流量之後，您才能繼續遷移的解除委任階段。
下圖說明 Canary 策略的個別步驟。
![\[使用 Canary 策略將應用程式從 Apache Cassandra 遷移至 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_tw/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# 線上遷移後停用 Cassandra
應用程式遷移完成後，您的應用程式會在 Amazon Keyspaces 上完全執行，而且您已驗證一段時間的資料一致性，您可以計劃停用 Cassandra 叢集。在此階段，您可以評估 Cassandra 叢集中剩餘的資料是否需要封存或可以刪除。這取決於您組織的資料處理和保留政策。
透過遵循此策略，並在規劃從 Cassandra 到 Amazon Keyspaces 的線上遷移時考慮本主題中描述的建議最佳實務，您可以確保無縫轉換至 Amazon Keyspaces，同時保持應用程式的read-after-write一致性和可用性。
從 Apache Cassandra 遷移到 Amazon Keyspaces 可以提供許多好處，包括降低營運開銷、自動擴展、改善安全性，以及協助您實現合規目標的架構。透過規劃具有雙重寫入、歷史資料上傳、資料驗證和漸進推展的線上遷移策略，您可以確保順暢的轉換，並將對應用程式及其使用者的干擾降至最低。
實作本主題中討論的線上遷移策略，可讓您驗證遷移結果、識別和解決任何問題，最終停用現有的 Cassandra 部署，以享有全受管 Amazon Keyspaces 服務。