# Apache Cassandra
Apache Cassandra は、[[Facebook]] が内部開発し 2008 年にオープンソース化、2010 年に Apache Software Foundation のトップレベルプロジェクトとなった分散 NoSQL データベースである。[[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]] で詳述されたとおり、[[@2007__SOSP__Dynamo - Amazon's Highly Available Key-value Store|Dynamo]] のパーティショニング・レプリケーション設計と [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data|Bigtable]] のカラムファミリデータモデルを統合している。
主要な技術的特徴は以下のとおりである。
- **パーティショニング**: [[一貫性ハッシュ法]]によるリング構造での自動データ分散
- **レプリケーション**: クォーラムベース、データセンタ対応レプリケーションポリシー
- **メンバーシップ**: [[ゴシッププロトコル]]（Scuttlebutt ベース）
- **障害検知**: Φ 累積障害検知器
- **永続化**: コミットログ → メムテーブル → SSTable（[[LSMツリー]]型）
Facebook の Inbox Search で 150 ノード・50 TB 超の本番展開を達成した後、Apple・Netflix・Instagram など大規模インターネットサービスで広く採用されている。
*詳説 データベース* 第1章は、プライマリキーという用語がDynamoベースのNoSQLストアの例としてCassandra(および Riak)で共通に使われると述べる。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]] §1.4.2)
## リーダーレスレプリケーションと衝突解決
[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]]は、CassandraをRiak・ScyllaDBと並ぶDynamo型[[リーダーレスレプリケーション]]の代表例として扱う。並行書き込みの衝突解決には LWW(last-write-wins、タイムスタンプが最大の書き込みを勝者とする)を採用し、Riakが使う手動解決(siblings保持)やCRDTベースの自動解決とは異なる設計を選ぶ。マルチリージョン運用では、クライアントが最初にローカルリージョン内のコーディネータノードへ書き込みを送り、コーディネータがローカルリージョンの全レプリカと他リージョンの1レプリカへ転送する(転送先が更に自リージョン内へ配布する)ことで、クロスリージョン通信の重複を避ける。クォーラムレベルは全リージョン横断・リージョンごと・ローカルリージョンのみから選択できる。実クロックのタイムスタンプに依存するLWWのため、クロックが進んだノードによる書き込みが正しい順序であっても無視されうるという弱点を持つ。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]] "Leaderless Replication", "Multi-Region Operation", "Detecting Concurrent Writes")
## フェイルスロー障害
[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] のバグスタディでは、ZooKeeper・HDFS・HBase・MapReduce と並ぶ調査対象 5 システムの 1 つとして、Cassandra から 5 件のフェイルスローハードウェア障害が収集された(48 件中最少)。ただし同論文の [[Sieve]] による障害注入評価の対象には含まれていない。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] Table 1)
## 状態一貫性の前提が引き起こしたバグ(詳説 データベース 第8章)
*詳説 データベース* 第8章§8.2.3は、「すべてのノードで状態には完全な一貫性がある」という誤謬(→ [[分散コンピューティングの誤謬]])が現実に引き起こした2つのバグの実例としてCassandraを挙げる。1つ目は、スキーマの変更が各サーバーに異なるタイミングで伝播する事象によって引き起こされたバグで、スキーマ伝播中にデータベースから読み取りを行うと、1つのサーバーがあるスキーマを前提に結果をエンコードした一方で別のサーバーが異なるスキーマでデコードするため、データが破損する可能性があった。2つ目は、リングのビューの不一致によって引き起こされたバグで、あるノードが別のノードのデータ保持状況について、実際とは異なる認識を持つことで、データの読み書きがデータレコードを誤った場所に配置したり空の応答を返したりする結果を招いた。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 8 基本事項の紹介と概要]] §8.2.3)
## ファイルフォーマットのバージョン管理(詳説 データベース 第3章)
*詳説 データベース* 第3章は、バイナリファイルフォーマットのバージョン識別方式の一例としてCassandraのファイル名プレフィックスを挙げる。Cassandraはデータファイル名にバージョンを示すプレフィクスを使い、ファイルを開かなくてもそのバージョンを判別できる。バージョン4.0のデータファイル名には`na`というプレフィックスを付け(例: `na-1-big-Data.db`)、バージョン3.0で書かれたファイルは`ma`という異なるプレフィクスを持つ。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]] §3.9)
## 障害検出(詳説 データベース 第9章)
*詳説 データベース* 第9章は、[[障害検出器]]の一種である Phi-Accrual Failure Detector[HAYASHIBARA04] の採用例として Cassandra を挙げる。この検出方式は障害を二者択一でなく連続した確率的尺度 φ として扱い、ネットワーク状態の変化に動的に適応する。Akka も同じ検出方式を(デッドライン障害検出機能と併用する形で)採用しており、両者は同一の障害検出アルゴリズムを異なる用途で用いる実装例として並置される。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 9 障害検出]] §9.2)
## LSMツリー実装の詳細(詳説 データベース 第7章)
*詳説 データベース* 第7章は、Cassandra の LSM ツリー実装をいくつかの具体的な特徴とともに詳述する。削除操作では単一キーの墓石に加えて **範囲墓石(range tombstone)** をサポートし、`DELETE FROM table WHERE key >= "k2" AND key < "k4"` のような述語削除を実装している。コンパクション戦略としては RocksDB が採用する平準化コンパクション(Leveled)とは別に **サイズ階層化コンパクション** および、有効期限付きの時系列ワークロード向けの **時間枠コンパクション(time window compaction)戦略** を実装している。墓石はコンパクション時に即座に排除されず、GC の猶予期間に到達するまで保持される(これは他ノードが結果整合性のため墓石を参照できるようにするためである)。またセカンダリインデックスの実装として、SSTable のライフサイクルにインデックス構造を結び付ける **SASI(SSTable-Attached Secondary Indexes)** と、memtable 内のセカンダリインデックスにスキップリストを使用する実装が紹介される。並行性の面では、フラッシュ・コンパクション時のテーブルビュー切り替えとログ同期の課題を **操作順序のバリア**(書き込みのために受け取られたすべての操作を memtable のフラッシュまで待機させる仕組み)で解決している。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 7 ログ構造化ストレージ]] §7.1.2, §7.1.6, §7.1.6.2, §7.3.1, §7.3.3, §7.5)
## 読み取り修復のマージリスナー実装(詳説 データベース 第12章)
*詳説 データベース* 第12章§12.1は、レプリカ応答間でどのレコードが異なっているかを正確に検出する実装例としてCassandraを挙げる。マージリスナー(merge listener)を備えた特殊なイテレータを使用し、マージの結果と個別の入力の間の差異を再構築する。この出力は、欠落しているデータをレプリカに通知するためにコーディネータによって使用される。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 12 アンチエントロピーと情報散布]] §12.1)
## 一貫性モデルとウィットネスレプリカ(詳説 データベース 第11章)
*詳説 データベース* 第11章は、因果一貫性の実装にベクタークロックを使うデータベースの対比として Cassandra を挙げ、「因果関係に従って操作を順序付けする代わりに、最後の書き込みが勝つルールを使用して競合を解決している」と説明する。これは DDIA 第6章が既に記録している LWW 採用の判断と同一の設計選択を、別の教科書が因果一貫性の文脈から補強するものである。また同章は、レプリカをコピーレプリカとウィットネスレプリカに分割しストレージコストを削減する**ウィットネスレプリカ**の実装例として、Spanner と並び Cassandra を挙げている。(Source: [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]] §11.5.4.1, §11.9)
## イミュータブルインフラストラクチャ環境での例外(SREの探求 24章)
『SREの探求』24章は、永続的なデータレイヤー上でイミュータブルなインフラストラクチャを使うのは不可能ではないにしても難しいとしたうえで、Cassandra を「イミュータブル環境で機能するように設計されている」データベースの例として挙げる。ただしこの場合でも、ブルー/グリーンリリースではなく、1度に1つのノードを交換するローリングリリースが必要になるとされる。データレイヤー以外のノードはイミュータブルに、データレイヤーは従来型の設定管理に基づくインフラストラクチャで運用する構成のほうが簡単な場合もあると付言している。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]] §24.12)
## 2010〜2011年時点の運用実務(ウェブオペレーション第15章)
『ウェブオペレーション』第15章(2011年、[[Eric Florenzano]])は、Cassandra を Digg・Twitter・Facebook・Rackspace・Reddit などで使われていた「高分散型データベース」として紹介する。同章は Cassandra の設計哲学を(1)追記型ログへの書き込みによる書き込みスケーリング重視(ハードディスクのヘッドがシークしない設計)、(2)単一障害点を認めない(「コーディネーション」サーバや「選ばれたマスタ」が存在せず、[[ゴシッププロトコル]]でノード情報を相互取得する)、(3)Dynamo論文の思想の踏襲([[一貫性ハッシュ法|コンシステントハッシュ]]でデータ保存先を決定・read repairで読み取り時の不一致を修正・hinted handoffでダウンしたノードが可用性を損なわないことを保証)の3点にまとめている。データモデルはキースペース・カラムファミリ・カラムからなる「巨大な多次元ハッシュマップ」と表現される。運用面では、コミットログ用の高速なディスクの追加購入が劇的な性能向上につながること、定期的なコンパクションでディスク容量が一時的に倍になりうること、監視は JMX(および HTTP/RESTful で JMX メトリクスを扱うオープンソースツール PolarRose)で行うことが述べられる。バックアップは各ノードで nodetool の flush コマンドを実行してから専用のバックアップコマンドを実行する手順が紹介される。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.2.1)
導入事例として、Digg のクリス・ゴフィネットが MySQL から Cassandra へ切り替えた理由を、書き込み比率の高さ・複数データセンタのサポート・ラックアウェアネス(できるだけ同じラックのノードで通信する性質)・結果整合性の許容・自動負荷分散の必要性という5点にまとめている。Digg は冗長性とフェイルオーバーを自動で行い、データセンタ間のフェイルオーバーのみアプリケーション側で処理していた。クリスは「Cassandra を使うことで、CPU に制限されることはなくなりましたが、ディスク容量・I/O スループット・ネットワーク帯域幅の制限を受けるようになりました」と述べ、数TB規模のデータを扱っていたと伝えられる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.2.1 導入事例)
## Rails/Active Record アダプタとしての採用検討(ウェブオペレーション第18章)
『ウェブオペレーション』18章(2011年、[[濱崎 健吾]])は、[[Cookpad|クックパッド]]がNoSQLの検討として、Twitterが導入を検討したことで有名になったKVSとしてCassandraを挙げ、既存のRailsアプリケーションにほとんど変更を加えずActive RecordからMySQLと同様に扱えるプラグイン(activerecord-cassandra-adapter)を開発したと述べる。15章(Eric Florenzano)がDigg・Twitter等の大規模事例を通じてCassandraの設計哲学(追記型ログ・単一障害点の不在・Dynamo系譜)を論じるのに対し、18章はRuby on Railsという特定のアプリケーションフレームワークからCassandraを「既存のORMインタフェースの背後で透過的に差し替える対象」として扱う、より小規模な実務者視点の採用検討例である。18章は本番導入の結果までは述べておらず、あくまで「検討・プラグイン開発を行った」という段階の記述にとどまる。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.6)
## 出典
- [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]]
- [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]](Table 1: FSH 障害 5 件の収集元)
- [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 6 Replication]](Dynamo型リーダーレスレプリケーションの実装例・LWWによる衝突解決・マルチリージョンコーディネータ)
- [[@2021__OReillyJapan__詳説 データベース - Chapter 3 ファイルフォーマット]](§3.9 ファイル名プレフィックスによるバージョン管理)
- [[@2021__OReillyJapan__詳説 データベース - Chapter 7 ログ構造化ストレージ]](§7.1.2 範囲墓石、§7.1.6 墓石のGC猶予期間、§7.1.6.2 時間枠コンパクション、§7.3.1 SASI、§7.3.3 スキップリスト、§7.5 操作順序のバリア)
- [[@2021__OReillyJapan__詳説 データベース - Chapter 1 基本事項の紹介と概要]](§1.4.2 プライマリキー用語の共通性)
- [[@2021__OReillyJapan__詳説 データベース - Chapter 9 障害検出]](§9.2 Phi-Accrual Failure Detector の採用例)
- [[@2021__OReillyJapan__詳説 データベース - Chapter 8 基本事項の紹介と概要]](§8.2.3 スキーマ伝播バグ・リングビュー不一致バグ)
- [[@2021__OReillyJapan__詳説 データベース - Chapter 12 アンチエントロピーと情報散布]](§12.1 マージリスナーによる読み取り修復の差分検出)
- [[@2021__OReillyJapan__詳説 データベース - Chapter 11 レプリケーションと一貫性]](§11.5.4.1 LWWによる競合解決、§11.9 ウィットネスレプリカの実装例)
- Jonah Horowitz, 「24章 イミュータブルなインフラストラクチャと SRE」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, §24.12.
- [[@2011__OReillyJapan__ウェブオペレーション - Chapter 15 非リレーショナルデータベース]] §15.2.1(2010〜2011年時点の設計哲学・運用実務・Diggの導入事例)
- [[@2011__OReillyJapan__ウェブオペレーション - Chapter 18 日本の料理のインフラ]] §18.6(Rails/Active Record アダプタとしての採用検討)