翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Apache Cassandra から Amazon Keyspaces への移行の計画を立てる
Apache Cassandra から Amazon Keyspaces への移行を成功させるために、適応可能な移行の概念とベストプラクティスを確認し、取り得る選択肢を比較検討することをお勧めします。
このトピックでは、いくつかの主要な概念と利用可能なツールや手法を紹介しながら、移行プロセスの仕組みを概説します。さまざまな移行戦略を評価することで、独自の要件に最適な戦略を選定できます。
**Topics**
+ [機能の互換性](#migrating-cassandra-compatibility)
+ [Amazon Keyspaces の料金を推定する](#migrating-cassandra-sizing)
+ [移行戦略を選択する](#migrating-cassandra-strategy)
+ [Amazon Keyspaces へのオンライン移行: 戦略とベストプラクティス](migrating-online.md)
+ [オフライン移行プロセス: Apache Cassandra から Amazon Keyspaces への移行](migrating-offline.md)
+ [ハイブリッド移行ソリューションの使用: Apache Cassandra から Amazon Keyspaces への移行](migrating-hybrid.md)
## 機能の互換性
移行の前に、Apache Cassandra と Amazon Keyspaces の機能面の違いを慎重に検討しておきましょう。Amazon Keyspaces は、キースペースとテーブルの作成、データの読み取り、データの書き込みなど、一般的に使用されるあらゆる Cassandra データプレーンオペレーションに対応しています。
ただし、Amazon Keyspaces がサポートしていない Cassandra API も一部あります。サポートされている API の詳細については、「[サポートされている Cassandra API、オペレーション、関数、データ型](cassandra-apis.md)」を参照してください。Amazon Keyspaces と Apache Cassandra のすべての機能の違いについては、「[機能の違い: Amazon Keyspaces と Apache Cassandra](functional-differences.md)」で概要をまとめて紹介しています。
現在使用中の Cassandra の API やスキーマを、Amazon Keyspaces でサポートされている機能と比較検討するために、[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py) の Amazon Keyspaces ツールキットから入手可能な互換性スクリプトを実行できます。
**互換性スクリプトを使用する方法**
1. [GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py) から Python 互換性スクリプトをダウンロードし、既存の Apache Cassandra クラスターへのアクセスが可能な場所に移動します。
1. 互換性スクリプトは、`CQLSH` と類似したパラメータを使用します。`--host` および `--port` には、クラスター内のいずれかの Cassandra ノードへの接続とクエリ実行に使用する IP アドレスとポートを入力します。
Cassandra クラスターで認証を使用している場合は、`-username` と `-password` も指定する必要があります。互換性スクリプトを実行するには、次のコマンドを使用します。
```
python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port
```
## Amazon Keyspaces の料金を推定する
ここでは、Amazon Keyspaces の推定コストを計算するために、Apache Cassandra テーブルから収集する必要がある情報をかいつまんで説明します。各テーブルは異なるデータ型を必要とし、サポートする必要がある CQL クエリも異なり、それぞれが特有の読み取り/書き込みトラフィックを維持しています。
要件をテーブルごとに考えれば、Amazon Keyspaces ではリソースの分離や[読み取り/書き込みスループットキャパシティモード](ReadWriteCapacityMode.md)がテーブル単位になっているため、うまく適合します。Amazon Keyspaces では、テーブルの読み取り/書き込みキャパシティと[自動スケーリングポリシー](autoscaling.md)を個別に定義できます。
テーブルの要件を理解すれば、機能、コスト、移行の負荷に基づいて、移行対象のテーブルに優先順位を付けやすくなります。
移行前に、Cassandra のテーブルについて次のメトリクスを収集しておきましょう。これらの情報を基に、Amazon Keyspaces におけるワークロードのコストを推定できます。
+ **テーブル名** – キースペースとテーブルの完全修飾名。
+ **説明** – テーブルの説明 (使用方法や保存するデータの型など)。
+ **1 秒あたりの平均読み取り数** — 長期間におけるテーブルへのコーディネーターレベルの読み取りの平均数。
+ **1 秒あたりの平均書き込み数** – 長期間におけるテーブルへのコーディネーターレベルの書き込みの平均数。
+ **平均行サイズ (バイト単位)** – バイト単位の行サイズの平均値。
+ **ストレージサイズ (GB 単位)** – テーブルの raw ストレージサイズ。
+ **読み取り整合性の内訳** – 結果整合性 (`LOCAL_ONE` または `ONE`) と強整合性 (`LOCAL_QUORUM`) のある読み取りの割合。
次の表は、移行を計画するにあたって揃える必要があるテーブル関連情報の例を示しています。
****
| テーブル名 | 説明 | 1 秒あたりの平均読み取り数 | 1 秒あたりの平均書き込み数 | 平均行サイズ (バイト単位) | ストレージサイズ (GB 単位) | 読み取り整合性の内訳 |
| --- | --- | --- | --- | --- | --- | --- |
| mykeyspace.mytable | ショッピングカート履歴の保存用 | 10,000 | 5,000 | 2,200 | 2,000 | 100% `LOCAL_ONE` |
| mykeyspace.mytable2 | 最新のプロファイル情報の保存用 | 20,000 | 1,000 | 850 | 1,000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` |
### テーブルのメトリクスを収集する方法
このセクションでは、既存の Cassandra クラスターから必要なテーブルメトリクスを収集する手順をステップバイステップで説明します。行サイズ、テーブルサイズ、1 秒あたりの読み取り/書き込みリクエスト数 (RPS) などのメトリクスが該当します。これらの情報から、Amazon Keyspaces のテーブルのスループットキャパシティ要件を評価し、料金を推定できます。
**Cassandra ソーステーブルのテーブルメトリクスを収集する方法**
1. 行サイズを調べる
行のサイズは、Amazon Keyspaces における読み取りと書き込みのキャパシティ使用率を判断する上で重要です。次の図は、Cassandra のトークン範囲における典型的なデータ分散を示しています。
![\[murmur3 パーティショナーを使用した Cassandra トークン範囲にわたる一般的なデータ分散を示す図。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/migration-data-distribution.png)
[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh) から入手可能な行サイズのサンプルスクリプトを使用して、Cassandra クラスター内の各テーブルの行サイズメトリクスを収集できます。
このスクリプトは、`cqlsh` と `awk` を使用して Apache Cassandra からテーブルデータをエクスポートし、任意で指定したテーブルデータのサンプルセットに基づいて、行サイズの最小値、最大値、平均値、標準偏差を計算します。行サイズのサンプルスクリプトに指定した引数が `cqlsh` に渡されるため、同じパラメータを使用して Cassandra クラスターに接続し、データを読み取ることができます。
以下のステートメントは、この例です。
```
./row-size-sampler.sh 10.22.33.44 9142 \\
-u "username" -p "password" --ssl
```
Amazon Keyspaces で行サイズを計算する方法の詳細については、「[Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)」を参照してください。
1. テーブルサイズを調べる
Amazon Keyspaces では、ストレージを事前にプロビジョニングする必要がありません。テーブルの請求対象サイズが継続的に監視され、ストレージ料金が決定されます。ストレージは GB/月単位で請求されます。Amazon Keyspaces のテーブルサイズは、単一レプリカの raw サイズ (非圧縮) に基づいています。
Amazon Keyspaces でテーブルサイズを監視するには、メトリクス `BillableTableSizeInBytes` を使用できます。これは、AWS マネジメントコンソールでテーブルごとに表示されます。
Amazon Keyspaces テーブルの請求対象サイズは、次の 2 とおりの方法で推定できます。
+ 行サイズの平均値に行数を掛ける。
Amazon Keyspaces テーブルのサイズは、行サイズの平均値に Cassandra ソーステーブルの行数を掛けることで推定できます。前のセクションで紹介した行サイズのサンプルスクリプトを使用して、行サイズの平均値を取得してください。行数を取得するには、`dsbulk count` などのツールを使用して、ソーステーブル内の行の総数を判断できます。
+ `nodetool` を使用してテーブルメタデータを収集する。
`Nodetool` は、Apache Cassandra ディストリビューションで提供されている管理ツールです。Cassandra プロセスの状態に関するインサイトを提供し、テーブルのメタデータを返します。`nodetool` を使用して、テーブルサイズに関するメタデータをサンプリングし、その情報を基に Amazon Keyspaces でのテーブルサイズを推定することができます。
使用するコマンドは `nodetool tablestats` です。tablestats は、テーブルのサイズと圧縮率を返します。テーブルのサイズは、テーブルの `tablelivespace` として保存されています。この値を `compression ratio` で割り、そのサイズ値にノード数を掛け、最後に、レプリケーション係数 (通常は 3) で割ります。
この計算の完全な式は次のとおりです。これを使用して、テーブルのサイズを評価できます。
```
((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)
```
Cassandra クラスターにノードが 12 あると想定しましょう。`nodetool tablestats` コマンドを実行した結果、`tablelivespace` として 200 GB、`compression ratio` として 0.5 が返されました。キースペースのレプリケーション係数は 3 です。
この例の場合、計算式は次のようになります。
```
(200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
= 4,800 GB / 3
= 1,600 GB is the table size estimate for Amazon Keyspaces
```
1. 読み取り数と書き込み数を調べる
Amazon Keyspaces テーブルのキャパシティとスケーリングの要件を判断するために、移行前に Cassandra テーブルの読み取りと書き込みのリクエストレートを調べておきましょう。
Amazon Keyspaces はサーバーレスであり、使用した分だけ料金を支払います。一般に、Amazon Keyspaces の読み取り/書き込みスループットの料金は、リクエストの数とサイズに基づいて決まります。
Amazon Keyspaces には 2 つのキャパシティモードがあります。
+ [オンデマンド](ReadWriteCapacityMode.OnDemand.md) – キャパシティプランニングの必要なく、1 秒あたり数千のリクエスト数を処理できる柔軟な請求オプションです。読み取りおよび書き込みのリクエスト数ごとの従量課金であるため、使用した分だけを支払います。
+ [プロビジョンド](ReadWriteCapacityMode.Provisioned.md) – プロビジョンドスループットキャパシティモードを選択した場合は、アプリケーションに必要な 1 秒あたりの読み込みと書き込みの数を指定します。これにより、Amazon Keyspaces の使用状況を管理して、定義されたリクエストレート以下を維持し、予測可能性を維持できます。
プロビジョンドモードでは、[自動スケーリング](autoscaling.md)を使用して、プロビジョニングしておいたレートを自動調整してスケールアップまたはスケールダウンし、運用効率を高めることができます。サーバーレスリソース管理の詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) でのサーバーレスリソースの管理](serverless_resource_management.md)」を参照してください。
Amazon Keyspaces では読み取りと書き込みのスループットキャパシティを個別にプロビジョニングするため、既存のテーブルの読み取りと書き込みのリクエストレートを個別に測定する必要があります。
既存の Cassandra クラスターから最も正確な使用率メトリクスを収集するには、テーブルへのコーディネーターレベルの読み取り/書き込みオペレーションについて、1 秒あたりのリクエスト数 (RPS) の平均値を長期間にわたって観察します。単一のデータセンター内のすべてのノードにわたる集計値から平均値を求めます。
少なくとも数週間にわたる RPS の平均値を取ることで、次の図に示すように、トラフィックパターンのピークと谷を捉えることができます。
![\[1 日ごとの RPS (1 秒あたりのリクエスト数) の平均レートを 2 週間にわたって示した図。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/migration-rps.png)
Cassandra テーブルの読み取りと書き込みのリクエストレートを判断するには、2 つの選択肢があります。
+ 既存の Cassandra モニタリングを使用する
次の表に示すメトリクスを使用して、読み取りリクエスト数と書き込みリクエスト数を観察できます。メトリクスの名前は、使用しているモニタリングツールによって異なる場合があります。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/migrating-cassandra.html)
+ `nodetool` の使用
`nodetool tablestats` および `nodetool info` を使用して、テーブルに対する読み取り/書き込みオペレーション数の平均値を求めます。`tablestats` は、ノードが開始された時点からの読み取り数と書き込み数の合計を返します。`nodetool info` は、ノードの稼働時間を秒単位で返します。
読み取りと書き込みの 1 秒あたりの平均数を求めるには、読み取り数と書き込み数をノードの稼働時間 (秒数) で割ります。その後、読み取り数については整合性レベルで割り、書き込み数についてはレプリケーション係数で割って求めます。これらの計算は、次の式で表すことができます。
1 秒あたりの平均読み取り数の式:
```
((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime
```
1 秒あたりの平均書き込み数の式:
```
((number of writes * number of nodes in cluster) / replication factor of 3) / uptime
```
クラスターに 12 のノードがあり、4 週間稼働していると想定しましょう。`nodetool info` が返した稼働時間は 2,419,200 秒、`nodetool tablestats` が返した書き込み数は 10 億件、読み取り数は 20 億件でした。この例の場合、計算式は次のとおりです。
```
((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
= 12 billion reads / 2,419,200 seconds
= 4,960 read request per second
((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
= 4 billion writes / 2,419,200 seconds
= 1,653 write request per second
```
1. テーブルのキャパシティ使用率を調べる
平均キャパシティ使用率を推定するには、まず、Cassandra ソーステーブルの平均リクエストレートと平均行サイズを確認します。
Amazon Keyspaces では、*読み取りキャパシティユニット* (RCU) と*書き込みキャパシティユニット* (WCU) に基づいて、テーブルの読み取りと書き込み用にプロビジョニングされたスループットキャパシティを測定します。この推定では、移行後の新しい Amazon Keyspaces テーブルの読み取りキャパシティと書き込みキャパシティのニーズを、これらのユニットに基づいて算出します。
このトピックの後半で、プロビジョンドキャパシティモードとオンデマンドキャパシティモードのどちらを選択すると、請求にどのような影響があるかを検討します。ただし、この例でキャパシティ使用率を推定するにあたっては、テーブルがプロビジョンドモードであると想定します。
+ **読み取り** – 1 RCU で、4 KB までの行に対して、`LOCAL_QUORUM` の読み取りリクエストを 1 回、または `LOCAL_ONE` の読み取りリクエストを 2 回実行できます。4 KB より大きい行を読み取る必要がある場合、読み取りオペレーションには追加の RCU が使用されます。必要な RCU の総数は、行のサイズと、必要な読み取り整合性 (`LOCAL_QUORUM` または `LOCAL_ONE`) によって異なります。
例えば、8 KB の行を読み取るには、読み取り整合性が `LOCAL_QUORUM` の場合は 2 RCU、読み取り整合性が `LOCAL_ONE` の場合は 1 RCU が必要です。
+ **書き込み** – 1 WCU で、1 KB までの行に対して書き込みを 1 回実行できます。すべての書き込みでは `LOCAL_QUORUM` 整合性が使用されており、軽量トランザクション (LWT) の使用には追加料金はかかりません。
必要な WCU の総数は、行サイズに応じて異なります。1 KB より大きい行を書き込む必要がある場合、書き込みオペレーションでは追加の WCU が使用されます。例えば、行のサイズが 2 KB の場合、書き込みリクエストを 1 回実行するには 2 WCU が必要です。
次の式を使用して、必要な RCU と WCU を推定できます。
+ **読み取りキャパシティ (RCU 単位)** を求めるには、1 秒あたりの読み取り数に、1 回で読み取る行数を掛け、その結果に、平均行サイズを 4 KB で割って最も近い整数に切り上げた結果を掛け合わせます。
+ **書き込みキャパシティ (WCU 単位)** を求めるには、リクエスト数に、平均行サイズを 1 KB で割って最も近い整数に切り上げた数を掛け合わせます。
これは、次の式で表されます。
```
Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second
```
例えば、行のサイズが 2.5 KB の Cassandra テーブルで 4,960 件の読み取りリクエストを実行している場合、Amazon Keyspaces では 4,960 RCU が必要です。行のサイズが 2.5 KB の Cassandra テーブルで 1 秒あたり 1,653 件の書き込みリクエストを実行している場合、Amazon Keyspaces では 1 秒あたり 4,959 WCU が必要になります。
この例は、次の式で表されます。
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit)
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs
```
`eventual consistency` を使用すれば、読み取りリクエストごとのスループットキャパシティを最大で半減させることができます。結果整合性のある読み込みでは、1 件あたり最大で 8 KB を処理することができます。結果整合性のある読み込みの場合は、次の式に示すとおり、前の計算結果に 0.5 を掛けて求めることができます。
```
4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5
= 2,480 read request per second * 1 RCU
= 2,480 RCUs
```
1. Amazon Keyspaces の月額の推定利用料金を計算する
読み取り/書き込みのキャパシティスループットに基づいてテーブルの月額の請求料金を推定するには、オンデマンドモードとプロビジョンドモードの料金を別々の式で求め、テーブルで利用できる選択肢を比較できます。
**プロビジョンドモード** – 読み取りおよび書き込みのキャパシティ消費量は、1 秒あたりのキャパシティユニットに基づいて時間単位で請求されます。まず、そのレートを 0.7 で割り、自動スケーリングのデフォルトのターゲット使用率である 70% 相当分を求めます。次に、暦日の 30、1 日の時間数 24、そしてリージョン別料金を掛け合わせます。
この計算をまとめた式は、次のとおりです。
```
(read capacity per second / .7) * 24 hours * 30 days * regional rate
(write capacity per second / .7) * 24 hours * 30 days * regional rate
```
**オンデマンドモード** – 読み取りキャパシティと書き込みキャパシティは、リクエストレート単位で請求されます。まず、リクエストレートに暦日の 30、1 日の時間数 24 を掛けます。次に、100 万リクエストユニットで割ります。最後に、リージョン別料金を掛けます。
この計算をまとめた式は、次のとおりです。
```
((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate
```
## 移行戦略を選択する
Apache Cassandra から Amazon Keyspaces に移行する場合は、次のいずれかの移行戦略を選択できます。
+ **オンライン** – ライブで移行します。デュアル書き込みを使用して、Amazon Keyspaces と Cassandra クラスターに同時に新しいデータの書き込みを始めます。アプリケーションでゼロダウンタイムの移行と書き込み後の読み取り整合性が必要な場合は、この移行手法が推奨されます。
オンライン移行の戦略を計画し、実装する方法の詳細については、「[Amazon Keyspaces へのオンライン移行: 戦略とベストプラクティス](migrating-online.md)」を参照してください。
+ **オフライン** – ダウンタイム期間を設けて、その間に Cassandra から Amazon Keyspaces にデータセットをコピーします。オフライン移行では、アプリケーションの変更や、履歴データと新しい書き込み間の競合解決が不要なため、移行プロセスを簡素化できます。
オフライン移行の計画方法の詳細については、「[オフライン移行プロセス: Apache Cassandra から Amazon Keyspaces への移行](migrating-offline.md)」を参照してください。
+ **ハイブリッド** – ほぼリアルタイムで変更を Amazon Keyspaces にレプリケートできますが、書き込み後の読み取り整合性は保証されません。
ハイブリッド移行の計画方法の詳細については、「[ハイブリッド移行ソリューションの使用: Apache Cassandra から Amazon Keyspaces への移行](migrating-hybrid.md)」を参照してください。
このトピックで説明した移行手法とベストプラクティスを確認したら、取り得る選択肢をディシジョンツリーに書き込み、独自の要件と利用可能なリソースに基づいて移行戦略を立てることができます。
# Amazon Keyspaces へのオンライン移行: 戦略とベストプラクティス
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)
# オンライン移行中の新しいデータの書き込み
オンライン移行計画の最初のステップは、アプリケーションが新たに書き込むデータが、既存の Cassandra クラスターと Amazon Keyspaces の両データベースに保存されるようにすることです。目標は、2 つのデータストア間のビューの一貫性を確保することです。そのためには、新しい書き込みをすべて両方のデータベースに適用します。デュアル書き込みを実装するには、次の 3 つのオプションのいずれかを検討してください。
+ **Amazon Keyspaces 移行用の ZDM デュアル書き込みプロキシ** – [Github](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md) で利用可能な Amazon Keyspaces 用の ZDM プロキシを使用すると、アプリケーションのダウンタイムなしで Apache Cassandra ワークロードを Amazon Keyspaces に移行できます。この拡張ソリューションは、AWSベストプラクティスを実装し、公式の ZDM Proxy 機能を拡張します。
+ Apache Cassandra と Amazon Keyspaces の間でオンライン移行を実行します。
+ アプリケーションのリファクタリングを行わずに、ソーステーブルとターゲットテーブルの両方に同時にデータを書き込みます。
+ デュアル読み取りオペレーションを使用してクエリを検証します。
このソリューションでは、 AWSと Amazon Keyspaces を操作するために以下の機能強化を提供しています。
+ **コンテナデプロイ** — VPC からアクセス可能なデプロイには、Amazon Elastic Container Registry (Amazon ECR) から事前設定された Docker イメージを使用します。
+ **コードとしてのインフラストラクチャ** – AWS CloudFormationテンプレートを使用してデプロイし、自動セットアップを行いますAWS Fargate。
+ **Amazon Keyspaces の互換性** – Amazon Keyspaces のカスタム適応を使用してシステムテーブルにアクセスします。
このソリューションは、Fargate を使用して Amazon ECS で実行され、ワークロードの需要に基づいてサーバーレスのスケーラビリティを提供します。Network Load Balancer は、受信アプリケーショントラフィックを複数の Amazon ECS タスクに分散して高可用性を実現します。
![\[Apache Cassandra から Amazon Keyspaces にデータを移行するための ZDM デュアル書き込みプロキシを実装します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/online-migration-zdm.png)
+ **アプリケーションのデュアル書き込み** – 既存の Cassandra クライアントライブラリとドライバーを活用することで、アプリケーションコードの変更を最小限に抑えてデュアル書き込みを実装できます。既存のアプリケーションにデュアル書き込みを実装するか、アーキテクチャに新しいレイヤーを作成してデュアル書き込みを処理することができます。詳しい情報や、既存のアプリケーションにデュアル書き込みを実際したお客様の導入事例については、[Cassandra 移行の導入事例](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/)を参照してください。
デュアル書き込みを実装する場合は、1 つのデータベースをリーダー、もう 1 つのデータベースをフォロワーとして指定できます。これにより、元のソース (リーダーデータベース) への書き込みを続けることができ、フォロワー (宛先データベース) への書き込みが失敗しても、アプリケーションのクリティカルパスに支障をきたすことがありません。
フォロワーへの書き込みが失敗した場合は再試行する代わりに、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 パターンに従ってデュアル書き込みを設定して、各書き込みをローカルトランザクションとして行い、異種データベースにまたがるオペレーションをアトミックに処理します。に推奨される設計パターンを使用した分散アプリケーションの設計の詳細についてはAWS クラウド、[「クラウド設計パターン、アーキテクチャ、実装](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction)」を参照してください。
![\[Apache Cassandra から Amazon Keyspaces への移行時にアプリケーションレイヤーでデュアル書き込みを実装します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png)
+ **メッセージング層のデュアル書き込み** – アプリケーションレイヤーにデュアル書き込みを実装する代わりに、既存のメッセージング層を使用して、Cassandra と Amazon Keyspaces へのデュアル書き込みを実行できます。
そのためには、メッセージングプラットフォームにコンシューマーを追加して、両方のデータストアに書き込みを送信するように設定できます。このアプローチなら、メッセージング層を利用したシンプルなローコード戦略で、両方のデータベース間で結果整合性のある 2 つのビューを作成できます。
# オンライン移行中の履歴データのアップロード
デュアル書き込みを実装して新しいデータを両方のデータストアにリアルタイムで書き込むようにした後、移行計画の次のステップでは、Cassandra から Amazon Keyspaces にコピーまたは一括アップロードする必要がある履歴データの量を評価します。これにより、アプリケーションの移行前に、新しいデータと履歴データの両方を新しい Amazon Keyspaces データベースに用意できます。
データ保持の要件 (組織のポリシーに基づいて保管しておく必要がある履歴データの量など) に応じて、次の 2 つの選択肢のいずれかを検討できます。
+ **履歴データの一括アップロード** – 既存の Cassandra デプロイから Amazon Keyspaces への履歴データの移行は、データの抽出、変換、ロード (ETL) に AWS Glueやカスタムスクリプトを使用するなど、さまざまな手法を通じて実現できます。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 に指定した期間が経過したら、データが自動的にデータベースから削除されます。
移行フェーズでは、履歴データを Amazon Keyspaces にコピーする代わりに、TTL を設定して履歴データを古いシステム (Cassandra) で自動的に期限切れにし、デュアル書き込み手法を用いて新しい書き込みのみを Amazon Keyspaces に適用することができます。時間が経つにつれて、Cassandra クラスターで古いデータが順次期限切れになり、デュアル書き込み手法で新しいデータが書き込まれていき、自ずと Amazon Keyspaces が追いつき、Cassandra と同じデータが揃います。
このアプローチなら、移行対象のデータ量を大幅に削減して、より効率的、合理的に移行プロセスを進めることができます。データ保持の要件がさまざまに異なる大規模なデータセットを処理する場合は、このアプローチを検討できます。TTL の詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) で有効期限 (TTL) を使用してデータを期限切れにする](TTL.md)」を参照してください。
TTL によるデータの有効期限を利用して、Cassandra から Amazon Keyspaces に移行する次の例を検討してみましょう。この例では、両方のデータベースの TTL を 60 日間に設定し、90 日の期間にわたって移行プロセスがどのように進行するかを見ていきます。両方のデータベースにはこの期間中、デュアル書き込み手法で新しいデータが書き込まれます。移行を 30 日間ずつの各フェーズに分けて検討します。
各フェーズで移行がどのように進むかを次の図にまとめています。
![\[Apache Cassandra から Amazon Keyspaces への移行時に TTL を使用して履歴データを期限切れにします。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/online-migration-TTL.png)
1. 最初の 30 日が過ぎた時点で、Cassandra クラスターと Amazon Keyspaces は新しい書き込みを受信しています。Cassandra クラスターには、60 日間の保持期間がまだ過ぎていない履歴データも含まれていて、これがクラスター内のデータの 50% を占めています。
60 日以上経ったデータは、TTL を使用して Cassandra クラスターから自動的に削除されます。この時点で、Amazon Keyspaces には Cassandra クラスターに保存されているデータの 50% が含まれており、これは新しい書き込みから履歴データを除いた分です。
1. 60 日後、Cassandra クラスターと Amazon Keyspaces の両方に、過去 60 日間に書き込まれた同じデータが揃います。
1. 90 日経過するまでの間に、Cassandra と Amazon Keyspaces の両方に同じデータが揃い、同じ速さでデータが期限切れになります。
この例で、TTL を使用して有効期限を 60 日に設定し、履歴データのアップロードを回避する方法がわかりました。
# オンライン移行中のデータ整合性の検証
オンライン移行プロセスの次のステップは、データの検証です。デュアル書き込みで Amazon Keyspaces データベースに新しいデータを追加し、履歴データの移行は一括アップロード、または TTL によるデータの有効期限のいずれかを利用して完了しました。
これで、検証フェーズを使用して、両方のデータストアが実際に同じデータを含み、同じ読み取り結果を返すことを確認できます。次の 2 つの選択肢のいずれかを使用して、両方のデータベースに同じデータが含まれていることを検証できます。
+ **デュアル読み取り** – ソースデータベースと宛先データベースの両方に、新しく書き込まれたデータと履歴データの同じセットが揃っていることを検証するために、デュアル読み取りを実装できます。それには、デュアル書き込み手法と同様に、プライマリ 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/ja_jp/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png)
+ **サンプル読み取り** – アプリケーションコードの変更を必要としない代替ソリューションは、 AWS Lambda関数を使用して、ソース Cassandra クラスターと宛先 Amazon Keyspaces データベースの両方から定期的かつランダムにデータをサンプリングすることです。
これらの Lambda 関数は、定期的な間隔で実行するように設定できます。Lambda 関数は、ソースシステムと宛先システムの両方からデータのランダムなサブセットを取得し、そのサンプルデータの比較を実行します。2 つのデータセット間の不一致や不整合があった場合は、後で照合するために記録し、専用の[デッドレターキュー (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) に送信できます。
次の図表は、このプロセスを示したものです。
![\[サンプル読み取りを使用して、Apache Cassandra から Amazon Keyspaces へのオンライン移行中のデータ整合性を検証します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png)
# オンライン移行中のアプリケーションの移行
オンライン移行の第 4 フェーズでは、アプリケーションを移行し、プライマリデータストアを Amazon Keyspaces に切り替えます。つまり、アプリケーションが読み書きを直接 Amazon Keyspaces との間で行うようになります。ユーザーへの中断を最小限に抑えるため、入念な計画を練り、関係各所と調整した上で進める必要があります。
アプリケーションの移行には、ブルー/グリーンカットオーバー戦略とカナリアカットオーバー戦略という 2 つの異なる推奨ソリューションを使用できます。以下のセクションでは、これらの戦略について詳しく説明します。
+ **ブルー/グリーン戦略** – Amazon Keyspaces をプライマリデータストアとして、Cassandra をセカンダリデータストアとして扱うように、アプリケーションを一度に切り替えます。これを行うには、AWS AppConfig機能フラグを使用して、アプリケーションインスタンス全体のプライマリデータストアとセカンダリデータストアの選択を制御します。詳細については、「[Creating a feature flag configuration profile in 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/ja_jp/keyspaces/latest/devguide/images/migration/online-migration-switch.png)
+ **カナリア戦略** – 一部のユーザーまたはトラフィックを対象に、移行を徐々にロールアウトします。最初は、アプリケーションのトラフィックのうち少量、例えば全体の 5% だけを Amazon Keyspaces をプライマリデータストアとして使用するバージョンにルーティングし、残りのトラフィックは引き続きプライマリデータストアとして Cassandra を使用します。
これにより、実際のトラフィックで移行後のバージョンを徹底的にテストし、そのパフォーマンス、安定性を監視し、潜在的な問題を調査することができます。問題が検出されなければ、Amazon Keyspaces にルーティングするトラフィックの割合を徐々に増やし、最終的にすべてのユーザーとトラフィックが Amazon Keyspaces をプライマリデータストアとして使用するまで続けます。
このように段階的にロールアウトしていくことで、サービス全体で障害が発生するリスクを最小限に抑え、移行プロセスを制御下に置くことができます。カナリアデプロイの最中に重大な問題が発生した場合は、影響を受けたトラフィックセグメントについて、プライマリデータストアとして Cassandra を使用する以前のバージョンにすばやくロールバックできます。Amazon Keyspaces が 100% のユーザーとトラフィックを正常に処理していることが検証されてはじめて、移行の廃止フェーズに進みます。
次の図は、カナリア戦略の各ステップを示しています。
![\[カナリア戦略を使用して、アプリケーションを Apache Cassandra から Amazon Keyspaces に移行します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/online-migration-canary.png)
# オンライン移行後の Cassandra の廃止
アプリケーションの移行が完了し、アプリケーションが完全に Amazon Keyspaces で実行されるようになり、一定期間にわたるデータ整合性が検証されたら、Cassandra クラスターの廃止計画を立てることができます。このフェーズでは、Cassandra クラスターに残っているデータをアーカイブする必要があるか、削除してもよいかを評価できます。どちらにするかは、データ処理と保持に関する組織のポリシーによって決まります。
この戦略に従い、このトピックで説明した推奨ベストプラクティスを検討して Cassandra から Amazon Keyspaces へのオンライン移行を計画することで、アプリケーションの書き込み後の読み取り整合性や可用性を維持しながら、Amazon Keyspaces へのシームレスな移行を実現できます。
Apache Cassandra から Amazon Keyspaces への移行には、運用上のオーバーヘッドの削減、自動スケーリング、セキュリティの強化、コンプライアンス目標の達成を支援するフレームワークなど、数多くのメリットがあります。デュアル書き込み、履歴データのアップロード、データ検証、段階的なロールアウトを踏まえてオンライン移行戦略を計画することで、アプリケーションとそのユーザーへの影響を最小限に抑えながら、スムーズな移行を実現できます。
このトピックで説明したオンライン移行戦略を実装すれば、移行の結果を検証し、問題があれば特定して対処し、最終的には既存の Cassandra デプロイを廃止して、フルマネージド型の Amazon Keyspaces サービスに完全移行できます。
# オフライン移行プロセス: Apache Cassandra から Amazon Keyspaces への移行
オフライン移行は、移行時にダウンタイムを許容できる場合に適しています。企業では、パッチの適用や大規模リリース、またはハードウェアのアップグレードやメジャーアップグレードによるダウンタイムに備えて、メンテナンスウィンドウを設けることが一般的です。オフライン移行では、このウィンドウを利用してデータをコピーし、アプリケーショントラフィックを Apache Cassandra から Amazon Keyspaces に切り替えることができます。
オフライン移行の場合、Cassandra と Amazon Keyspaces の双方と同時に通信する必要がないため、アプリケーションの変更の手間を省けます。また、データフローを一時停止して、そのままの状態をコピーでき、途中変更の管理も不要です。
ここで紹介する例では、オフライン移行中のデータのステージングエリアとして Amazon Simple Storage Service (Amazon S3) を活用し、ダウンタイムを最小限に抑えます。Spark Cassandra コネクタと AWS Glue を使用して、Amazon S3 に Parquet 形式で保存されているデータを Amazon Keyspaces テーブルに自動的にインポートできます。この後のセクションでは、このプロセスの大筋を説明します。このプロセスのコード例は、[Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue) で公開されています。
Amazon S3 を使用した Apache Cassandra から Amazon Keyspaces へのオフライン移行プロセスには、次のAWS GlueジョブAWS Glueが必要です。
1. CQL データを抽出して変換し、Amazon S3 バケットに保存する ETL ジョブ。
1. バケットから Amazon Keyspaces にデータをインポートする 2 つ目のジョブ。
1. 増分データをインポートする 3 つ目のジョブ。
**Amazon Virtual Private Cloud の Amazon EC2 で実行されている Cassandra から Amazon Keyspaces へのオフライン移行の実行方法**
1. まずAWS Glue、 を使用して Cassandra から Parquet 形式でテーブルデータをエクスポートし、Amazon S3 バケットに保存します。Cassandra を実行している Amazon EC2 インスタンスが存在する VPC へのAWS Glueコネクタを使用してAWS Glueジョブを実行する必要があります。その後、Amazon S3 プライベートエンドポイントを使用して、Amazon S3 バケットにデータを保存できます。
次の図は、これらの手順の流れを示しています。
![\[AWS Glue を使用して、VPC で実行されている Amazon EC2 から Amazon S3 バケットに Apache Cassandra データを移行します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/migration-export.png)
1. Amazon S3 バケット内のデータをシャッフルして、データのランダム性を高めます。データを均等にインポートすれば、ターゲットテーブルでトラフィックをより分散させることができます。
この手順は、パーティションが大きい (1000 行を超えるパーティション) Cassandra からデータをエクスポートして、Amazon Keyspaces に挿入する場合に、ホットキーのパターンを回避するために必要です。ホットキーの問題が生じると、Amazon Keyspaces で `WriteThrottleEvents` が発生し、ロード時間が長引きます。
![\[AWS Glueジョブは Amazon S3 バケットからデータをシャッフルし、別の Amazon S3 バケットに返します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/migration-shuffle.png)
1. 別のAWS Glueジョブを使用して、Amazon S3 バケットから Amazon Keyspaces にデータをインポートします。シャッフル後のデータは Amazon S3 バケット内に Parquet 形式で保存されます。
![\[AWS GlueインポートジョブはAmazon S3バケットからシャッフルされたデータを取得し、Amazon Keyspaces テーブルに移動します。\]](http://docs.aws.amazon.com/ja_jp/keyspaces/latest/devguide/images/migration/migration-import.png)
オフライン移行プロセスの詳細については、 [を使用した Amazon KeyspacesAWS Glue](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue) ワークショップを参照してください。
# ハイブリッド移行ソリューションの使用: Apache Cassandra から Amazon Keyspaces への移行
以下に紹介する移行ソリューションは、オンライン移行とオフライン移行を組み合わせたハイブリッドソリューションと言えます。このハイブリッド手法では、データがほぼリアルタイムで宛先のデータベースに書き込まれますが、書き込み後の読み取り整合性は保証されません。つまり、新たに書き込まれたデータをすぐには利用できず、遅延が想定されます。書き込み後の読み取り整合性が必要な場合は、「[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 を使用してデータを移行する
[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) を使用してデータを移行する
[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)