LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

ワイドカラム型NoSQLとは何か

Cassandra/ScyllaDBのワイドカラム型NoSQLとは、行ごとに異なる数の列を持てる分散データベースの一種で、パーティションキーを軸に大量の書き込みを複数ノードへ分散させる仕組みを指します。IPA等の一般的な定義とは別に、Apache Cassandra公式ドキュメントでは、テーブルの主キーを「パーティションキー」と「クラスタリングキー」に分けて定義し、この構造がデータの配置と検索の起点になるとしています^*1。

Apache Cassandraはオープンソースの分散データベースで、単一障害点を持たない設計と、複数のデータセンターにまたがるレプリケーションを特徴とします^*2。ScyllaDBは、高いパフォーマンスと低レイテンシーを求めるデータ集約型アプリケーション向けの分散NoSQLワイドカラムデータベースとして提供されており、Cassandraと互換性のあるプロトコルを採用しています^*3。

両者とも、行と列という表形式のデータモデルを持ちながら、RDB（リレーショナルデータベース）のようなJOINやトランザクションの豊富さよりも、書き込みのスケーラビリティと高可用性を優先する設計思想を採っています。次章以降で、その分散アーキテクチャの具体的な仕組みを見ていきます。

マスターレス・リング構造という分散の仕組み

Cassandraのアーキテクチャは、Amazon Dynamoの設計思想を継承しており、マルチマスターレプリケーションを採用しています。すべてのレプリカが独立して書き込みを受け付けられるため、特定のノードが停止してもクラスタ全体の書き込みが止まらない構成になっています^*4。この「マスターレス」という特性が、RDBのプライマリ・レプリカ構成と最も異なる点です。

データの配置には、コンシステントハッシングという手法が使われます。各ノードはトークンリング上に位置づけられ、パーティションキーをハッシュ関数（既定ではMurmur3）で計算した値に基づいて、リングを時計回りにたどることで担当ノードが決まります^*4*5。この仕組みにより、ノードの追加・削除時もデータ全体を再配置せず、担当範囲の一部だけを移動させれば済みます。

また、単一トークンの制約を避けるため、1台の物理ノードに複数のトークン（Virtual Node、vnode）を割り当てる方式が採られています。ScyllaDBも同様にvnode方式を採用し、既定では1ノードあたり256個のトークンを割り当てる設定になっています^*5。レプリケーション戦略には、データセンターごとに複製数を指定するNetworkTopologyStrategyと、単一の複製係数（レプリケーションファクタ）をクラスタ全体に適用するSimpleStrategyがあります^*4。

パーティションキーとクラスタリングキーの設計

Cassandraのテーブル設計では、主キーを「パーティションキー」と「クラスタリングキー」に分けて考えます。パーティションキーは、どのノードにデータを配置するかを決める必須要素であり、想定するクエリの条件に合わせて選ぶ必要があります^*1。同じパーティションキーを持つ行は、常に同じレプリカ群に格納される決まりです^*1。

クラスタリングキーは、パーティション内での行の一意性を保証し、あわせてディスク上の並び順（ソート順）を決める役割を持ちます^*1。公式ドキュメントの例では、ホテル検索を想定したテーブルにおいて、チェックイン日をクラスタリングキーに設定し、日付範囲での絞り込みを高速化する設計が示されています^*1。

この設計思想は、RDBの正規化とは方向性が異なります。RDBでは正規化してJOINで結合しますが、Cassandra/ScyllaDBでは想定クエリごとにテーブルを非正規化して作る「クエリファーストモデリング」が基本です。既存のRDBスキーマをそのまま移植すると、パーティションが巨大化してホットスポット（特定ノードへの負荷集中）を生む失敗パターンが起きやすく、この点は導入初期に見落とされがちです。

結果整合性とチューナブル整合性の考え方

Cassandra/ScyllaDBは、書き込みが全レプリカに反映されるまで一定の時間差が生じる「結果整合性（eventually consistent）」を前提としたシステムです^*2。ただし、常に緩い整合性しか選べないわけではなく、読み書きごとに整合性の強さを指定できる「チューナブル整合性」が用意されています。

整合性レベルとは、コーディネータが読み書き操作を成功と判断するまでに、応答を必要とするノード数を指します。主なレベルには、1台の応答で成立するONE、過半数（レプリケーションファクタの半数を超える数）の応答を要するQUORUM、全レプリカの応答を要するALLなどがあります^*6。

書き込み時の整合性レベルをW、読み取り時をR、レプリケーションファクタをRFとすると、W+R>RFの関係を満たす組み合わせを選ぶことで、読み取り時に最新の書き込みを一貫して参照できる設計が可能になります^*4。たとえばRF=3の場合、書き込みQUORUM・読み取りQUORUMの組み合わせは2+2>3を満たすため、強い整合性に近い挙動が得られます。整合性レベルの選択は、レイテンシーと正確性のどちらを優先するかを業務要件ごとに判断する必要があり、外部の技術者に丸投げしにくい設計判断の一つです。

CassandraとScyllaDBの実装思想の違い

CassandraとScyllaDBは、CQL（Cassandra Query Language）や通信プロトコルの互換性を保ちながら、内部実装の考え方が異なります。Cassandraは、Java Virtual Machine（JVM、Javaプログラムを実行する仮想環境）上で動作するJava実装です。一方ScyllaDBは、C++で書かれたオープンソースの非同期I/Oフレームワーク「Seastar」を基盤に構築されています^*7。

Seastarの特徴は「shard-per-core」という設計です。CPUコアごとに専用のメモリ・キャッシュ・ネットワークI/Oを割り当て、コア間はロックを使わずメッセージパッシングでやり取りします^*7。この設計により、コア数が増えるほどリニアに性能を伸ばしやすく、GC(ガベージコレクション、不要になったメモリ領域を自動的に回収する仕組み)の一時停止によるレイテンシー悪化を避けやすい構造になっています。

ScyllaDBは、クラスタ構成をノードの集合として環状に可視化する「リングアーキテクチャ」を採用し、共有ディスクを持たないシェアードナッシング構成を前提としています^*8。パーティショナーがパーティションキーをハッシュ化してリング上の配置を決める仕組みは、Cassandraと基本的な考え方を共有しています^*8。両者ともにCQLドライバの互換性があるため、既存のCassandra運用知識をある程度ScyllaDBへ持ち込めますが、内部のチューニングパラメータやコンパクション戦略の勘所は異なるため、置き換え時には別個の検証が欠かせません。

RDBやDynamoDBとの使い分け

Cassandra/ScyllaDBの採用が向いているのは、時系列データやセンサーログ、アクセスログのような、書き込み量が読み取り量を上回る、かつ複数ノードへの水平スケールが前提になるワークロードです。マスターレス構造により、特定ノードの一時停止が全体の書き込み停止につながりにくい点も、大量書き込みを継続させたい用途に合っています。

一方、複雑なJOINやトランザクション整合性を必要とする業務システムでは、RDBの方が適しています。RDBはACID特性(Atomicity・Consistency・Isolation・Durability、トランザクションの信頼性を支える4つの性質)を前提に設計されているため、在庫や会計のように整合性を絶対視する処理には不向きな面があります。

下表は、ワイドカラム型（Cassandra/ScyllaDB）と、RDB・AWSのマネージド型NoSQLであるDynamoDBとの違いを整理したものです。DynamoDBはAWSが提供するフルマネージドのキーバリュー・ドキュメント型データベースであり、インフラ運用をAWS側に委ねられる点がCassandra/ScyllaDBの自己運用モデルとの大きな違いになります。

導入で内製が難しくなる理由

Cassandra/ScyllaDBの導入では、まずデータモデリングの発想の転換が必要になります。RDB出身のエンジニアがパーティションキーの設計を誤ると、特定パーティションへの書き込みが集中し、リングの一部ノードだけが高負荷になるホットスポットが発生します。この設計ミスは、稼働後にデータを再配置しないと解消しづらく、サービス停止を伴う移行作業に発展するおそれがあります。

クラスタ運用の面でも専門知識が求められます。ノード追加時のトークン再配分、コンパクション戦略(ディスク上のデータファイルを整理・再構成する処理)の選択、整合性レベルとレイテンシーのトレードオフ調整など、RDBの管理と異なる運用ノウハウの蓄積が必要です。内製で対応する場合、これらを1〜2名の担当者だけで抱えると、設計判断の属人化やノウハウの停滞につながりやすくなります。

専門パートナーに委託した場合と内製の場合の違いは、初期のデータモデリング検証をどれだけ手厚く行えるかに表れます。パートナー側は複数クラスタでの構築・移行経験を踏まえてパーティション設計をレビューできますが、内製の場合は本番投入後の負荷試験で問題が発覚するケースが少なくありません。導入判断は「難しいから頼む」のではなく、稼働後の設計変更リスクを抑えるために、初期段階で外部の設計レビューを組み込むという位置づけで検討するのが妥当です。

外注先を選ぶときの評価軸

Cassandra/ScyllaDBの導入を外注する際は、単なる構築代行ではなく、データモデリングの設計支援まで対応できるかを確認する必要があります。具体的には、想定クエリからパーティションキー・クラスタリングキーを設計した実績、整合性レベルの選定を業務要件に落とし込んだ経験、クラスタの監視・スケールアウト対応の体制の3点が主な確認ポイントになります。

また、CassandraとScyllaDBのどちらを選ぶかは、既存の運用チームのスキルセットや、必要とするレイテンシー要件によって変わります。JVMの運用知識が社内に蓄積されているならCassandraの継続利用が現実的な選択肢になりますし、より低いレイテンシーとハードウェア効率を求めるならScyllaDBへの移行を検討する価値があります。この判断も、両方の実装に触れた経験を持つ外部パートナーの知見を借りることで、比較検証の工数を抑えられます。

LASSIC IT事業部では、元請（プライムベンダー）としてシステムの保守・運用を受託する体制のもと、分散データベースを含むインフラ設計の相談を受け付けています。導入前の設計レビューから、稼働後の運用保守まで一貫して対応できる体制を整えています。

まとめ：Cassandra/ScyllaDB導入の3つの判断軸

本稿では、ワイドカラム型分散NoSQLであるCassandraとScyllaDBについて、分散アーキテクチャ・データモデリング・整合性設計の観点から整理しました。要点を3つに集約すると、第一にマスターレス・リング構造による書き込みスケーラビリティが主な強みであること、第二にパーティションキー設計を誤るとホットスポットのリスクを抱えること、第三に整合性レベルの選択は業務要件に応じたトレードオフ判断が必要であることです。これらの判断は導入前の設計フェーズで固める必要があり、外部の設計支援を組み込むかどうかが、稼働後の手戻りリスクを左右します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apache Cassandra「Logical data modeling」（https://cassandra.apache.org/doc/latest/cassandra/developing/data-modeling/data-modeling_logical.html）
2. *2　出典：Apache Cassandra「Overview」（https://cassandra.apache.org/doc/latest/cassandra/architecture/overview.html）
3. *3　出典：ScyllaDB「ScyllaDB Documentation」（https://docs.scylladb.com/manual/master/index.html）
4. *4　出典：Apache Cassandra「Dynamo」（https://cassandra.apache.org/doc/4.1/cassandra/architecture/dynamo.html）
5. *5　出典：ScyllaDB「Scylla Ring Architecture – Overview」（https://docs.scylladb.com/stable/architecture/ringarchitecture/）
6. *6　出典：Apache Cassandra「Cassandra Glossary」（https://cassandra.apache.org/_/glossary.html）
7. *7　出典：ScyllaDB「Why ScyllaDB’s Shard Per Core Architecture Matters」（https://www.scylladb.com/2024/10/21/why-scylladbs-shard-per-core-architecture-matters/）
8. *8　出典：ScyllaDB「Scylla Ring Architecture – Overview」（https://docs.scylladb.com/stable/architecture/ringarchitecture/）

Tweet