翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Apache Cassandra から Amazon Keyspaces への移行を成功させるために、適応可能な移行の概念とベストプラクティスを確認し、取り得る選択肢を比較検討することをお勧めします。
このトピックでは、いくつかの主要な概念と利用可能なツールや手法を紹介しながら、移行プロセスの仕組みを概説します。さまざまな移行戦略を評価することで、独自の要件に最適な戦略を選定できます。
トピック
機能の互換性
移行の前に、Apache Cassandra と Amazon Keyspaces の機能面の違いを慎重に検討しておきましょう。Amazon Keyspaces は、キースペースとテーブルの作成、データの読み取り、データの書き込みなど、一般的に使用されるあらゆる Cassandra データプレーンオペレーションに対応しています。
ただし、Amazon Keyspaces APIsがサポートしていない Cassandra もあります。サポートされている の詳細についてはAPIs、「」を参照してくださいサポートされている Cassandra APIs、オペレーション、関数、およびデータ型。Amazon Keyspaces と Apache Cassandra のすべての機能の違いについては、「機能の違い: Amazon Keyspaces と Apache Cassandra」で概要をまとめて紹介しています。
使用している Cassandra APIsとスキーマを Amazon Keyspaces でサポートされている機能と比較するには、 の Amazon Keyspaces ツールキットで利用可能な互換性スクリプトを実行できますGitHub
互換性スクリプトを使用する方法
互換性がある Python スクリプトを からダウンロードGitHub
し、既存の Apache Cassandra クラスターにアクセスできる場所に移動します。 互換性スクリプトは、
CQLSH
と類似したパラメータを使用します。--host
および--port
には、クラスター内のいずれかの Cassandra ノードへの接続とクエリ実行に使用する IP アドレスとポートを入力します。Cassandra クラスターで認証を使用している場合は、
-username
と-password
も指定する必要があります。互換性スクリプトを実行するには、次のコマンドを使用します。python toolkit-compat-tool.py --host
hostname or IP
-u "username
" -p "password
" --portnative transport port
Amazon Keyspaces の料金を推定する
ここでは、Amazon Keyspaces の推定コストを計算するために、Apache Cassandra テーブルから収集する必要がある情報をかいつまんで説明します。テーブルごとに異なるデータ型が必要で、異なるCQLクエリをサポートし、固有の読み取り/書き込みトラフィックを維持する必要があります。
要件をテーブルごとに考えれば、Amazon Keyspaces ではリソースの分離や読み取り/書き込みスループットキャパシティモードがテーブル単位になっているため、うまく適合します。Amazon Keyspaces では、テーブルの読み取り/書き込みキャパシティと自動スケーリングポリシーを個別に定義できます。
テーブルの要件を理解すれば、機能、コスト、移行の負荷に基づいて、移行対象のテーブルに優先順位を付けやすくなります。
移行前に、Cassandra のテーブルについて次のメトリクスを収集しておきましょう。これらの情報を基に、Amazon Keyspaces におけるワークロードのコストを推定できます。
テーブル名 – キースペースとテーブルの完全修飾名。
説明 – テーブルの説明 (使用方法や保存するデータの型など)。
1 秒あたりの平均読み取り数 — 長期間におけるテーブルへのコーディネーターレベルの読み取りの平均数。
1 秒あたりの平均書き込み数 – 長期間におけるテーブルへのコーディネーターレベルの書き込みの平均数。
平均行サイズ (バイト単位) – バイト単位の行サイズの平均値。
でのストレージサイズ GBs – テーブルの raw ストレージサイズ。
読み取り整合性の内訳 – 結果整合性 (
LOCAL_ONE
またはONE
) と強整合性 (LOCAL_QUORUM
) のある読み取りの割合。
次の表は、移行を計画するにあたって揃える必要があるテーブル関連情報の例を示しています。
テーブル名 | 説明 | 1 秒あたりの平均読み取り数 | 1 秒あたりの平均書き込み数 | 平均行サイズ (バイト単位) | のストレージサイズ GBs | 読み取り整合性の内訳 |
---|---|---|---|---|---|---|
mykeyspace.mytable |
ショッピングカート履歴の保存用 |
10,000 |
5,000 |
2,200 |
2,000 |
100% |
mykeyspace.mytable2 |
最新のプロファイル情報の保存用 |
20,000 |
1,000 |
850 |
1,000 |
25% |
テーブルのメトリクスを収集する方法
このセクションでは、既存の Cassandra クラスターから必要なテーブルメトリクスを収集する手順をステップバイステップで説明します。これらのメトリクスには、行サイズ、テーブルサイズ、1 秒あたりの読み取り/書き込みリクエスト () が含まれますRPS。これらの情報から、Amazon Keyspaces のテーブルのスループットキャパシティ要件を評価し、料金を推定できます。
Cassandra ソーステーブルのテーブルメトリクスを収集する方法
行サイズを調べる
行のサイズは、Amazon Keyspaces における読み取りと書き込みのキャパシティ使用率を判断する上で重要です。次の図は、Cassandra のトークン範囲における典型的なデータ分散を示しています。
で使用できる行サイズのサンプラスクリプトを使用してGitHub
、Cassandra クラスター内の各テーブルの行サイズメトリクスを収集できます。 このスクリプトは、
cqlsh
とawk
を使用して Apache Cassandra からテーブルデータをエクスポートし、任意で指定したテーブルデータのサンプルセットに基づいて、行サイズの最小値、最大値、平均値、標準偏差を計算します。行サイズのサンプルスクリプトに指定した引数がcqlsh
に渡されるため、同じパラメータを使用して Cassandra クラスターに接続し、データを読み取ることができます。以下のステートメントは、この例です。
./row-size-sampler.sh
10.22.33.44
9142 \\ -u "username
" -p "password
" --sslAmazon Keyspaces で行サイズを計算する方法の詳細については、「Amazon Keyspaces で行のサイズを推定する」を参照してください。
テーブルサイズを調べる
Amazon Keyspaces では、ストレージを事前にプロビジョニングする必要がありません。テーブルの請求対象サイズが継続的に監視され、ストレージ料金が決定されます。ストレージは GB/月単位で請求されます。Amazon Keyspaces のテーブルサイズは、単一レプリカの raw サイズ (非圧縮) に基づいています。
Amazon Keyspaces でテーブルサイズを監視するには、メトリクス
BillableTableSizeInBytes
を使用できます。これは、 AWS Management Consoleでテーブルごとに表示されます。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
読み取り数と書き込み数を調べる
Amazon Keyspaces テーブルのキャパシティとスケーリングの要件を判断するために、移行前に Cassandra テーブルの読み取りと書き込みのリクエストレートを調べておきましょう。
Amazon Keyspaces はサーバーレスであり、使用した分だけ料金を支払います。一般に、Amazon Keyspaces の読み取り/書き込みスループットの料金は、リクエストの数とサイズに基づいて決まります。
Amazon Keyspaces には 2 つのキャパシティモードがあります。
オンデマンド – キャパシティプランニングの必要なく、1 秒あたり数千のリクエスト数を処理できる柔軟な請求オプションです。読み取りリクエストと書き込みリクエストの pay-per-request料金が提供されるため、使用した分だけ料金が発生します。
プロビジョンド – プロビジョンドスループットキャパシティモードを選択した場合は、アプリケーションに必要な 1 秒あたりの読み込みと書き込みの数を指定します。これにより、Amazon Keyspaces の使用状況を管理して、定義されたリクエストレート以下を維持し、予測可能性を維持できます。
プロビジョンドモードでは、自動スケーリングを使用して、プロビジョニングしておいたレートを自動調整してスケールアップまたはスケールダウンし、運用効率を高めることができます。サーバーレスリソース管理の詳細については、「Amazon Keyspaces (Apache Cassandra 向け) でのサーバーレスリソースの管理」を参照してください。
Amazon Keyspaces では読み取りと書き込みのスループットキャパシティを個別にプロビジョニングするため、既存のテーブルの読み取りと書き込みのリクエストレートを個別に測定する必要があります。
既存の Cassandra クラスターから最も正確な使用率メトリクスを収集するには、1 つのデータセンター内のすべてのノードに集約されたテーブルに対して、コーディネーターレベルの読み取りおよび書き込みオペレーションの 1 秒あたりの平均リクエスト数 (RPS) を長期間にわたってキャプチャします。
次の図に示すように、RPS少なくとも数週間の平均をキャプチャすると、トラフィックパターンのピークと谷がキャプチャされます。
Cassandra テーブルの読み取りと書き込みのリクエストレートを判断するには、2 つの選択肢があります。
既存の Cassandra モニタリングを使用する
次の表に示すメトリクスを使用して、読み取りリクエスト数と書き込みリクエスト数を観察できます。メトリクスの名前は、使用しているモニタリングツールによって異なる場合があります。
ディメンション Cassandra JMXメトリクス writes
org.apache.cassandra.metrics:type=ClientRequest, scope=Write,name=Latency#Count
reads
org.apache.cassandra.metrics:type=ClientRequest, scope=Read,name=Latency#Count
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
テーブルのキャパシティ使用率を調べる
平均キャパシティ使用率を推定するには、まず、Cassandra ソーステーブルの平均リクエストレートと平均行サイズを確認します。
Amazon Keyspaces は、読み込みキャパシティーユニット (RCUs) と書き込みキャパシティーユニット (WCUs) を使用して、テーブルの読み込みと書き込みのプロビジョニングされたスループットキャパシティーを測定します。この推定では、移行後の新しい Amazon Keyspaces テーブルの読み取りキャパシティと書き込みキャパシティのニーズを、これらのユニットに基づいて算出します。
このトピックの後半で、プロビジョンドキャパシティモードとオンデマンドキャパシティモードのどちらを選択すると、請求にどのような影響があるかを検討します。ただし、この例でキャパシティ使用率を推定するにあたっては、テーブルがプロビジョンドモードであると想定します。
読み取り - 1 つは最大 4 KB の行に対する
LOCAL_QUORUM
1 つの読み取りリクエスト、または 2 つのLOCAL_ONE
読み取りリクエストRCUを表します。4 KB を超える行を読み取る必要がある場合、読み取りオペレーションでは追加の が使用されますRCUs。RCUs 必要な の合計数は、行サイズと、 を使用するLOCAL_QUORUM
か、整合性LOCAL_ONE
を読み取るかによって異なります。たとえば、8 KB の行を読み取るには、
LOCAL_QUORUM
読み取り整合性RCUsを使用して 2 つ、LOCAL_ONE
読み取り整合性を選択した場合RCUは 1 つが必要です。書き込み - 1 つは最大 1 KB のサイズの行に対する 1 つの書き込みWCUを表します。すべての書き込みは
LOCAL_QUORUM
整合性を使用しており、軽量トランザクション () の使用に追加料金はかかりませんLWTs。WCUs 必要な の合計数は、行サイズによって異なります。1 KB を超える行を書き込む必要がある場合、書き込みオペレーションでは追加の が使用されますWCUs。たとえば、行サイズが 2 KB の場合、1 回の書き込みリクエストを実行するWCUsには 2 が必要です。
次の式を使用して、必要な RCUsと を見積もることができますWCUs。
の読み込みキャパシティRCUsは、1 秒あたりの読み込み数に読み込みごとの行数を乗算して、平均行サイズを 4KB で割って、最も近い整数に切り上げて決定できます。
の書き込み容量WCUsは、リクエスト数に平均行サイズを 1KB で割って最も近い整数に切り上げて乗算することで決定できます。
これは、次の式で表されます。
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
例えば、Cassandra テーブルで行サイズが 2.5 KB の 4,960 件の読み取りリクエストを実行する場合、Amazon Keyspaces RCUsでは 4,960 件が必要です。現在、Cassandra テーブルで行サイズが 2.5 KB の 1 秒あたり 1,653 件の書き込みリクエストを実行している場合は、Amazon Keyspaces で 1 秒WCUsあたり 4,959 件が必要です。
この例は、次の式で表されます。
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
-
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 へのオンライン移行: 戦略とベストプラクティス」を参照してください。
オフライン – ダウンタイム期間を設けて、その間に Cassandra から Amazon Keyspaces にデータセットをコピーします。オフライン移行では、アプリケーションの変更や、履歴データと新しい書き込み間の競合解決が不要なため、移行プロセスを簡素化できます。
オフライン移行の計画方法の詳細については、「オフライン移行プロセス: Apache Cassandra から Amazon Keyspaces への移行」を参照してください。
ハイブリッド – ほぼリアルタイムで変更を Amazon Keyspaces にレプリケートできますが、書き込み後の読み取り整合性は保証されません。
ハイブリッド移行の計画方法の詳細については、「ハイブリッド移行ソリューションの使用: Apache Cassandra から Amazon Keyspaces への移行」を参照してください。
このトピックで説明した移行手法とベストプラクティスを確認したら、取り得る選択肢をディシジョンツリーに書き込み、独自の要件と利用可能なリソースに基づいて移行戦略を立てることができます。