翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # 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)」を参照してください。 このトピックで説明した移行手法とベストプラクティスを確認したら、取り得る選択肢をディシジョンツリーに書き込み、独自の要件と利用可能なリソースに基づいて移行戦略を立てることができます。