ScalarDL Overview / ScalarDL 製品概要

Transcript

1. ScalarDL 製品概要 Ver. 202605
2. © 2025 Scalar, inc. Scalarの製品 データマネジメントの未来を創る Scalarは、独自のデータ管理技術を用いてデータマネジメントの未来を創ること目指 しています。現在は、ScalarDB と ScalarDL と呼ばれる2つの主要製品を開発・販売 しており、これらは既存のデータベースではうまく扱えない信頼性の課題を解決しま す。 汎用的なデータベース仮想化(Universal HTAP)エンジン データベースにおける改ざん検知ミドルウェア データの整合性やデータ管理の複雑性の課題を解決します。複数 のデータベースにまたがるトランザクションや分析クエリを一元 的に管理します。マイクロサービス間や企業間でデータベースを 正しく管理したいユースケースで活用いただけます。 データの真正性の課題を解決します。データベースにおける改ざ ん等の故障（ビザンチン故障）を正しく、かつ、スケーラブルに 検知します。デジタルデータに証拠姓（真正性）を付与したい ユースケースで活用いただけます。 https://github.com/scalar-labs/scalardb https://github.com/scalar-labs/scalardl 2
3. © 2025 Scalar, inc. 概要 1
4. © 2025 Scalar, inc. ScalarDL: データベースにおける実用的な改ざん検知ミドルウェア • データベースにおけるビザンチン故障検知ミドルウェア ◦ ビザンチン故障: 任意の故障（改ざん、悪意のある攻撃、バグ） • これまでの分散データベースではクラッシュ故障までにのみ対応 Transaction Database System ビザンチン故障の検知を保証
5. © 2025 Scalar, inc. Motivation: データ社会においてはデータの正しさが重要 • データ中心の社会においてはデータの正しさ（真正性）が重要 • データを保存するデータベースが正しく動作することが肝要 • データベースの正しさを保証するための一つの方法として、ビザンチン故 障への対処がある データベースにおいて実用的かつスケーラブルにビザンチン故障に対処したい DB Process1 Process2
6. © 2025 Scalar, inc. • 基本原理：レプリカ間の差異を検出 • ビザンチン故障のマスキング (BFT: Byzantine Fault Tolerance) ◦ N > 3f, N: レプリカの数, f: ビザンチン故障の数 • ビザンチン故障の検知（BFD: Byzantine fault detection (BFD)) ◦ N > f, N: レプリカの数, f: ビザンチン故障の数 AD-1 AD-2 AD-3 AD-4 1つのビザンチン故障をマスクするために 4管理ドメイン（AD）が必要 2つのADで1つの ビザンチン故障を検知可能 AD-1 AD-2 BFT BFD ScalarDLのアプローチ ビザンチン故障の対処方法
7. © 2025 Scalar, inc. BFT (Byzantine Fault Tolerance) N > 3f, マスキング BFD (Byzantine Fault Detection) N > f, 検知 SMR トランザクション を逐次実行 DB トランザクション を並列実行 BFT SMR PBFT [OSDI’99], BFT-SMaRt [DNS’14], HotStuff [PODC’19] BFD SMR PeerReview [SOSP’07] BFT DB HRDB [SOSP’07], Byzantium [EuroSys’11], Hyperledger Fabric [EuroSys’17], Basil [SOSP’21] ？ Challenges: スケーラブルな BFD アプローチ
8. © 2025 Scalar, inc. BFT DB を拡張して BFD DB が実現可能であるか？ • レプリカを２つの管理組織（AD）に分離すればOK? => NO • 1レプリカにおけるビザンチン故障により保証条件が不成立 N=4, f=2 => N>3f BFT DB を拡張して BFD DB を実現する のは困難 AD-1 AD-2
9. © 2025 Scalar, inc. BFD SMR を拡張して BFD DB が実現可能であるか？ • BFD SMR でトランザクションを並列実行可能か？ => 部分的にYes ◦ プライマリ側でのみ並列実行可能 • 正しさを保証するには、セカンダリ側ではハッシュチェーンベースのログ を逐次的に実行する必要あり ◦ セカンダリ側で並列実行するとタイムトラベル異常が発生 AD-1 AD-2 T1 T2 T2 T1 hash-chained log プライマリ セカンダリ（Witness） 逐次実行が必要
10. © 2025 Scalar, inc. BFT (Byzantine Fault Tolerance) N > 3f, マスキング BFD (Byzantine Fault Detection) N > f, 検知 SMR トランザクション を逐次実行 DB トランザクション を並列実行 BFT SMR PBFT [OSDI’99], BFT-SMaRt [DNS’14], HotStuff [PODC’19] BFD SMR PeerReview [SOSP’07] BFT DB HRDB [SOSP’07], Byzantium [EuroSys’11], Hyperledger Fabric [EuroSys’17], Basil [SOSP’21] BFD DB ScalarDL [VLDB’22] Challenges: スケーラブルな BFD アプローチ
11. © 2025 Scalar, inc. ScalarDL - 他の分散型台帳製品との比較 ビザンチン故障 管理組織数と 保証条件 性能 （TPS） スケーラビリティ クラッシュ耐性 環境依存度 Public Blockchains (Bitcoin, Ethereum) マスキング （ただし、確率的。後述文 献参照） 1000-数万 （過半数の管理組織が正 しければ、正しく動作） 1-100 スケールしない 高い （ピア数による） N/A Hyperledger Fabric (Private/Consortiu m Blockchains) マスキング （一部のコンポーネントが クラッシュ故障のみ対応の ため不完全） 4以上 （4の場合、3組織が正しけ れば、正しく動作） 100-数千 スケールしない 高い （ピア数による） クラウド非依 存、DB依存 Oracle Blockchain Table 対応しない （オペレーションミスや簡易 な改ざんであれば検知で きる可能性あり） 1 （保証なし） 100-数千 限定的（スケール アップのみ） 高い （と思われるが内部構成 が不明なため詳細は不 明） クラウド依存、 DB依存 Azure Confidential Ledger (w/ CCF) 対応しない （TEEにより、コードの改ざ んは防止） 1 （保証なし） ? 限定的（スケール アップのみ） 高い （CCFを構成するノード数 による） クラウド依存、 DB依存、H/W 依存 ScalarDL 検知 2 （1組織が正しければ 正しく動作） 100-数10万 （計算資源の総 量による） ニアリニアスケーラ ビリティ （計算資源10倍で9倍程度 の性能向上） 高い （使用するデータベースに よる） クラウド非依 存、DB非依存
12. © 2025 Scalar, inc. • 厳密な直列化可能性を保証しつつ、トランザクションを並列に実行 • DBのAPIだけを用いることでデータベース非依存かつ非侵襲に実現 Primary Secondary ScalarDL Ledger Servers Primary Database AD1 ScalarDL Clients Applications ScalarDL Auditor Servers Secondary Database AD2 Database System ScalarDL: スケーラブルかつ実用的なBFDアプローチ
13. © 2025 Scalar, inc. ScalarDL Ledger User (Client) Java コントラクト 電子署名 秘密鍵 ScalarDL Ledger リクエスト : (contract, args, sig) Asset ID Age Data (before) Data (after) Sigs Func (ref) Args Hash A 1 { } { balance = 100, …} charge { val = 100 } B 1 { } { balance = 200, …} charge { val = 200 } A 2 { A: {balance = 100}, B: {balance = 200} …} { balance = 90, …} payment { val = 10 } 公開鍵 B 2 { A: {balance = 100}, B: {balance = 200} …} { balance = 210, …} payment { val = 10 } H(A1) H(B1) State hash chain * includes other accounts data 引数 S N = Contract (S N-1 , Args) Deterministic & TE TE If S 0 is TE ⇒ S N is TE Ledger データの完全性 function invoke() { if (accounts[0].data.balance < args.val) { throw new Error(“not enough balance”); } accounts[0].data.balance -= args.val; accounts[1].data.balance += args.val; results = { … }; } Payment コントラクト 引数 { accounts = [“A”, “B”], val = 10, …}
14. © 2025 Scalar, inc. ScalarDL Auditor Ledger とは別の管理ドメインに存在 実行 実行結果の証拠 リクエストの証拠 実行結果の証拠 T 状態を比較し、 ビザンチン故障を検知 Auditor はリクエストの実行とその結果の証拠を管理し、Ledger からのデータを信 頼することなく、Ledger と同じデータを再計算可能（特許取得済、PVLDB採録） User (Client) Scalar DL Ledger Scalar DL Auditor
15. © 2025 Scalar, inc. BFT/BFD SMR (プライベートブロックチェーン) と Scalar DL の本質的な違い BFT/BFD SMR （プライベートブロックチェーン） Scalar DL データを全順序で管理 並列化・スケールが困難 データを半順序で管理 ⇒ 並列化・スケールが容易 逐次実行が必要 並列化が可能
16. © 2025 Scalar, inc. 主要機能と最近の取り組み 2
17. © 2026 Scalar, inc. TableStore & HashStore
18. © 2026 Scalar, inc. TableStore & HashStore: ScalarDLの新しい抽象化層 • 標準的またはシンプルなインターフェースと事前定義済みコントラクトを 提供 ◦ コントラクトの作成が不要となり、開発効率の大幅な向上を実現が可能に • TableStore: SQLインターフェースを備えた抽象化層 ◦ SQL処理系とステートメントごとの事前定義済みコントラクトを提供 ◦ 標準的なSQLでアプリケーション開発が可能 • HashStore: 証拠保全ユースケースに特化した抽象化層 ◦ 証拠保全用の事前定義済みコントラクトを提供 ◦ 証拠保全アプリケーションの開発が容易に
19. © 2026 Scalar, inc. TableStore: SQLインターフェースを備えた抽象化層 • ScalarDLをSQLで処理するインターフェースを提供 Client ScalarDL Register Develop Execute w/o TableStore w/ TableStore ExecuteStatement(SQL) Predefined Contracts Select Insert Update Create … SELECT * FROM table WHERE id = 10; SQL: User-defined contracts Immutable Immutable
20. © 2026 Scalar, inc. HashStore: 証拠保全ユースケースに特化した抽象化層 • ドキュメントのハッシュ値（証拠）を保全するためのインターフェースを 提供 Client ScalarDL Register Develop Execute (hash) w/o HashStore w/ HashStore PutObject/GetObject Predefined Contracts Put Get PutToMutable … Document 0bf2b66062d6baf3b 622def836bb1f3e41 84d9993c44153cbcb 8496659a6e47a createCollection/addToCollection/ getCollectionHistory Document Create Add GetHistory … 0bf2b66062d6baf3b 622def836bb1f3e41 84d9993c44153cbcb 8496659a6e47a hash: hash: User-defined contracts Immutable Mutable Immutable Mutable
21. © 2026 Scalar, inc. 汎用コントラクト
22. © 2026 Scalar, inc. 汎用コントラクト • 典型的なユースケースをカバーした汎用コントラクト ◦ 利用者はコントラクトを新たに書く必要はなく、当該コントラクトを使用してアプリケー ションを実装可能に • ２つの抽象化 ◦ オブジェクト真正性管理 ▪ PubObject, GetObject, ValidateObject ◦ コレクション真正性管理 22 $ scalardl execute-contract --properties client.properties --contract-id PutObject \\ --contract-argument '{"objct_id":"xyz", "hash_value":"a3ae11", "properties": {"note": "something"}}' $ scalardl execute-contract --properties client.properties --contract-id GetObject \\ --contract-argument '{"objct_id":"xyz"}' Contract result: {"object_id" : "xyz", "hash_value" : "a3ae11", "properties" : {"note" : "something"}}
23. © 2026 Scalar, inc. 名前空間
24. © 2026 Scalar, inc. 名前空間 (3.13 -) • ScalarDLのデータ（Assetの集合）を複数の論理的な区画に分離 ◦ セキュリティ境界の分離も可能 • ルールに基づくパーティショニングやマルチテナントを実現可能 Asset 1 Asset 2 Asset 3 App 1 App 2 App 3 マルチテナント Asset 1 Asset 2 Asset 3 App ルールに基づくパーティショニング NS 1 NS 2 NS 3 NS:2024 NS:2025 NS:2026
25. © 2026 Scalar, inc. デプロイのGUI化
26. © 2025 Scalar, inc. GCP Marketplace • Omnistrate社との連携によりBYOA (Bring Your Own Account) SaaSを実現 ◦ 自社のクラウド環境にGUI操作でScalarDBをデプロイを可能に ◦ Scalarとの直接契約なしにScalarDB Clusterを使用可能 26
27. © 2025 Scalar, inc. 詳細 3
28. © 2025 Scalar, inc. • トランザクションの半順序を分権したまま並列に合意 ◦ プライマリとセカンダリが、トランザクション実行順序を明に共有することな く同じ結果になるようにオペレーション列の送信順序を制御 ◦ メッセージ認証（HMAC）を利用して、プロトコルを強制 • 3フェーズのプロトコル: Ordering -> Commit -> Validation. • 詳細は後述の論文を参照ください Client Secondary Primary Ordering Commit Validation ScalarDLの基本アイデア
29. © 2025 Scalar, inc. • 2PLの亜種を用いてトランザクションを Strict Serializable に順序付け ◦ トランザクションを仮実行し、R/W セットを取得 ◦ 下位の DB の Linearizable なオペレーションを用いて R/W ロックを取得 ◦ トランザクション ID に対するメッセージ認証をクライアントに返却 • 明に順序を共有しないことから、プライマリとセカンダリは異なる Version Order になりうるため、Multi-version の活用は困難 Primary key Version Lock count Lock mode Lock holders (TxIDs) Input dependencies Lock entry: <primary-key, version> のセット Client Secondary Primary Ordering Commit Validation トランザクショ ンの半順序関係 ScalarDL BFD プロトコル - Ordering フェーズ
30. © 2025 Scalar, inc. • クライアントとセカンダリからのメッセージ認証を検証 ◦ セカンダリを通っていないリクエストはアボート • トランザクションを任意の順序で ACID に実行 ◦ <TxID, Status> を DB にログとして書き込み（リカバリ用） ◦ 書けた時点でコミットが確定 • 実際に書かれた R/W セット（Proof）とそのメッセージ認証と実行結果 を返却 Primary key Version TxID Input dependencies MAC Proof entry: Client Secondary Primary Ordering Commit Validation トランザクション の半順序関係 ScalarDL BFD プロトコル - Commit フェーズ
31. © 2025 Scalar, inc. • プライマリからのメッセージ認証を検証 • 半順序関係を比較（Lock entry と Proof entry を比較） • セカンダリ側でトランザクションを再実行 • クライアントでプライマリとセカンダリの実行結果と Proof を比較 ◦ 異なるならビザンチン故障と判断 Primary Secondary Result Proofs Result Proofs 2. Commit phase 3. Validation phase Compare =? Compare lock table =? Pre-validation Client Client Secondary Primary Ordering Commit Validation ScalarDL BFD プロトコル - Validation フェーズ
32. © 2025 Scalar, inc. 評価実験 • 各DBインスタンス: AWS. c5d.4xlarge (8 cores, 32GB DRAM, NVMe SSD) • クライアント: c5.9xlarge • ワークロード: YCSB (100B x 100M records), TPC-C (1000 warehouse) • 比較対象: PeerReviewTX（PeerReviewの拡張）、ScalarDL PostgreSQL Scalar DL C* DL … PostgreSQL Scalar DL C* DL C* DL C* DL … C* DL C* DL Clients Clients AD AD AD AD
33. © 2025 Scalar, inc. PostgreSQL環境での評価実験結果 YCSB-F TPC-C (NP) ScalarDLは並行性制御により、スレッド数の増加に伴い性能がスケール （PeerReviewTxは4スレッドで頭打ち）
34. © 2025 Scalar, inc. Cassandra環境での評価実験結果 YCSB-F TPC-C (NP) Cassandraでの同様の傾向（データベース非依存性の実現を確認）
35. © 2025 Scalar, inc. スケーラビリティ (TPC-C) ADごとのノード数の増加に比例してスループットがほぼ線形に増加
36. © 2025 Scalar, inc. ロードマップ 4
37. © 2025 Scalar, inc. 直近ロードマップ • ライフサイクル管理 (3.13) • 性能最適化 • https://scalardl.scalar-labs.com/docs/latest/roadmap