Amazon Keyspaces 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon Keyspaces は、Apache Cassandra との完全互換性を持つ サーバーレス・フルマネージド Wide-Column データベース です。CQL（Cassandra Query Language）・公式 Cassandra ドライバー・既存 Cassandra ワークロードがそのまま使用可能。自動スケーリング・キャパシティ管理不要・マルチリージョンレプリケーション対応で、オンプレミス Cassandra から AWS への移行コストを最小化します。2025 年 7 月の Change Data Capture（CDC）Streams サポート、2026 年 2 月の WarmThroughput によるプリウォーミング機能により、リアルタイムデータ同期とトラフィックスパイク対応が強化されました。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： Cassandra / Keyspaces とは何か、オンプレミス Cassandra からの移行を検討している方
• 開発者向け： CQL クエリ・テーブル設計・分散データモデルを実装したい方
• データアーキテクト向け： Wide-Column 設計・パーティショニング戦略・マルチリージョンレプリケーション
• DBA/インフラ向け： キャパシティモード・スケーリング・バックアップ・PITR 運用
• 意思決定者向け： オンプレミス Cassandra vs Keyspaces、DynamoDB との比較・投資判断

2025-2026 年の Keyspaces エコシステム

• Change Data Capture（CDC）Streams（2025 年 7 月）： 行レベル変更のリアルタイムキャプチャ、24 時間保持、自動スケーリング対応
• WarmThroughput によるプリウォーミング（2026 年 2 月）： ピークトラフィック事前指定で遅延なしスケーリング、プロビジョンド・オンデマンドモード対応
• マルチリージョン拡張（2025 年 11 月）： 中東（バーレーン）・アジア太平洋（香港）リージョン対応、レイテンシ最適化
• Multi-Region User Defined Types（UDT）サポート（2025 年 3 月）： グローバルレプリケーション時のカスタム型対応
• 非同期レンジ削除（2026 年 7 月）： Range delete 操作の非同期処理化

目次

1. 概要
2. Keyspaces が解決する課題
3. 主な特徴
4. Cassandra データモデル
5. Wide-Column 設計
6. キャパシティモード
7. CQL（Cassandra Query Language）
8. インデックス戦略
9. パーティショニング・レプリケーション
10. 変更ストリーム（Change Data Capture - CDC）
11. マルチリージョンレプリケーション
12. バックアップ・PITR・復元
13. セキュリティ
14. 性能チューニング
15. コスト最適化
16. 主要ユースケース
17. 設定・操作の具体例
18. Cassandra・DynamoDB 比較
19. ベストプラクティス
20. トラブルシューティング
21. 2025-2026 最新動向
22. 学習リソース
23. 実装チェックリスト
24. まとめ

概要

初心者向けメモ： Keyspaces は「Cassandra を AWS で動かしたい」という需要から生まれたサービス。オンプレミスで Cassandra を自分たちでクラスター構築・管理している組織が、AWS に移行する時に「コード・CQL クエリ・ドライバーをほぼ変更なしに」使えるのが最大の魅力。DynamoDB（AWS ネイティブ NoSQL）ではなく、既存の Cassandra ワークロード移行に特化しています。

Keyspaces は以下を実現します：

• Cassandra 完全互換：CQL 3.11・公式 Cassandra ドライバー・ツールがそのまま使用可能
• サーバーレス自動スケーリング：トラフィック増減に自動対応、キャパシティ管理不要
• Wide-Column 柔軟性：行ごとに異なる列を持つスキーマレスな設計
• マルチリージョンレプリケーション：グローバルな読み取りレイテンシ最適化
• エンタープライズセキュリティ：IAM・KMS・VPC・CloudTrail が統合

Keyspaces が解決する課題

課題 1: オンプレミス Cassandra 運用の工数

状況： 自社データセンターで 30 ノード Cassandra クラスターを管理、ノード追加・パッチ・バックアップに月 40 時間消費

Keyspaces の解決：

• ノード管理ゼロ（AWS マネージド）
• パッチ・ファイアウォール・バックアップが自動
• スケーリングが自動（オンデマンドモード）
• 運用工数 80～90% 削減

課題 2: Cassandra の初期構築難易度

状況： Cassandra クラスター構築に「シード設定・レプリケーション戦略・圧縮戦略」など複雑な設定が必要

Keyspaces の解決：

• AWS コンソール数クリックでキースペース・テーブル作成
• デフォルト設定で本番環境対応
• CQL スクリプトで既存テーブル定義をそのまま使用可能

課題 3: トラフィックスパイク対応

状況： 定期セール時にトラフィックが 10 倍に跳ねるが、事前のキャパシティ確保が難しい

Keyspaces の解決：

• オンデマンドモードで自動スケーリング
• WarmThroughput（2026 年 2 月）で事前にピークを指定
• 遅延なしでスケーリング

主な特徴

graph TD
    A["Keyspaces クラスター<br/>サーバーレス"] --> B["キースペース（Keyspace）<br/>データベース相当"]
    B --> C["テーブル"]
    
    C --> D["パーティションキー<br/>データ分散の基準"]
    C --> E["クラスタリングカラム<br/>パーティション内ソート"]
    C --> F["その他カラム<br/>動的・行ごとに異なる可"]
    
    G["キャパシティモード"] --> H["プロビジョンド<br/>安定した負荷向け"]
    G --> I["オンデマンド<br/>予測不能・スパイク向け"]
    
    J["マルチリージョン"] --> K["Auto Scaling"]
    J --> L["レイテンシ最適化"]
    
    M["Change Data Capture<br/>CDC Streams"] --> N["Kinesis"]
    M --> O["Lambda"]
    M --> P["外部システム"]

主な特徴の詳細

1. Cassandra API 互換性

   • CQL 3.11 対応
   • 公式 Cassandra ドライバー互換（Java・Python・Node.js など）
   • オンプレミス Cassandra ツール（nodetool 相当機能）対応

2. Wide-Column データモデル

   • パーティションキー + クラスタリングカラム
   • 行ごとに異なるカラム可能
   • スキーマレスな柔軟性

3. キャパシティモード

   • プロビジョンド：RCU/WCU 事前確保、コスト低（安定負荷向け）
   • オンデマンド：実際の使用量課金、スパイク対応

4. サーバーレス自動スケーリング

   • トラフィック増減に自動対応
   • キャパシティプランニング不要
   • WarmThroughput でピークを事前指定（2026 年 2 月）

アーキテクチャ

┌────────────────────────────────────┐
│  アプリケーション（Cassandra API）  │
│ - CQL クエリ                       │
│ - Cassandra ドライバー              │
└─────────────────┬──────────────────┘
                  │
      ┌───────────┴───────────┐
      │                       │
┌─────▼──────┐      ┌────────▼─────┐
│ Keyspaces  │      │ Auth Plugin   │
│ エンドポイント│      │ (SigV4)       │
└─────┬──────┘      └────────────────┘
      │
      │ 3 AZ レプリケーション
      │ 自動フェイルオーバー
      │
┌─────▼──────────────────────────────┐
│    Keyspaces クラスター             │
│  - キースペース（DB 相当）           │
│  - テーブル（複数）                 │
│  - インデックス                      │
│  - TTL 自動削除                    │
└──────────────────────────────────────┘

キーポイント

• 完全マネージド：ノード・クラスター管理ゼロ
• 高可用性：3 AZ 自動レプリケーション、99.99% SLA
• スケーラビリティ：オンデマンドで自動スケーリング
• セキュリティ：IAM・KMS・VPC・CloudTrail 統合

Cassandra データモデル

データモデルの概念

Cassandra:
  Cluster（クラスター）
  └── Keyspace（キースペース）= ユーザー作成
      └── Table（テーブル）
          ├── Partition（パーティション）= パーティションキー単位
          │   └── Row（行）= クラスタリングキー単位
          │       └── Column（カラム）
          └── Node（ノード）= 3 つ以上のレプリカ

テーブル設計例

-- キースペース作成
CREATE KEYSPACE IF NOT EXISTS analytics
WITH replication = {'class': 'SingleRegionStrategy'};

-- テーブル作成（時系列データ）
CREATE TABLE IF NOT EXISTS analytics.events (
  device_id    TEXT,
  timestamp    TIMESTAMP,
  event_type   TEXT,
  value        DOUBLE,
  metadata     MAP<TEXT, TEXT>,
  PRIMARY KEY (device_id, timestamp)
) WITH CLUSTERING ORDER BY (timestamp DESC)
  AND TTL 2592000;  -- 30 日後に自動削除

-- テーブル作成（ユーザープロファイル）
CREATE TABLE IF NOT EXISTS analytics.users (
  user_id      TEXT PRIMARY KEY,
  email        TEXT,
  name         TEXT,
  created_at   TIMESTAMP,
  tags         SET<TEXT>,
  preferences  MAP<TEXT, TEXT>
);

-- セカンダリインデックス（カラムの値で検索）
CREATE INDEX IF NOT EXISTS users_email ON analytics.users (email);

-- 複合インデックス（複数カラム）
CREATE INDEX IF NOT EXISTS events_type ON analytics.events (event_type);

Wide-Column 設計

パーティションキー vs クラスタリングキー

セッション管理テーブルの例:

CREATE TABLE sessions (
  user_id    TEXT,          ← パーティションキー（データ分散）
  session_id TEXT,          ← クラスタリングキー（同一パーティション内のソート）
  created_at TIMESTAMP,     ← クラスタリングキー（複合キー）
  ip_address TEXT,
  user_agent TEXT,
  PRIMARY KEY (user_id, session_id, created_at)
)

実装結果:
Partition 1: user_id = "user_001"
  ├── Row 1: session_id = "sess_abc", created_at = 2024-04-26 10:00
  ├── Row 2: session_id = "sess_def", created_at = 2024-04-26 11:00
  └── Row 3: session_id = "sess_ghi", created_at = 2024-04-26 12:00

Partition 2: user_id = "user_002"
  ├── Row 1: session_id = "sess_jkl", created_at = 2024-04-26 09:30
  └── Row 2: session_id = "sess_mno", created_at = 2024-04-26 10:45

クエリ例：
SELECT * FROM sessions WHERE user_id = 'user_001'  ← パーティション指定必須
SELECT * FROM sessions WHERE user_id = 'user_001' AND session_id = 'sess_abc'
SELECT * FROM sessions WHERE user_id = 'user_001' AND created_at > '2024-04-26 10:00'

ホットパーティション回避

❌ 悪い例：
CREATE TABLE user_clicks (
  user_id  TEXT PRIMARY KEY,  ← 同じ user_id でまとめる = ホットパーティション
  clicks   BIGINT
)

✅ 良い例：
CREATE TABLE user_clicks (
  user_id     TEXT,
  click_time  TIMESTAMP,
  click_id    UUID,
  PRIMARY KEY (user_id, click_time, click_id)
)
// パーティションを時間で分割 → 複数 Cassandra ノードに分散

キャパシティモード

プロビジョンド vs オンデマンド

キャパシティ設定例

# AWS CLI でキースペース・テーブル作成（プロビジョンド）
aws cassandra create-keyspace \
  --keyspace-name "my_keyspace" \
  --replication-strategy "SingleRegionStrategy" \
  --region us-east-1

# テーブル作成（プロビジョンド）
aws cassandra create-table \
  --keyspace-name "my_keyspace" \
  --table-name "users" \
  --schema-definition '{
    "allColumns": [
      {"name": "user_id", "type": "text"},
      {"name": "email", "type": "text"},
      {"name": "created_at", "type": "timestamp"}
    ],
    "partitionKeys": [{"name": "user_id"}],
    "clusteringKeys": [
      {"name": "created_at", "orderBy": "DESC"}
    ]
  }' \
  --capacity-mode "PROVISIONED" \
  --billing-mode "PAY_PER_REQUEST" \
  --provisioned-throughput-settings "ReadCapacityUnits=100,WriteCapacityUnits=100"

# テーブル作成（オンデマンド）
aws cassandra create-table \
  --keyspace-name "my_keyspace" \
  --table-name "events" \
  --schema-definition '{...}' \
  --capacity-mode "ON_DEMAND" \
  --billing-mode "PAY_PER_REQUEST"

# Auto Scaling の設定（プロビジョンド）
aws autoscaling register-scalable-target \
  --service-namespace cassandra \
  --resource-id "table/my_keyspace/users" \
  --scalable-dimension "cassandra:table:WriteCapacityUnits" \
  --min-capacity 10 \
  --max-capacity 1000

# スケーリングポリシー
aws autoscaling put-scaling-policy \
  --policy-name "scale-writes" \
  --service-namespace cassandra \
  --resource-id "table/my_keyspace/users" \
  --scalable-dimension "cassandra:table:WriteCapacityUnits" \
  --policy-type "TargetTrackingScaling" \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "CassandraWriteCapacityUtilization"
    }
  }'

CQL（Cassandra Query Language）

基本的な CQL クエリ

-- キースペース作成
CREATE KEYSPACE IF NOT EXISTS myapp
WITH replication = {'class': 'SingleRegionStrategy'};

-- テーブル作成
CREATE TABLE IF NOT EXISTS myapp.users (
  user_id   TEXT PRIMARY KEY,
  email     TEXT,
  name      TEXT,
  age       INT,
  tags      SET<TEXT>,
  created_at TIMESTAMP
);

-- データ挿入
INSERT INTO myapp.users (user_id, email, name, age, tags, created_at)
VALUES (
  'user_001',
  'user@example.com',
  'John Doe',
  30,
  {'premium', 'verified'},
  toTimestamp(now())
);

-- 複数データ挿入
BEGIN BATCH
  INSERT INTO myapp.users VALUES ('user_002', 'user2@example.com', 'Jane Doe', 28, {'regular'}, toTimestamp(now()));
  INSERT INTO myapp.users VALUES ('user_003', 'user3@example.com', 'Bob Smith', 35, {'premium', 'early_adopter'}, toTimestamp(now()));
APPLY BATCH;

-- クエリ（パーティションキー指定必須）
SELECT * FROM myapp.users WHERE user_id = 'user_001';

-- 複合条件（パーティションキー + クラスタリングキー）
SELECT * FROM myapp.users WHERE user_id = 'user_001' AND created_at > '2024-01-01';

-- セットからの抽出
SELECT * FROM myapp.users WHERE tags CONTAINS 'premium';

-- 更新
UPDATE myapp.users SET name = 'John Smith', age = 31 WHERE user_id = 'user_001';

-- TTL 付き更新（30 日後に自動削除）
UPDATE myapp.users USING TTL 2592000 SET age = 31 WHERE user_id = 'user_001';

-- 削除
DELETE FROM myapp.users WHERE user_id = 'user_001';

-- TTL インデックス（自動削除）
ALTER TABLE myapp.users WITH default_time_to_live = 2592000;  -- 30 日

Cassandra ドライバー使用例（Node.js）

const cassandra = require('cassandra-driver');

const client = new cassandra.Client({
  contactPoints: ['cassandra.us-east-1.amazonaws.com'],
  localDataCenter: 'us-east-1',
  authProvider: new cassandra.auth.PlainTextAuthProvider(
    'cassandra',
    'cassandra'
  ),
  keyspace: 'myapp'
});

(async () => {
  try {
    // 接続
    await client.connect();
    console.log('Connected');

    // クエリ実行
    const result = await client.execute(
      'SELECT * FROM users WHERE user_id = ?',
      ['user_001'],
      { prepare: true }
    );
    console.log('User:', result.rows[0]);

    // 複数行挿入
    const queries = [
      {
        query: 'INSERT INTO users (user_id, email, name, created_at) VALUES (?, ?, ?, ?)',
        params: ['user_002', 'user2@example.com', 'Jane', new Date()]
      },
      {
        query: 'INSERT INTO users (user_id, email, name, created_at) VALUES (?, ?, ?, ?)',
        params: ['user_003', 'user3@example.com', 'Bob', new Date()]
      }
    ];
    
    await client.executeConcurrent(queries);
    console.log('Inserted multiple rows');

    // 集計クエリ（Cassandra 3.0+）
    const countResult = await client.execute(
      'SELECT COUNT(*) as count FROM users'
    );
    console.log('Total users:', countResult.rows[0].count);

  } finally {
    await client.shutdown();
  }
})();

インデックス戦略

インデックスタイプ

インデックス作成例

-- セカンダリインデックス（シングルカラム）
CREATE INDEX IF NOT EXISTS idx_users_email ON myapp.users (email);
CREATE INDEX IF NOT EXISTS idx_users_age ON myapp.users (age);

-- セカンダリインデックス（マップキー）
CREATE TABLE user_preferences (
  user_id TEXT PRIMARY KEY,
  prefs MAP<TEXT, TEXT>
);

CREATE INDEX IF NOT EXISTS idx_prefs_lang ON user_preferences (KEYS(prefs));

-- セカンダリインデックス後のクエリ
SELECT * FROM myapp.users WHERE email = 'user@example.com';

-- ❌ 注意：複数セカンダリインデックス AND は避ける
-- SELECT * FROM myapp.users WHERE email = 'user@example.com' AND age = 30;
-- → メモリ消費が増加、ホットパーティション化

-- ✅ 代替：パーティションキーを含める
CREATE TABLE users_by_age (
  age INT,
  user_id TEXT,
  email TEXT,
  PRIMARY KEY (age, user_id)
);

パーティショニング・レプリケーション

レプリケーション戦略

Single Region Strategy (推奨):
  3 ノード以上の同一リージョン内レプリケーション
  └─ 各レコードが 3 つのノードに複製
  └─ 1 ノード障害でも可用性確保

Multi Region Strategy:
  複数リージョンへのレプリケーション
  └─ Keyspaces: マルチリージョン読み取りレプリカ対応

マルチリージョン設定

# グローバルテーブル作成（マルチリージョン）
aws cassandra create-keyspace \
  --keyspace-name "global_keyspace" \
  --replication-strategy "MultiRegionStrategy" \
  --region us-east-1

# レプリケーション構成
aws cassandra update-keyspace \
  --keyspace-name "global_keyspace" \
  --replication-strategy "MultiRegionStrategy" \
  --replica-region us-west-1 \
  --replica-region eu-west-1

変更ストリーム（変更データキャプチャ - CDC）

CDC Streams（2025 年 7 月）は、テーブルの挿入・更新・削除をリアルタイムでキャプチャ。

Keyspaces テーブル
    ↓ (CDC Streams: 行レベル変更)
Kinesis Data Streams
    ↓ (トリガー)
Lambda Function
    ├─→ OpenSearch (検索インデックス同期)
    ├─→ S3 (データレイク)
    ├─→ Redshift (ウェアハウス)
    └─→ 外部システム（API 呼び出し）

CDC 有効化

# テーブル作成時に CDC 有効化
aws cassandra create-table \
  --keyspace-name "myapp" \
  --table-name "users" \
  --schema-definition {...} \
  --cdc-mode "NEW_AND_OLD_IMAGES"

# 既存テーブルで CDC 有効化
aws cassandra update-table \
  --keyspace-name "myapp" \
  --table-name "users" \
  --cdc-mode "NEW_AND_OLD_IMAGES"

CDC データの処理

import boto3
import json

kinesis = boto3.client('kinesis')

# Kinesis ストリーム読み取り
response = kinesis.get_shard_iterator(
    StreamName='keyspaces-cdc-stream',
    ShardId='shardId-000000000000',
    ShardIteratorType='LATEST'
)

shard_iterator = response['ShardIterator']

while shard_iterator:
    response = kinesis.get_records(
        ShardIterator=shard_iterator,
        Limit=100
    )
    
    for record in response['Records']:
        change_data = json.loads(record['Data'])
        
        print(f"Operation: {change_data['OperationType']}")
        print(f"Table: {change_data['TableName']}")
        print(f"Timestamp: {change_data['Timestamp']}")
        
        if change_data['OperationType'] == 'INSERT':
            new_image = change_data['NewImage']
            # OpenSearch / S3 へ送信
        elif change_data['OperationType'] == 'UPDATE':
            old_image = change_data['OldImage']
            new_image = change_data['NewImage']
            # 差分を処理
        elif change_data['OperationType'] == 'DELETE':
            old_image = change_data['OldImage']
            # 削除処理
    
    shard_iterator = response.get('NextShardIterator')

マルチリージョンレプリケーション

マルチリージョンレプリケーション（2025 年 11 月拡張）により、グローバルユーザーへのレイテンシを最適化。

Primary Region (Tokyo)
    └── Keyspace (読み書き)
        └── Table: users, events, products
           ↓
           Replication Stream
           ↓
Secondary Region (Singapore)
    └── Keyspace (読み取り）
        └── Table: users, events, products

Secondary Region (Sydney)
    └── Keyspace (読み取り)
        └── Table: users, events, products

RPO: < 1 秒
RTO: < 1 分

マルチリージョン設定

# グローバルキースペース作成
aws cassandra create-keyspace \
  --keyspace-name "global_app" \
  --replication-strategy "MultiRegionStrategy" \
  --region us-east-1

# セカンダリリージョン追加（シンガポール）
aws cassandra update-keyspace \
  --keyspace-name "global_app" \
  --add-replica-region ap-southeast-1

# セカンダリリージョン追加（シドニー）
aws cassandra update-keyspace \
  --keyspace-name "global_app" \
  --add-replica-region ap-southeast-2

# Multi-Region UDTs 対応（2025 年 3 月）
CREATE TYPE IF NOT EXISTS global_app.address AS (
  street TEXT,
  city TEXT,
  zipCode TEXT
);

-- グローバルテーブルで UDT 使用
CREATE TABLE IF NOT EXISTS global_app.users (
  user_id TEXT PRIMARY KEY,
  address FROZEN<address>,
  created_at TIMESTAMP
);

バックアップ・PITR・復元

バックアップタイプ

Point-in-Time Recovery（PITR）
    ├─ 最大 35 日まで復元可能
    ├─ 継続的トランザクションログ保存
    └─ AWS Backup との統合

On-Demand Backups
    ├─ 手動作成
    ├─ 削除まで保持
    └─ 別アカウント・別リージョンに復元可

PITR 復元

# PITR バックアップの有効化
aws cassandra update-keyspace \
  --keyspace-name "myapp" \
  --point-in-time-recovery-enabled true

# PITR からの復元
aws cassandra restore-table \
  --keyspace-name "myapp" \
  --table-name "users" \
  --restore-timestamp "2024-04-26T12:30:00Z"

# オンデマンドバックアップ作成
aws cassandra create-backup \
  --keyspace-name "myapp" \
  --table-name "users" \
  --backup-name "users-backup-2024-04-26"

# バックアップから復元
aws cassandra restore-table \
  --keyspace-name "myapp" \
  --table-name "users-restored" \
  --backup-arn "arn:aws:cassandra:us-east-1:123456789012:backup/users-backup-2024-04-26"

セキュリティ

ネットワークセキュリティ

# VPC エンドポイント設定（PrivateLink）
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name "com.amazonaws.us-east-1.cassandra" \
  --vpc-endpoint-type "Interface" \
  --subnet-ids subnet-12345678 subnet-87654321

IAM 認証

# IAM ポリシー例
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cassandra:Select",
        "cassandra:Modify"
      ],
      "Resource": "arn:aws:cassandra:*:*:keyspace/myapp/*"
    },
    {
      "Effect": "Allow",
      "Action": "cassandra:Connect",
      "Resource": "arn:aws:cassandra:*:*:table/myapp/*"
    }
  ]
}

# Cassandra ドライバーで SigV4 認証
from cassandra.cluster import Cluster
from cassandra_sigv4.auth import SigV4AuthProvider
from boto3 import Session

auth_provider = SigV4AuthProvider(
    Session(),
    region_name='us-east-1'
)

cluster = Cluster(
    contact_points=['cassandra.us-east-1.amazonaws.com'],
    auth_provider=auth_provider,
    port=9142,
    ssl_context=SSLContext(PROTOCOL_TLSv1_2)
)

session = cluster.connect('myapp')

暗号化

# KMS 暗号化を有効化
aws cassandra update-keyspace \
  --keyspace-name "myapp" \
  --encryption-specification "KmsKeyArn=arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"

性能チューニング

ホットパーティション対策

❌ 悪い例：
CREATE TABLE global_settings (
  setting_key TEXT PRIMARY KEY,
  value TEXT
);
-- すべてのレコードが 1 パーティションに集中

✅ 良い例：
CREATE TABLE global_settings (
  bucket INT,
  setting_key TEXT,
  value TEXT,
  PRIMARY KEY (bucket, setting_key)
);

-- クエリ時に複数 bucket を並列クエリ
SELECT * FROM global_settings WHERE bucket IN (1, 2, 3, 4, 5);

クエリ最適化

-- ALLOW FILTERING は避ける（メモリ消費増）
❌ SELECT * FROM users WHERE age = 30 ALLOW FILTERING;

-- パーティションキーでクエリ
✅ SELECT * FROM users WHERE user_id = 'user_001';

-- クラスタリングキーでの範囲クエリ
✅ SELECT * FROM events WHERE device_id = 'dev_001' AND timestamp > '2024-04-26';

-- セカンダリインデックス使用（単一カラム）
✅ CREATE INDEX idx_status ON users (status);
   SELECT * FROM users WHERE status = 'active';

CloudWatch メトリクス監視

# CPU 利用率
aws cloudwatch get-metric-statistics \
  --namespace AWS/Cassandra \
  --metric-name CPUUtilization \
  --dimensions Name=KeyspaceName,Value=myapp \
  --start-time 2024-04-25T00:00:00Z \
  --end-time 2024-04-26T00:00:00Z \
  --period 300 \
  --statistics Average,Maximum

# ユーザー エラー率
aws cloudwatch get-metric-statistics \
  --namespace AWS/Cassandra \
  --metric-name UserErrors \
  --dimensions Name=KeyspaceName,Value=myapp \
  --statistics Sum

コスト最適化

コスト構造

月額費用（オンデマンド）= (読み取りユニット × $0.25) + (書き込みユニット × $1.25) + ストレージ

月額費用（プロビジョンド）= (RCU × $0.00013/時間) + (WCU × $0.00065/時間) + ストレージ

例：
  オンデマンド：1 百万読み取り + 1 百万書き込み = $250 + $1,250 = $1,500/月
  プロビジョンド：100 RCU + 100 WCU = $94 + $470 = $564/月
  
  ✅ 安定した負荷 → プロビジョンド推奨
  ✅ スパイク・不規則 → オンデマンド推奨

コスト削減パターン

# ✅ WarmThroughput でスケーリング効率化（2026 年 2 月）
aws cassandra update-table \
  --keyspace-name "myapp" \
  --table-name "users" \
  --warm-throughput "ReadCapacityUnits=200,WriteCapacityUnits=200"

# ✅ TTL で古いデータ自動削除
ALTER TABLE myapp.events WITH default_time_to_live = 2592000;  -- 30 日

# ✅ プロビジョンド + Auto Scaling で最適化
# ターゲット CPU 利用率を 70% に設定

主要ユースケース

設定・操作の具体例

CLI 例

# キースペース作成（プロビジョンド）
aws cassandra create-keyspace \
  --keyspace-name "production" \
  --replication-strategy "SingleRegionStrategy" \
  --region us-east-1

# テーブル作成（時系列データ）
aws cassandra create-table \
  --keyspace-name "production" \
  --table-name "metrics" \
  --schema-definition '{
    "allColumns": [
      {"name": "host_id", "type": "text"},
      {"name": "timestamp", "type": "timestamp"},
      {"name": "cpu_usage", "type": "double"},
      {"name": "memory_usage", "type": "double"}
    ],
    "partitionKeys": [{"name": "host_id"}],
    "clusteringKeys": [
      {"name": "timestamp", "orderBy": "DESC"}
    ]
  }' \
  --capacity-mode "PROVISIONED" \
  --provisioned-throughput-settings "ReadCapacityUnits=100,WriteCapacityUnits=500" \
  --default-time-to-live 2592000

Python SDK 例

from cassandra.cluster import Cluster
from cassandra.auth import PlainTextAuthProvider
from cassandra_sigv4.auth import SigV4AuthProvider
from boto3 import Session

# SigV4 認証で接続
auth = SigV4AuthProvider(Session(), region_name='us-east-1')
cluster = Cluster(
    contact_points=['cassandra.us-east-1.amazonaws.com'],
    auth_provider=auth,
    port=9142
)
session = cluster.connect('production')

# データ挿入
session.execute(
    """
    INSERT INTO metrics (host_id, timestamp, cpu_usage, memory_usage)
    VALUES (%s, %s, %s, %s)
    """,
    ['host_001', datetime.utcnow(), 45.5, 72.3]
)

# クエリ
rows = session.execute(
    "SELECT * FROM metrics WHERE host_id = %s AND timestamp > %s",
    ['host_001', datetime.utcnow() - timedelta(hours=1)]
)

for row in rows:
    print(row)

Cassandra・DynamoDB 比較

ベストプラクティス

テーブル設計

✅ 推奨パターン

• パーティションキーは高カーディナリティ（均等分散）
• クラスタリングキーで時系列・ソートを実装
• TTL で古いデータ自動削除
• セカンダリインデックスは限定的使用

❌ アンチパターン

• ホットパーティション（1 パーティションに集中）
• パーティションキー指定なしの全テーブルスキャン
• 複数セカンダリインデックス AND（メモリ消費増）

運用

✅ 推奨パターン

• オンプレミス Cassandra からの段階的移行
• CDC で変更をリアルタイム同期
• CloudWatch でメトリクス監視
• PITR で定期的なリカバリテスト

❌ アンチパターン

• ALLOW FILTERING の多用
• バックアップなし（PITR 機能を活用せず）
• キャパシティ設定不適切（コスト最適化なし）

トラブルシューティング

2025-2026 最新動向

Change Data Capture（CDC）Streams（2025 年 7 月）

• 行レベル変更のリアルタイムキャプチャ
• 24 時間保持、自動スケーリング対応
• Kinesis 統合で外部システム同期

WarmThroughput によるプリウォーミング（2026 年 2 月）

• ピークトラフィック事前指定で遅延なしスケーリング
• プロビジョンド・オンデマンド両モード対応
• スケーリング効率向上・エラー削減

マルチリージョン拡張（2025 年 11 月）

• 中東（バーレーン）・アジア太平洋（香港）リージョン対応
• Multi-Region UDTs サポート
• グローバルアプリのレイテンシ最適化

非同期レンジ削除（2026 年 7 月）

• Range delete 操作の非同期処理化
• バックグラウンド削除でクエリへの影響削減

学習リソース

公式ドキュメント

• Amazon Keyspaces Developer Guide
• CQL Reference
• Cassandra Drivers

Cassandra リソース

• Apache Cassandra Official Docs
• DataStax Cassandra Driver
• Cassandra Best Practices

AWS リソース

• AWS Keyspaces Samples
• AWS Database Blog

実装チェックリスト

導入前の検討事項

• [ ] 既存 Cassandra ワークロードの存在確認
• [ ] CQL・ドライバー互換性の検証
• [ ] スキーマ・パーティション戦略の設計
• [ ] DynamoDB との比較検討（AWS ネイティブ vs Cassandra 互換性）
• [ ] グローバル展開・マルチリージョンレプリケーション必要性確認

クラスター構築

• [ ] キースペース作成・レプリケーション戦略設定
• [ ] テーブル設計・パーティション/クラスタリングキー定義
• [ ] インデックス戦略（セカンダリインデックスの最小化）
• [ ] TTL 設定（古いデータの自動削除）
• [ ] バックアップ・PITR 有効化

開発フェーズ

• [ ] Cassandra ドライバーのセットアップ
• [ ] コネクションプーリング設定
• [ ] IAM 認証（SigV4）の実装
• [ ] エラーハンドリング・リトライロジック
• [ ] パフォーマンステスト・負荷テスト

本番運用

• [ ] CloudWatch メトリクス監視（CPU・ストレージ・スループット）
• [ ] CDC Streams でのリアルタイム同期設定
• [ ] バックアップ・復旧テストの定期実施
• [ ] WarmThroughput でのスケーリング効率化
• [ ] セキュリティ・監査ログ（CloudTrail）確認

まとめ

Amazon Keyspaces は 「オンプレミス Cassandra 環境を最小変更で AWS に移行するサーバーレス Wide-Column データベース」 です。CQL・Cassandra ドライバーがそのまま使用でき、自動スケーリング・キャパシティ管理不要・エンタープライズセキュリティが統合されています。

選ぶべき場合：

• 既存 Cassandra ワークロードを AWS に移行
• CQL が必須（DynamoDB API ではなく）
• Wide-Column データモデルが要件
• マルチリージョンレプリケーション必要

避けるべき場合：

• 新規構築・AWS ネイティブ NoSQL → DynamoDB
• リレーショナルデータ・複雑 JOIN → RDS / Aurora
• Cassandra 知識がない・学習コスト高い

2025 年の CDC Streams と 2026 年の WarmThroughput により、リアルタイムデータ同期とスケーリング効率が大幅に向上。既存 Cassandra ユーザーにとって、AWS への移行メリットが一層高まっています。

最終更新：2026-04-26 バージョン：v2.0