翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 サービスに完全移行できます。