

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

# 変更データキャプチャ (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)
