DS201学習記録：Cassandraのレプリケーションについて

この記事のポイント: Cassandraのレプリケーションファクタ（RF）の設定方法と、SimpleStrategy / NetworkTopologyStrategy の使い分けを解説します。本番環境ではRF=3 + NetworkTopologyStrategyが推奨されます。

DS201シリーズ目次（全17回）

DS201: Foundations of Apache Cassandra™ and DataStax Enterprise の学習記録です。

レプリケーション (Replication) とは

Cassandraは、高い可用性と耐障害性を実現するために、データを複数のノードに複製する**レプリケーション（Replication）**という仕組みを採用しています。これにより、一部のノードに障害が発生してもデータの喪失やサービスの停止を防ぎ、継続的な運用を可能にします。

レプリケーションファクタ (Replication Factor, RF)

**レプリケーションファクタ（RF）**は、各データセットがクラスター内で何回複製されるかを指定するパラメータです。RFの値は、キースペース（Keyspace）ごとに設定します。

RF	耐障害性	ストレージ	書き込みコスト
1	なし（ノード障害でデータ喪失）	1倍	低い
2	1ノード障害まで耐える	2倍	中程度
3	2ノード障害まで耐える	3倍	高い

本番環境ではRF = 3が一般的な推奨値です。これにより、2ノードが同時にダウンしてもデータを失わずに運用を継続できます。

CQLでのRF設定

キースペース作成時にRFを指定します。

-- SimpleStrategy でRF=3のキースペースを作成
CREATE KEYSPACE my_keyspace
WITH replication = {
  'class': 'SimpleStrategy',
  'replication_factor': 3
};

-- NetworkTopologyStrategy でデータセンターごとにRFを指定
CREATE KEYSPACE production_keyspace
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'dc1': 3,
  'dc2': 2
};

既存のキースペースのRFを変更する場合はALTER KEYSPACEを使います。

ALTER KEYSPACE my_keyspace
WITH replication = {
  'class': 'SimpleStrategy',
  'replication_factor': 2
};

RF変更後はnodetool repairを実行して、既存データのレプリケーションを更新する必要があります。

レプリケーション戦略 (Replication Strategy)

Cassandraには、データの複製方法を決定するレプリケーション戦略がいくつかあります。

SimpleStrategy

単一のデータセンターで構成されるクラスター向けです。パーティショナーによって決定された担当ノードから、リング上で時計回りに次のノードへ順番にレプリカを配置します。

開発・テスト環境に適している
ラックやデータセンターのトポロジーを考慮しない
複数データセンター構成では使用すべきでない

NetworkTopologyStrategy

複数のデータセンターやラックで構成されるクラスター向けです。データセンターごとに異なるRFを設定でき、ラックのトポロジーを考慮してレプリカを異なるラックに分散配置します。

本番環境では常にこの戦略が推奨される（単一DC構成でも将来の拡張に備えて）
データセンターごとにRFを独立して設定可能
ラック障害時のデータ保全性が高い

戦略の選択基準

条件	推奨戦略
開発・テスト（単一ノード）	SimpleStrategy
本番環境（単一DC）	NetworkTopologyStrategy
本番環境（複数DC）	NetworkTopologyStrategy

レプリケーションとConsistency Levelの関係

レプリケーション戦略とRFは、Consistency Levelと密接に関連しています。例えば、RF=3のクラスターでQUORUM（過半数）を使用すると、読み書きともに2ノードからの応答が必要になります。

強い一貫性を保証するためのルール：

\[ W + R > RF \]

ここで、\(W\)は書き込みConsistency Levelで応答が必要なノード数、\(R\)は読み取りConsistency Levelで応答が必要なノード数です。

実践シナリオ：RFと戦略の選び方

シナリオ1：開発・テスト環境

単一ノードでの開発には SimpleStrategy + RF=1 で十分です。

CREATE KEYSPACE dev_keyspace
WITH replication = {
  'class': 'SimpleStrategy',
  'replication_factor': 1
};

シナリオ2：単一データセンターの本番環境

3ノード以上のクラスターでは、将来の拡張を見据えて NetworkTopologyStrategy + RF=3 を使用します。

CREATE KEYSPACE prod_keyspace
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'dc1': 3
};

シナリオ3：マルチリージョンのグローバルサービス

東京とバージニアの2リージョン構成では、各DCに異なるRFを設定できます。

CREATE KEYSPACE global_keyspace
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'tokyo': 3,
  'virginia': 2
};

メインリージョン（東京）は RF=3 で完全な冗長性を確保し、DR用リージョン（バージニア）は RF=2 でコストを抑えつつ可用性を維持します。

Docker Composeによるマルチコンテナ環境の構築と管理 - Cassandraクラスターの開発環境構築にDocker Composeを活用する方法を解説しています。
GitHub Actionsの基本的な書き方 - CI/CDパイプラインの構築に関する記事です。Cassandraのスキーマ管理やテストの自動化に応用できます。

DS201シリーズ

この記事はDS201学習記録シリーズの一部です。

前の記事: CassandraのSnitchについて
次の記事: CassandraのConsistency Levelについて