Apache Cassandra入門:アーキテクチャ、整合性、運用のベストプラクティス

はじめに — Cassandra とは

Apache Cassandra(以下 Cassandra)は、高スケーラビリティと高可用性を重視した分散型のNoSQLデータベースです。大量の書き込みに対して低レイテンシで応答できるよう設計されており、複数のデータセンター間でのレプリケーションや障害耐性を標準で備えています。Facebookで開発されオープンソース化され、その後Apacheソフトウェア財団のプロジェクトとして成長しました。

歴史と立ち位置

Cassandraは2008年頃にFacebookで開発され、分散ハッシュテーブル(Dynamo)とGoogle Bigtableのアイデアを組み合わせたアーキテクチャを採用しています。2010年にApacheプロジェクトとなり、現在もオープンソースで活発に開発・運用されています。リレーショナルデータベース(RDBMS)とは設計思想が異なり、主に「大量データの分散保存」「高スループットな書き込み」「ローカル/グローバル両方向での可用性」を求めるユースケースに適しています。

基本アーキテクチャ

  • ピアツーピアのクラスタ — Cassandraはマスター/スレーブ方式ではなく、全ノードが対等(ピア)なクラスタ構成です。各ノードは担当するデータのレンジを持ち、トークン(ハッシュ)に基づいてデータを分散します。
  • パーティションとキー — データはパーティションキーによって分散され、同一パーティション内はクラスタリング列で順序付けされます。テーブルの主キーは PRIMARY KEY ((partition_key), clustering_cols...) のように定義します。
  • レプリケーション — データは指定したレプリケーション因子(replication factor)に従って複数ノードに複製されます。複数データセンターを跨ぐレプリケーションも可能で、NetworkTopologyStrategy等で制御します。
  • Gossip と Snitch — ノード間の状態共有はGossipプロトコルで行われ、Snitchはネットワークトポロジー(どのノードがどのDCやラックに属するか)を判定してルーティングやレプリケーションに利用されます。

主要コンポーネント:ストレージとIOパス

  • Commit Log — 書き込み到着時にまず永続化されるログ。障害後のリカバリに使用します。
  • Memtable — メモリ上の書き込みバッファ。一定サイズでフラッシュされてSSTableになります。
  • SSTable(Sorted String Table) — ディスク上に不変のファイルとして書き出される構造。複数のSSTableをマージするのがコンパクションです。
  • Compaction(コンパクション) — 古いSSTableのマージや削除済みデータ(tombstone)の整理を行い、読み取り性能やディスク使用効率を維持します。STCS、LCS、TWCSといった戦略があります。

読み書きと整合性(Consistency)

Cassandraの大きな特徴は「チューナブルな整合性」です。クライアントは読み書き時にConsistency Level(CL)を指定できます。代表的なレベルは以下の通りです(用途により使い分けます)。

  • ANY(書き込み専用。Hinted Handoffや一時格納を許容)
  • ONE / TWO / THREE(指定数のノードからの応答を待つ)
  • QUORUM(レプリカの過半数を待つ)
  • LOCAL_QUORUM / EACH_QUORUM(複数DC環境での局所的/各DCの過半数)
  • ALL(全レプリカの応答を待つ — 高整合性だが可用性低下の可能性)

一般的にwrites + readsのCLをうまく組み合わせることで実質的な整合性を得る(例:write QUORUM + read QUORUM で強い一貫性に近づける)ことが可能です。一方で、低レイテンシや高可用性を優先するなら整合性を緩める選択もできます。

可用性と障害対策の仕組み

  • Hinted Handoff — 書き込み時に本来のレプリカがダウンしている場合、別ノードがその書き込み(ヒント)を保持し、復旧時に転送する。
  • Read Repair — 読み取り時にレプリカ間の不整合が発見されると、最新データで他のレプリカを修正する(同期的・非同期的に行われる)。
  • Anti-Entropy Repair(nodetool repair) — 定期的に全レプリカの差分を修正することで、tombstoneや不整合の蓄積を解消する。運用上非常に重要。

データモデルとCQL(Cassandra Query Language)

CassandraはRDBMSのようなSQL風の言語CQLを提供しますが、内部モデルはカラム志向のストレージです。特徴的なポイント:

  • クエリ駆動のモデリング:必要とする検索パターンごとにテーブルを作り、データを冗長に持つ設計が一般的。
  • ジョインやサブクエリの非対応:クライアントまたはアプリケーション側で結合処理を行うか、あらかじめ集約した形で保存する。
  • パーティションキー設計が重要:ホットパーティション(特定パーティションへの集中書き込み)を避ける。パーティションサイズは数十MB〜100MBを目安にすることが推奨される(ワークロードに依存)。
  • セカンダリインデックスやマテリアライズドビューは存在するが制約・性能問題があるため、使用は慎重に。検索用途はElasticsearchやSolr等の外部インデックスと組み合わせるケースも多い。

トランザクションと軽量トランザクション(LWT)

Cassandraは分散システムとしての性質上、RDBMSのような多行に渡るACIDトランザクションを提供しません。ただし、条件付き更新(INSERT/UPDATE ... IF NOT EXISTS / IF column = value)をサポートする軽量トランザクション(LWT)を提供しており、Paxosアルゴリズムに基づいて線形化(linearizable)な操作を実現します。LWTはコストが高いため、必要な場面に限定して使うのが一般的です。

運用上の注意点

  • ノード追加・削除のコスト — データの再配置(ストリーミング)によるネットワーク/IO負荷が発生する。計画的に行う必要がある。
  • ガーベジ(tombstone)の管理 — 大量の削除やTTLの運用でtombstoneが蓄積すると読み取り性能が劣化する。gc_grace_secondsや適切なcompaction設定、定期的なrepairを検討する。
  • JVMチューニング — CassandraはJVM上で動作するため、ガベージコレクションやヒープ設定のチューニングが運用上重要。
  • 監視とメトリクス — nodetool、JMX、Prometheusエクスポーター、DataStax OpsCenter等での監視を行い、レイテンシ、コンパクション状況、ヒープ使用率、ストリーミング状況などを注視する。

代表的なユースケース

  • ログ収集やイベントストリーム(高頻度書き込み)
  • タイムシリーズデータ(メトリクス、IoTデータ) — TWCSなどのコンパクション戦略が有効
  • ユーザープロファイルやセッションデータ(低レイテンシの読み書き)
  • メッセージングやキューイングのバックエンド

Cassandra と他技術との比較

  • RDBMS — ACIDや複雑なクエリ(JOIN等)を保証しない代わりに可用性と水平スケーラビリティを提供。
  • HBase — HBaseはHadoopエコシステムに密接でマスター(HBase Master)を持つ構成。Cassandraはマスター不要で運用の柔軟性が高い。
  • MongoDB — 文書指向DBで柔軟なクエリが可能。Cassandraは大規模分散・高書き込みスループットに優れる。

推奨される設計・運用のベストプラクティス

  • クエリ駆動でテーブル設計を行う(読みたい形をまず決める)。
  • パーティションキーは均等に分散されるよう設計し、ホットパーティションを避ける。
  • パーティションサイズの目安を守る(ワークロードに依存するが、巨大パーティションは避ける)。
  • 定期的なnodetool repairと適切なgc_grace_seconds設定でtombstone問題に対処する。
  • 監視を整備し、コンパクションやGC、IO帯域を常にチェックする。
  • 重要な検索要件がある場合は外部インデックス(Elasticsearch等)との併用を検討する。

制約と注意点

利点が多い反面、Cassandraには制約もあります。強い整合性が常に必要なトランザクション処理、複雑な結合クエリ、柔軟な二次検索などは得意ではありません。また、運用面ではノードの追加・削除や修復作業、JVM関連のチューニングが必要であり、"放っておける"データベースではありません。設計段階でデータアクセスパターンを明確にすることが成功の鍵です。

まとめ

Cassandraは"可用性とスケーラビリティ"を重視する場面で非常に有力な選択肢です。大量書き込み、複数データセンターの分散運用、フェイルオーバーの自動化などを必要とするサービスに向いています。ただし、データモデリングや運用(repair、コンパクション、JVMチューニングなど)に一定の専門知識が求められるため、用途と要件を慎重に検討した上で採用を判断してください。

参考文献