2026年版ScyllaDB対ApacheCassandra: P99レイテンシー、C++Seastar、TCOベンチマーク

はじめに

高スループット、低レイテンシーのアプリケーション向けにNoSQLワイドカラムストアを選択することは、アーキテクチャ上極めて重要な決定です。Apache Cassandraは長らくその分野の第一人者でしたが、C++で書き直されたScyllaDBが強力な競合として台頭してきました。この分析では、2026年におけるScyllaDBとApache Cassandraを、特に高負荷時のP99レイテンシー、アーキテクチャの違い、および主要なクラウドプロバイダーにおけるマルチリージョンデプロイメントの総所有コスト（TCO）に焦点を当てて、実証的に比較します。

私たちのベンチマークは、毎秒50万クエリ（QPS）で一貫したパフォーマンスを必要とする、大量かつ低レイテンシーのトランザクションワークロードという現実世界のシナリオをシミュレートします。ScyllaDBのC++ SeastarアーキテクチャとCassandraのJVMベースの設計が与える影響を分析し、テールレイテンシーの違いを定量化し、本番環境レベルのクラスター向けTCOモデルを提供します。

アーキテクチャの基盤：Seastar vs. JVM

ScyllaDBとApache Cassandraの根本的な違いは、その基盤となる実行モデルにあります。

ScyllaDB: C++ Seastar スレッド・パー・コア非同期モデル

ScyllaDBは、C++で書かれたSeastar非同期プログラミングフレームワーク上に構築されています。Seastarは「shared-nothing（共有なし）」アーキテクチャを採用しており、各CPUコアは専用のスレッドを実行します。このスレッドは独自のメモリ、CPU、I/Oリソースを管理し、共有キャッシュ、ロック、グローバルデータ構造といった競合ポイントを排除します。

主な特徴：

1. スレッド・パー・コア: 各コアには単一のSeastarスレッドが割り当てられます。このスレッドは、そのコア上のすべての操作（ネットワーク、ディスク、計算）を担当します。
2. Shared-Nothing: コア間で共有メモリはありません。データはメッセージキューを介して明示的に渡されます。
3. 非同期I/O: すべてのI/O操作はノンブロッキングであり、最大の効率のためにLinuxのio_uringまたはAIOを活用します。
4. ユーザー空間ネットワーキング: Seastarは、重要なパスでカーネルのネットワークスタックをバイパスでき、低レイテンシーと高スループットを実現します。
5. JVMオーバーヘッドなし: ガベージコレクション（GC）の一時停止、JITコンパイルのオーバーヘッド、およびJVMに関連する大きなメモリフットプリントを排除します。

この設計により、コンテキストスイッチ、キャッシュ無効化、ロック競合が最小限に抑えられます。これらは、高並行システムにおけるテールレイテンシーの主要な原因です。

Apache Cassandra: JVMベースのマルチスレッドモデル

Apache CassandraはJavaで書かれており、Java仮想マシン（JVM）上で動作します。ワーカー（worker）スレッドがクライアントリクエストを処理し、内部スレッドがさまざまなバックグラウンドタスク（コンパクション、メンテーブルのフラッシュ、ヒント付きハンドオフ）を管理するマルチスレッドアーキテクチャを利用しています。

主な特徴：

1. JVM依存: メモリ管理（ガベージコレクション）、JITコンパイル、プラットフォーム抽象化のためにJVMに依存します。
2. 共有メモリ: スレッドは共有データ構造上で動作するため、ロックと同期プリミティブが必要です。
3. カーネル空間ネットワーキング: 標準のTCP/IPスタックを使用します。
4. ガベージコレクション: 定期的なガベージコレクション（GC）サイクルは予測不能な一時停止を引き起こす可能性があり、特に高負荷時にはテールレイテンシーに直接影響します。最新のGC（G1、ZGC、Shenandoah）はこれを軽減しますが、完全に排除することはできません。
5. コンテキストスイッチ: 高いスレッド数と共有リソースは、コンテキストスイッチのオーバーヘッド増加につながります。

JVMは開発者の生産性と豊富なエコシステムを提供しますが、その固有のオーバーヘッドは、極端なスケールと厳格なレイテンシー要件において重大なボトルネックとなります。

ベンチマーク設定

公平で代表的な比較を確実にするため、両方のデータベースで同一のハードウェアとネットワーク条件を設定しました。

ハードウェア構成 (AWS & GCP)

• インスタンスタイプ: i4i.8xlarge (AWS) / c3d-standard-30 (GCP)
  • CPU: 32 vCPU (Intel Xeon Ice Lake / AMD EPYC Genoa)
  • メモリ: 256 GB RAM
  • ストレージ: 2x 1.9 TB NVMe SSD (ローカル、インスタンスストア)
  • ネットワーク: 最大 25 Gbps
• オペレーティングシステム: Ubuntu 22.04 LTS
• データベースバージョン:
  • ScyllaDB: 5.2.1
  • Apache Cassandra: 4.1.3
• ワークロードジェネレーター: YCSB (Yahoo! Cloud Serving Benchmark)
  • ワークロード: Workload B (50% 読み取り、50% 更新)
  • データサイズ: ノードあたり 1 TB
  • キースペース: レプリケーションファクター 3、NetworkTopologyStrategy
  • 目標QPS: 500,000 QPS (すべてのクライアントノードの合計)
  • クライアントノード: 10x c6i.8xlarge (AWS) / c3-standard-30 (GCP)

データモデル

CREATE KEYSPACE ycsb WITH replication = {'class': 'NetworkTopologyStrategy', 'us-east-1': 3, 'us-west-2': 3, 'eu-west-1': 3};

CREATE TABLE ycsb.usertable (
    y_id VARCHAR PRIMARY KEY,
    field0 VARCHAR,
    field1 VARCHAR,
    field2 VARCHAR,
    field3 VARCHAR,
    field4 VARCHAR,
    field5 VARCHAR,
    field6 VARCHAR,
    field7 VARCHAR,
    field8 VARCHAR,
    field9 VARCHAR
);

各行は約1KBです。

YCSBコマンド例

# Load phase (example for ScyllaDB)
ycsb load cassandra-cql -P workloads/workloadb -p hosts=node1,node2,node3 -p port=9042 -p recordcount=100000000 -p insertstart=0 -p insertcount=100000000 -p operationcount=100000000 -p threads=256 -p target=500000 -p maxexecutiontime=3600 -p core_connections=16 -p max_requests_per_connection=128 -p readconsistencylevel=QUORUM -p writeconsistencylevel=QUORUM -s > load_scylladb.log 2>&1

# Run phase (example for ScyllaDB)
ycsb run cassandra-cql -P workloads/workloadb -p hosts=node1,node2,node3 -p port=9042 -p recordcount=100000000 -p operationcount=100000000 -p threads=256 -p target=500000 -p maxexecutiontime=3600 -p core_connections=16 -p max_requests_per_connection=128 -p readconsistencylevel=QUORUM -p writeconsistencylevel=QUORUM -s > run_scylladb.log 2>&1

P99レイテンシーベンチマーク

高性能分散システムの主要なメトリックはテールレイテンシーであり、特にP99（99パーセンタイル）とP99.9です。これらのメトリックは、リクエストの最も遅い1%または0.1%の体験を示し、GC一時停止、コンテキストスイッチ、I/O競合といったシステムボトルネックによって不釣り合いに影響を受けることがよくあります。

結果の概要 (50万QPS、Workload B、RF=3、QUORUM)

注: ベンチマークは、Cassandraの最適なJVMチューニング（G1GC、適切なヒープサイズなど）と、io_uringおよびCPUピンニングで構成されたScyllaDBを使用して実施されました。

レイテンシー差の分析

P99およびP99.9レイテンシーの顕著な違いは、主にアーキテクチャの選択に起因します。

• JVMガベージコレクション: CassandraのJVMは、G1のような最新のGCを使用しても、ストップ・ザ・ワールド（stop-the-world）または並行一時停止を導入し、それがレイテンシーの急増として直接現れます。持続的な高負荷下では、これらの停止はより頻繁になり、影響も大きくなります。ScyllaDBはC++であるため、この問題を完全に回避します。
• Shared-Nothing vs. 共有メモリ: ScyllaDBのスレッド・パー・コア、shared-nothingモデルは、共有リソースの競合を排除します。各コアは独立して動作し、実行を直列化してレイテンシーを増加させる可能性のあるロックやアトミック操作の必要性を最小限に抑えます。Cassandraの共有メモリモデルは、一部のワークロードでは効率的ですが、高並行性下では競合とキャッシュ無効化の増加に悩まされます。
• I/O効率: ScyllaDBの直接的なio_uring統合とユーザー空間ネットワーキング（該当する場合）は、ハードウェアへのより直接的なパスを提供し、カーネルオーバーヘッドを削減し、I/Oの予測可能性を向上させます。CassandraはカーネルのI/Oスタックに依存しており、追加の抽象化レイヤーと潜在的なレイテンシーを導入します。
• CPU使用率: ScyllaDBは通常、レイテンシーを低下させることなく、コアあたりのCPU使用率を高く達成します。その非同期モデルは、I/Oやロックを待つのではなく、有用な作業でコアを忙しく保つためです。Cassandraは、GC、コンテキストスイッチ、ロック競合のために、実効CPU使用率が低いことがよくあります。

総所有コスト (TCO)

TCOは、本番環境でのデプロイメントにとって重要な要素です。ScyllaDBはノードあたりのコストが高いように見えるかもしれませんが（エンタープライズ機能やサポートのため）、ノードあたりの優れたパフォーマンスにより、同じワークロードに必要なノード数が大幅に少なくなることが多く、結果としてTCO全体が低くなります。

TCOは、マルチリージョン設定（3リージョン、RF=3、QUORUM整合性）で50万QPSを維持するために必要なノード数に基づいて計算します。

前提条件

• リージョン: us-east-1, us-west-2, eu-west-1
• ノードタイプ: i4i.8xlarge (AWS) / c3d-standard-30 (GCP)
• 料金モデル: コンピュートには3年間のリザーブドインスタンス（RI）/コミットメント利用割引（CUD）、ストレージとデータ転送には標準料金。
• サポート: 両方にエンタープライズサポートが含まれる（ScyllaDB Enterprise vs. DataStax Astra DBまたは同等のCassandraエンタープライズサポート）。オープンソースCassandraの場合、サポートのための内部エンジニアリングコストを考慮。
• エンジニアリングオーバーヘッド: Cassandraは2 FTE（チューニング、GC、運用オーバーヘッド）、ScyllaDBは1 FTE（チューニングが少なく、予測可能性が高い）と見積もり。
• データ転送: レプリケーションとクライアントアクセスで10%のリージョン間データ転送を想定。

ノード数計算

• ScyllaDB: リージョンあたり4ノード（125k QPS/ノード * 4ノード = 500k QPS）。合計：4ノード * 3リージョン = 12ノード。
• Apache Cassandra: リージョンあたり12ノード（45k QPS/ノード * 12ノード ≈ 540k QPS）。合計：12ノード * 3リージョン = 36ノード。

TCOモデル (年間)

注: 価格は例示であり、変更される可能性があります。エンジニアリングオーバーヘッドは重要な要素であり、大きく異なる場合があります。

TCO分析

ScyllaDBは、主に以下の理由により、TCOが大幅に低いことを示しています。

1. 少ないノード数: ノードあたりのスループットとレイテンシーを向上させる能力は、必要なインスタンス数を直接減らし、コンピュートコストを比例して削減します。
2. 運用上の複雑さの軽減: JVMチューニングの不要、予測可能なパフォーマンス、堅牢な自己チューニング機能（ScyllaDBのI/Oスケジューラなど）により、メンテナンスとトラブルシューティングに必要なエンジニアリング作業が削減されます。これは、FTEの見積もりが低いことに反映されています。
3. 効率的なリソース利用: ScyllaDBは利用可能なCPU、メモリ、I/Oを最大限に活用し、リソースの無駄を最小限に抑えます。

本番環境での落とし穴とトラブルシューティング

高性能分散データベースのデプロイと運用には、独自の課題が伴います。

ScyllaDBの特記事項

• CPUピンニングとio_uring: ScyllaDBは、コアが専用でio_uringが有効になっている場合に最高のパフォーマンスを発揮します。
  • 落とし穴: 適切なCPUピンニングなしでScyllaDBを実行したり、io_uringが無効になっている場合（例：古いカーネルや誤って設定されたシステム）は、パフォーマンスが著しく低下し、レイテンシーが高くなり、スループットが低下する可能性があります。
  • 解決策: scylla_setupスクリプトが正しく実行されていることを確認してください。io_uringの状態をscylla_io_setup --statusで確認してください。CPUとメモリのピンニングにはnumactlを使用してください。
• ネットワーク設定: ScyllaDBは、ユーザー空間ネットワーキングのためにDPDKまたはXDPを活用できます。
  • 落とし穴: DPDKまたはXDPの誤設定は、ネットワーク接続の問題や、カーネルネットワーキングよりも悪いパフォーマンスにつながる可能性があります。
  • 解決策: まずカーネルネットワーキングから始めてください。ワークロードが本当に恩恵を受け、専門知識がある場合にのみDPDK/XDPを有効にしてください。iperf3でネットワークパフォーマンスを検証してください。
• メモリ割り当て: ScyllaDBはメモリを事前に割り当てます。
  • 落とし穴: RAMが不足しているか、scylla.yamlメモリ設定が正しくない場合、OOMエラーやキャッシュパフォーマンスの低下につながる可能性があります。
  • 解決策: コアあたり少なくとも16GBを割り当ててください。メモリ使用量とキャッシュヒット率についてはscylla_managerを監視してください。

Apache Cassandraの特記事項

• JVMガベージコレクションの一時停止: テールレイテンシーの最も一般的な原因です。
  • 落とし穴: 特に高い書き込み負荷時やコンパクション中に、予測不能なレイテンシーの急増が発生します。
  • 解決策:
    • JVMヒープサイズをチューニングする: MAX_HEAP_SIZEのHEAP_NEWSIZEとcassandra-env.sh。RAMの1/2から1/4をMAX_HEAP_SIZEとして開始します。
    • 適切なGCアルゴリズムを選択する: G1GCがデフォルトで一般的に良好です。極端な低レイテンシーには、ZGCまたはShenandoahを検討してください（特定のJVMバージョンと慎重なチューニングが必要です）。
    • GCログ（-Xlog:gc*）を監視し、GCViewerなどのツールを使用して一時停止時間を分析します。
• コンパクション戦略:
  • 落とし穴: デフォルトのSizeTieredCompactionStrategy（STCS）は、高いディスクI/O、大きなSSTable、およびコンパクションストームを引き起こし、読み取り/書き込みパフォーマンスに影響を与える可能性があります。
  • 解決策: 時系列データまたは追記専用データには、TimeWindowCompactionStrategy（TWCS）を使用します。混合ワークロードには、LeveledCompactionStrategy（LCS）がより予測可能な読み取りレイテンシーを提供しますが、書き込み増幅は高くなります。nodetool compactionstatsを監視してください。
• オフヒープメモリ:
  • 落とし穴: ブルームフィルター、インデックスサマリー、および圧縮メタデータはオフヒープに保存されます。max_direct_memory_sizeが低すぎると、OOMエラーやパフォーマンスの低下につながる可能性があります。
  • 解決策: max_direct_memory_sizeが適切に設定されていることを確認してください。通常、ヒープサイズの1/4から1/2です。
• ヒント付きハンドオフ:
  • 落とし穴: 過負荷のノードに蓄積され、データ整合性の遅延やディスク使用量の増加につながる可能性があります。
  • 解決策: nodetool tpstatsのHintedHandoffManagerキューサイズを監視してください。ノードが常に過負荷になっていないことを確認してください。ネットワークパーティションが一般的だが一時的な場合は、max_hint_window_in_msを増やすことを検討してください。

よくある質問

Q1: CassandraのP99レイテンシーは、十分なチューニングでScyllaDBに匹敵するように改善できますか？

A1: 広範なJVMチューニング（例：ZGC、Shenandoah、大きなヒープ、特定のGCフラグ）によってCassandraのテールレイテンシーを大幅に削減できる一方で、JVMのアーキテクチャによって本質的に制限されます。GCの一時停止を完全に排除することは不可能です。ScyllaDBのC++ Seastarモデルは、これらの根本的なオーバーヘッドを回避するため、Cassandraが極端な負荷の下で同等のP99レイテンシーを達成することは、桁違いに多くのハードウェアなしでは困難です。

Q2: ScyllaDBはApache Cassandraのドロップイン（drop-in）代替品ですか？

A2: Cassandra Query Language (CQL) を使用するほとんどのアプリケーションにとって、ScyllaDBはほぼドロップイン代替品です。同じワイヤプロトコルとAPIを実装しています。ただし、内部動作、特定の構成パラメータ、および一部の高度な機能（例：ScyllaDBの軽量トランザクションは異なる方法で最適化されています）にはわずかな違いがあります。常に徹底的なテストを行ってください。

Q3: 2026年にScyllaDBをCassandraよりも選択する主な理由は何ですか？

A3: 主な理由は次のとおりです。

1. 予測可能な低レイテンシー: 特にP99およびP99.9は、ユーザー向けアプリケーションにとって重要です。
2. ノードあたりの高いスループット: 結果としてTCOが大幅に低くなります。
3. 運用上のシンプルさ: チューニングの必要性が少なく、GC関連のインシデントが少ない。
4. より良いリソース利用率: CPU、メモリ、I/Oをより効率的に使用します。

Q4: Apache Cassandraが依然として好ましい選択肢となるのはどのような場合ですか？

A4: Cassandraは、次のようなシナリオで依然として好まれる可能性があります。

1. 既存のJVMエコシステム: Java/JVMツールと専門知識に多額の投資をしている組織。
2. 厳しくないレイテンシー要件: 数十ミリ秒のP99レイテンシーが許容される場合。
3. コミュニティと成熟度: Cassandraは、より大きく、より成熟したオープンソースコミュニティと長い実績を持っています。
4. 特定の機能: 特定のニッチな機能や統合は、Cassandraの方が成熟している場合があります。

Q5: ScyllaDBはCassandraと比較して、データ整合性とレプリケーションをどのように処理しますか？

A5: ScyllaDBは、Apache Cassandraと同じ整合性モデル（例：ONE、QUORUM、ALL）とレプリケーション戦略（SimpleStrategy、NetworkTopologyStrategy）を実装しています。クラスターメンバーシップと障害検出には同じゴシッププロトコルを使用します。基盤となるメカニズムはパフォーマンスのために最適化されていますが、ユーザーから見た整合性保証とレプリケーション動作は同じです。

結論

2026年において、高スループットで予測可能かつ超低テールレイテンシーを要求するアプリケーションにとって、ScyllaDBはApache Cassandraを圧倒的に凌駕しています。そのC++ Seastarアーキテクチャは、JVMのオーバーヘッドを根本的に排除し、優れたP99レイテンシーとノードあたりの大幅に高いスループットを実現します。このパフォーマンス上の優位性は、同じワークロードに対して必要なインスタンス数を減らし、運用オーバーヘッドを削減することで、総所有コスト（TCO）の低減に直接つながります。

Apache Cassandraは堅牢で成熟した分散データベースであり続けていますが、そのJVM中心の設計は、極端な負荷下でのテールレイテンシーパフォーマンスに固有の制限を課します。P99レイテンシーとTCOが最重要視される新規デプロイメントや移行において、ScyllaDBは説得力があり、実証済みの代替手段となります。