Cassandra 互換データベース - Amazon Keyspaces で実現するサーバーレスな分散データベース
Amazon Keyspaces (for Apache Cassandra) と DynamoDB を活用した分散データベースの設計・運用方法を解説します。
Apache Cassandra と Amazon Keyspaces の位置づけ
Apache Cassandra は大規模な分散データベースとして、高い書き込みスループット、線形スケーラビリティ、マルチリージョンレプリケーションを特徴とする NoSQL データベースです。書き込みが集中する時系列データやイベントログ、メッセージ履歴のような用途で大規模サービスの基盤として広く使われてきましたが、オンプレミスでの運用には高度な専門知識が求められます。ノードの追加・削除時のデータリバランス、コンパクション戦略の最適化、トゥームストーンの管理、JVM のチューニングなど、運用タスクは多岐にわたります。Amazon Keyspaces は Apache Cassandra 互換のフルマネージドデータベースサービスで、CQL (Cassandra Query Language) をそのまま使用できます。既存の Cassandra アプリケーションのドライバーとツールをほぼ無修正で利用でき、運用負荷を大幅に削減しながら Cassandra のデータモデルとクエリパターンを維持できます。サーバーレスアーキテクチャにより、テーブルの作成後すぐにデータの読み書きが可能で、キャパシティの事前プロビジョニングは不要です。
Amazon Keyspaces の特徴とアーキテクチャ
Amazon Keyspaces はサーバーレスで動作し、テーブルのスループットはトラフィックに応じて自動的にスケールします。オンデマンドモードでは読み書きリクエストに対する従量課金で、トラフィックが少ない時間帯のコストを最小化できます。プロビジョンドモードでは予測可能なワークロードに対してコスト効率の高い料金設定が可能です。ストレージは自動的に拡張され、データはリージョン内の 3 つのアベイラビリティゾーンにレプリケーションファクター 3 で複製されます。可用性 SLA は構成によって 2 段階に分かれており、公式 SLA (2023 年 5 月 24 日更新版) の Service Commitment は、単一リージョン構成に適用される Standard SLA が月間稼働率 99.99%、多リージョンレプリケーションを構成した場合に適用される Multi-Region Replication SLA が 99.999% と定められています。3 AZ への複製は単一リージョン内の耐久性を支える仕組みであり、それ自体が 99.999% の根拠になるわけではない点に注意してください。暗号化は保存時と転送時の両方でデフォルトで有効になっており、AWS KMS によるカスタマーマネージドキーの使用も可能です。Keyspaces は CQL 3.11 API (2.x と後方互換) に対応し、テーブル定義、データ型、クエリ構文は Cassandra と互換性があります。軽量トランザクション (LWT) による条件付き書き込み (IF NOT EXISTS など) と counter 型はいずれもサポート対象で、LWT の利用に追加料金はかかりません。ただし条件判定が FALSE になった書き込みは行サイズに応じた書き込みユニットを消費するため、CloudWatch の ConditionalCheckFailed メトリクスで失敗数を監視します。公式の対応表 (2026 年 8 月時点) で非対応とされているのは、セカンダリインデックス (CREATE INDEX / DROP INDEX)、マテリアライズドビュー、トリガー、ユーザー定義関数 (UDF) と集計関数、ALTER TYPE、TRUNCATE などです。静的カラム、TTL、LOGGED / UNLOGGED BATCH、ユーザー定義型 (UDT) は利用できます。Point-in-Time Recovery (PITR) により、過去 35 日間の任意の時点にテーブルを復元でき、誤操作やデータ破損からの回復が容易です。以下は Keyspaces でテーブルを作成する CQL の例です。 CREATE TABLE my_keyspace.orders ( customer_id text, order_id timeuuid, product_name text, quantity int, total_amount decimal, PRIMARY KEY (customer_id, order_id) ) WITH CLUSTERING ORDER BY (order_id DESC) AND CUSTOM_PROPERTIES = {'capacity_mode': {'throughput_mode': 'PAY_PER_REQUEST'}};
Cassandra から Keyspaces への移行戦略
既存の Cassandra クラスターから Keyspaces への移行は、段階的なアプローチが推奨されます。まず cqlsh や DataStax ドライバーを使用して Keyspaces への接続を検証し、スキーマの互換性を確認します。データ移行には AWS Glue を使用したバッチ移行と、デュアルライト (両方のデータベースに同時書き込み) による段階的移行の 2 つのアプローチがあります。 Glue を使用する場合、 Cassandra からデータを読み取り、 Keyspaces に書き込む ETL ジョブを構成します。大規模なデータセットの移行では、 Keyspaces のプロビジョンドモードで十分な書き込みキャパシティを確保し、移行完了後にオンデマンドモードに切り替えるのが効率的です。アプリケーション側の変更は最小限で済みます。接続エンドポイントの変更と、 TLS 接続の設定 (Keyspaces は TLS が必須) が主な変更点です。移行時のパフォーマンステストでは、 Keyspaces の一貫性レベルの扱いを踏まえた検証が重要です。書き込みは耐久性のため常に LOCAL_QUORUM で実行され、読み取りは ONE / LOCAL_ONE / LOCAL_QUORUM の 3 段から選択します (既定値はドライバー側の設定で決まるため、明示的な指定が安全です)。4 KB の読み取り 1 回あたりの消費は ONE / LOCAL_ONE が 0.5 ユニット、 LOCAL_QUORUM が 1 ユニットと差があるため、一貫性の要件とレイテンシ・コストのトレードオフを移行前に確認しておきます。
Keyspaces と DynamoDB の使い分け
AWS で分散データベースを選択する際、Keyspaces と DynamoDB はどちらも候補になります。Keyspaces は既存の Cassandra アプリケーションの移行先として最適で、CQL の知識とスキルをそのまま活用できます。複合パーティションキーやクラスタリングカラムによる柔軟なデータモデリング、TTL (Time to Live) によるデータの自動期限切れ、静的カラムによるパーティションレベルの共有データなど、Cassandra 固有のデータモデリングパターンを維持できます。Keyspaces 側も多リージョンレプリケーションに対応しており、アクティブ・アクティブ構成で各リージョンが独立して読み書きを処理し、競合は last writer wins で自動調停されます。リージョン間のレプリケーション遅延は通常 1 秒未満、リージョン障害時の RPO は数秒台で、フェイルオーバーは Route 53 によるルーティング切り替えで済みます (昇格やフェイルオーバー操作は不要)。ただし公式ドキュメント (2026 年 8 月時点) に記載された制約として、TTL は多リージョンテーブルの作成時に設定する必要があり後から有効化・無効化や値の変更ができない、保存時暗号化は AWS 所有キーのみでカスタマーマネージドキーは使えない、同期レプリケーションや QUORUM 一貫性は非対応、AWS GovCloud (US) と中国リージョンは対象外、といった点があります。一方 DynamoDB は AWS ネイティブのサービスとして、Lambda、AppSync、API Gateway などとのシームレスな統合を提供します。DynamoDB Streams によるイベント駆動アーキテクチャ、グローバルテーブル、DAX (DynamoDB Accelerator) によるマイクロ秒レベルのキャッシュなど、AWS エコシステムとの統合が強みです。新規開発で Cassandra の経験がないチームには DynamoDB を、既存の Cassandra ワークロードの移行には Keyspaces を推奨します。両サービスとも IAM 認証、VPC エンドポイント、暗号化をサポートし、エンタープライズレベルのセキュリティ要件を満たします。
Keyspaces の料金
以下は 2026 年 8 月時点の AWS 公式料金表に基づく単価で、バージニア北部 (us-east-1) と東京 (ap-northeast-1) を併記します。オンデマンドモードは読み取り 100 万リクエストユニットあたり 0.125 USD (バージニア北部) / 0.1425 USD (東京)、書き込み 100 万リクエストユニットあたり 0.625 USD (バージニア北部) / 0.715 USD (東京) です。プロビジョンドモードは月額ではなく時間単価での課金で、読み取りキャパシティユニット (RCU) 1 単位あたり 0.00013 USD/時 (バージニア北部) / 0.0001484 USD/時 (東京)、書き込みキャパシティユニット (WCU) 1 単位あたり 0.00065 USD/時 (バージニア北部) / 0.000742 USD/時 (東京) です。単価は書き込み側が読み取り側の約 5 倍で、730 時間の月換算ではバージニア北部で RCU 1 単位が約 0.095 USD、WCU 1 単位が約 0.475 USD になります。ストレージは 1 GB あたり月額 0.25 USD (バージニア北部) / 0.285 USD (東京)、PITR 用のバックアップストレージは 1 GB あたり月額 0.20 USD (バージニア北部) / 0.228 USD (東京)、TTL による自動削除は 100 万件あたり 0.275 USD (バージニア北部) / 0.315 USD (東京)、バックアップからの復元は 1 GB あたり 0.15 USD (バージニア北部) / 0.171 USD (東京) です。リージョン間では東京がバージニア北部より 1 割から 2 割ほど高い水準にあるため、レイテンシ要件が許すならリージョン選択自体がコスト差になります。DynamoDB と料金体系はほぼ同等ですが、CQL でアクセスできるため既存 Cassandra ワークロードの移行コストが低い点がメリットです。
まとめ - Cassandra 互換データベースの最適な選択
Cassandra の移行先としての Keyspaces と、AWS ネイティブの DynamoDB を、ワークロードの特性と既存資産に応じて使い分けることで、最適な分散データベース戦略を構築できます。CQL 互換が必要な場合は Keyspaces、サーバーレスの柔軟性を重視する場合は DynamoDB が適しています。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。