翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Keyspaces (Apache Cassandra 向け) への移行
Amazon Keyspaces (Apache Cassandra 向け) への移行は、企業や組織にとって魅力的なさまざまなメリットをもたらします。Amazon Keyspaces には主に次のような利点があるため、移行先として魅力的な選択肢となっています。
+ **スケーラビリティ** – Amazon Keyspaces は、大量のワークロードを処理し、データ量とトラフィックの増加に合わせてシームレスにスケールできるように設計されています。従来の Cassandra では、スケーリングはオンデマンドでは実行されず、将来のピークに備えて計画しておく必要がありました。Amazon Keyspaces では、需要に応じてデータベースを簡単にスケールアップまたはスケールダウンできるため、アプリケーションのパフォーマンスを損なうことなくトラフィックの急増に対応できます。
+ **パフォーマンス** – Amazon Keyspaces では低レイテンシーでのデータアクセスが可能であるため、並外れた速度でデータをアプリケーションに取得して処理できます。分散型アーキテクチャにより、読み取りと書き込みの操作が複数のノードに分散され、高いリクエストレートでも 1 桁ミリ秒単位の応答時間を一貫して実現できます。
+ **フルマネージド** – Amazon Keyspaces は、 AWSが提供するフルマネージドサービスです。つまり、 は、プロビジョニング、設定、パッチ適用、バックアップ、スケーリングなど、データベース管理の運用面 AWS を処理します。これにより、企業はデータベースの管理タスクよりもアプリケーションの開発に集中できます。
+ **サーバーレスアーキテクチャ** – Amazon Keyspaces はサーバーレスです。前もってキャパシティをプロビジョニングしておく必要がなく、消費したキャパシティの分だけ料金を支払います。サーバーを管理する必要も、インスタンスを選択する必要もありません。このリクエストベースの課金モデルでは、使用したリソースに対してのみ支払いを行うことになり、キャパシティのプロビジョニングや監視の必要がないため、コスト効率が向上し、運用上のオーバーヘッドも最小限に抑えられます。
+ **NoSQL によるスキーマの柔軟性** – Amazon Keyspaces は NoSQL データモデルを採用しているため、柔軟なスキーマ設計が可能です。Amazon Keyspaces では、構造化データ、半構造化データ、非構造化データを保存でき、変化し続ける多様なデータ型の処理に最適です。また、Amazon Keyspaces は書き込み時にスキーマ検証を実行するため、データモデルを一元的に進化させることができます。この柔軟性により、開発サイクルが短縮され、変化するビジネス要件に容易に適応できます。
+ **高可用性と耐久性** – Amazon Keyspaces は、 内の複数の[アベイラビリティーゾーン](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)にデータをレプリケートし AWS リージョン、高可用性とデータ耐久性を確保します。レプリケーション、フェイルオーバー、リカバリが自動的に処理されるため、データ損失やサービス中断のリスクが最小限に抑えられます。Amazon Keyspaces の可用性 SLA は最大 99.999% です。耐障害性と低レイテンシーのローカル読み取りをさらに強化するために、Amazon Keyspaces は[マルチリージョンレプリケーション](multiRegion-replication.md)にも対応しています。
+ **セキュリティとコンプライアンス** – Amazon Keyspaces と AWS Identity and Access Management の統合によって、きめ細かいアクセスコントロールが実現します。保管中も転送中もデータを暗号化してセキュリティを強化します。Amazon Keyspaces は、HIPAA、PCI DSS、SOC などの特定のプログラムに対するセキュリティとコンプライアンスについて、第三者監査機関の評価を受けているため、規制要件を満たすことが可能です。詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) のコンプライアンス検証](Keyspaces-compliance.md)」を参照してください。
+ ** AWS エコシステムとの統合** – エコシステムの一部として AWS 、Amazon Keyspaces は AWS CloudFormation Amazon CloudWatch AWS のサービスや などの他の とシームレスに統合されます AWS CloudTrail。この統合により、サーバーレスアーキテクチャの構築、Infrastructure as Code の活用、リアルタイムのデータ主導型アプリケーションの作成が可能になります。詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) のモニタリング](monitoring-overview.md)」を参照してください。
**Topics**
+ [Apache Cassandra から Amazon Keyspaces への移行の計画を立てる](migrating-cassandra.md)
+ [Amazon Keyspaces へのデータの一括アップロードまたは移行に適したツールを選択する方法](migrating-tools.md)
# 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)
# Amazon Keyspaces へのデータの一括アップロードまたは移行に適したツールを選択する方法
このセクションでは、Amazon Keyspaces にデータを一括アップロードまたは移行するために使用できるさまざまなツールを確認し、ニーズに応じて適切なツールを選定する方法を学びます。さらに、このセクションでは、Amazon Keyspaces にデータをインポートする方法を示す、利用可能なstep-by-stepのチュートリアルの概要とユースケースについて説明します。
Apache Cassandra から Amazon Keyspaces にワークロードを移行するための戦略を確認するには、「[Apache Cassandra から Amazon Keyspaces への移行の計画を立てる](migrating-cassandra.md)」を参照してください。
+ **移行ツール**
+ Github で利用可能な [Amazon Keyspaces (Apache Cassandra 向け) の料金計算ツール](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra)を使用すると、既存の Apache Cassandra ワークロードに基づいて Amazon Keyspaces の月額コストを見積もることができます。Amazon Keyspaces の Cassandra nodetool ステータス出力と意図したサーバーレス設定からメトリクスを入力して、2 つのソリューション間の直接コストを比較します。この計算ツールは、既存の Cassandra デプロイと比較した Amazon Keyspaces の運用コストにのみ重点を置いていることに注意してください。インフラストラクチャのメンテナンス、運用オーバーヘッド、Cassandra のサポートコストなどの総所有コスト (TCO) 要因は含まれません。
+ **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 へのダウンタイムのない移行をサポートしています。
+ **CQLReplicator** – CQLReplicator はオープンソースのユーティリティで、[Github](https://github.com/aws-samples/cql-replicator) から入手できます。このユーティリティを利用して、Apache Cassandra から Amazon Keyspaces にほぼリアルタイムでデータを移行できます。
詳細については、「[CQLReplicator を使用してデータを移行する](migration-hybrid-cql-rep.md)」を参照してください。
+ Amazon Managed Streaming for Apache Kafka を使用して、デュアル書き込みによる[オンライン移行](migrating-online.md)プロセスを実装する方法の詳細については、「[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/)」を参照してください。
+ 大規模な移行については、抽出、変換、ロード (ETL) ツールの使用を検討してください。 AWS Glue を使用すると、データ変換移行を迅速かつ効果的に実行できます。詳細については、「[オフライン移行プロセス: Apache Cassandra から Amazon Keyspaces への移行](migrating-offline.md)」を参照してください。
+ Apache Cassandra Spark コネクタを使用して Amazon Keyspaces にデータを書き込む方法については、「[チュートリアル: Apache Spark と統合してデータをインポートまたはエクスポートする](spark-integrating.md)」を参照してください。
+ cqlsh `COPY FROM` コマンドを使用してデータを Amazon Keyspaces にロードすることから始めます。cqlsh は、Apache Cassandra に含まれており、小さなデータセットまたはテストデータのロードに最適です。手順については、「[チュートリアル: cqlsh を使用した Amazon Keyspaces へのデータのロード](bulk-upload.md)」を参照してください。
+ また、Apache Cassandra 用の DataStax Bulk Loader を使用すれば、`dsbulk` コマンドを使用して Amazon Keyspaces にデータをロードできます。DSBulk は、インポート機能が cqlsh よりも強力で、[GitHub リポジトリ](https://github.com/datastax/dsbulk)から入手できます。手順については、「[チュートリアル: DSBulk を使用した Amazon Keyspaces へのデータのロード](dsbulk-upload.md)」を参照してください。
Amazon Keyspaces へのデータアップロードに関する一般的な考慮事項
+ **データを小さな単位に分けてアップロードします。**
生データサイズの観点から、次の移行単位とその潜在的なフットプリントを考慮してください。1 つまたは複数のフェーズで少量ずつデータをアップロードすれば、移行を簡単に進めることができます。
+ **クラスター別** — すべての Cassandra データを一度に移行します。このアプローチはクラスターが小さければおそらく問題ありません。
+ **キースペース別またはテーブル別** - 移行をキースペースまたはテーブルのグループに分割します。このアプローチは、各ワークロードの要件に基づいてフェーズでデータを移行する場合に役立ちます。
+ **データ別** - データサイズを縮小するために、特定のユーザーまたは製品グループのデータを移行することを検討します。
+ **最初に優先的にアップロードするデータを処理のしやすさに基づいて決めます。**
特定の時間に変更されないデータ、夜間のバッチジョブのデータ、オフライン時間に使用されないデータ、内部アプリのデータなど、最初に簡単に移行できるデータがあるかどうかを検討します。
**Topics**
+ [チュートリアル: cqlsh を使用した Amazon Keyspaces へのデータのロード](bulk-upload.md)
+ [チュートリアル: DSBulk を使用した Amazon Keyspaces へのデータのロード](dsbulk-upload.md)
# チュートリアル: cqlsh を使用した Amazon Keyspaces へのデータのロード
このチュートリアルガイドでは、`cqlsh COPY FROM` コマンドを使用して Apache Cassandra から Amazon Keyspaces にデータを移行する手順を案内します。`cqlsh COPY FROM` コマンドは、学術的な目的やテスト用に小さなデータセットを Amazon Keyspaces に迅速かつ簡単にアップロードするのに便利です。本稼働ワークロードの移行方法の詳細については、「[オフライン移行プロセス: Apache Cassandra から Amazon Keyspaces への移行](migrating-offline.md)」を参照してください。このチュートリアルでは、次の手順を実行します。
前提条件 – 認証情報を使用して AWS アカウントを設定し、証明書の JKS トラストストアファイルを作成し、Amazon Keyspaces に接続する`cqlsh`ように を設定します。
1. **ソース CSV とターゲットテーブルの作成** – ソースデータとして CSV ファイルを準備し、Amazon Keyspaces でターゲットのキースペースとテーブルを作成します。
1. **データの準備** – CSV ファイル内のデータをランダム化して分析し、行サイズの平均値と最大値を求めます。
1. **スループットキャパシティの設定** – データサイズと必要なロード時間に基づいて必要な書き込みキャパシティユニット (WCU) を計算し、テーブルにプロビジョニングされるキャパシティを設定します。
1. **cqlsh パラメータの設定** – ワークロードを均等に分散させるために、`INGESTRATE`、`NUMPROCESSES`、`MAXBATCHSIZE`、`CHUNKSIZE` などの `cqlsh COPY FROM` パラメータの最適値を求めます。
1. **`cqlsh COPY FROM` コマンドの実行** – `cqlsh COPY FROM` コマンドを実行して、CSV ファイルから Amazon Keyspaces テーブルにデータをアップロードし、進行状況を監視します。
トラブルシューティング – 無効なリクエスト、パーサーエラー、キャパシティエラー、cqlsh エラーなど、データアップロードの処理中によく起きる問題を解決します。
**Topics**
+ [前提条件: `cqlsh COPY FROM` を使用してデータをアップロードする前に完了する手順](bulk-upload-prequs.md)
+ [ステップ 1: データアップロード用のソース CSV ファイルとターゲットテーブルを作成する](bulk-upload-source.md)
+ [ステップ 2: データを正常にアップロードできるようにソースデータを準備する](bulk-upload-prepare-data.md)
+ [ステップ 3: テーブルのスループットキャパシティを設定する](bulk-upload-capacity.md)
+ [ステップ 4: `cqlsh COPY FROM` を設定する](bulk-upload-config.md)
+ [ステップ 5: `cqlsh COPY FROM` コマンドを実行して CSV ファイルからターゲットテーブルにデータをアップロードする](bulk-upload-run.md)
+ [トラブルシューティング](bulk-upload-troubleshooting.md)
# 前提条件: `cqlsh COPY FROM` を使用してデータをアップロードする前に完了する手順
このチュートリアルを開始する前に、次のタスクを完了しておく必要があります。
1. まだサインアップしていない場合は、「」の手順に従って にサインアップ AWS アカウント します[セットアップ AWS Identity and Access Management](accessing.md#SettingUp.IAM)。
1. [Amazon Keyspaces にプログラムによってアクセスするためのサービス固有の認証情報を作成する](programmatic.credentials.ssc.md) のステップに従って、サービス固有の認証情報を作成します。
1. Cassandra クエリ言語シェル (cqlsh) 接続をセットアップし、[`cqlsh` を使用した Amazon Keyspaces への接続](programmatic.cqlsh.md) のステップに従って Amazon Keyspaces に接続できることを確認します。
# ステップ 1: データアップロード用のソース CSV ファイルとターゲットテーブルを作成する
このチュートリアルでは、`keyspaces_sample_table.csv` という名前のカンマ区切り値 (CSV) ファイルをデータ移行用のソースファイルとして使用します。提供されたサンプルファイルには、`book_awards` という名前のテーブルに関する数行のデータが含まれています。
1. ソースファイルを作成します。次のオプションのいずれかを選択します。
+ 次のアーカイブファイル [samplemigration.zip](samples/samplemigration.zip) に含まれているサンプル CSV ファイル (`keyspaces_sample_table.csv`) をダウンロードします。アーカイブを解凍し、`keyspaces_sample_table.csv` へのパスをメモしておきます。
+ Apache Cassandra データベースに保存されている独自のデータを CSV ファイルに入力するには、次の例に示すように、`cqlsh` `COPY TO` ステートメントを使用してソース CSV ファイルに入力します。
```
cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true";
```
作成する CSV ファイルが以下の要件を満たしていることを確認してください。
+ 最初の行に列名が含まれています。
+ ソース CSV ファイルの列名がターゲットテーブルの列名と一致してます。
+ データがカンマで区切られてます。
+ すべてのデータ値が有効な Amazon Keyspaces データ型です。「[データ型](cql.elements.md#cql.data-types)」を参照してください。
1. Amazon Keyspaces でターゲットのキースペースとテーブルを作成します。
1. `cqlsh` を使用して Amazon Keyspaces に接続し、次の例のサービスエンドポイント、ユーザー名、およびパスワードをそれぞれ独自の値に置き換えます。
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. 次の例に示すように、`catalog` という名前の新しいキースペースを作成します。
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. 新しいキースペースが利用可能になったら、次のコードを使用してターゲットテーブル `book_awards` を作成します。
```
CREATE TABLE "catalog.book_awards" (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Apache Cassandra が元のデータソースである場合、ヘッダーが一致している Amazon Keyspaces ターゲットテーブルを作成する簡単な方法は、次のステートメントに示すように、ソーステーブルから `CREATE TABLE` ステートメントを生成する方法です。
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
次に、Amazon Keyspaces で、列名とデータ型が Cassandra ソーステーブルの説明と一致しているターゲットテーブルを作成します。
# ステップ 2: データを正常にアップロードできるようにソースデータを準備する
効率的な転送のためのソースデータの準備には、2 つのステップがあります。まず、データをランダム化します。第 2 のステップでは、データが正常にアップロードされるように、データを分析して、適切な `cqlsh` パラメータ値と必要なテーブル設定を判断します。
**データをランダム化する**
`cqlsh COPY FROM` コマンドは、CSV ファイルに表示される順序と同じ順序でデータの読み取りと書き込みを行います。`cqlsh COPY TO` コマンドを使用してソースファイルを作成すると、データはキーソートされた順序で CSV に書き込まれます。内部的には、Amazon Keyspaces でパーティションキーを使用してデータが分割されます。Amazon Keyspaces には、同一のパーティションキーに対するロードバランスリクエストに役立つロジックが内蔵されていますが、順序をランダム化すると、データのロードが高速かつ効率的になります。これは、Amazon Keyspaces で異なるパーティションにデータが書き込まれたときに発生する組み込みのロードバランシングを利用できるためです。
パーティション間で書き込みを均等に分散させるには、ソースファイル内のデータをランダム化する必要があります。アプリケーションを書き込んでこれを実行することができます。また、[Shuf](https://en.wikipedia.org/wiki/Shuf) などのオープンソースツールを使用することもできます。Shuf は、Linux ディストリビューション、macOS (コアユーティリティを [homebrew](https://brew.sh) にインストールする)、Windows (Windows Subsystem for Linux (WSL) を使用する) で無料で使用できます。このステップで列名を含むヘッダー行がシャッフルされないようにするには、追加のステップが 1 つ必要です。
ヘッダーを維持した状態でソースファイルをランダム化するには、次のコードを入力します。
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf により、`keyspace.table.csv` という新しい CSV ファイルにデータが書き換えられます。これで、不要になった `keyspaces_sample_table.csv` ファイルを削除できます。
**データを分析する**
データを分析して、平均行サイズと最大行サイズを決定します。
この作業を行う理由は次のとおりです。
+ 転送されるデータの総量を見積もる場合に、平均行サイズが役立ちます。
+ データのアップロードに必要な書き込みキャパシティをプロビジョニングする際には、平均行サイズが必要になります。
+ 各行のサイズが 1 MB 未満 (Amazon Keyspaces の行サイズの上限) であることを確認できます。
**注記**
このクォータは、パーティションサイズではなく、行サイズを指します。Apache Cassandra のパーティションとは異なり、Amazon Keyspaces のパーティションのサイズは事実上無制限です。パーティションキーとクラスタリング列には、メタデータ用の追加のストレージが必要です。このストレージは行の raw サイズに追加する必要があります。詳細については、「[Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)」を参照してください。
次のコードは、[AWK](https://en.wikipedia.org/wiki/AWK) を使用して CSV ファイルを分析し、行の平均サイズと最大サイズを出力します。
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
このコードを実行すると、次の出力が表示されます。
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
このチュートリアルの次のステップの平均行サイズを使用して、テーブルの書き込みキャパシティをプロビジョニングします。
# ステップ 3: テーブルのスループットキャパシティを設定する
このチュートリアルでは、設定された時間範囲内でデータがロードされるように cqlsh を調整する方法を示します。事前に実行する読み取りと書き込みの数がわかっているので、プロビジョンドキャパシティモードを使用します。データ転送が完了したら、アプリケーションのトラフィックパターンに合わせてテーブルのキャパシティモードを設定する必要があります。キャパシティ管理の詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) でのサーバーレスリソースの管理](serverless_resource_management.md)」を参照してください。
プロビジョンドキャパシティモードでは、事前にテーブルにプロビジョニングする読み取りキャパシティと書き込みキャパシティの量を指定します。書き込みキャパシティは時間ユニットで課金され、書き込みキャパシティユニット (WCU) で計測されます。各 WCU は、1 秒あたり 1 KB のデータの書き込みをサポートするのに十分な書き込みキャパシティです。データをロードする際に、書き込みレートが、ターゲットテーブルで設定した WCU の上限 (パラメータ: `write_capacity_units`) を超えないようにしてください。
デフォルトでは、1 つのテーブルに最大 40,000 の WCU を、アカウント内のすべてのテーブルに最大 80,000 の WCU をプロビジョニングすることができます。追加のキャパシティが必要な場合は、[Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas) コンソールでクォータの増加をリクエストできます。クォータの詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) のクォータ](quotas.md)」を参照してください。
**挿入に必要な WCU の平均数を計算する**
1 秒あたり 1 KB のデータを挿入するには、1 WCU が必要です。CSV ファイルに 360,000 の行があり、1 時間ですべてのデータをロードする場合は、1 秒あたり 100 行 (360,000 行 / 60 分 / 60 秒 = 100 行/秒) を書き込む必要があります。各行に最大 1 KB のデータがある場合、1 秒あたり 100 行を挿入するには、100 WCU をテーブルにプロビジョニングする必要があります。各行に 1.5 KB のデータがある場合、1 秒あたり 1 行を挿入するには 2 WCU が必要です。したがって、1 秒あたり 100 行を挿入するには、200 WCU をプロビジョニングする必要があります。
1 秒あたり 1 行の挿入が必要な WCU 数を調べるには、平均行サイズ (バイト) を 1024 で割り、端数を切り上げて最も近い整数にします。
例えば、平均行サイズが 3000 バイトの場合、1 秒あたり 1 行を挿入するには 3 WCU が必要です。
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**データのロード時間とキャパシティを計算する**
これで、CSV ファイルの平均サイズと平均行数が分かったので、特定の時間内にデータをロードする場合に必要な WCU 数と、さまざまな WCU 設定を使用して CSV ファイルにすべてのデータをロードするのにかかるおおよその時間を計算できます。
例えば、ファイルの各行が 1 KB で、CSV ファイルに 1,000,000 行がある場合、1 時間でデータをロードするには、その時間に少なくとも 278 WCU をテーブルにプロビジョニングする必要があります。
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**プロビジョンドキャパシティを設定する**
テーブルの書き込みキャパシティは、そのテーブルの作成時、または `ALTER TABLE` CQL コマンドを使用して、設定することができます。以下は、`ALTER TABLE` CQL ステートメントを使用してテーブルのプロビジョンキャパシティ設定に変更を加えるための構文です。
```
ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
完全な言語リファレンスについては、「[ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)」を参照してください。
# ステップ 4: `cqlsh COPY FROM` を設定する
このセクションでは、`cqlsh COPY FROM` のパラメータ値を決定する方法について説明します。`cqlsh COPY FROM` コマンドは、前の手順で準備した CSV ファイルを読み取り、CQL を使用して Amazon Keyspaces にデータを挿入します。このコマンドにより、行の分割と一連のワーカー間での `INSERT` オペレーションの配分が行われます。各ワーカーは Amazon Keyspaces との接続を確立し、このチャンネルに沿って `INSERT` リクエストを送信します。
`cqlsh COPY` コマンドには、ワーカー間でワークを均等に分配するための内部ロジックがありません。ただし、ワークが均等に分配されるように手動で設定することはできます。まず、次の主要な cqlsh パラメータを確認します。
+ **DELIMITER** — カンマ以外の区切り文字を使用した場合はこのパラメータを設定できます。デフォルトはカンマです。
+ **INGESTRATE** — `cqlsh COPY FROM` により処理が試行される 1 秒あたりのターゲット行数。設定しない場合のデフォルト値は 100,000 です。
+ **NUMPROCESSES** — `COPY FROM` タスクに対して cqlsh により作成される子ワーカープロセスの数。この設定の最大値は 16 で、デフォルトは `num_cores - 1` です。`num_cores` は cqlsh が実行されているホストの処理コア数です。
+ **MAXBATCHSIZE** - バッチサイズにより、1 つのバッチで挿入先テーブルに挿入される最大行数が決まります。設定されていない場合、cqlsh により挿入行数が 20 行のバッチが使用されます。
+ **CHUNKSIZE** — 子ワーカーに渡すワーク単位のサイズ。デフォルトでは、5,000 に設定されます。
+ **MAXATTEMPTS** — 失敗したワーカーチャンクの再試行の最高回数。最高試行回数に達すると、失敗したレコードが新しい CSV ファイルに書き込まれ、後ほど、失敗を調査した上で再実行できます。
ターゲット送信先テーブルにプロビジョニングした WCU の数に基づいて `INGESTRATE` を設定します。`cqlsh COPY FROM` コマンドの `INGESTRATE` は制限ではなくターゲット平均です。これは、設定した数を大きく上回る可能性がある (多くの場合そうなる) ことを意味します。このような超過を許可し、データロードリクエストを処理できるだけの十分なキャパシティを確保するには、`INGESTRATE` をテーブルの書き込みキャパシティの 90% に設定します。
```
INGESTRATE = WCUs * .90
```
次に、`NUMPROCESSES` パラメータを、システムのコア数より 1 少ない値に設定します。システムのコア数を調べるには、次のコードを実行します。
```
python -c "import multiprocessing; print(multiprocessing.cpu_count())"
```
このチュートリアルでは、以下の値を使用します。
```
NUMPROCESSES = 4
```
各プロセスでワーカーが作成され、各ワーカーで Amazon Keyspaces への接続が確立されます。Amazon Keyspaces は、接続ごとに 1 秒あたり最大で 3,000 件の CQL リクエストに対応できます。つまり、各ワーカーの 1 秒あたりのリクエスト処理数が 3,000 件未満であるか確認する必要があるということです。
`INGESTRATE` と同様に、ワーカーは設定した数値を大幅に上回ることが多く、クロックの秒数に制限されません。したがって、大幅な超過を考慮しておくために、各ワーカーの 1 秒あたりの目標リクエスト処理数が 2,500 件になるように cqlsh パラメータを設定します。ワーカーに分配されるワーク量を計算するには、次のガイドラインを使用します。
+ `INGESTRATE` を `NUMPROCESSES` で割ります。
+ `INGESTRATE` / `NUMPROCESSES` > 2,500 になった場合は、この式が真になるように `INGESTRATE` を下げます。
```
INGESTRATE / NUMPROCESSES <= 2,500
```
サンプルデータのアップロードを最適化するための設定を行う前に、`cqlsh` のデフォルト設定を再確認し、その使用がデータのアップロードプロセスにどのように影響するのか見てみましょう。`cqlsh COPY FROM` では `CHUNKSIZE` を使用して膨大なワークが作成されて (`INSERT` ステートメント) ワーカーに分配されるので、ワークは自動的には均等に分配されません。`INGESTRATE` 設定によっては、アイドル状態になるワーカーもあります。
ワーカー間でワークを均等に分配し、各ワーカーに対して 1 秒あたりの最適なリクエスト数を 2,500 件で維持するには、入力パラメータを変更して `CHUNKSIZE`、`MAXBATCHSIZE`、`INGESTRATE` に設定する必要があります。データロード中のネットワークトラフィックの使用率を最適化するには、`MAXBATCHSIZE` の値として最大値の 30 に近い値を選択します。`CHUNKSIZE` を 100 に、`MAXBATCHSIZE` を 25 に変更すると、10,000 行が 4 つのワーカーに均等に分配されます (10,000 / 2500 = 4)、
次のコード例はこのことを示しています。
```
INGESTRATE = 10,000
NUMPROCESSES = 4
CHUNKSIZE = 100
MAXBATCHSIZE. = 25
Work Distribution:
Connection 1 / Worker 1 : 2,500 Requests per second
Connection 2 / Worker 2 : 2,500 Requests per second
Connection 3 / Worker 3 : 2,500 Requests per second
Connection 4 / Worker 4 : 2,500 Requests per second
```
要約するために、`cqlsh COPY FROM` パラメータの設定時に次の数式を使用します。
+ **INGESTRATE** = write\$1capacity\$1units \$1 .90
+ **NUMPROCESSES** = num\$1cores -1 (デフォルト)
+ **INGESTRATE / NUMPROCESSES** = 2,500 (これは true ステートメントでなければなりません。)
+ **MAXBATCHSIZE** = 30 (デフォルトは 20。Amazon Keyspaces では最大で 30 のバッチが受け入れられます。)
+ **CHUNKSIZE** = (INGESTRATE / NUMPROCESSES) / MAXBATCHSIZE
これで `NUMPROCESSES`、`INGESTRATE`、`CHUNKSIZE` の計算が完了し、データをロードする準備が整いました。
# ステップ 5: `cqlsh COPY FROM` コマンドを実行して CSV ファイルからターゲットテーブルにデータをアップロードする
`cqlsh COPY FROM` コマンドを使用して、以下のステップを実行します。
1. cqlsh を使用して Amazon Keyspaces に接続します。
1. 次のコードがあるキースペースを選択します。
```
USE catalog;
```
1. 書き込み整合性を `LOCAL_QUORUM` に設定します。データの耐久性を確保するため、Amazon Keyspaces では他の書き込み整合性設定は使用できません。以下のコードを参照してください。
```
CONSISTENCY LOCAL_QUORUM;
```
1. 次のコード例を使用して `cqlsh COPY FROM` 構文を作成します。
```
COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true
AND INGESTRATE=calculated ingestrate
AND NUMPROCESSES=calculated numprocess
AND MAXBATCHSIZE=20
AND CHUNKSIZE=calculated chunksize;
```
1. 前のステップで準備したステートメントを実行します。cqlsh は、構成したすべての設定をエコーバックします。
1. 設定が入力と一致していることを確認します。次の例を参照してください。
```
Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'}
Using 15 child processes
```
1. 次の例に示すように、転送された行数と現在の平均レートを確認します。
```
Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s
```
1. cqlsh によるデータのアップロードが完了したら、次の例に示すように、データロード統計のサマリー (読み取られたファイルの数、ランタイム、スキップされた行数) を確認します。
```
15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped).
```
このチュートリアルの最後のステップでは、データを Amazon Keyspaces にアップロードしました。
**重要**
データを転送したので、アプリケーションの通常のトラフィックパターンに合わせてターゲットテーブルのキャパシティモード設定を調整します。プロビジョンドキャパシティは、変更するまでは、時間ユニットで課金されます。
# トラブルシューティング
データのアップロードが完了したら、行がスキップされたかどうかを確認します。これを行うには、ソース CSV ファイルのソースディレクトリに移動し、次の名前のファイルを検索します。
```
import_yourcsvfilename.err.timestamp.csv
```
cqlsh により、この名前のファイルに、スキップされたデータ行が書き込まれます。ファイルがソースディレクトリに存在し、その中にデータが含まれている場合、これらの行は Amazon Keyspaces にアップロードされませんでした。これらの行のアップロードを再試行するには、まずアップロード中に発生したエラーを確認し、それに応じてデータを調整します。これらの行のアップロードを再試行するために、プロセスを再実行します。
**一般的なエラー**
行がロードされない最も一般的な理由は、容量エラーとパーサーエラーです。
**Amazon Keyspaces にデータをアップロードする際の不正なリクエストエラー**
次の例では、ソーステーブルにカウンター列が含まれているため、`COPY` cqlshコマンドからのバッチ呼び出しがログに記録されます。Amazon Keyspaces では、ログに記録されたバッチコールはサポートされていません。
```
Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25
```
このエラーを解決するには、DSBulk を使用してデータを移行します。詳細については、「[チュートリアル: DSBulk を使用した Amazon Keyspaces へのデータのロード](dsbulk-upload.md)」を参照してください。
**Amazon Keyspaces にデータをアップロードする際のパーサーエラー**
次の例では、`ParseError` が原因で行がスキップされます。
```
Failed to import 1 rows: ParseError - Invalid ... –
```
このエラーを解決するには、インポートするデータが Amazon Keyspaces のテーブルスキーマと一致していることを確認する必要があります。インポートファイルで解析エラーが発生していないか確認してください。`INSERT` ステートメントを使用してエラーを切り離すことで、1 行のデータの使用を試すことができます。
**Amazon Keyspaces にデータをアップロードする際の容量エラー**
```
Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses]
message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency':
'LOCAL_QUORUM'}, will retry later, attempt 1 of 100
```
Amazon Keyspaces では、スループットキャパシティ不足により書き込みリクエストが失敗した場合に、`ReadTimeout` 例外と `WriteTimeout` 例外を使用してその失敗が示されます。キャパシティ不足の例外を診断するために、Amazon Keyspaces は Amazon CloudWatch で `WriteThrottleEvents` と `ReadThrottledEvents` のメトリクスを公開しています。詳細については、「[Amazon CloudWatch による Amazon Keyspaces のモニタリング](monitoring-cloudwatch.md)」を参照してください。
**Amazon Keyspaces にデータをアップロードする際の cqlsh エラー**
cqlsh エラーのトラブルシューティングに役立てるために、失敗したコマンドに `--debug` フラグを付けて再実行します。
互換性のないバージョンの cqlsh を使用すると、次のエラーが表示されます。
```
AttributeError: 'NoneType' object has no attribute 'is_up'
Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts
```
次のコマンドを実行して、正しいバージョンの cqlsh がインストールされていることを確認します。
```
cqlsh --version
```
出力に関して次のような内容が表示されます。
```
cqlsh 5.0.1
```
Windows を使用している場合は、`cqlsh` のすべてのインスタンスを `cqlsh.bat` に置き換えます。例えば、Windows で cqlsh のバージョンを確認するには、次のコマンドを実行します。
```
cqlsh.bat --version
```
サーバーから cqlsh クライアントに何らかの種類のエラーが 3 回連続で送信されると、Amazon Keyspaces への接続が失敗します。cqlsh クライアントで処理が失敗すると、次のメッセージが表示されます。
```
Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100
```
このエラーを解決するには、インポートするデータが Amazon Keyspaces のテーブルスキーマと一致していることを確認する必要があります。インポートファイルで解析エラーが発生していないか確認してください。INSERT ステートメントを使用してエラーを切り離すことで、1 行のデータの使用を試すことができます。
クライアントにより接続の再確立が自動的に試行されます。
# チュートリアル: DSBulk を使用した Amazon Keyspaces へのデータのロード
このステップバイステップのチュートリアルでは、[GitHub](https://github.com/datastax/dsbulk.git) で入手できる DataStax Bulk Loader (DSBulk) を使用して、Apache Cassandra から Amazon Keyspaces にデータを移行する手順が説明されています。DSBulk は、学術用途やテスト目的で Amazon Keyspaces にデータセットをアップロードする場合に便利です。本稼働ワークロードの移行方法の詳細については、「[オフライン移行プロセス: Apache Cassandra から Amazon Keyspaces への移行](migrating-offline.md)」を参照してください。このチュートリアルでは、次の手順を実行します。
前提条件 – 認証情報を使用して AWS アカウントを設定し、証明書の JKS トラストストアファイルを作成し、 を設定し`cqlsh`、DSBulk をダウンロードしてインストールし、 `application.conf` ファイルを設定します。
1. **ソース CSV とターゲットテーブルの作成** – ソースデータとして CSV ファイルを準備し、Amazon Keyspaces でターゲットのキースペースとテーブルを作成します。
1. **データの準備** – CSV ファイル内のデータをランダム化して分析し、行サイズの平均値と最大値を求めます。
1. **スループットキャパシティの設定** – データサイズと必要なロード時間に基づいて必要な書き込みキャパシティユニット (WCU) を計算し、テーブルにプロビジョニングされるキャパシティを設定します。
1. **DSBulk 設定の構成** – 認証、SSL/TLS、整合性レベル、接続プールサイズなどを設定した、DSBulk 設定ファイルを作成します。
1. **DSBulk ロードコマンドの実行** – DSBulk ロードコマンドを実行して、CSV ファイルから Amazon Keyspaces テーブルにデータをアップロードし、進行状況を監視します。
**Topics**
+ [前提条件: DSBulk でデータをアップロードする前に完了する手順](dsbulk-upload-prequs.md)
+ [ステップ 1: DSBulk を使用してデータアップロード用のソース CSV ファイルとターゲットテーブルを作成する](dsbulk-upload-source.md)
+ [ステップ 2: DSBulk を使用してアップロード対象のデータを準備する](dsbulk-upload-prepare-data.md)
+ [ステップ 3: ターゲットテーブルのスループットキャパシティを設定する](dsbulk-upload-capacity.md)
+ [ステップ 4: CSV ファイルからターゲットテーブルにデータをアップロードするように `DSBulk` を設定する](dsbulk-upload-config.md)
+ [ステップ 5: DSBulk `load` コマンドを実行して CSV ファイルからターゲットテーブルにデータをアップロードする](dsbulk-upload-run.md)
# 前提条件: DSBulk でデータをアップロードする前に完了する手順
このチュートリアルを開始する前に、次のタスクを完了しておく必要があります。
1. まだサインアップしていない場合は、「」の手順に従って AWS アカウントにサインアップします[セットアップ AWS Identity and Access Management](accessing.md#SettingUp.IAM)。
1. [Amazon Keyspaces の AWS 認証情報の作成と設定](access.credentials.md) のステップに従って認証情報を作成します。
1. JKS 信頼ストアファイルを作成します。
1. 次のデジタル証明書をダウンロードし、ローカルまたはホームディレクトリにファイルを保存します。
1. AmazonRootCA1
1. AmazonRootCA2
1. AmazonRootCA3
1. AmazonRootCA4
1. Starfield クラス 2 ルート (オプション – 下位互換性用)
証明書をダウンロードするには、次のコマンドを使用できます。
```
curl -O https://www.amazontrust.com/repository/AmazonRootCA1.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA2.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA3.pem
curl -O https://www.amazontrust.com/repository/AmazonRootCA4.pem
curl -O https://certs.secureserver.net/repository/sf-class2-root.crt
```
**注記**
Amazon Keyspaces は以前、Starfield Class 2 CA に固定された TLS 証明書を使用していました。 AWS は、Amazon Trust Services (Amazon ルート CAs で発行された証明書 AWS リージョン にすべて移行しています。この移行中に、Amazon ルート CAs 1～4 と Starfield ルートの両方を信頼するようにクライアントを設定し、すべてのリージョンで互換性を確保します。
1. デジタル証明書を trustStore ファイルに変換し、キーストアに追加します。
```
openssl x509 -outform der -in AmazonRootCA1.pem -out temp_file.der
keytool -import -alias amazon-root-ca-1 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA2.pem -out temp_file.der
keytool -import -alias amazon-root-ca-2 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA3.pem -out temp_file.der
keytool -import -alias amazon-root-ca-3 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in AmazonRootCA4.pem -out temp_file.der
keytool -import -alias amazon-root-ca-4 -keystore cassandra_truststore.jks -file temp_file.der
openssl x509 -outform der -in sf-class2-root.crt -out temp_file.der
keytool -import -alias cassandra -keystore cassandra_truststore.jks -file temp_file.der
```
最後のステップでは、キーストアのパスワードを作成し、各証明書を信頼する必要があります。対話型コマンドは次のようになります。
```
Enter keystore password:
Re-enter new password:
Owner: CN=Amazon Root CA 1, O=Amazon, C=US
Issuer: CN=Amazon Root CA 1, O=Amazon, C=US
Serial number: 66c9fcf99bf8c0a39e2f0788a43e696365bca
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sun Jan 17 00:00:00 UTC 2038
Certificate fingerprints:
SHA1: 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16
SHA256: 8E:CD:E6:88:4F:3D:87:B1:12:5B:A3:1A:C3:FC:B1:3D:70:16:DE:7F:57:CC:90:4F:E1:CB:97:C6:AE:98:19:6E
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 84 18 CC 85 34 EC BC 0C 94 94 2E 08 59 9C C7 B2 ....4.......Y...
0010: 10 4E 0A 08 .N..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 2, O=Amazon, C=US
Issuer: CN=Amazon Root CA 2, O=Amazon, C=US
Serial number: 66c9fd29635869f0a0fe58678f85b26bb8a37
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A
SHA256: 1B:A5:B2:AA:8C:65:40:1A:82:96:01:18:F8:0B:EC:4F:62:30:4D:83:CE:C4:71:3A:19:C3:9C:01:1E:A4:6D:B4
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: B0 0C F0 4C 30 F4 05 58 02 48 FD 33 E5 52 AF 4B ...L0..X.H.3.R.K
0010: 84 E3 66 52 ..fR
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 3, O=Amazon, C=US
Issuer: CN=Amazon Root CA 3, O=Amazon, C=US
Serial number: 66c9fd5749736663f3b0b9ad9e89e7603f24a
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E
SHA256: 18:CE:6C:FE:7B:F1:4E:60:B2:E3:47:B8:DF:E8:68:CB:31:D0:2E:BB:3A:DA:27:15:69:F5:03:43:B4:6D:B3:A4
Signature algorithm name: SHA256withECDSA
Subject Public Key Algorithm: 256-bit EC (secp256r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: AB B6 DB D7 06 9E 37 AC 30 86 07 91 70 C7 9C C4 ......7.0...p...
0010: 19 B1 78 C0 ..x.
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: CN=Amazon Root CA 4, O=Amazon, C=US
Issuer: CN=Amazon Root CA 4, O=Amazon, C=US
Serial number: 66c9fd7c1bb104c2943e5717b7b2cc81ac10e
Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040
Certificate fingerprints:
SHA1: F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE
SHA256: E3:5D:28:41:9E:D0:20:25:CF:A6:90:38:CD:62:39:62:45:8D:A5:C6:95:FB:DE:A3:C2:2B:0B:FB:25:89:70:92
Signature algorithm name: SHA384withECDSA
Subject Public Key Algorithm: 384-bit EC (secp384r1) key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: D3 EC C7 3A 65 6E CC E1 DA 76 9A 56 FB 9C F3 86 ...:en...v.V....
0010: 6D 57 E5 81 mW..
]
]
Trust this certificate? [no]: yes
Certificate was added to keystore
Enter keystore password:
Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US
Serial number: 0
Valid from: Tue Jun 29 17:39:16 UTC 2004 until: Thu Jun 29 17:39:16 UTC 2034
Certificate fingerprints:
SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A
SHA256: 14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58
Signature algorithm name: SHA1withRSA (weak)
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
[OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US]
SerialNumber: [ 00]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U.....
0010: 0E A9 88 E7 ....
]
]
Warning:
The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
Trust this certificate? [no]: yes
Certificate was added to keystore
```
1. Cassandra クエリ言語シェル (cqlsh) 接続をセットアップし、[`cqlsh` を使用した Amazon Keyspaces への接続](programmatic.cqlsh.md) のステップに従って Amazon Keyspaces に接続できることを確認します。
1. DSBulk をダウンロードしてインストールします。
**注記**
このチュートリアルで示されているバージョンは、利用可能な最新バージョンではない可能性があります。DSBulk をダウンロードする前に、[DataStax Bulk Loader のダウンロードページで](https://downloads.datastax.com/#bulk-loader)最新バージョンを確認し、それに応じて次のコマンドのバージョン番号を更新します。
1. DSBulk をダウンロードするには、次のコードを使用します。
```
curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz
```
1. 次に、tar ファイルを解凍し、以下の例に示されているように、DSBulk を `PATH` に追加します。
```
tar -zxvf dsbulk-1.8.0.tar.gz
# add the DSBulk directory to the path
export PATH=$PATH:./dsbulk-1.8.0/bin
```
1. DSBulk により使用される設定を保存するための `application.conf` ファイルを作成します。次の例を `./dsbulk_keyspaces.conf` として保存できます。ローカルノード上にいない場合は、`localhost` を、ローカルの Cassandra クラスターのコンタクトポイント (DNS 名や IP アドレスなど) に置き換えます。ファイル名とパスは、後で `dsbulk load` コマンドで指定する必要があるためメモしておいてください。
```
datastax-java-driver {
basic.contact-points = [ "localhost"]
advanced.auth-provider {
class = software.aws.mcs.auth.SigV4AuthProvider
aws-region = us-east-1
}
}
```
1. SigV4 サポートを有効にするには、次の例に示すように、[GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/) からシェード `jar` ファイルをダウンロードし、DSBulk `lib` フォルダに配置します。
```
curl -O -L https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/download/4.0.6-shaded-v2/aws-sigv4-auth-cassandra-java-driver-plugin-4.0.6-shaded.jar
```
# ステップ 1: DSBulk を使用してデータアップロード用のソース CSV ファイルとターゲットテーブルを作成する
このチュートリアルでは、`keyspaces_sample_table.csv` という名前のカンマ区切り値 (CSV) ファイルをデータ移行用のソースファイルとして使用します。提供されたサンプルファイルには、`book_awards` という名前のテーブルに関する数行のデータが含まれています。
1. ソースファイルを作成します。次のオプションのいずれかを選択します。
+ 次のアーカイブファイル [samplemigration.zip](samples/samplemigration.zip) に含まれているサンプル CSV ファイル (`keyspaces_sample_table.csv`) をダウンロードします。アーカイブを解凍し、`keyspaces_sample_table.csv` へのパスをメモしておきます。
+ Apache Cassandra データベースに保存されている独自のデータを CSV ファイルに入力するには、次の例に示すように、`dsbulk unload` を使用してソース CSV ファイルに入力します。
```
dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv
```
作成する CSV ファイルが以下の要件を満たしていることを確認してください。
+ 最初の行に列名が含まれています。
+ ソース CSV ファイルの列名がターゲットテーブルの列名と一致してます。
+ データがカンマで区切られてます。
+ すべてのデータ値が有効な Amazon Keyspaces データ型です。「[データ型](cql.elements.md#cql.data-types)」を参照してください。
1. Amazon Keyspaces でターゲットのキースペースとテーブルを作成します。
1. `cqlsh` を使用して Amazon Keyspaces に接続し、次の例のサービスエンドポイント、ユーザー名、およびパスワードをそれぞれ独自の値に置き換えます。
```
cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl
```
1. 次の例に示すように、`catalog` という名前の新しいキースペースを作成します。
```
CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'};
```
1. 新しいキースペースが利用可能な状態になったら、次のコードを使用してターゲットテーブル `book_awards` を作成します。非同期的なリソース作成と、リソースが利用可能かどうかを確認する方法については、「[Amazon Keyspaces でキースペースの作成ステータスを確認する](keyspaces-create.md)」を参照してください。
```
CREATE TABLE catalog.book_awards (
year int,
award text,
rank int,
category text,
book_title text,
author text,
publisher text,
PRIMARY KEY ((year, award), category, rank)
);
```
Apache Cassandra が元のデータソースである場合、ヘッダーが一致している Amazon Keyspaces ターゲットテーブルを作成する簡単な方法は、次のステートメントに示すように、ソーステーブルから `CREATE TABLE` ステートメントを生成する方法です。
```
cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;"
```
次に、Amazon Keyspaces で、列名とデータ型が Cassandra ソーステーブルの説明と一致しているターゲットテーブルを作成します。
# ステップ 2: DSBulk を使用してアップロード対象のデータを準備する
効率的な転送のためのソースデータの準備には、2 つのステップがあります。まず、データをランダム化します。2 番目のステップでは、データを分析して、適切な `dsbulk` パラメータ値と必要なテーブル設定を明確にします。
**データをランダム化する**
`dsbulk` コマンドは、CSV ファイルに表示される順序と同じ順序でデータの読み取りと書き込みを行います。`dsbulk` コマンドを使用してソースファイルを作成すると、データはキーソートされた順序で CSV に書き込まれます。内部的には、Amazon Keyspaces でパーティションキーを使用してデータが分割されます。Amazon Keyspaces には、同一のパーティションキーに対するロードバランスリクエストに役立つロジックが内蔵されていますが、順序をランダム化すると、データのロードが高速かつ効率的になります。これは、Amazon Keyspaces で異なるパーティションにデータが書き込まれたときに発生する組み込みのロードバランシングを利用できるためです。
パーティション間で書き込みを均等に分散させるには、ソースファイル内のデータをランダム化する必要があります。アプリケーションを書き込んでこれを実行することができます。また、[Shuf](https://en.wikipedia.org/wiki/Shuf) などのオープンソースツールを使用することもできます。Shuf は、Linux ディストリビューション、macOS (コアユーティリティを [homebrew](https://brew.sh) にインストールする)、Windows (Windows Subsystem for Linux (WSL) を使用する) で無料で使用できます。このステップで列名を含むヘッダー行がシャッフルされないようにするには、追加のステップが 1 つ必要です。
ヘッダーを維持した状態でソースファイルをランダム化するには、次のコードを入力します。
```
tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv
```
Shuf により、`keyspace.table.csv` という新しい CSV ファイルにデータが書き換えられます。これで、不要になった `keyspaces_sample_table.csv` ファイルを削除できます。
**データを分析する**
データを分析して、平均行サイズと最大行サイズを決定します。
この作業を行う理由は次のとおりです。
+ 転送されるデータの総量を見積もる場合に、平均行サイズが役立ちます。
+ データのアップロードに必要な書き込みキャパシティをプロビジョニングする際には、平均行サイズが必要になります。
+ 各行のサイズが 1 MB 未満 (Amazon Keyspaces の行サイズの上限) であることを確認できます。
**注記**
このクォータは、パーティションサイズではなく、行サイズを指します。Apache Cassandra のパーティションとは異なり、Amazon Keyspaces のパーティションのサイズは事実上無制限です。パーティションキーとクラスタリング列には、メタデータ用の追加のストレージが必要です。このストレージは行の raw サイズに追加する必要があります。詳細については、「[Amazon Keyspaces で行のサイズを推定する](calculating-row-size.md)」を参照してください。
次のコードは、[AWK](https://en.wikipedia.org/wiki/AWK) を使用して CSV ファイルを分析し、行の平均サイズと最大サイズを出力します。
```
awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv
```
このコードを実行すると、次の出力が表示されます。
```
using 10,000 samples:
{lines: 10000, avg: 123 bytes, max: 225 bytes}
```
最大行サイズが 1 MB を超えないようにしてください。超えた場合は、行を分割するか、データを圧縮して、行サイズを 1 MB 未満にする必要があります。このチュートリアルの次のステップでは、平均行サイズを使用して、テーブルの書き込みキャパシティをプロビジョニングします。
# ステップ 3: ターゲットテーブルのスループットキャパシティを設定する
このチュートリアルでは、設定された時間範囲内でデータがロードされるように DSBulk を調整する方法を示します。事前に実行する読み取りと書き込みの数がわかっているので、プロビジョンドキャパシティモードを使用します。データ転送が完了したら、アプリケーションのトラフィックパターンに合わせてテーブルのキャパシティモードを設定する必要があります。キャパシティ管理の詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) でのサーバーレスリソースの管理](serverless_resource_management.md)」を参照してください。
プロビジョンドキャパシティモードでは、事前にテーブルにプロビジョニングする読み取りキャパシティと書き込みキャパシティの量を指定します。書き込みキャパシティは時間ユニットで課金され、書き込みキャパシティユニット (WCU) で計測されます。各 WCU は、1 秒あたり 1 KB のデータの書き込みをサポートするのに十分な書き込みキャパシティです。データをロードする際に、書き込みレートが、ターゲットテーブルで設定した WCU の上限 (パラメータ: `write_capacity_units`) を超えないようにしてください。
デフォルトでは、1 つのテーブルに最大 40,000 の WCU を、アカウント内のすべてのテーブルに最大 80,000 の WCU をプロビジョニングすることができます。追加のキャパシティが必要な場合は、[Service Quotas](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas) コンソールでクォータの増加をリクエストできます。クォータの詳細については、「[Amazon Keyspaces (Apache Cassandra 向け) のクォータ](quotas.md)」を参照してください。
**挿入に必要な WCU の平均数を計算する**
1 秒あたり 1 KB のデータを挿入するには、1 WCU が必要です。CSV ファイルに 360,000 の行があり、1 時間ですべてのデータをロードする場合は、1 秒あたり 100 行 (360,000 行 / 60 分 / 60 秒 = 100 行/秒) を書き込む必要があります。各行に最大 1 KB のデータがある場合、1 秒あたり 100 行を挿入するには、100 WCU をテーブルにプロビジョニングする必要があります。各行に 1.5 KB のデータがある場合、1 秒あたり 1 行を挿入するには 2 WCU が必要です。したがって、1 秒あたり 100 行を挿入するには、200 WCU をプロビジョニングする必要があります。
1 秒あたり 1 行の挿入が必要な WCU 数を調べるには、平均行サイズ (バイト) を 1024 で割り、端数を切り上げて最も近い整数にします。
例えば、平均行サイズが 3000 バイトの場合、1 秒あたり 1 行を挿入するには 3 WCU が必要です。
```
ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs
```
**データのロード時間とキャパシティを計算する**
これで、CSV ファイルの平均サイズと平均行数が分かったので、特定の時間内にデータをロードする場合に必要な WCU 数と、さまざまな WCU 設定を使用して CSV ファイルにすべてのデータをロードするのにかかるおおよその時間を計算できます。
例えば、ファイルの各行が 1 KB で、CSV ファイルに 1,000,000 行がある場合、1 時間でデータをロードするには、その時間に少なくとも 278 WCU をテーブルにプロビジョニングする必要があります。
```
1,000,000 rows * 1 KBs = 1,000,000 KBs
1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs
```
**プロビジョンドキャパシティを設定する**
テーブルの書き込みキャパシティは、そのテーブルの作成時、または `ALTER TABLE` コマンドを使用して、設定することができます。以下は、`ALTER TABLE` コマンドを使用してテーブルのプロビジョンドキャパシティ設定に変更を加えるための構文です。
```
ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ;
```
完全な言語リファレンスについては、「[CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create)」と「[ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)」を参照してください。
# ステップ 4: CSV ファイルからターゲットテーブルにデータをアップロードするように `DSBulk` を設定する
このセクションでは、データが Amazon Keyspaces にアップロードされるように DSBulk を設定する場合に必要なステップについて説明します。DSBulk を設定するには、設定ファイルを使用します。設定ファイルは、コマンドラインから直接指定します。
1. Amazon Keyspaces への移行用の DSBulk 設定ファイルを作成します。この例では、ファイル名 `dsbulk_keyspaces.conf` を使用します。DSBulk 設定ファイルで以下の設定を指定します。
1. *`PlainTextAuthProvider`* — `PlainTextAuthProvider` クラスを使用して認証プロバイダーを作成します。`ServiceUserName` と `ServicePassword` は、[Amazon Keyspaces にプログラムによってアクセスするための認証情報を作成する](programmatic.credentials.md) の手順に従ってサービス固有の認証情報を生成したときに取得したユーザー名とパスワードと一致している必要があります。
1. *`local-datacenter`* – の値を接続 AWS リージョン 先の `local-datacenter`に設定します。例えば、アプリケーションを `cassandra.us-east-1.amazonaws.com` に接続する場合は、ローカルデータセンターを `us-east-1` に設定します。使用可能なすべての については AWS リージョン、「」を参照してください[Amazon Keyspaces のサービスエンドポイント](programmatic.endpoints.md)。レプリカを避けるには、`slow-replica-avoidance` を `false` に設定します。
1. *`SSLEngineFactory`* — SSL/TLS を設定するには、`class = DefaultSslEngineFactory` を使用してクラスを指定する設定ファイル (1 行が含まれている) に、セクションを追加して、`SSLEngineFactory` を初期化します。`cassandra_truststore.jks` へのパスと、作成しておいたパスワードを提供します。
1. *`consistency`* — 整合性レベルを `LOCAL QUORUM` に設定します。他の書き込み整合性レベルはサポートされません。詳細については「[Apache Cassandra でサポートされている読み取り/書き込み整合性レベルと関連コスト](consistency.md)」を参照してください。
1. プールごとの接続数は Java ドライバーで設定できます。この例では、`advanced.connection.pool.local.size` を 3 に設定します。
次に、完全なサンプル設定ファイルを示します。
```
datastax-java-driver {
basic.contact-points = [ "cassandra.us-east-1.amazonaws.com:9142"]
advanced.auth-provider {
class = PlainTextAuthProvider
username = "ServiceUserName"
password = "ServicePassword"
}
basic.load-balancing-policy {
local-datacenter = "us-east-1"
slow-replica-avoidance = false
}
basic.request {
consistency = LOCAL_QUORUM
default-idempotence = true
}
advanced.ssl-engine-factory {
class = DefaultSslEngineFactory
truststore-path = "./cassandra_truststore.jks"
truststore-password = "my_password"
hostname-validation = false
}
advanced.connection.pool.local.size = 3
}
```
1. DSBulk `load` コマンドのパラメータを確認します。
1. *`executor.maxPerSecond`* — ロードコマンドにより処理が試行される 1 秒あたりの最大行数。設定しない場合、この設定は -1 となり無効になります。
ターゲット送信先テーブルにプロビジョニングした WCU の数に基づいて `executor.maxPerSecond` を設定します。`load` コマンドの `executor.maxPerSecond` は制限ではなくターゲット平均です。これは、設定した数を大きく上回る可能性がある (多くの場合そうなる) ことを意味します。このような超過を許可し、データロードリクエストを処理できるだけの十分なキャパシティを確保するには、`executor.maxPerSecond` をテーブルの書き込みキャパシティの 90% に設定します。
```
executor.maxPerSecond = WCUs * .90
```
このチュートリアルでは、`executor.maxPerSecond` を 5 に設定します。
**注記**
DSBulk 1.6.0 以上を使用している場合は、代わりに `dsbulk.engine.maxConcurrentQueries` を使用できます。
1. DSBulk `load` コマンドのためにこれらの追加パラメータを設定します。
+ *`batch-mode`* — このパラメータは、パーティションキー別にオペレーションをグループ化するようにシステムに指示を出します。バッチモードは無効にすることを推奨します。バッチモードは、ホットキーシナリオを引き起こし、`WriteThrottleEvents` の原因となる可能性があるためです。
+ *`driver.advanced.retry-policy-max-retries`* — これにより、失敗したクエリが再試行される回数が決まります。設定しない場合のデフォルトは 10 になります。この値は必要に応じて調整できます。
+ *`driver.basic.request.timeout`* — クエリが返されるまでのシステムの待機時間 (分)。設定しない場合のデフォルトは「5 分」です。この値は必要に応じて調整できます。
# ステップ 5: DSBulk `load` コマンドを実行して CSV ファイルからターゲットテーブルにデータをアップロードする
このチュートリアルの最後のステップでは、データを Amazon Keyspaces にアップロードします。
DSBulk `load` コマンドを使用して、以下のステップを実行します。
1. 次のコードを実行して、CSV ファイルから Amazon Keyspaces テーブルにデータをアップロードします。前の手順で作成したアプリケーション設定ファイルへのパスを必ず更新してください。
```
dsbulk load -f ./dsbulk_keyspaces.conf --connector.csv.url keyspace.table.csv -header true --batch.mode DISABLED --executor.maxPerSecond 5 --driver.basic.request.timeout "5 minutes" --driver.advanced.retry-policy.max-retries 10 -k catalog -t book_awards
```
1. 出力には、成功したオペレーションと失敗したオペレーションの詳細が記されているログファイルの場所が含まれます。このファイルは次のディレクトリに保存されています。
```
Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911
```
1. ログファイルのエントリには、次の例のように、メトリックが含まれます。行数が csv ファイルの行数と一致しているか確認します。
```
total | failed | rows/s | p50ms | p99ms | p999ms
200 | 0 | 200 | 21.63 | 21.89 | 21.89
```
**重要**
データを転送したので、アプリケーションの通常のトラフィックパターンに合わせてターゲットテーブルのキャパシティモード設定を調整します。プロビジョンドキャパシティは、変更するまでは、時間ユニットで課金されます。詳細については、「[Amazon Keyspaces で読み取り/書き込みのキャパシティモードを設定する](ReadWriteCapacityMode.md)」を参照してください。