Apache Cassandra データベースから Amazon DynamoDB への移行を容易にする

お客様から、さまざまなデータベースエンジン間でのデータの移行 (異種間移行とも呼ばれています) は困難で時間がかかるという話を伺います。サムスンのような一部のお客様は、Apache Cassandra データベースを Amazon DynamoDB に移行する方法を自ら探らなければなりませんでした (「Moving a Galaxy into the Cloud: Best Practices from Samsung on Migrating to Amazon DynamoDB」をご覧ください)。NoSQL データベース間のこれらの移行は、データの規模と変更の速度のため、より困難になりえます。詳細については、この「Applied Live Migration to DynamoDB from Cassandra」テックトークをご覧ください。

AWS Database Migration Service (AWS DMS) と AWS Schema Conversion Tool (AWS SCT) により、AWS のお客様はデータベースを AWS クラウドに移行しやすくなりました。AWS DMS と AWS SCT を使用して、任意のサポート対象のソース (MongoDB など) から任意のサポート対象のターゲット (Amazon DynamoDB など) に移行できます。現在、AWS DMS と AWS SCT を使用して、Cassandra から DynamoDB への移行が容易になるようにしています。

この記事では、Cassandra データベースから DynamoDB テーブルにデータを一括ロードする手順を順を追って説明します。また、AWS DMS と AWS SCT を使用して切り替える準備が整うまで、DynamoDB テーブルをソースと完全に同期した状態を維持する方法も紹介します。

なぜ Cassandra から DynamoDB に移行する必要があるのでしょうか?

お客様からは、Cassandra のアーキテクチャにはかなりの運用オーバーヘッドが必要であり、その専門知識は見つけるのは困難で高価になる可能性があるとの話を伺います。一方、DynamoDB は完全マネージド型サービスであり、ソフトウェアエンジニアはデータベースインフラストラクチャの管理と保守ではなく、ビジネスイノベーションに集中できます。

また、DynamoDB のサーバーレスプロビジョニングモデルでは、データベースインフラストラクチャの過剰供給の必要性がなくなり、特化したリソースまたはライセンスを必要とせずに提供されます。その結果、お客様は、Cassandra と比較して、DynamoDB でバックアップされたアプリケーションを実行するのに総所有コストを 70% も節約できると報告しています。

Cassandra の一般的な機能の他、Transparent Data Encryption、複数のデータセンターのレプリケーション、バックアップや再構築などのサードパーティ製のツールが、DynamoDB で簡略化されています。グローバルテーブル、ポイントインタイムリカバリ、および保管時の暗号化は、Cassandra が提供するものと同様の機能を開発者に提供します。けれども、これらの機能は、オーバーヘッドやダウンタイムのないプッシュボタンを実装しています。

Cassandra から DynamoDB への移行の仕組み

プライマリ Cassandra クラスタから移行負荷をオフロードし、追加の移行処理に必要なデータ一貫性を確保するために、新しいオンプレミスまたは Amazon EC2 Cassandra データセンターを作成できます。

Cassandra クラスタから DynamoDB ターゲットにデータを移行するには、次の手順に従います。

AWS SCT Clone Data Center Wizard を使用して新しい Cassandra データセンターを展開するか、独自のデータセンターを準備して使用します。
データ抽出エージェント、AWS SCT や AWS DMS タスクを使用して、既存のまたは新規に複製された Cassandra クラスタからデータを抽出します。

現在のバージョンの Cassandra データ抽出エージェントは、Apache Cassandra の最も一般的なバージョン (3.1.1 および 3.0) をサポートしています。エージェントは以前の Apache Cassandra 2.2 および 2.1 でも動作します。他のバージョンについては、現在サポートされていません。

次の図は、この移行方法を示しています。

直前に説明した移行方法を示す図

データの抽出は、Cassandra ドライバとデータ抽出エージェントを使用してバイナリ .db ファイルから直接実行されます。このアプローチの主なメリットは次のとおりです。

複数のデータ抽出エージェントをノードとして使用すると、データ抽出プロセスを迅速に行うことができます。
アクセスはファイルシステムにのみ必要となります (Cassandra クラスタをアクティブにする必要はありません)。

データ抽出処理中にデータが .csv ファイルに抽出され、メタデータがテーブルマッピングおよび (AWS DMS タスクが使用する) タスク設定 JSON ファイルに保存されます。

この記事の残りの部分では、Cassandra クラスタから DynamoDB にデータを移行する方法を示す一連の手順について説明します。

DynamoDB に移行するデータを持つ Cassandra クラスタを特定します。
必要に応じて、Cassandra クラスタをマルチデータセンタークラスタ設定に切り替え、一括抽出アプローチを使用してレプリケーションファクターを 1 に設定したデータセンターを新たに追加します。このオプションを選択すると、Cassandra でより復元性が向上します。これは、移行中に負荷を増加させるときに役立ちます。
AWS SCT を使用して、Cassandra テーブルを DynamoDB 構造に変換します。
AWS SCT データ抽出エージェントの助けを借りて Cassandra テーブルからデータを抽出し、そのデータを .csv ファイルに書き込みます。
AWS SCT を使用して .csv ファイルを Amazon S3 にアップロードします。
AWS DMS を使用して .csv ファイルを DynamoDB にロードします。
AWS DMS 進行中のレプリケーションプロセスの一環として、データ変更をキャプチャします。

移行

移行プロセスには、主に次の 2 つのステップがあります。

Cassandra クラスタをマルチデータセンタークラスタに切り替える。
データ抽出エージェント、AWS SCT や AWS DMS タスクを使用して、Cassandra クラスタからデータを抽出する。

パート 1: Cassandra クラスタをマルチデータセンタークラスタに切り替える

移行のこの部分では、既存のクラスタにデータセンターを追加します。このデータセンターは元のクラスタからすべてのデータを受け取り、次に新しく追加されたデータセンターからのみデータがダウンロードされます。このセクションの手順に従って、既存のデータセンターを複製します。

ステップ 1: AWS SCT を使用して新しいプロジェクトを作成する

注: 複製する Cassandra データセンターを既にお持ちの場合は、この手順をスキップしてパート 2 に直接進むことができます。

AWS SCT をインストールします。次に、以下の手順を実行します。

AWS SCT を開始します。
[ファイル]、[新規プロジェクト]を選択します。
[NoSQL データベース]を選択し、[OK] をクリックします。
Cassandra に接続し、データセンターの公開 IP アドレスまたはプライベート IP アドレスを使用します。AWS SCT を実行しているインスタンスが、ソースとして使用されているクローンデータセンターと同じ Virtual Private Cloud (VPC) にある場合は、プライベート IP アドレスを使用できます。また、プライベート通信が不可能な場合は、パブリック IP アドレスを使用することもできます。
データセンターのコンテキスト (右クリック) メニューを開き、[データセンターを複製して抽出] を選択します。

ステップ 2: ソースの Cassandra データセンターを設定する

マルチデータセンターモードに切り替えようとしているソース Cassandra クラスタの必要なすべての詳細を入力します。

マルチデータセンターモードに切り替えることを試みているソース Cassandra クラスタの必要なすべての詳細を入力する最初の画面

ステップ 2.1: ソースクラスタパラメータを入力する

デフォルトでデータセンター名が選択されています。この設定は、AWS SCT が自動的に Cassandra 設定からこの情報を収集するため、編集できません。
[Snitch モード] を選択:「Ec2Snitch」。

ソースデータセンターとターゲットデータセンターが Amazon EC2 にあるけれども、異なる AWS リージョンにある場合は、ソースデータセンターの [Ec2MultiRegionSnitch] を選択します。それ以外の場合は、Snitch モードを保持します。

ステップ 2.2: Cassandra ノードのパラメータを入力する

ステップ 2 で入力したクラスタ情報がデフォルトで表示されます。
ノードに必要なすべてのボックスに入力するか、.csv ファイルから接続データをインポートします。
今後の参照用に、エクスポートを使用して、入力されたすべてのデータをノードのリストから .csv ファイルに保存できます。
[次へ] を選択して、すべてのソースデータセンターノードの cassandra.yaml ファイル間のパラメータの不一致を検証します。
注: .yaml ファイル間でいくつかのパラメータ (IP アドレスを除く) が異なる場合、不一致レポートが表示され、ターゲットデータセンターノードのテンプレートとして cassandra.yaml ファイルを使用するために必要なノードを選択する必要があります。ただし、相違がない場合は、次のステップに進むことができます。

ステップ 3: ターゲットの Cassandra データセンターを設定する

注: ソースデータセンターノードがプライベート IP アドレスに設定されている場合は、ターゲットノードに Telnet をインストールします。

必要に応じて、ターゲットの Cassandra データセンターのデフォルトディレクトリを変更します。ソースの Cassandra クラスタのディレクトリー構造が異なる場合は、ここでも変更することをお勧めします。
[Snitch モード] を選択します (可能な Snitch モードは
PropertyFileSnitch、Ec2Snitch、GossipingPropertyFileSnitch、およびEc2MultiRegionSnitch) です。
データセンターのサフィックスを入力するか、デフォルト (_tgt) を使用します。
データセンター名を入力します。

ステップ 3.1: 新しいターゲットノードを追加する

[新しいノードの追加] を選択します。
プライベート IP:SSH ポートに X.X.X:22 と入力します
パブリック IP:SSH ポートに X.X.X:22 と入力します
OS ユーザーに ubuntu と入力します
OS パスワードを入力します。この場合、ボックスを空のままにしておきます (システムにパスワードを設定した場合は、このボックスにパスワードを入力します)。
Key path のロケーションを入力するか、またはファイルを参照して選択します。この場合、ファイルは your-pem-file.pem です。
Passphrase: パスワードを設定した場合は、このボックスにパスワードを入力します。
Cassandra 設定 YAML ファイルを開くには、Cassandra 設定の表示リンクを選択してください。このリンクには、ターゲットデータセンターのノード上の cassandra.yaml ファイルで使用されているソース Cassandra データセンターから自動的に収集された構成パラメータに関する情報が含まれています
すべての入力を検証するには、[次へ] を選択します。
[ログの表示] を選択して、自動検証プロセスを実行します。

ステップ 4: データのレプリケーションを開始する

キースペースを選択する:
- Cassandra バージョン 3.x: データをコピーするキースペースを選択します。
- Cassandra バージョン 2.x の場合: すべてのキースペースに対して 1 つの一般的な行を選択します。
ターゲットデータセンターへのデータのレプリケーションプロセスを開始するには、[開始] をクリックします。
次のスクリーンショットに示すように、レプリケーションが開始すると [開始] が [停止] になります。レプリケーションプロセスの進行状況を監視できます。
レプリケーション処理が完了したら、[次へ] を選択します。

ステップ 5: データレプリケーションの概要を確認する

Cassandra クラスタの現在の状態テーブルに、ソースノードとターゲットノードのリストが表示されます。
[終了] を選択します。[データセンターを複製して抽出] ページが閉じ、新しいデータセンターがソースツリーに表示されます。

パート 2: データ抽出エージェント、AWS SCT、および AWS DMS タスクを使用して、Cassandra クラスタからデータを抽出する

Cassandra クラスタからデータを抽出するには、データ抽出エージェントと AWS SCT をインストールして使用する必要があります。

データ抽出エージェントを設定および準備するには、「Migrating Data From Apache Cassandra to Amazon DynamoDB」にある次の手順を実行します。

データ抽出エージェントの前提条件をインストールします。
AWS Cassandra データ移行エージェントをインストールします。
AWS Cassandra データ移行エージェントを設定します。
Cassandra のホームディレクトリとデータディレクトリをマウントします。
AWS Cassandra データ移行エージェントを起動します。

ステップ 1: データ抽出エージェントの実行後に AWS SCT に切り替える

データ抽出エージェントを設定して正常に実行したら、AWS SCT がインストールされているインスタンスに戻り、次の手順を実行します。

AWS プロファイル情報を AWS SCT (AWS SCT のグローバル設定で利用可能) に追加します。AWS プロファイル情報により、AWS リソースとの通信に使用するアクセスキーとシークレットアクセスキーを設定します。たとえば、AWS SCT はこの情報を使用して、アカウント内の DynamoDB テーブルにアクセスします。
[ファイル] を選択し、新しい Cassandra to DynamoDB プロジェクトを作成します。Cassandra と DynamoDB に接続します。Cassandra の情報は左側のパネルに表示され、DynamoDB の情報は右側のパネルに表示されます (次のスクリーンショット参照)。
左側のパネルから抽出する Cassandra データセンターを選択し、「ノード」に切り替えます。
移行元の Cassandra ノードの正しい IP アドレスと、現在のノードの jmxUser および jmxPassword を指定します。次に、[適用] を選択します。
特定のキースペース中に移行するテーブルを選択します。選択したテーブルのコンテキスト (右クリック) メニューを開き、テーブルを DynamoDB に変換します。AWS SCT は自動的にテーブル構造を Cassandra から DynamoDB に変換します。これらのテーブルを変換した後、各テーブルの [設定] タブで、テーブルの必要な読み書き容量の単位を設定できます。
AWS SCT の右側のパネルで、DynamoDB の変換されたすべてのテーブルのコンテキスト (右クリック) メニューを開き、DynamoDB で作成するテーブルの変更を適用します。

ステップ 2: データ抽出エージェントを登録する

この手順では、前の手順で設定したデータ抽出エージェントを登録します。AWS SCT の次の手順に従って、データ抽出エージェントを登録します。

[View] を選択し、次に [Data Migration View] を選択します。
[Register] を選択します。
エージェントが設定されているマシンのエージェント名、ホスト、およびポートを入力します。エージェントが Cassandra データセンターに接続するための Secure Sockets Layer (SSL) を使用するかどうかを決定することもできます。
[Register] を選択します。エージェントの表示が「アクティブ」になっているはずです。

ステップ 3: 抽出タスクと AWS DMS タスクを作成する

データ抽出が AWS SCT に登録されたら、データを抽出して Cassandra から DynamoDB に移行するタスクを作成できるはずです。

データ抽出エージェントを使用して、一括ロードデータと、進行中の Cassandra データセンターから Amazon S3 への変更情報を収集するローカル抽出タスクを作成します。
リモート AWS DMS タスクは、Amazon S3 から抽出されたデータを取得し、DynamoDB に移行します。
データ抽出エージェントを登録したら、AWS SCT の左側のパネルで、移行する Cassandra のキースペースのコンテキスト (右クリック) メニューを開きます。[ローカルタスクと DMS タスクの作成] を選択します。
覚えやすく親しみやすいタスク名を入力します。
AWS アカウントで [DMS レプリケーションインスタンス] を選択します。AWS SCT は、AWS プロファイル情報を使用して、アカウント内の AWS DMS リソースを検索します。持っていない場合は、AWS DMS でレプリケーションインスタンスを作成します。
適切な移行タイプを選択します。進行中のレプリケーションを使用して、1 回限りのロードを実行したり、既存のすべてのデータをロードしたりすることができます。
前の手順で AWS SCT を使用して DynamoDB にテーブルを作成した場合は、ターゲットテーブル準備モードを [何もしない] に設定します。まだ行っていない場合は、このプロセスを選択して DynamoDB にテーブルを自動的に作成できます。
抽出と移行のために [IAM ロール] を選択します。この IAM ロールに必要な権限は、Using Data Extraction Agentsに記載されています。
適切なロギングレベルを選択して、タスクのステータスを確認します。
説明をオプションで追加します。
必要に応じて、データ暗号化を有効にします。
Amazon S3 にアップロードした後に .csv ファイルを削除する場合は、[ローカルディレクトリからファイルを削除する] を選択します。これは、ディスク容量が一杯にならないようにするのに役立ちます。
データ抽出先の S3 バケットに名前を付けます。
抽出タスクと AWS DMS タスクを作成するには、[作成] を選択します。

ステップ 4: AWS DMS タスクを開始する

タスクを開始し、データフローを監視するには、[開始] を選択します。エージェントは進行中のレプリケーションが変更されるのを待つため、AWS DMS タスクは常に「実行中」の状態になります。タスクを一時停止することができ、移行が完了した後で、タスクを削除してエージェントを登録解除することができます。

ステップ 5: AWS DMS タスクを監視する

[タスク] タブのテーブルの AWS DMS タスクの進行状況を監視します。ステータスには、フルロードの進捗率 (%)、経過時間、読込済みのテーブル、読込中のテーブルなどの変数が表示されます。AWS DMS タスクの開始後、AWS DMS が公開する Amazon CloudWatch メトリックを使用してタスクを監視することができます。詳細については、「Monitoring AWS DMS Tasks」をご覧ください。

概要

この記事のソリューションを使用して、Apache Cassandra データベースを DynamoDB に移行するのと同時に、移行プロセス中に Cassandra ソースデータベースを完全に機能させ続けることができます。準備ができたら、最小限のダウンタイムでアプリケーションを DynamoDB に切り替えることができます。また、複数のデータ抽出エージェントを使用して、複数の Cassandra キースペースから同時にテーブルを移行することで、DynamoDB への移行をより迅速に行うことができます。

重要事項:

元の Cassandra のデータセンターは、レプリケーションファクタが 1 の新しいデータセンターを追加するときは変更されません。したがって、データが失われることはありません。DataStax ユーザーガイドをデータセンターのレプリケーションに使用しています。そのため、エンドユーザー接続に local_quorum を使用することをお勧めします。これにより、最初のデータ抽出中の変更から保護するため、矛盾が発生する可能性のあるターゲットデータセンターへの変更を回避するのに役立ちます。また、ターゲットデータセンターでブートストラップオプションを使用して、これらのデータセンターをデータの変更から保護します。これらの予防措置により、一貫した再構築やデータ抽出が可能になります。ターゲットデータセンターのデータは、データセンターを複製した直後に一貫していなければならず、抽出中は変更しないようにしてください。さらに、auto_bootstrap: false オプションと disableautocompaction コマンドを使用して、初期データ抽出中のデータの変更からターゲットデータセンターを保護します。
AWS Schema Conversion Tool は、新しいデータセンターが作成され、正常な状態になった後にのみ抽出を開始します。ウィザードは、すべてのターゲットノードの再構築完了ステータスを確認します。再構築を正常に完了するには、データのレプリケーションの開始直前にソースデータセンターのデータが一貫していなければなりません。一貫性を保つために、ソースデータセンターでフラッシュコマンドと修復コマンドを実行することをお勧めします。
発生する可能性がある唯一の問題は、新しいデータセンターノードの 1 つ以上のノードが破損し、移行が強制的に再開される可能性があることです (データが失われることはありませんが、移行に時間がかかります)。ターゲットデータセンターのノードが破損している場合、ウィザードを最初から開始して新しいデータセンターを再度レプリケートすることができます。ターゲットデータセンターで初期データ抽出を開始した後、ソースデータセンターに来る可能性のある新しいデータを抽出するために、変更データキャプチャ (CDC) を使用します。再構築コマンドを発行する直前に、ターゲットデータセンターで増分バックアップを自動的に有効にします。
CDC データの抽出を開始する前に、最初のデータ抽出プロセスが終了した後に以下の手順を実行してください。
- ターゲットデータセンターでブートストラップを有効にします。
- アプリケーションコネクタで [CL] を [EACH_QUORUM] に変更します。
- ターゲットデータセンターノードで修復を実行します。

著者について

Arun Thiagarajanはアマゾンウェブサービスの AWS DMS と AWS SCT チームのデータベースエンジニアです。 彼はデータベースの移行に関する課題に取り組み、お客様と緊密に協力して AWS DMS の真の可能性を実感できるようにサポートしています。AWS DMS と AWS SCT を使用して、何百ものデータベースを AWS クラウドに移行するのを手伝いました。

Mahesh Kansara は、アマゾンウェブサービスのデータベースエンジニアです。 彼はお客様と協力して、データベースおよび分析プロジェクトに関する指導と技術援助を提供し、AWS を使用してソリューションの価値を向上させるお手伝いをしています。

Amazon Web Services ブログ