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

# オンライン移行中の新しいデータの書き込み
<a name="migration-online-dw"></a>

オンライン移行計画の最初のステップは、アプリケーションが新たに書き込むデータが、既存の 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 つのビューを作成できます。