

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

# ハイブリッド移行ソリューションの使用: Apache Cassandra から Amazon Keyspaces への移行
<a name="migrating-hybrid"></a>

以下に紹介する移行ソリューションは、オンライン移行とオフライン移行を組み合わせたハイブリッドソリューションと言えます。このハイブリッド手法では、データがほぼリアルタイムで宛先のデータベースに書き込まれますが、書き込み後の読み取り整合性は保証されません。つまり、新たに書き込まれたデータをすぐには利用できず、遅延が想定されます。書き込み後の読み取り整合性が必要な場合は、「[Amazon Keyspaces へのオンライン移行: 戦略とベストプラクティス](migrating-online.md)」を参照してください。

Apache Cassandra から Amazon Keyspaces にほぼリアルタイムで移行する場合は、次の 2 つの方法から選択できます。
+ **CQLReplicator** – (推奨) CQLReplicator はオープンソースのユーティリティで、[Github](https://github.com/aws-samples/cql-replicator) から入手できます。このユーティリティを利用して、Apache Cassandra から Amazon Keyspaces にほぼリアルタイムでデータを移行できます。

  送信先データベースに伝達する書き込みと更新を決定するために、CQLReplicator は Apache Cassandra トークン範囲をスキャンし、 AWS Glueジョブを使用して重複イベントを削除し、書き込みと更新を Amazon Keyspaces に直接適用します。
+ **変更データキャプチャ (CDC)** – Cassandra CDC をよくご存じの場合は、Apache Cassandra に組み込まれている CDC 機能でコミットログを個別の CDC ディレクトリにコピーし、変更を追跡できるため、ハイブリッド移行を実装するための 2 つ目の選択肢となるでしょう。

  その場合は、データ変更を Amazon Keyspaces にレプリケートすることで、データ移行シナリオの別の選択肢として CDC を活用できます。

書き込み後の読み取り整合性が不要な場合は、CQLReplicator または CDC パイプラインを使用して、好みとツールの知識に基づいて Apache Cassandra から Amazon Keyspaces にデータを移行し、各ソリューションでAWS のサービス使用できます。これらの方法でデータをほぼリアルタイムで移行することは、オンライン移行に代わるハイブリッドな移行手法と見なすことができます。

この戦略がハイブリッドな手法だと言えるのは、このトピックで概説している選択肢に加えて、過去のデータのコピーや、[オンライン移行](migrating-online.md)のトピックで解説するアプリケーション移行戦略など、オンラインで移行を進めるためのステップを一部実装する必要があるためです。

以下のセクションでは、これらのハイブリッド移行の選択肢について詳説します。

**Topics**
+ [CQLReplicator を使用してデータを移行する](migration-hybrid-cql-rep.md)
+ [変更データキャプチャ (CDC) を使用してデータを移行する](migration-hybrid-cdc.md)

# CQLReplicator を使用してデータを移行する
<a name="migration-hybrid-cql-rep"></a>

[CQLReplicator](https://github.com/aws-samples/cql-replicator) を使用すると、CQL クエリを使用して Cassandra トークンリングをインテリジェントにスキャンすることで、Apache Cassandra からほぼリアルタイムでデータを読み取ることができます。CQLReplicator は Cassandra CDC を使用しません。その代わりにキャッシュ戦略を実装して、フルスキャンによるパフォーマンスへの影響を軽減しています。

宛先への書き込み数を減らすために、重複するレプリケーションイベントは自動的に削除されます。CQLReplicator を使用すると、ソースデータベースから宛先データベースへの変更のレプリケーションを調整できるため、Apache Cassandra から Amazon Keyspaces にほぼリアルタイムでデータを移行できます。

次の図は、AWS Glue を使用した CQLReplicator ジョブの一般的なアーキテクチャを示しています。

1. プライベート VPC で実行されている Apache Cassandra へのアクセスを許可するには、AWS Glue接続タイプ **Network** を使用して接続を設定します。

1. CQLReplicator ジョブで重複を削除してキーのキャッシュを有効にするには、Amazon Simple Storage Service (Amazon S3) を設定します。

1. CQLReplicator ジョブが、ソースデータベースの検証済みの変更内容を Amazon Keyspaces に直接ストリーミングします。

![\[CQLReplicator を使用して、Apache Cassandra から Amazon Keyspaces にデータを移行します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png)


CQLReplicator を使用した移行プロセスの詳細については、 AWSデータベースブログの[CQLReplicator を使用して Cassandra ワークロードを Amazon Keyspaces に移行する](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/)」およびAWS「 [を使用して Apache Cassandra ワークロードを Amazon Keyspaces に移行するAWS Glue](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html)」の記事を参照してください。

# 変更データキャプチャ (CDC) を使用してデータを移行する
<a name="migration-hybrid-cdc"></a>

[Debezium](https://debezium.io/) での変更データキャプチャ (CDC) パイプラインの設定に慣れている場合は、CQLReplicator の代わりにこの方法を選んで Amazon Keyspaces にデータを移行できます。Debezium は、CDC 用のオープンソースの分散型プラットフォームです。データベースを監視し、行レベルの変更を確実に捉えるように設計されています。

[Apache Cassandra 用の Debezium コネクタ](https://debezium.io/documentation/reference/stable/connectors/cassandra.html)が Amazon Managed Streaming for Apache Kafka (Amazon MSK) に変更をアップロードし、その変更をダウンストリームのコンシューマーが使用および処理できるようになり、最終的にそれらのコンシューマーが Amazon Keyspaces にデータを書き込みます。詳細については、「[Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/)」を参照してください。

データ整合性の潜在的な問題に対処するために、コンシューマーが Cassandra と Amazon Keyspaces でキーやパーティションを比較するプロセスを Amazon MSK で実装できます。

このソリューションを問題なく実装できるように、次の点を検討することをお勧めします。
+ CDC コミットログを解析する方法 (重複イベントを削除する方法など)。
+ CDC ディレクトリを維持する方法 (古いログを削除する方法など)。
+ Apache Cassandra で部分的な障害に対処する方法 (例えば、書き込みが 3 つのレプリカの 1 つでのみ成功した場合など)。
+ リソースの割り当てを処理する方法 (ノードで発生する CDC プロセス用の CPU、メモリ、ディスク、IO の追加要件を考慮して、インスタンスのサイズを増やすなど)。

このパターンでは、Cassandra からの変更を、キーが以前の状態から変更された可能性があるという「ヒント」として扱います。宛先データベースに伝達すべき変更があるかを判断するには、まずソースとなる Cassandra クラスターから `LOCAL_QUORUM` オペレーションを使用して最新のレコードを取得する必要があり、その後、そのレコードを Amazon Keyspaces に書き込みます。

範囲指定の削除や更新の場合、パーティション全体との比較を実行しないと、宛先データベースに書き込む必要がある書き込みイベントや更新イベントを判断できない可能性があります。

書き込みがべき等でない場合は、Amazon Keyspaces に書き込む前に、書き込み内容を宛先データベースの既存データと比較する必要も生じます。

次の図は、Debezium と Amazon MSK を使用した CDC パイプラインの一般的なアーキテクチャを示しています。

![\[変更データキャプチャパイプラインを使用して、Apache Cassandra から Amazon Keyspaces にデータを移行します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png)
