Amazon Keyspaces

解決する課題

• Apache Cassandraを使いたいが、クラスターの構築・パッチ適用・ノード増減といった運用を自分で抱えたくない
• アクセスが急増してもスループットを落とさず、容量計画やシャーディングを手作業でやりたくない
• 既存のCassandraアプリケーションやCQLの資産を書き換えずにマネージドへ移行したい

主要概念と用語

• キースペース: テーブルをまとめる論理的な入れ物。Cassandraのキースペースに相当する
• テーブル / 行 / カラム: ワイドカラムモデルのデータ構造。行ごとにカラム構成が柔軟に異なりうる
• パーティションキー: データの分散先を決める最重要キー。同じ値の行が同一パーティションにまとまる
• クラスタリングカラム: パーティション内での並び順や範囲検索を決めるキー
• CQL（Cassandra Query Language）: Cassandra互換のクエリ言語。SQLに似た構文で操作する
• 容量モード: スループットの課金方式で、オンデマンドとプロビジョンドを選べる
• 整合性レベル: 読み書き時に求める整合性の強さ。結果整合性と強い整合性を指定できる
• Time to Live（TTL）: 行やカラムに有効期限を設定し、期限切れで自動削除する仕組み

仕様・制限・クォータ

• サーバーレスで提供され、ノードやクラスターの管理は不要。利用した読み書きとストレージの量に応じて課金される
• 既存のCassandra用ドライバーとCQLを利用でき、Cassandraからの移行時にアプリの変更を最小化できる
• 容量はオンデマンド（自動スケール）とプロビジョンド（事前指定とオートスケーリング）から選べる
• データはマルチAZへ自動的に複製され、可用性と耐久性が確保される。マルチリージョン構成にも対応する
• 1行のサイズ、パーティションあたりのデータ量、1リクエストで扱えるサイズなどには上限がある。具体的な数値は変動するため、最新値は公式ドキュメントで確認する

内部の仕組み

Keyspacesはパーティションキーをハッシュして内部のストレージへ分散し、アクセス量に応じて自動でスケールします。Cassandra自体のリングやノードを意識する必要はなく、利用者はテーブルとキー設計に集中できます。ゆえにパーティションキー設計＝性能設計であり、特定のキーへアクセスが偏るとホットパーティションとなり、スループットが頭打ちになります。読み書きの整合性は要求ごとに指定でき、強い整合性を求めるほど内部のレプリカ調整が増えてコストや応答に影響します。

設計パターン / ベストプラクティス

• アクセスパターンを列挙し、それに合わせてパーティションキーとクラスタリングカラムを設計する
• パーティションキーにはカーディナリティが高く分散しやすい属性を選び、ホットパーティションを避ける
• スパイクが読めない、または負荷が不規則なワークロードにはオンデマンド容量を使う
• 定常的で予測可能な負荷にはプロビジョンド＋オートスケーリングでコストを抑える
• 一時的なデータにはTTLを設定し、不要データの自動削除でストレージと管理の手間を減らす
• 既存Cassandraからの移行では、CQLとドライバーの互換性を活かしつつ、容量モードや整合性レベルをKeyspacesの特性に合わせて見直す

運用・監視

• CloudWatchで読み書きの消費容量、スロットリング、エラーなどを監視する
• スロットルが出る場合はホットパーティションか容量不足を疑い、キー設計か容量モードを見直す
• 大量データを全走査する重いクエリは避け、パーティションキーで絞り込むクエリを基本にする
• プロビジョンド容量を使う場合は、オートスケーリングの上限・下限と実際の負荷の乖離を定期的に確認する
• 操作の監査にはCloudTrailを利用し、誰がいつ何をしたかを記録する

コスト

• 主なコストは読み書きのスループット（オンデマンドまたはプロビジョンド）とストレージ量
• スパイクが大きく利用が不規則ならオンデマンド、負荷が安定して予測できるならプロビジョンドが安くなりやすい
• 強い整合性の読み取りは結果整合性より割高になるため、要件に応じて整合性レベルを選ぶ
• TTLで不要データを自動削除し、ストレージコストの肥大化を防ぐ
• 料金は変動するため、最新の単価は公式の料金ページで確認する

セキュリティ

• アクセス制御はIAMで行い、最小権限の原則に従ってキースペースやテーブル単位の権限を付与する
• 保存データはKMSで暗号化され、通信はTLSで保護される
• VPCエンドポイント経由でプライベートにアクセスを構成し、ネットワーク到達範囲を絞る
• 認証には専用の認証情報やIAMベースの仕組みを用い、長期の固定資格情報の利用を避ける

Well-Architected の観点

• パフォーマンス効率: パーティションキーで自動分散・自動スケールし、高スループットなキーアクセスを安定して処理する
• 信頼性: マルチAZへの自動複製とマルチリージョン構成により、高い可用性と耐久性を確保する
• 運用上の優秀性: サーバーレスでクラスター運用やパッチ適用が不要になり、運用の手間が小さい
• コスト最適化: 容量モードと整合性レベルの使い分けで、ワークロードに応じた費用に調整する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# キースペースを作成
aws keyspaces create-keyspace \
  --keyspace-name app_keyspace

# テーブルを作成（パーティションキー=user_id, クラスタリングカラム=created_at）
aws keyspaces create-table \
  --keyspace-name app_keyspace \
  --table-name orders \
  --schema-definition 'allColumns=[{name=user_id,type=text},{name=created_at,type=timestamp},{name=amount,type=decimal}],partitionKeys=[{name=user_id}],clusteringKeys=[{name=created_at,orderBy=ASC}]' \
  --capacity-specification throughputMode=PAY_PER_REQUEST

# テーブル定義を確認
aws keyspaces get-table \
  --keyspace-name app_keyspace \
  --table-name orders