Azure Managed Instance for Apache Cassandra とAzure Cosmos DB for Apache Cassandra の違い
この記事では、Azure Managed Instance for Apache Cassandra と RU ベースの Azure Cosmos DB for Apache Cassandra との違いについて説明します。 この記事では、この 2 つのサービスからの選び方、また、どのような場合に独自の Apache Cassandra 環境をホストすべきかについての推奨事項を紹介しています。
主な相違点
Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフル マネージド サービスです。 このサービスでは、各ワークロードの特定のニーズに応じて構成をオーバーライドすることもできます。これにより、必要に応じて最大限の柔軟性と制御が可能になります。 また、既にあるオンプレミスまたはクラウドのセルフホステッド Apache Cassandra クラスターの容量をスケールアウトする機能も備えています。 スケールアウトするには、マネージド Cassandra データセンターを既存のクラスター リングに追加します。
Azure Cosmos DB の RU ベースの Azure Cosmos DB for Apache Cassandra は、Microsoft のグローバルに分散されたクラウドネイティブ データベース サービスである Azure Cosmos DB に対する互換性レイヤーです。
選び方
次の表は、それぞれのデプロイ方法が適している一般的なシナリオやワークロード要件、目標を示しています。
| オンプレミスまたは Azure におけるセルフホステッド Apache Cassandra | Azure Managed Instance for Apache Cassandra | Azure Cosmos DB for Apache Cassandra | |
|---|---|---|---|
| デプロイの種類 | カスタムのパッチまたはスニッチを使用して、高度にカスタマイズされた Apache Cassandra のデプロイがある。 | カスタム コードを一切使用していない標準的なオープンソースの Apache Cassandra デプロイがある。 | 下層は Apache Cassandra でなくても、ワイヤ プロトコル レベルですべてのオープンソースのクライアント ドライバーに準拠しているプラットフォームであれば問題ない。 |
| 運用上のオーバーヘッド | クラスターのデプロイ、構成、保守を行うことができる Cassandra エキスパートが既にいる。 | オープン ソースの Apache Cassandra に対してフル マネージドのサービスとしてのデータベースを使用して運用上のオーバーヘッドをなくしたいが、必要に応じてレプリケーションや整合性などの Cassandra 固有の構成を制御するという選択肢もあります。 | クラウドにおけるフル マネージドの PaaS (サービスとしてのプラットフォーム) データベースを使用して運用上のオーバーヘッドを解消したい。 |
| 運用環境サポート | コンピューティング、ネットワーク、ストレージなどの関連インフラストラクチャ チームへの連絡など、ライブ インシデントや停止には、お客様が自分で対処します。 | お客様は、ライブ インシデントと停止のサポートに対するワンストップ ショップとして機能する、ファーストパーティのマネージド サービス エクスペリエンスを希望します。 | お客様は、ライブ インシデントと停止に対するワンストップ ショップとして機能する、ファーストパーティのマネージド サービス エクスペリエンスを希望します。 |
| ソフトウェアのサポート | お客様がすべてのパッチを処理し、ソフトウェアのサポート終了前に確実にアップグレードします。 | お客様は、サポート終了後の Cassandra のソフトウェア レベルのサポート、パッチの自動適用、メジャー バージョンのターンキー アップグレードを提供する、ファーストパーティのマネージド サービス エクスペリエンスを希望します | お客様は、ソフトウェア レベルのサポートが完全に抽象化された、ファーストパーティのマネージド サービス エクスペリエンスを希望します。 |
| オペレーティング システムの要件 | 仮想マシンのオペレーティング システムのカスタム イメージまたはゴールデン イメージを保守するという要件がある。 | バニラ イメージを使用してもよいが、さまざまな SKU、メモリ、ディスク、IOPS に対する制御手段は確保しておきたい。 | 容量プロビジョニングを単純化し、Azure Cosmos DB の要求ユニットのように、スループットと一対一の関係で結びついた単一の正規化メトリックとして表したい。 |
| 価格モデル | Datastax ツールなどの管理ソフトウェアを使用したい。ライセンス コストも問題ない。 | 純粋なオープンソースのライセンスと VM インスタンスベースの価格の方が望ましい。 | 自動スケーリングとサーバーレスのプランを含む、クラウドネイティブの価格を使用したい。 |
| Analytics | 分析パイプラインのプロビジョニングに対するフル コントロールが、その構築と維持のオーバーヘッドに関係なく必要。 | Azure Databricks など、クラウドベースの分析サービスを使用したい。 | Azure Synapse Link for Azure Cosmos DB と共にプラットフォームに組み込まれた凖リアルタイムのハイブリッド トランザクショナル分析が必要。 |
| ワークロード パターン | ワークロードの状態はかなり安定しているため、クラスターのノードを頻繁にスケーリングする必要はない。 | ワークロードが不安定なため、データ センターのノードのスケールアップとスケールダウンまたはデータ センターの追加と削除を容易に行える必要がある。 | ワークロードは不安定であることが多いため、スケールアップとスケールダウンをすばやく、かつきわめて大規模に行える必要がある。 |
| SLA | 一貫性、スループット、可用性、ディザスター リカバリーに関する SLA を維持するプロセスに不安がない。 | 一貫性とスループットに関する SLA を維持するプロセスに不安はないが、可用性に関する SLA が必要であり、バックアップに関する支援が必要。 | 一貫性、スループット、可用性、ディザスター リカバリーに関して全面的かつ包括的な SLA が必要。 |
| レプリケーションと整合性 | Apache Cassandra で読み取りおよび書き込みパスに使用できる調整可能な整合性設定の完全な配列を構成できる必要がある。 | Apache Cassandra で読み取りおよび書き込みパスに使用できる調整可能な整合性設定の完全な配列を構成できる必要がある。 | ONE (eventual) または ALL (strong) の読み取りパスの整合性は、すべてのアプリケーションに十分である (Cassandra の整合性レベルのマッピングも参照) |
| データ モデル | データの一様分布と非対称のデータ (パーティション キー間のストレージとスループットの両方に関して) が混在するワークロードを移行するには、ノードの垂直スケールに柔軟性が必要。 | データの一様分布と非対称のデータ (パーティション キー間のストレージとスループットの両方に関して) が混在するワークロードを移行するには、ノードの垂直スケールに柔軟性が必要。 | 新しいアプリケーションを構築しているか、または既存のアプリケーションで、パーティション キー間のストレージとスループットの両方に関して、データが比較的一様に分布している。 |