ScyllaDBとは？Cassandra互換C++実装の仕組み・ライセンス変更と採用判断を解説

ScyllaDBは、Apache CassandraのデータモデルとCQLをそのまま受け継ぎながら、実装をJavaからC++へ書き直した分散NoSQLデータベースです。CPUコアごとにシャードを割り当てるshard-per-core設計により、JVMのガベージコレクションに起因するレイテンシの揺れを構造的に持ちません。この記事では2026.1 LTS（2026年3月23日アナウンス）時点の一次情報をもとに、Seastarベースの内部設計、既定になったTabletsによるデータ分散、DynamoDB互換APIであるAlternatorの位置づけ、そして2025年に切り替わったSource Availableライセンスと無償枠の線引きを整理し、採用してよい条件と見送る場面を実装者の目線で示します。

まとめ：ScyllaDBの立ち位置と採用可否を分ける3条件

ScyllaDBは「Cassandraの互換品」ではなく「Cassandraの互換インターフェースを持つ別実装」です。アプリ側から見ればCQLもドライバも同じで、内部はC++とSeastarで書かれたシャード分割型のエンジン。同じワークロードをより少ないノードで捌ける、という主張が製品の中心にあります。

採用可否は3条件で決まります。第一に、レイテンシの平均値ではなくテールレイテンシ（P99）が業務要件になっていること。第二に、ノード台数の削減がインフラ費用の削減に直結する規模であること。第三に、無償枠の上限である合計10TB・50 vCPUに収まるか、超えるなら商用ライセンスの予算が取れること。

3つ目で止まる案件が実際には多いところです。分水嶺は、ライセンス条件を要件定義の段階で顧客と握れているかどうか。「Cassandra互換のOSS」という2023年までの前提で見積もると、稼働直前に費用が乗ります。

ScyllaDBの実体｜Cassandra互換をC++で書き直した分散NoSQL

Seastarとshard-per-core｜1コア1シャードで捌く内部設計

ScyllaDBは、ScyllaDB社（旧Cloudius Systems）が開発するワイドカラム型の分散データベースです。データモデル、CQL、レプリケーション方式といった外形はCassandraを踏襲し、実装だけをC++20と独自の非同期フレームワークSeastarへ置き換えています。

設計の核はshard-per-coreです。1つのCPUコアに1つのシャードを固定で割り当て、そのシャードが担当するデータへの読み書きをそのコアだけが処理する。コア間でロックを取り合う場面が消えるため、コア数を増やしたぶんがそのままスループットに乗ります。ディスクI/Oも汎用のページキャッシュに任せず、独自のIOスケジューラとキャッシュで制御します。

実務で効くのはJVMが無いことです。Cassandraの運用でヒープサイズやGCアルゴリズムの調整に時間を割いた経験があるなら、その工程そのものが消えると考えてください。GCの停止時間が乗らないぶん、P99やP999といったテールレイテンシが平坦になります。ただし「ノード数を5分の1から10分の1へ」という数字はベンダー公称値で、独立した検証値ではありません。自社ワークロードでの実測が前提です。

2026.1 LTSまでのリリース系列と本番で選ぶ版の判断基準

現行のLTSは2026.1で、2026年3月23日にアナウンスされました。ひとつ前の系列が2025.1で、こちらはライセンス転換後の最初のリリースにあたります。アップグレードは2025.x系の任意のマイナー版から2026.1へ直接上げられる設計です。

2026.1で入った変更のうち、設計判断に効くのは3つあります。Tabletsがcountersに対応し、TabletsとvNodesの機能差が解消されたこと。tabletベースのkeyspaceがラックのリスト形式でレプリケーション係数を指定できるようになり、配置の保証が強くなったこと。そしてインクリメンタルリペアで、前回リペア以降の差分だけを処理するようになったことです。変更量が1%程度なら約100倍速くなるとされ、リペアの所要時間が運用のボトルネックだった構成ほど効きます。ベクトル検索のフィルタリングと量子化への対応も入りましたが、こちらはScyllaDB Cloud限定の提供です。

Tabletsによるデータ分散｜vNodesから置き換わった配置設計

タブレット単位の分割とロードバランサによる自動再配置の内部動作

データ分散の方式は、Cassandra譲りのvNodesからTabletsへ置き換わりました。現行版では既定で有効です（enable_tablets）。テーブルをタブレットという単位に分割し、レプリケーション係数のぶんだけ別ノードにレプリカを持たせます。

vNodesとの違いは動的であることです。テーブルが育つと1つのタブレットが2つに分割され、ロードバランサが分割後の半分ずつを別のノードや別のシャードへ移動します。運用側から見た帰結は明確で、ノードを増やしたときにトークンレンジを手で計算し直す作業が要らなくなります。Raftによる一貫したトポロジ更新と組み合わさるため、複数ノードを同時に追加できる点も従来との差です。

Raft統合と機能ギャップ｜2026.1でcountersに対応

Tabletsは登場時点で機能ギャップを抱えていました。counters、CDC、軽量トランザクション（LWT）、Alternatorが使えず、tabletsを有効にすると機能が削れる状態だったところです。この差は段階的に埋められ、2026.1のcounters対応をもって「TabletsとvNodesの機能差の解消」と公式にアナウンスされています。

現行版で残る制約は3つです。Materialized ViewsとSecondary Indexesを使う場合、keyspaceがRF-rack-validな状態である必要があり、その状態を維持しなければなりません。ノード再起動時にシャード数を減らすリシャーディングは非対応です。そしてALTER KEYSPACEでTabletsの有効・無効を切り替えられず、変えるならkeyspaceの再作成が要ります。

3つ目が設計初期に効きます。keyspaceを作る時点でTabletsを使うかどうかを決め切る必要があり、後から方針を変えるとデータ移行を伴う。古い日本語記事の手順をそのままなぞると、vNodes前提のkeyspaceを作ってしまう場面があるため、構築前に現行版のドキュメントで既定値を確認してください。

Cassandraからの移行｜持ち込める資産と書き換えが要る点

CQLとドライバ・SSTable互換でそのまま持ち込める既存資産

移行のしやすさがScyllaDBの営業上の武器です。CQLはそのまま通り、Cassandra用のドライバ、ORM、CLI、各種コネクタが接続レベルで動きます。SSTableのファイル形式も互換のため、既存データの取り込み経路が用意されている点も大きいところです。

アプリケーションコードの観点では、クエリを書き換える作業はほぼ発生しません。パーティションキーとクラスタリングキーの設計思想も同じで、クエリ起点でテーブルを設計する前提は変わらない。データモデリングの基礎はCassandraの仕組みとデータモデルで整理しているため、設計そのものに不安があるならそちらを先に読んでください。

JVMチューニングが消える代わりに増える運用作業と監視項目の違い

一方で、運用の中身は入れ替わります。消えるのはヒープとGCの調整、そしてJavaのバージョン管理。増えるのは、シャード単位でのリソース監視です。

shard-per-coreはコア間で負荷を融通しない設計のため、パーティションキーが偏ると特定のシャードだけが飽和します。ノード全体のCPU使用率は50%なのに応答が遅い、という症状はここから来る。監視ダッシュボードをノード単位のままにしておくと原因に辿り着けないため、シャード単位のメトリクスを最初から取ってください。

設定ファイルの互換性も完全ではありません。scylla.yamlはCassandraのcassandra.yamlと多くの項目が共通する一方、JVM関連の設定は存在せず、代わりにCPUピニングやIOスケジューラの項目が加わります。運用スクリプトを流用する計画なら、nodetool相当のコマンド体系も含めて差分の洗い出しを先に済ませるべきところです。

Alternator｜DynamoDB互換APIとして使うときの前提条件

alternator_write_isolationで決まる書き込みの整合性設定

ScyllaDBにはもう1つの入口があります。DynamoDB互換APIのAlternatorです。CQLではなくDynamoDBのAPIでアクセスでき、AWS SDKのDynamoDBクライアントの接続先を差し替える形で使えます。

起動には最低2つの設定が要ります。APIを受けるポート番号を指定するalternator_portと、書き込みの隔離方式を決めるalternator_write_isolationです。後者はonly_rmw_uses_lwt、always、forbid、unsafeから選びます。HTTPSで受けるならalternator_https_portと証明書・秘密鍵の配置が加わります。

読み取りの一貫性はCQL側の整合性レベルに対応づけられており、強い一貫性を求める読み取りはLOCAL_QUORUM、結果整合の読み取りはLOCAL_ONEで実装されています。read-modify-write操作は軽量トランザクション（LWT）で隔離される。ここは性能に直結するため、unsafeを選んで速度を出す構成にすると、条件付き更新の保証が失われます。

DynamoDBから移す判断｜Alternatorが向く条件と外れる条件

Alternatorが刺さるのは、DynamoDBのAPIに依存したコードを抱えたまま、AWS外へ動かしたい案件です。オンプレミスや他クラウドへの配置、あるいは自己ホストによる費用構造の変更が目的なら、アプリ側の書き換えを最小に抑えられます。

逆に外れるのは、DynamoDB StreamsやDAX、IAMベースの細粒度な認可といったAWS固有の周辺機能に深く依存している構成です。互換性は「ほぼ完全」と公式に表現されている一方、差異と未実装機能があることも同じドキュメントに明記されている。移行判断の前に、実際に使っているAPI呼び出しを洗い出し、差異の一覧と突き合わせる工程を必ず挟んでください。DynamoDB側の前提はDynamoDBの特徴と料金の解説に整理しています。

2025年のライセンス変更｜無償枠10TBと50vCPUの線引き

AGPL 6.2.xで終わったOSS版とSource Availableへの転換

日本語の解説で最も情報が古いのがここです。ScyllaDBは長くAGPLのOSS版と有償Enterpriseの二本立てでしたが、2024年12月にライセンス転換が発表され、ScyllaDB Enterprise 2025.1（2025年第1四半期）からSource Availableへ切り替わりました。

OSS版の側は、ScyllaDB Open Source 6.2.xがAGPLの最終マイナー版とされています。以降のAGPLリリース予定はなく、リリースの流れはEnterprise系列へ一本化された。「ScyllaDBはOSSだから自由に使える」という説明を載せた記事は、この転換より前に書かれたものだと考えてください。

無償枠10TB・50vCPUの条件と受託案件での見積もり判定

転換と引き換えに、フル機能のEnterpriseに無償枠が用意されました。条件は組織単位で、全ScyllaDBサーバのディスク容量の合計が10TBまで、全クラスタを通じた仮想CPU（ハイパースレッドを含む）の合計が50 vCPUまでです。この範囲なら、以前は有償だった性能・効率・セキュリティ機能も含めて無償で使えます。

受託開発で見落としやすいのは、この枠が「組織単位の合計」である点です。本番と非本番の区別がないため、開発・ステージング・本番を並べた構成では、検証環境のvCPUも同じ50の枠を食う。レプリケーション係数3で実データ4TBを持つなら、ストレージ側は12TBとなり枠を超えます。要件定義の段階でレプリカ込みの容量と全環境のvCPU合計を積み上げ、有償前提かどうかを見積書に明記してください。条項の遵守は現時点で信頼ベースとされていますが、将来的なライセンスマネージャ導入にも言及があります。

マネージド側はScyllaDB Cloudで、AWSとGCPをホスト先とする形態のほか、自社のクラウドアカウント内で動かすBYOA、弾力性を持たせたX Cloudが選べます。課金はインスタンスタイプ（vCPU・RAM）、ストレージ容量、サービスプラン（Standard／Professional／Premium）、デプロイ形態、ネットワークとバックアップの変動費で構成され、DynamoDBのような読み書きユニット単位の課金ではありません。試用はDeveloper Free Trial（30日・小規模インスタンス）とProduction Evaluation（48時間・本番グレード）の2種です。当社ではデータ分析基盤構築・MLOps構築支援として、DB選定から移行設計・運用体制の構築までを受託しています。

採用してよい条件と見送る場面｜Cassandra・DynamoDBとの選び分け

採用してよい3条件と、過剰投資に終わる案件の具体的な見分け方

採用してよいのは、次の3条件のいずれかに当てはまる案件です。第一に、テールレイテンシが業務要件として数値で定まっていること。GCの停止時間が読めない構成では守れない要件が、ScyllaDBなら構造的に守りやすくなります。第二に、既存のCassandraクラスタが台数の多さで運用負荷とインフラ費用を押し上げていること。第三に、DynamoDB依存のコードをAWS外へ持ち出す必要があることです。

見送るべき場面もはっきりしています。データ量が数百GB規模で、単一のマネージドRDBやマネージドNoSQLで捌けている業務システムには持ち込まないでください。得られるのはノード削減の余地だけで、代わりに分散データベースの運用責任を丸ごと引き受けることになります。判断の前提を整理したいならRDBとNoSQLの選び方から入るほうが早いところです。

もう1つの見送り条件が、社内に分散DBの運用要員がいない自己ホスト構成です。シャード単位の監視、リペアの計画、ローリングアップグレードの版差管理を引き受ける体制が無いなら、ScyllaDB Cloudか、CQL互換のマネージドであるAmazon Keyspacesへ振り替える判断になります。

Cassandra・DynamoDB・Bigtableとの比較と選定の分岐点

決め手になるのは性能値よりも、運用主体とライセンス条件です。

選定はこう分岐します。ライセンス条項の制約を一切持ち込めない案件、あるいは無償枠を確実に超える規模で商用費用の予算が取れないなら、Apache-2.0のCassandraを選ぶ。インフラがAWSに固定され、運用を外に出したいならAmazon KeyspacesかDynamoDBです。Google Cloudに固定されているならCloud Bigtableが第一候補になります。

ScyllaDBが勝つのは、クラウドを跨ぐ配置が要件に入っていて、かつテールレイテンシとノード台数の両方に具体的な数値目標がある案件です。逆に言えば、その数値目標が無い状態で「Cassandraより速いから」という理由だけで選ぶと、ライセンス条件の管理コストだけが残ります。

ScyllaDBの採用検討でよくある質問と移行時の注意点まとめ

導入の相談でよく挙がる質問を、公式ドキュメントと一次情報の記載から整理しました。

ScyllaDBは無料で使えますか？

条件付きで無料です。2025.1以降のScyllaDB EnterpriseはSource Availableライセンスで、組織単位の合計がディスク容量10TBまで、仮想CPU 50 vCPUまでなら全機能を無償で使えます。本番と非本番の区別はないため、検証環境も同じ枠を消費します。AGPLのOSS版はOpen Source 6.2.xが最終マイナー版で、以降のAGPLリリース予定はありません。

ScyllaDBとCassandraの違いは何ですか？

外形はほぼ同じで、実装と運用が違います。CQL、ドライバ、SSTable形式に互換性があるため、アプリ側のクエリはそのまま通ります。差が出るのは内部で、CassandraがJavaで動くのに対しScyllaDBはC++20とSeastarによるshard-per-core設計。JVMのGCに起因するレイテンシの揺れが構造的に無く、同じ負荷をより少ないノードで捌ける前提に立ちます。ライセンスもApache-2.0とSource Availableで分かれます。

Cassandraからの移行はどの程度の作業になりますか？

アプリケーションの書き換えは小さく、運用の作り直しが本体です。CQLとドライバが互換のためクエリ変更はほぼ不要ですが、監視をシャード単位へ組み替える工程、scylla.yamlとJVM設定の差分吸収、運用スクリプトのコマンド体系の確認が要ります。パーティションキーの偏りは移行後により強く症状として出るため、データモデルの偏り検証を移行前に済ませてください。

TabletsとvNodesはどちらを使うべきですか？

新規構築なら既定のTabletsです。2026.1でcountersに対応し、TabletsとvNodesの機能差は解消されたとアナウンスされています。ノード追加時の自動再配置と複数ノードの同時追加が使える点も差分。ただしMaterialized ViewsやSecondary Indexesを使う場合はkeyspaceがRF-rack-validである必要があり、ALTER KEYSPACEでの切り替えができないため、keyspace作成前に方針を決め切ってください。

DynamoDBのアプリをそのまま動かせますか？

Alternatorを有効にすれば、DynamoDB APIのクライアントから接続できます。公式には「ほぼ完全な互換性」と表現されていますが、差異と未実装機能があることも同時に明記されています。StreamsやDAX、IAMベースの細粒度な認可に依存した構成は素通りしません。移行前に実際に呼んでいるAPIを洗い出し、差異の一覧と突き合わせる工程を挟んでください。書き込み隔離はalternator_write_isolationの設定で決まります。

関連記事

• Cassandraとは？分散NoSQLの仕組み・データモデル・採用判断を実装者目線で解説：ScyllaDBが互換性を保つ元の実装です。データモデル設計はこちらが土台になります。
• Amazon Keyspacesとは？Cassandra互換サーバーレスDBの仕組み・料金・採用判断を実装者目線で解説：運用を外に出したい場合のCQL互換マネージド版です。
• AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説：Alternatorで互換対象となるAPI側の前提整理です。
• Cloud Bigtableとは？GCPのワイドカラム型NoSQLの仕組みと採用判断を実装目線で解説：Google Cloud固定の案件で対になる候補です。
• Azure Cosmos DBとは？マルチモデルNoSQLの仕組み・整合性レベル・RU課金と採用判断を実装者目線で解説：Azure側でCassandra APIも選べるマルチモデルの選択肢です。
• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説：そもそもNoSQLを選ぶべきかを整理する前提記事です。