Scalar製品新機能説明会（ScalarDB 3.19, ScalarDL 3.14）

Transcript

1. Scalar製品新機能説明会 ScalarDB 3.19, ScalarDL 3.14 2026年8月7日
2. 免責事項 本資料に記載された情報は、作成時点で入手可能な情報に基づき作成されていますが、そ の正確性、完全性、最新性を保証するものではありません。 本資料の内容は予告なく変更されることがあります。本資料は情報提供のみを目的とする ものであり、契約上の義務や保証を構成するものではありません。 © 2026 Scalar, inc.
3. 本日のアジェンダ • Scalar製品（ScalarDBとScalarDL）の概要 (-3m)（山田） • ScalarDB 3.19 について (35m) ◦ リリースの背景（山田） ◦ ScalarDB Saga 概要（山田） ◦ ScalarDB 2PC マイクロサービス向け新インターフェース（鈴木） ◦ ScalarDB Manager（野村） リリース内容の背景、 • ScalarDL 3.14 について (15m) 機能概要、デモを ◦ リリースの背景 （根本） 実際に開発担当者から ◦ メタデータのパージ機能（根本） お話します。 • ロードマップ (-2m) ◦ ScalarDB 3.20, ScalarDL 3.15 以降について（山田） • 質疑応答・要望フィードバック (5m-) ◦ 質問は最後に伺います。説明終了後も受付ます。 © 2026 Scalar, inc.
4. Scalar製品の概要 © 2026 Scalar, inc.
5. Scalarの製品 データマネジメントの未来を創る Scalarは、独自のデータ管理技術を用いてデータマネジメントの未来を創ること目指 しています。現在は、ScalarDB と ScalarDL と呼ばれる2つの主要製品を開発・販売 しており、これらは既存のデータベースではうまく扱えない信頼性の課題を解決しま す。 汎用的なデータベース仮想化(Universal HTAP)エンジン データベースにおける改ざん検知ミドルウェア データの整合性やデータ管理の複雑性の課題を解決します。複数 のデータベースにまたがるトランザクションや分析クエリを一元 的に管理します。マイクロサービス間や企業間でデータベースを 正しく管理したいユースケースで活用いただけます。 データの真正性の課題を解決します。データベースにおける改ざ ん等の故障（ビザンチン故障）を正しく、かつ、スケーラブルに 検知します。デジタルデータに証拠姓（真正性）を付与したい ユースケースで活用いただけます。 https://github.com/scalar-labs/scalardb https://github.com/scalar-labs/scalardl © 2026 Scalar, inc. 5
6. ScalarDB: Universal HTAPエンジン • 複数・異種のデータベースを仮想的に統合し、それらをまたぐトランザクション・ 分析問合せ・セキュリティを一元的に管理 ◦ 複数のデータベースを扱う複雑性・煩わしさからユーザを解放 App Relational Databases App NoSQL App BI NewSQL Data Lakes ML Vector Stores Blob Storage AlloyDB Blob Storage Cloud Storage Spanner Azure AI Search © 2026 Scalar, inc. Private Preview Vector Store は別インターフェースにより対応 のため、トランザクション・分析クエリは非対応
7. ScalarDL: データベースにおける実用的な改ざん検知ミドルウェア • データベースにおけるビザンチン故障検知ミドルウェア ◦ ビザンチン故障: 任意の故障（改ざん、悪意のある攻撃、バグ） • これまでの分散データベースではクラッシュ故障までにのみ対応 Transaction ビザンチン故障の検知を保証 Database System © 2026 Scalar, inc.
8. ScalarDB 3.19 について © 2026 Scalar, inc.
9. ScalarDB 3.19 の概要 主テーマ: マイクロサービスユースケースにおける機能強化 ScalarDB Saga Saga/TCCを実行するモダンな Sagaオーケストレータ。 API連携・長時間処理に対応 マイクロサービス向け 新インターフェース マイクロサービスにおける 2相コミットをより簡単に なぜ今マイクロサービスなのか？ © 2026 Scalar, inc. その他の改善 ScalarDB Managerの刷新 （オブザーバビリティ強化）。 ScalarDB Analyticsの高速化 （Where句のプッシュダウン）
10. ScalarDB 3.19の背景: AI駆動開発におけるベストプラティス • コンテキストが大きくなりすぎないように開発 • ドメイン/モジュールを切って、予期せぬ変更を防ぐ • 脆弱性対応を迅速に行えるようにする 出典: NoLiMa (ICML 2025, Adobe Research) © 2026 Scalar, inc.
11. ScalarDB 3.19の背景: AI駆動開発により採るべきアーキテクチャが変化 AI駆動開発(AIDD)がマイクロサービスアーキテクチャの選択を後押し AI1 AI2 AI コンテキストを小さく保てる 変更範囲を閉じ込められる 部分的に早くリリースできる AIに渡すコンテキストが小さいほど AIは正確に動作 境界を物理的に閉じ、AIに意図しな い変更をさせない。並行開発も可能 部分リリースにより、迅速なリ リースと脆弱性対応が可能 AIDDによる経営スピードの向上は、マイクロサービスアーキテクチャの選択が一つの鍵 ScalarDB 3.19 はマイクロサービスユースケースにおける大幅な機能強化を実施 © 2026 Scalar, inc.
12. ScalarDB 3.19 の背景: マイクロサービス最大の課題 - データ整合性 • サービスやシステムの分離は、それらをまたいだデータの整合性の保証が困難 • これまでもScalarDB (ScalarDB 2PC) はデータベース間の整合性の保証を実現（強 い整合性を保証） 課題1 課題2 API/SaaS連携や長時間トランザクションはう まく扱えなかった ScalarDB 2フェーズのインターフェースの 使い方が簡単ではなかった ScalarDB Sagaの提供で解決 2PC用の新I/Fの提供で解決 マイクロサービスにおいてより多くの課題を解決する製品へ © 2026 Scalar, inc.
13. ScalarDB 3.19 新機能1: ScalarDB Saga © 2026 Scalar, inc.
14. 新機能1: ScalarDB Saga • • Saga / TCC をスケーラブルかつ高可用に実現するオーケストレータ ScalarDB Core を用いたロバストな状態管理により、Participant DB の Eventual Atomicity を実現可能 ◦ 失敗時は補償トランザクションにより巻き戻し（実際には逆操作を実行） Participants MS1 MS2 Saga Orchestrator Saga SagaOrchestrator Orchestrator MS3 ScalarDB Core Eventual Atomicity / All or Nothing を保証 （Participant は冪等であることが前提） State databases © 2026 Scalar, inc.
15. 補足: ScalarDB SagaとScalarDB 2PCについて MS 1 ScalarDB Saga ScalarDB 2PC Orchestrator Coordinator MS 2 MS 3 APIを順次実行し、失敗時は補償処理で巻き戻す （分離性は保証しない、結果整合性） MS 1 MS 2 MS 3 Prepare → Commit (2フェーズ) で全DBを更新、失敗時は ロールバック（ACID・強整合性を保証） © 2026 Scalar, inc.
16. マイクロサービスにおける広範なユースケースに対応 Applications / BFF Layer マイクロサービスに 跨ってEventual Atomicなトラ ンザクションを実現 （結果整合性を保証） Universal Analytics Engine Modern Saga/TCC Orchestrator API / MS 異種・複数の DBに跨って ACIDトランザクション (2PC) を実現 （強整合性を保証） ANALYTICS SAGA API / MS 異種・複数の DBに跨っ て分析問合せを実現 API / MS API / MS API / MS API / MS SaaS CLUSTER Universal Transaction Manager DWH / Data Lake / Lakehouse ETL / ELT © 2026 Scalar, inc.
17. ScalarDB 2PCとSagaの使い分け — ユースケース アプリケーションの要件に合わせて、Sagaと2PCを使い分けることが肝要 判断の軸 Sagaが向く場合 2PCが向く場合 連携先のDBに直接アクセスできるか アクセスできない アクセスできる 分離性（途中経過を見えて良いか、 最悪ロストアップデートが許容できる） 許容できる 許容できない 処理にかかる時間 長時間に及ぶ処理 短時間の処理 外部連携・人手の介在がある ある ない 求める整合性 結果整合性で良い 強整合性が必要 銀行システムの例: 口座開設に関連する一連の処理 → Saga、口座振替 → 2PC © 2026 Scalar, inc.
18. 使い方 • Orchestratorの稼働方法 ◦ Serverモード（推奨） ▪ ◦ コンテナとして提供 Embeddedモード • アプリケーション/クライアントからのアクセス方法 ◦ Serverモード ◦ ▪ Java Client SDK によるアクセス（内部的にはgRPCを使用）（推奨） • Maven Centralから取得可能 ▪ REST APIに対するHTTPによるアクセス Embeddedモード ▪ DefaultSagaOrchestratorを用いてSagaを実行 • Maven Centralから取得可能 © 2026 Scalar, inc.
19. ScalarDB Sagaデモ © 2026 Scalar, inc.
20. ScalarDB 3.19 新機能2: マイクロサービス向け 新トランザクションインターフェース © 2026 Scalar, inc.
21. ScalarDB 2PC マイクロサービス向け新機能 • マイクロサービス向け新インターフェース「Global Transaction API」 • Transaction Coordinatorを用いた、新しい分離クラスターパターン © 2026 Scalar, inc.
22. Global Transaction APIについて • マイクロサービスのような複数のプロセス/サービス間での分散トランザクション • • • を管理するAPI 複数のブランチにまたがる分散トランザクション(グローバルトランザクション)を 管理 ブランチは通常、各プロセス/サービスで動く 全体でまとめてコミットまたはロールバックされる © 2026 Scalar, inc.
23. Global Transaction APIの実行の流れ • トランザクションIDを共有することで、各プロセス/サービスの処理が１つのトラン ザクションに束ねられる STEP 1 STEP 2 STEP 3 STEP 4 begin() beginBranch(id) end() commit() イニシエータがグローバル トランザクションを開始 し、ID を取得して共有する 各プロセス/サービスが同 じ ID でブランチを開始 し、CRUD を実⾏する ブランチが⾃分の処理の終 了を宣⾔する イニシエータが全ブランチ の書き込みをまとめて確定 する 失敗したときは rollback() を呼ぶだけで、全ブランチの書き込みが破棄される。 © 2026 Scalar, inc.
24. Global Transaction APIのコード例 ブランチ側 イニシエータ側 GlobalTransactionManager manager = …; GlobalTransactionManager manager = …; // グローバルトランザクション開始の宣言 GlobalTransaction tx = manager.begin(); // トランザクションID String txId = tx.getId(); // ブランチ開始の宣言 BranchTransaction branch = manager.beginBranch(txId); // CRUD処理 Optional<Result> r = branch.get(get); branch.update(update); try { // 各サービスにトランザクションIDを共有 callServiceA(txId); callServiceB(txId); // コミットではなく終了の宣言 branch.end(); // グローバルトランザクションのコミット tx.commit(); } catch (Exception e) { // グローバルトランザクションのロールバック tx.rollback(); } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc.
25. 新しい分離クラスターパターン マイクロサービスのためのデプロイメントパターン 共有クラスターパターン MS1 MS2 分離クラスターパターン MS3 MS1 MS2 MS3 prepare() validate() commit() commit() DB1 • • DB2 DB3 DB1 C クラスターをすべてのマイクロサービスで共有 シンプルなデプロイメント • • © 2026 Scalar, inc. DB2 DB3 C 各マイクロサービスが自分専用のクラスターを持つ 管理やリソースの分離が可能
26. 新しい分離クラスターパターン • これまでの分離クラスターパターン – アプリケーション側で2フェーズコミット処理を実装する必要があった – アプリケーションコードが複雑に – エラーハンドリングを間違えるとデータが不整合に • 新しい分離クラスターパターン – Transaction Coordinator コンポーネントを導入 – 2フェーズコミット処理はTransaction Coordinatorが受け持つ – アプリケーションコードがシンプルになる © 2026 Scalar, inc.
27. Transaction Coordinator (TC) の導入 これまでの 分離クラスターパターン TCを用いた 分離クラスターパターン commit() MS1 MS2 MS3 MS1 MS2 MS3 prepare() validate() commit() DB1 DB2 DB3 TC prepare() validate() commit() C DB1 全サービスがprepare(), (validate()), commit()を呼び出す必要がある DB2 DB3 C 1つのサービスがcommit()を呼び出すのみ © 2026 Scalar, inc.
28. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー Order サービスが起点となり、在庫引き当てと決済を 1 トランザクションで⾏う Order サービス Inventory サービス Payment サービス order クラスタ inventory クラスタ payment クラスタ 注⽂を作成する。イニシエータとして begin / commit も⾏う 在庫を引き当てる。ブランチとして CRUD の み⾏う 残⾼を引き落とし、決済履歴を残す © 2026 Scalar, inc.
29. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 Inventory サービス DB2 Payment サービス DB3 TC © 2026 Scalar, inc. C
30. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー 注文リクエスト クライアント Order サービス DB1 Inventory サービス DB2 Payment サービス DB3 TC © 2026 Scalar, inc. C
31. 実装：Order サービス (イニシエータ兼ブランチ) GlobalTransaction tx = manager.begin(); String txId = tx.getId(); グローバルトランザクション の開始宣言 try { BranchTransaction branch = manager.beginBranch(txId); // オーダーの記録 branch.insert(orderInsert); branch.end(); inventoryClient.reserve(txId, itemId, qty); paymentClient.charge(txId, customerId, amount); tx.commit(); } catch (Exception e) { tx.rollback(); throw e; } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc.
32. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー グローバル トランザクション の開始 クライアント Order サービス DB1 Inventory サービス DB2 Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
33. 実装：Order サービス (イニシエータ兼ブランチ) GlobalTransaction tx = manager.begin(); String txId = tx.getId(); try { BranchTransaction branch = manager.beginBranch(txId); // オーダーの記録 branch.insert(orderInsert); branch.end(); inventoryClient.reserve(txId, itemId, qty); paymentClient.charge(txId, customerId, amount); tx.commit(); } catch (Exception e) { tx.rollback(); throw e; } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc. ブランチの開始宣言
34. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー ブランチの開 始 クライアント Order サービス DB1 Inventory サービス DB2 Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
35. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー ブランチの開 始 クライアント ブランチの開 始 Order サービス DB1 BTx State Inventory サービス DB2 Payment サービス DB3 TC © 2026 Scalar, inc. C
36. 実装：Order サービス (イニシエータ兼ブランチ) GlobalTransaction tx = manager.begin(); String txId = tx.getId(); try { BranchTransaction branch = manager.beginBranch(txId); // オーダーの記録 branch.insert(orderInsert); branch.end(); CRUD処理 inventoryClient.reserve(txId, itemId, qty); paymentClient.charge(txId, customerId, amount); tx.commit(); } catch (Exception e) { tx.rollback(); throw e; } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc.
37. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー CRUD処理 クライアント Order サービス DB1 BTx State Inventory サービス DB2 Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
38. 実装：Order サービス (イニシエータ兼ブランチ) GlobalTransaction tx = manager.begin(); String txId = tx.getId(); try { BranchTransaction branch = manager.beginBranch(txId); // オーダーの記録 branch.insert(orderInsert); branch.end(); Inventoryサービス に在庫予約依頼 inventoryClient.reserve(txId, itemId, qty); paymentClient.charge(txId, customerId, amount); tx.commit(); } catch (Exception e) { tx.rollback(); throw e; } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc.
39. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー Order サービス クライアント DB1 BTx State 在庫予約依頼 Inventory サービス DB2 Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
40. 実装：Inventory サービス (ブランチ) public void reserve(String txId, String itemId, int qty) { BranchTransaction branch = manager.beginBranch(txId); // 在庫数のチェック Optional<Result> stock = branch.get(stockGet(itemId)); int remaining = stock.get().getInt("quantity") - qty; if (remaining < 0) throw new OutOfStockException(); branch.update(stockUpdate(itemId, remaining)); // 在庫数を更新 branch.end(); } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc. ブランチの開始宣言
41. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス ブランチの開 始 DB1 BTx State Inventory サービス DB2 Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
42. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス ブランチの開 始 DB1 ブランチの開BTx State 始 Inventory サービス DB2 BTx State Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
43. 実装：Inventory サービス (ブランチ) public void reserve(String txId, String itemId, int qty) { BranchTransaction branch = manager.beginBranch(txId); // 在庫数のチェック Optional<Result> stock = branch.get(stockGet(itemId)); int remaining = stock.get().getInt("quantity") - qty; if (remaining < 0) throw new OutOfStockException(); branch.update(stockUpdate(itemId, remaining)); // 在庫数を更新 branch.end(); } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc. CRUD処理
44. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 CRUD処理 BTx State Inventory サービス DB2 BTx State Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
45. 実装：Order サービス (イニシエータ兼ブランチ) GlobalTransaction tx = manager.begin(); String txId = tx.getId(); try { BranchTransaction branch = manager.beginBranch(txId); // オーダーの記録 branch.insert(orderInsert); branch.end(); inventoryClient.reserve(txId, itemId, qty); paymentClient.charge(txId, customerId, amount); tx.commit(); } catch (Exception e) { tx.rollback(); throw e; } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc. paymentサービス に決済依頼
46. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 BTx State 決済依頼 Inventory サービス DB2 BTx State Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
47. 実装：Payment サービス (ブランチ) public void charge(String txId, String customerId, int amount) { BranchTransaction branch = manager.beginBranch(txId); ブランチの開始宣言 // 残高のチェック Optional<Result> account = branch.get(accountGet(customerId)); int balance = account.get().getInt("balance") - amount; if (balance < 0) throw new InsufficientBalanceException(); branch.update(balanceUpdate(customerId, balance)); // 残高を更新 branch.insert(paymentInsert(txId, amount)); // 決済履歴を追加 branch.end(); } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc.
48. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 BTx State Inventory サービス DB2 BTx State ブランチの開 始 Payment サービス DB3 TC C GTx State © 2026 Scalar, inc.
49. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 BTx State Inventory サービス DB2 ブランチの開 始 ブランチの開BTx State 始 Payment サービス DB3 BTx State TC C GTx State © 2026 Scalar, inc.
50. 実装：Payment サービス (ブランチ) public void charge(String txId, String customerId, int amount) { BranchTransaction branch = manager.beginBranch(txId); // 残高のチェック Optional<Result> account = branch.get(accountGet(customerId)); int balance = account.get().getInt("balance") - amount; if (balance < 0) throw new InsufficientBalanceException(); branch.update(balanceUpdate(customerId, balance)); // 残高を更新 branch.insert(paymentInsert(txId, amount)); // 決済履歴を追加 branch.end(); } ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc. CRUD処理
51. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 BTx State Inventory サービス DB2 CRUD処理 BTx State Payment サービス DB3 BTx State TC C GTx State © 2026 Scalar, inc.
52. 実装：Order サービス (イニシエータ兼ブランチ) GlobalTransaction tx = manager.begin(); String txId = tx.getId(); try { BranchTransaction branch = manager.beginBranch(txId); // オーダーの記録 branch.insert(orderInsert); branch.end(); inventoryClient.reserve(txId, itemId, qty); paymentClient.charge(txId, customerId, amount); tx.commit(); } catch (Exception e) { tx.rollback(); throw e; } グローバル トランザクション をコミット ※ エラーハンドリングは⼀部省略 © 2026 Scalar, inc.
53. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 コミット BTx State Inventory サービス DB2 BTx State Payment サービス DB3 BTx State TC C GTx State © 2026 Scalar, inc.
54. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 BTx State prepare/ validate Inventory サービス DB2 BTx State Payment サービス DB3 BTx State TC C GTx State © 2026 Scalar, inc.
55. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 BTx State Inventory サービス DB2 BTx State Payment サービス DB3 BTx State TC C GTx State commit © 2026 Scalar, inc.
56. 新しい分離クラスターパターンを用いたマイクロサービス実装例 • 題材：注文フロー クライアント Order サービス DB1 BTx State commit Inventory サービス DB2 BTx State Payment サービス DB3 BTx State TC C GTx State © 2026 Scalar, inc.
57. ScalarDB 3.19 2PC マイクロサービス向け新機能 まとめ • マイクロサービス向け新インターフェース「Global Transaction API」 • Transaction Coordinatorを用いた、新しい分離クラスターパターン • シンプルなコードでマイクロサービス間のトランザクションができるようになった © 2026 Scalar, inc.
58. 3.19へのアップグレード時の注意点 • 特になし ◦ サポートバージョンからのアップグレードは後方互換性を維持 ◦ 新しい分離クラスターパターンを使う場合は、Transaction Coodinatorのデプロイが必要 © 2026 Scalar, inc.
59. ScalarDB 3.19 新機能3: ScalarDB Manager © 2026 Scalar, inc.
60. ScalarDB Manager (概要) • ScalarDB の統合監視ツール ◦ 運用に欠かせない情報を、一つの画面から容易に把握 • 主な機能 ◦ ◦ ◦ ◦ • トランザクション関連情報（TPS / エラーレート / レイテンシ） ScalarDB Cluster および接続先バックエンドDBのヘルスチェック データベーススキーマの閲覧 ScalarDB Cluster のコンフィグ設定内容の閲覧 技術基盤 ◦ ◦ ScalarDB Cluster に OpenTelemetry を組み込み、テレメトリを取得 現在は Trace / Metrics に対応、今後 Log などにも対応予定 © 2026 Scalar, inc.
61. ScalarDB Manager (アーキテクチャ図) Kubernetes ScalarDB Manager ScalarDBCluster Cluster ScalarDB ScalarDB Cluster (Instrumented by ScalarDB Manager Frontend Client (Instrumented by OTel SDK)by (Instrumented OTel SDK) Backend (User App) OTel SDK) Get Telemetry View as Web UI Store Telemetry Data OTLP PostgreSQL as Backend DB Browser © 2026 Scalar, inc. Workload
62. ScalarDL 3.14 について © 2026 Scalar, inc.
63. ScalarDL 3.14 の背景: 証拠の長期保存とコストのバランス 前提: ScalarDLはデータの証拠を保つ仕組みであるため、データは長期保存が基本 3.13以前 3.14以降 量・ コスト 量・ コスト 時間 時間 証拠として保存する量に比例してメタデータも増加 正しさの保証に必要な部分以外は削除 データ（証拠） メタデータ 長期運用フェーズのお客様をサポート © 2026 Scalar, inc.
64. ScalarDL 3.14 の新機能: メタデータのパージ機能 01 02 03 トランザクション処理後の「不要になったメタデータ」を消せる Ledger 側の Coordinator state record と、Auditor 側の request proof。役目を終えてもこれまでは残 り続けていました。 asset record は一切消えない 業務データとその履歴、つまり改ざん検知の根拠となるレコードはそのまま残ります。データの証拠性は 維持されます。 自動2種 + 手動1種、すべてデフォルト無効 明示的に有効化するまで挙動は従来どおり。既存環境はスキーマ更新をすれば使えます。 © 2026 Scalar, inc.
65. 課題 — 2つのテーブルが増え続ける 1トランザクションごとに、Ledger と Auditor がそれぞれ処理・リカバリ用の状態を書きます。役目を終 えても自動では消えないため、運用期間とトランザクション量に比例して積み上がります。 LEDGER SIDE AUDITOR SIDE Coordinator state record Request proof ScalarDB が Coordinator テーブルで管理する、トラ ンザクションの最終結果（commit / abort）の記 録。障害復旧時に結果を一意に決めるために使われ ます。 Auditor がクライアントからのリクエストごとに保 存する記録。Ledger で実行されたトランザクション の検証と、途中で終わってしまった場合のリカバリ に使われます。 運用期間 → 運用期間 → © 2026 Scalar, inc.
66. 補足 — コントラクト実行1回で何が書かれるか Ledger + Auditor 構成の検知プロトコルは ordering / commit / validation の3フェーズで進みます。 STEP 1 STEP 2 STEP 3 STEP 4 ORDERING COMMIT VALIDATION Client が リクエス トに署名 Auditor が 事前に 順序づけ Ledger が実行し コ ミット Auditor が結果を 検証し 自らも実行 Client が 結果を照 合 実行したいコントラクト と引数に署名し Auditor に送る。 競合をもとにトランザク ションを部分的に順序づ け、受け付けた事実を記 録する。 Auditor が決めた順序で コントラクトを実行し、 asset の新しい版を追加 してコミットする。 Ledger が返した結果か ら正しい順序で実行され たかを検証し、request proof に基づいて自らも 同じコントラクトを実行 する。 Ledger と Auditor から 返った結果を突き合わ せ、食い違えば Byzantine 故障 として 検知する。 → asset record → asset record purge されない purge されない → request proof → Coordinator state record purge 対象 purge 対象 © 2026 Scalar, inc. STEP 5
67. 何が消えて、何が残るのか パージで消えるもの パージされないもの LEDGER SIDE LEDGER SIDE Coordinator state record Asset record ScalarDB が Coordinator テーブルで管理する確定結果 業務データ本体とその履歴（ハッシュチェーン） AUDITOR SIDE AUDITOR SIDE Request proof Asset record リクエストごとに保存される受付の記録 Ledger と突き合わせるために保持する同一の状態 両者をまとめて residual transaction state（残存トランザク ション状態） と呼びます。 Ledger 側・Auditor 側それぞれの asset record は残ります。 ScalarDL の 改ざん検知とデータ検証の仕組みは、パージを有効 にしても変わりません。 © 2026 Scalar, inc.
68. いつ消してよいのか トランザクションが確定し、リカバリの必要がなくなった時点で、この状態は役目を終えています。 実行中 / リカバリ前 確定後 状態が必要 パージ可能 処理とリカバリのために不可欠 役目を終えており、ScalarDL の動作には不要 残すべき唯一の実務的な理由 アプリケーションが後から「あのトランザクションは commit されたのか、abort されたのか」を照会する必要があ る場合です。その要件があるうちは状態を残し、不要になってから消します。この運用には 手動パージ が向いてい ます。 © 2026 Scalar, inc.
69. 3つの パージ オプション 3つは排他ではなく、組み合わせて使えます。 On-completion 自動 / 即時 Scheduled 自動 / 定期スキャン Manual 手動 / コマンド 各トランザクションの完了直後、ロック 解放後に非同期で削除。 best-effort な ので取りこぼしはあり得ます。 通常運用で残存状態を最小に保ちたいと き。 残存状態をバックグラウンドで定期ス キャンして回収。 障害などで on-completion が取りこぼし た分の回収。 scalardl purge-state を実行。 scheduled と同じスキャン処理を任意の タイミングで走らせられます。 自動パージを切り、アプリが結果を引か なくなってから消したいとき。 © 2026 Scalar, inc.
70. 設定 まず Ledger と Auditor の両方でマスタスイッチを入れます。どちらも既定値は false です。 MASTER SWITCHES — パージ機能利用時に必須 scalar.dl.ledger.transaction_state_purge.enabled = true scalar.dl.auditor.transaction_state_purge.enabled = true On-completion purge Scheduled purge scalar.dl.auditor.transaction_state_purge scalar.dl.auditor.transaction_state_purge .on_completion.enabled = true .scan.interval_secs = <秒> .scan.limit = <件数> これらの設定は起動時にのみ読み込まれます。変更後は Ledger と Auditor の再起動が必要です。 © 2026 Scalar, inc.
71. 前提条件と、既存環境からの移行 Ledger + Auditor 構成が必須。 Ledger 単体の構成 では パージ機能 を利用できません。 両側のスキーマが パージ 対応であること。 3.14.0 以 降で作成したスキーマは対応済みです。 新規構築の場合 既存環境をアップグレードする場合 通常どおり Schema Loader でスキーマを作成 します。Ledger 側でのみ、write-set logging を有効にするプロパティを追加してください。 3.14.0 対応の Schema Loader で、次の順に実行します。 1 Ledger の properties に write-set logging を追加 2 Ledger スキーマを更新 --coordinator --repair-all 3 Auditor の不足テーブルを作成（オプション無しで実行） 4 Auditor スキーマを更新 --alter scalar.db.consensus_commit .coordinator.write_set_logging .enabled = true 順序に注意。--alter は既存テーブルへの列追加のみを行うた め、テーブルが無い状態で実行すると失敗します。 Auditor 側は追加オプション不要です。 © 2026 Scalar, inc.
72. 既存環境では、先に削除ツールで溜まった分を回収する パージ機能を有効にしても、それ以前に蓄積された state は削除されません。 手動パージを実行しても対象外で す。既存環境で有効化する場合は、原則として事前に削除ツールを実行してください。 実施順序例 なぜツールが必要か パージが対象にできるのは、パージ対応スキーマの もとで記録された state です。それ以前に蓄積され た分は、自動パージ でも 手動パージ でも回収され ません。 1 スキーマを purge 対応に更新する つまり、有効化しただけでは 今後の増加が止まる だけ で、すでに使っているストレージは減りませ ん。 2 自動パージ (on-completion) を有効化する 3 削除ツールで既存の蓄積分を回収する 4 自動パージ (定期スキャン) も有効化する 削除ツールは現時点では、バックエンドスト レージとして Cosmos DB のみ を使用している 環境に対応しています。それ以外の構成につい ては個別にご相談ください。 Schema Loader での手順は前のスライドのとおり 以降、正常終了した新規の state は回収されます このステップを飛ばすと、過去分は残り続けます 過去分が残存していると定期スキャンが進捗しないので注意 © 2026 Scalar, inc.
73. 運用上の注意点 導入の前提条件 通信経路を TLS で保護してから有効化する ✓ Client ↔ Ledger request proof には、同じリクエストの再送を検知する役割もあ ります。purge 後は ScalarDL 単体でのリプレイ検知には依存で きなくなるため、その防御をネットワーク層で担保します。 ✓ Client ↔ Auditor ✓ Ledger ↔ Auditor on-completion は best-effort 設定変更には再起動が必要 削除に失敗した分は残り、定期スキャンによるパージ または 手動パージ で回収されます。 パージ関連の設定は起動時にのみ読み込まれます。無効時は 手動パージも拒否されます。 トランザクション結果の照会 削除ツールの実行はオフピーク推奨 commit / abort を後から引く必要があるなら、その期間は 残す設計に。自動purgeは無効のままにします。 削除ツールは、サービス稼働中に実行しても不整合がないよ うに設計されていますが、asset recordの読み書きが競合し た場合、実行時間が増大する可能性があります。 © 2026 Scalar, inc.
74. パージ機能まとめ 機能のまとめ 有効化を検討すべき環境 ✓ Ledger + Auditor 構成で運用している 消えるのは残存トランザクション状態だけ Coordinator state record と request proof。asset record は Ledger 側・Auditor 側とも残り、改ざん検知の 仕組みは変わりません。 ✓ 長期運用、あるいはトランザクション量が多い ✓ ストレージ使用量や保存コストが課題になっている ✓ 通信経路が TLS で保護されている 自動2種 + 手動1種を組み合わせる on-completion / scheduled / manual。すべてデフォルト 無効で、有効化するまで挙動は従来どおりです。 既存環境は削除ツールが前提 有効化しただけでは今後の増加が止まるだけ。蓄積済みの 分は事前に削除ツールで回収します。 詳細はドキュメント「Purge the Residual Transaction State」をご参 照ください。 © 2026 Scalar, inc.
75. デモ © 2026 Scalar, inc.
76. ロードマップ © 2026 Scalar, inc.
77. ロードマップ ScalarDB 3.20以降 ScalarDL 3.15以降 Microprofile準拠のマイクロサービスフレームワーク との連携 ライフサイクル管理 Quarkus等の既存のフレームワークから2PCやSagaを実行 古いデータは安価なストレージ（オブジェクトストレージ等）に 移して、長期保存を実現しつつ、データの保持コストを削減 AIベースのカタログ管理機能 ScalarDL Manager (オブザーバビリティの強化) AI+HITLによる半自動のカタログ構築を実現 ScalarDLの運用監視ツール SQLパススルー、対応SQLの拡充 Google Marketplaceへの対応 Google Marketplaceへの対応 詳細はこちら ScalarDBロードマップ © 2026 Scalar, inc. ScalarDLロードマップ
78. 質疑応答・要望フィードバック © 2026 Scalar, inc.