Apache Cassandra から移行する場合に Azure Cosmos DB for Apache Cassandra に適応する方法

  • [アーティクル]

適用対象: Cassandra

Azure Cosmos DB for Apache Cassandra では、既存の Cassandra の SDK およびツールとのワイヤ プロトコルの互換性が提供されます。 最小限の変更で Cassandra 用の API を使用して、Apache Cassandra に接続するように設計されたアプリケーションを実行できます。

Cassandra 用の API を使用する場合は、Apache Cassandra と Azure Cosmos DB の違いを認識する必要があります。 ネイティブの Apache Cassandra に慣れている場合は、この記事を参考にして Azure Cosmos DB for Apache Cassandra を使い始めることができます。

機能サポート

Cassandra 用の API は、Apache Cassandra の多くの機能をサポートしています。 サポートされていない機能や制限がある機能もいくつかあります。 移行する前に、必要な Azure Cosmos DB for Apache Cassandra 機能がサポートされていることを確認してください。

レプリケーション

レプリケーションを計画する場合は、移行と一貫性の両方を確認することが重要です。

Cassandra Query Language (CQL) バイナリ プロトコル v4 ワイヤ プロトコルを介して Cassandra 用の API と通信することができますが、Azure Cosmos DB は独自の内部レプリケーション プロトコルを実装します。 ライブ マイグレーションまたはレプリケーションに Cassandra ゴシップ プロトコルを使用することはできません。 詳細については、「デュアル書き込みを使用した Apache Cassandra から Cassandra 用の API へのライブ マイグレーション」を参照してください。

オフライン移行の情報については、「Azure Databricks を使用して Cassandra から Azure Cosmos DB for Apache Cassandra アカウントにデータを移行する」を参照してください。

Apache Cassandra と Azure Cosmos DB でのレプリケーション整合性のアプローチは似ていますが、その違いを理解することが重要です。 マッピング ドキュメント では、レプリケーションの一貫性に対する Apache Cassandra と Azure Cosmos DB のアプローチを比較します。 ただし、Azure Cosmos DB の整合性設定を特に確認するか、Azure Cosmos DB プラットフォームの整合性設定について簡単なビデオ ガイドを参照することを強くお勧めします。

Cassandra 用の API を使用する場合、Apache Cassandra を実行する既存のアプリケーションに大幅なコード変更を加える必要はありません。 Azure Cosmos DB 内の Cassandra 用の API のためにいくつかのアプローチと構成設定をお勧めします。 ブログ記事の「Java に関する Cassandra 用の API の推奨事項」をご覧ください。

コード サンプル

Cassandra 用の API は、既存のアプリケーション コードを使用するように設計されています。 接続関連のエラーが発生した場合は、クイックスタート サンプルから始めて、既存のコードで必要になる可能性がある小さなセットアップの変更を検出します。

Java v3 および Java v4 ドライバーのための詳細なサンプルがあります。 これらのコード サンプルではカスタム拡張機能が実装され、これによって、推奨されるクライアント構成が実装されます。

Java Spring Boot (v3 ドライバー) および Java Spring Boot (v4 ドライバー) のサンプルも使用できいます。

Storage

Cassandra 用の API は、ドキュメント指向の NoSQL データベース エンジンである Azure Cosmos DB でサポートされます。 Azure Cosmos DB はメタデータを保持しているため、特定のワークロードに必要な物理ストレージの量が変化する可能性があります。

ネイティブ Apache Cassandra と Azure Cosmos DB のストレージ要件の違いは、行のサイズが小さい場合に最も顕著に現れます。 場合によっては、Azure Cosmos DB が圧縮または廃棄を実装しないので、その差が相殺される可能性があります。 この要因はワークロードに大きく依存します。 ストレージ要件について不明な場合は、最初に概念実証を作成することをお勧めします。

複数リージョンのデプロイ

ネイティブの Apache Cassandra は、既定ではマルチマスター システムです。 Apache Cassandra には、読み取り専用のマルチリージョン レプリケーションを備えたシングルマスターのオプションはありません。 書き込み用の別のリージョンへのアプリケーション レベルのフェールオーバーの概念は、Apache Cassandra では冗長になっています。 すべてのノードが独立し、単一障害点はありません。 ただし、Azure Cosmos DB には、書き込み用に単一マスター リージョンまたはマルチマスター リージョンを構成する機能が備わっています。

書き込み用の単一マスター リージョンを使用する利点は、リージョン間の競合シナリオを回避することです。 これにより、高可用性レベルを維持しながら、複数のリージョン間で強力な一貫性を維持できます。

Note

すべてのノードが書き込みを行うことができるため、リージョン間の強力な整合性や復旧ポイント目標 (RPO) ゼロはネイティブの Apache Cassandra では実現できません。 Azure Cosmos DB は、"単一の書き込みリージョン" 構成でリージョン間の厳密な整合性を確保するように構成できます。 ただし、ネイティブの Apache Cassandra と同様に、強力な一貫性のために複数の書き込みリージョンで構成された Azure Cosmos DB アカウントを構成することはできません。 分散システムでは、RPO を 0、目標復旧時間 (RTO) を 0 に設定できません。

詳しくは、「Java に関する Cassandra 用の API の推奨事項」ブログの「負荷分散ポリシー」をご覧ください。 また、公式の Cassandra Java v4 ドライバー向けコード サンプルのフェールオーバー シナリオもご覧ください。

要求ユニット

ネイティブの Apache Cassandra クラスターの実行と Azure Cosmos DB アカウントのプロビジョニングの主な違いの 1 つは、データベース容量のプロビジョニング方法です。 従来のデータベースでは、容量は CPU コア、RAM、IOPで表現されていました。 Azure Cosmos DB は、マルチテナントのサービスとしてのプラットフォーム データベースです。 容量は、要求ユニットと呼ばれる 1 つの正規化メトリックを使用して表現されます。 データベースに送信されるすべての要求には、要求ユニット コスト (RU コスト) が含まれます。 各要求をプロファイリングして、そのコストを確認できます。

要求ユニットをメトリックとして使用する利点は、データベース容量を予測可能なパフォーマンスと効率を高めるのに、定義論的にプロビジョニングできるという利点があります。 各要求のコストをプロファイルした後、要求ユニットを使用して、データベースに送信された要求の数をプロビジョニングする必要がある容量に直接関連付けできます。 この容量プロビジョニング方法の課題は、ワークロードのスループットの特性をしっかり理解している必要があるということです。

要求をプロファイリングすることを強くお勧めします。 その情報を使って、プロビジョニングする必要がある要求ユニットの数を見積もります。 見積もりを行うのに役立つ可能性がある記事を次に示します。

容量のプロビジョニング モデル

従来のデータベース プロビジョニングでは、予想されるスループットを処理するために、前もって固定の容量をプロビジョニングしていました。 Azure Cosmos DB では、スループットのプロビジョニングと呼ばれる容量ベースのモデルが用意されています。 Azure Cosmos DB は、マルチテナント サービスとして、自動スケール モードとサーバーレス モードで消費ベースのモデルも提供します。 これらの消費ベースのプロビジョニング モデルのいずれかをワークロードがどの程度利用できるかは、ワークロードのスループットの予測可能性によって異なります。

一般に、予測可能なスループットを持つ安定状態のワークロードは、プロビジョニングされたスループットから最もメリットがあります。 休止期間が長いワークロードには、サーバーレス モードが有効です。 最小限のレベルのスループットが継続し、予測不能なスパイクが発生するワークロードの場合、自動スケールモードから最も多くのメリットが得られます。 スループットニーズに最適な容量モデルを明確に理解するために、次の記事を確認することをお勧めします。

パーティション分割

Azure Cosmos DB でのパーティション分割は、Apache Cassandra でのパーティション分割と似ています。 主な違いの 1 つは、Azure Cosmos DB の方が "水平方向のスケーリング" に最適化されている点です。 Azure Cosmos DB では、任意の物理パーティションで使用できる垂直方向のスループット容量に制限が設定されます。 この最適化の効果は、既存のデータ モデルに大幅なスループット スキューがある場合に最も顕著です。

パーティション キーの設計によって、要求が比較的均等に分散されるように対策を講じます。 論理的パーティション分割と物理的パーティション分割の動作およびパーティションあたりのスループット容量の制限については、「Azure Cosmos DB for Apache Cassandra でのパーティション分割」をご覧ください。

スケーリング

ネイティブの Apache Cassandra では、容量とスケールを増やすには、クラスターに新しいノードを追加し、そのノードをCassandra リングに適切に追加する必要があります。 Azure Cosmos DB では、ノードの追加は透過的かつ自動で行われます。 スケーリングは、キースペースまたはテーブルに対してプロビジョニングされる要求ユニットの数を表す関数です。 物理マシンのスケーリングは、物理ストレージまたは必要なスループットが論理パーティションまたは物理パーティションで許容される制限に達したときに発生します。 詳細については、「Azure Cosmos DB for Apache Cassandra でのパーティション分割」をご覧ください。

レート制限

要求ユニットのプロビジョニングの課題は、特にプロビジョニングされたスループットを使用している場合 は、レート制限です。 クライアントがプロビジョニングされた量より多くのリソースを消費すると、Azure Cosmos DB によってレート制限エラーが返されます。 Azure Cosmos DB の Cassandra 用 API は、このような例外を Cassandra のネイティブ プロトコルの過負荷エラーに変換します。 アプリケーションでレート制限を回避する方法については、「Azure Cosmos DB for Apache Cassandra 操作のレート制限エラーを防ぐ」を参照してください。

Apache Spark コネクタ

多くの Apache Cassandra ユーザーは、分析やデータ移動の必要性からデータを照会するために、Apache Spark Cassandra コネクタを使用します。 Cassandra 用の API にも、同じコネクタを使用して同じ方法で接続できます。 Cassandra 用の API に接続する前に、「Spark から Azure Cosmos DB for Apache Cassandra に接続する」を確認してください。 特に、「Spark コネクタのスループット構成の最適化」に関するセクションを参照してください。

一般的な問題のトラブルシューティング

一般的な問題の解決策については、「Azure Cosmos DB for Apache Cassandra の一般的な問題のトラブルシューティング」を参照してください。

次のステップ