Azure Managed Instance for Apache Cassandra

解決する課題

オープンソースの Apache Cassandra を、互換性を一切犠牲にせず、運用の重さだけをクラウドに肩代わりさせます。

• Cassandra の互換性は守りたいが、ノード管理・パッチ・修復（repair）の運用が重い
• 自前で組んだ Cassandra クラスターをそのままマネージド化したい
• オンプレや他クラウドの既存クラスターとハイブリッドで動かしながら移行したい
• Cosmos DB の Cassandra API では足りない、OSS 固有の機能や挙動に依存している

主要概念と用語

• マネージドインスタンス（Managed Instance）: Azure が VM・ストレージ・ネットワークをプロビジョニングし、OSS の Cassandra をホストする単位。エンジンは本物の Apache Cassandra
• クラスター / データセンター / ノード: Cassandra 本来の階層。1 クラスターは複数のデータセンターを持ち、各データセンターが複数ノードで構成される
• ハイブリッドクラスター: 既存のオンプレや他クラウドの Cassandra クラスターに、本サービスのデータセンターを追加データセンターとして参加させる構成。移行やマルチクラウドに使う
• CQL（Cassandra Query Language）: Cassandra のクエリ言語。アプリは標準の Cassandra ドライバーでそのまま接続できる
• 委任サブネット（delegated subnet）: マネージドインスタンスは必ず仮想ネットワークのサブネットに配置され、ノードがその中に立つ
• シードノード: クラスターへの参加時に他ノードを発見する起点となるノード。ハイブリッド参加時に既存クラスターのシードを指定する
• レプリケーション係数（RF）: 各キースペースのデータを何ノードに複製するか。可用性と整合性のトレードオフを決める

仕様・制限・クォータ

• エンジン: オープンソースの Apache Cassandra をホストする。サポートされるメジャーバージョンは公式ドキュメントで確認する（順次更新される）
• 配置: 必ず仮想ネットワークのサブネットに配置する。アプリは仮想ネットワーク内またはプライベート接続経由で CQL ポートに到達する
• データセンター単位のスケール: ノードを追加・削除してスケールアウト/インできる。データセンターを別リージョンに増やして地理冗長を組める
• ハイブリッド参加: 既存クラスターへデータセンターとして参加させ、Cassandra のレプリケーションで両者を同期できる
• 自動運用: OS とエンジンのパッチ適用、ノードの健全性監視、修復（repair）などをプラットフォームが代行する
• リージョン／サブスクリプションごとにノード数や vCore のクォータがあり、引き上げ申請が可能。具体的な上限値は変動するため公式の制限ページで確認する

内部の仕組み

Cassandra はマスターレス（ピアツーピア）アーキテクチャで、すべてのノードが対等です。データはパーティションキーをハッシュしてトークンリング上の担当ノードへ振り分け、レプリケーション係数の数だけ複数ノードへ複製します。特定のキーへ書き込みが偏るとホットパーティションになり、担当ノードに負荷が集中します。

• 読み書きは**整合性レベル（Consistency Level）**で調整する。ONE は速いが弱く、QUORUM は過半数で整合を取り、ALL は全レプリカで確認する。RF と整合性レベルの組み合わせで可用性と一貫性のバランスを決める
• 書き込みは追記中心のコミットログ + メモリ（memtable）+ ディスク（SSTable）で処理され、バックグラウンドのコンパクションで SSTable を統合する
• データセンター間は非同期に複製され、各データセンターはローカルで読み書きを完結できる（マルチデータセンター運用）
• マネージドインスタンスはノードの障害検知・置換や**修復（repair）**を自動化し、エントロピー（レプリカ間の不整合）を抑える

設計パターン / ベストプラクティス

• アクセスパターンを列挙し、分散が均等になるパーティションキーを設計する（必要なら複合キー）
• 可用性とコストに合わせてレプリケーション係数と整合性レベルを選ぶ。一般には RF=3 + ローカルクォータム読み書きがバランス点
• 移行はハイブリッドクラスターで既存クラスターにデータセンターを追加し、複製が追いついてから旧データセンターを切り離す
• 地理冗長や読み取り分散には複数リージョンのデータセンターを構成し、アプリは近いデータセンターへローカル整合性で接続する
• アプリには**接続の再試行（リトライ）**とトークン認識ドライバーの利用を前提にする
• 大量の削除（tombstone）を生む設計や、頻繁な更新で SSTable が肥大化するパターンを避ける

運用・監視

• Azure Monitor / メトリクスでノードの CPU・メモリ・ディスク・レイテンシ・スループットを監視する
• **診断ログ（Diagnostic Settings）**を Log Analytics へ送り、遅いクエリやエラーを分析する
• 修復（repair）やパッチはプラットフォームが自動化するが、スケール操作やバージョン更新の計画は運用側で管理する
• スループットが頭打ちならホットパーティションかノード不足を疑い、パーティションキー見直しかノード追加で対処する
• バックアップ/復元の手順とフェイルオーバー時の挙動を定期的に検証する

コスト

• 課金はノード数（VM サイズ）× 稼働時間 ＋ ストレージが基本。ノードを増やすほどスループットと容量が増えるが費用も比例する
• 定常稼働は VM の予約割引などで下げられる。具体的な料金は構成・リージョンで変動するため公式の料金計算ツールで見積もる
• データセンターを必要なリージョンだけに絞り、過剰なレプリケーションやノード数を避けることがコスト最適化の肝

セキュリティ

• 保存時暗号化はプラットフォーム側で提供され、通信は TLS で暗号化される
• 仮想ネットワーク分離でパブリック露出を排除し、サブネットのネットワークセキュリティグループでアクセス元を最小化する
• 認証は Cassandra の認証に加え、Microsoft Entra ID ベースの権限管理を活用してアクセスを制御する
• ハイブリッド構成ではデータセンター間通信をプライベート接続で結び、クラスター間の認証情報を安全に管理する

関連サービス・比較

OSS 互換の Cassandra を求めるなら本サービス、フルマネージドで運用を極限まで減らしたいなら Cosmos DB の Cassandra API が候補です。AWS では Amazon Keyspaces（for Apache Cassandra）が CQL 互換のサーバーレス相当に当たります。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Cassandra マネージドインスタンス用クラスターを作成
az managed-cassandra cluster create \
  --cluster-name demo-cassandra \
  --resource-group demo-rg \
  --location japaneast \
  --delegated-management-subnet-id "/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/Microsoft.Network/virtualNetworks/demo-vnet/subnets/cassandra-subnet" \
  --initial-cassandra-admin-password 'StrongP@ssw0rd!'

# クラスターにデータセンターを追加（ノード数を指定）
az managed-cassandra datacenter create \
  --cluster-name demo-cassandra \
  --resource-group demo-rg \
  --data-center-name dc-japaneast \
  --data-center-location japaneast \
  --delegated-subnet-id "/subscriptions/<sub-id>/resourceGroups/demo-rg/providers/Microsoft.Network/virtualNetworks/demo-vnet/subnets/cassandra-subnet" \
  --node-count 3

# クラスターの状態を確認
az managed-cassandra cluster show \
  --cluster-name demo-cassandra \
  --resource-group demo-rg