翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon Keyspaces へのオンライン移行: 戦略とベストプラクティス
<a name="migrating-online"></a>

Apache Cassandra から Amazon Keyspaces への移行中もアプリケーションの可用性を維持する必要がある場合は、このトピックで説明する主要コンポーネントを実装して、カスタムのオンライン移行戦略を準備できます。オンライン移行に関するこれらのベストプラクティスに従うことで、移行プロセス全体でアプリケーションの可用性と書き込み後の読み取り整合性を維持し、ユーザーへの影響を最小限に抑えることができます。

Apache Cassandra から Amazon Keyspaces へのオンライン移行の戦略を立てる際は、以下の主なステップについて検討する必要があります。

1. **新しいデータの書き込み**
   + **Amazon Keyspaces 移行用の ZDM デュアル書き込みプロキシ** – [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) で利用可能な ZDM デュアル書き込みプロキシを使用して、Apache Cassandra から Amazon Keyspaces へのダウンタイムのない移行を実行します。ZDM Proxy は、既存のアプリケーションをリファクタリングすることなくデュアル書き込みを実行し、クエリ検証のためにデュアル読み取りを実行します。
   + アプリケーションのデュアル書き込み: 既存の Cassandra クライアントライブラリとドライバーを使用して、アプリケーションにデュアル書き込みを実装できます。1 つのデータベースをリーダー、もう 1 つをフォロワーとして指定します。フォロワーデータベースへの書き込み失敗は、分析用として[デッドレターキュー (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 をセカンダリのデータストアとして扱うように、アプリケーションを一度に切り替えます。パフォーマンスをモニタリングして、問題が発生した場合はロールバックします。
   + カナリアデプロイ: 最初は一部のユーザーのみを対象に移行を段階的に進め、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)