We are pleased to announce that Scalar DB is listed in the database category of CNCF Landscape. We will further accelerate our customers’ DX journey with Scalar DB and the other cloud-native computing products.

今回はScalar DLの実装について紹介します。Scalar DLのアーキテクチャやScalar DLのビザンチン故障検知プロトコルの概要については、以前のエントリを参照ください。（英語版はこちら）

Scalar DL（下図参照）はデータベース上で動作する主にJavaで書かれたミドルウェアであり、Ledger, Auditor, Client SDKから構成されています。それぞれのコンポーネントの実装を見ていきましょう。

Ledger

Ledgerはビザンチン故障検知プロトコルのCommitフェーズを実装しています。LedgerはContractと呼ばれる決定的関数を管理し、ユーザはその関数を定義し指定することでトランザクションを実行することができます。コントラクトにおいては、ユーザは任意のビジネスロジックを記述することでき、またコントラクトのインターフェースに従いデータベース操作を行うことできます。コントラクトが他のコントラクトを呼び出すコントラクトのネスト実行も可能であり、この機能を用いてコントラクトのモジュール化を行うことができます。Ledgerにおける一連のコントラクトにおけるデータベースへの操作はACIDを保証します。各コントラクトはJavaバイトコードの形式で電子署名と共にデータベースに保存されているため、処理内容（バイトコード）に変化がないかを後から検証することができます。

Ledgerは下位層のデータベースをキーバリューベースの多次元マップで抽象化しています。シンプルな抽象化であるため、多様なデータベースを扱うことができます。多次元マップはレコードの集合として構成され、レコードはレコードキー（アプリケーションレベルのプライマリキー）、バージョン、値の集合から構成されます。値の集合は、レコードを導出するために用いられるコントラクトの引数や、値の集合のダイジェスト等を含みます。レコードキーとバージョンでプライマリキーを構成し、プライマリキーが値の集合を一意に特定します。同じレコードキーをもつレコード群に対してハッシュチェーンが構築しているため、そのレコード群に対する改ざん等を部分的に防止します。ただし、当該機構はビザンチン故障の検知を実現するために必要というわけではありません。

Ledgerは上記のデータベース抽象化を用いて改ざん検知機構を実装しています。また、データベース抽象化はトランザクションマネージャであるScalar DBを用いて効率的に実装されています。データベース抽象化層においては、現状、PostgreSQL、MySQL、Oracle Database、Microsoft SQL Server、Apache Cassandra、Amazon DynamoDB、Amazon Aurora、Azure Cosmos DB、とこれらと互換性のあるデータベースをサポートしています。Scalar DBはデータベース非依存のACIDトランザクション機構をもち、(Read-committed) Snapshot IsolationとStrict Serializabilityの分離レベルをサポートしています。下位のデータベースがACID準拠のデータベースである場合は、ユーザは、下位のデータベースにトランザクション管理を委譲するか、Scalar DB独自のトランザクションを行うかの、どちらかの方法を選択できます。

Ledger単体でもサービスを提供することが可能です。その場合は、Scalar DLはデータベース非依存性や高いスケーラビリティ等のScalar DL固有の性質を除いて、Oracle Blockchain TableやAmazon QLDBと同様のビザンチン故障検知性を提供します。つまり、一つの管理ドメインでデータベースを管理するため、ある一部のビザンチン故障のみを検知します。

Auditor

Auditorはビザンチン故障検知プロトコルのOrderingフェーズとValidationフェーズを実装しています。AuditorはLedgerと同じコントラクトを管理します。また、Ledgerと同じデータベース抽象化層を用いているため、下位に多様なデータベースを用いることが可能です。

正しさ（安全性）を保証するために、AuditorはLedgerが配置される管理ドメインとは別の管理ドメインに配置される必要があります。

Client SDK

Client SDKはビザンチン故障検知プロトコルに基づきLedgerとAuditorをやりとりをします。Client SDKを用いて作られたアプリケーションプログラムは電子署名のための鍵ペア（秘密鍵の証明書）を（必要に応じてユーザごとに）管理し、電子署名付きの実行リクエストを作成します。LedgerおよびAuditorは当該実行リクエストを受け取ると、署名を対応する証明書で検証し、検証が成功したらコントラクトを実行します。電子署名付きリクエストはレコードと共にデータベースに保存されるため、レコードを見ることにより、そのレコードがどの秘密鍵の所有者により実行されたものかを判別することが可能です。電子署名のかわりにHMACで認証をするオプションもあります。トランザクション処理をより高速に実行できるようになりますが、その場合は、上記のような否認防止性を提供することができません。

現段階では、Java、Node.js、ブラウザにおけるJavaScript、およびGoにより書かれたClient SDKが提供されています。

まとめ

このブログエントリでは、Scalar DLの実装を説明しました。今後は、Scalar DLに関するさらなる詳細を紹介してく予定です。

今回はスケーラブルかつ実用的なビザンチン故障検知ミドルウェアであるScalar DLの概要を紹介します。Scalar DLが解決する課題については、以前のエントリを参照ください。（英語版）

概要

Scalar DLはデータベース上で稼働し、下位のデータベースを変更することなく、ビザンチン故障検知機構を提供するミドルウェアです。

Scalar DLは、ユーザに対して単一データベースのビューを提供し、内部で以下の二つのデータベースサーバを異なる管理ドメイン*で管理します。

• プライマリデータベースサーバ（Ledgerサーバ）：アプリケーションのデータを保持するプライマリデータベースレプリカを管理し、トランザクションのコミットを行う
• セカンダリデータベースサーバ（Auditorサーバ）：プライマリデータベースレプリカと同じデータを保持するセカンダリデータベースレプリカを監査の目的で管理する

双方のサーバはContractと呼ばれる決定性を有する関数（ビジネスロジック）を保持し、与えられた入力に基づき状態と結果を導出します。

Scalar DLのビザンチン故障検知プロトコルのポイントは、LedgerとAuditorがトランザクションの半順序を非中央集権的かつ並行に同意することです。当該プロトコルでは、Auditorがクライアントから受け取ったトランザクションを競合に基づいて半順序に整列し（Orderingフェーズ）、Ledgerが並び替えられたトランザクションを実行・コミットし（Commitフェーズ）、AuditorがLedgerから受け取った順序結果を検証します（Validationフェーズ）。この3フェーズのプロトコルにより、双方の管理ドメインが（故障なく）正しく動作する限りにおいては、双方のデータベースは正しい（つまりstrict serializableな）同一の状態と結果を導出します。すなわち、もしどちらかのドメインにおいてビザンチン故障が発生する場合、データベースの状態または結果は食い違うため、その結果、クライアントがその食い違いを観測することでデータベースにおけるビザンチン故障を検知します。プロトコルのさらなる詳細については、今後のエントリで説明をする予定です。

*管理ドメインとは、一つの組織や管理機関が管理する、ノードとネットワークの集合です。

設計目標

Scalar DLの設計目標は以下の通りです。

改ざん検知性

Scala DLはデータベースシステムにおけるビザンチン故障を検知することで、データベースシステムに改ざん検知性を提供します。Scalar DLは、どちかの管理ドメインが正しく動作する限りは、ビザンチン故障を検知します。

スケーラブル

Scalar DLは各データベースレプリカを構成するノード数の増加に比例した性能スケーラビリティを実現します。各データベースレプリカにおいては、データ分割とレプリケーションにより高い性能とクラッシュ耐性を提供する（複数ノード構成の）分散データベースを用いることが可能です。

正しさ

Scalar DLはデータベースのトランザクションを並列に実行しつつ、正しさを保証します。Scalar DLの安全性（safety）は、Scalar DLが管理するデータベースシステムにおいて、双方の管理ドメインが正しい場合はStrict Serializabilityを提供し、どちらかの管理ドメインが故障している場合は、ビザンチン故障を検知します。Scalar DLの正しさについては、今後のエントリにおいてさらに説明します。

データベース非依存

Scalar DLはScalar DBを用いて実現されているため、データベース非依存のミドルウェアです。データベースシステムにおけるビザンチン故障検知機構をデータベースの変更なく、また、データベース固有の機能を用いずに実現します。Scalar DLは現状で、PostgreSQL、MySQL、Oracle Database、MySQL SQL Server、Apache Cassandra、Apache HBase、Amazon Dynamo DB、Amazon Aurora、Azure Cosmos DBとこれらと互換性があるデータベース上で稼働します。

クラウド非依存

LedgerおよびAuditorはコンテナ化されたミドルウェアであるため、Scalar DLはクラウド非依存です。Scalar DLはAWS CloudとAzure Cloudにおいて本番の稼働実績があり、Oracle Cloud、Google Cloudにおいては稼働確認が済んでいます。

まとめ

Scalar DLの概要と設計目標について説明しました。Scalar DLの主要な利点は、スケーラビリティおよび実用性を犠牲にすることなく、ビザンチン故障検知機構を提供することです。今後のエントリでは、Scalar DLのさらなる詳細や有用な機能について説明していく予定です。

最初のEngineering Blogでは、Scalarという会社とその主要製品について簡単に紹介します。（英語版はこちら）

Scalarは、Scalar社独自の信頼性を有するデータ管理技術を使ってお客様企業のDXを推進することを目的としている東京ベースのスタートアップです。現在は、Scalar DBとScalar DLと呼ばれる2つの主要製品を開発・提供しており、これらは既存のデータベースではうまく扱えない信頼性に関する課題を解決します。

Scalar DB: 汎用的なトランザクションマネージャ

Scalarが取り組む一つ目の課題は、複数のデータベースが連携する際に生じるトランザクション一貫性に関する課題です。この課題は一つの組織・企業において運用されているデータベースシステムにおいても、複数の組織・企業において別々に運用されているデータベースシステムにおいても起きるものです。そのような課題が起きるケースとしては、例えば、一つの企業の複数の部署で異なるサービス（例えば、クレジットカードサービスとポイントサービス）が運用されており、これらのサービスは連携する必要があるものの、サービスの独立性やシステムを疎結合にするために、それぞれのサービスが別々のデータベースを保持している場合などです。また、複数の企業においてそれぞれの別のサービスを運営している状況においても、それらのサービスが協調して付加価値を提供する場合なども考えられます。例えば、旅行予約サービスと保険サービスが連携して、旅行の予約と旅行保険の加入を同時に成立させるというオプションを提供する場合などです。

このようなケースにおいては、各々のシステムのデータベースは独立して管理されているため、複数のデータベースのトランザクション一貫性を保証することは必ずしも簡単ではありません。また、データベースの種類が異なったり、データベースがトランザクション機構を持たない場合においては、問題は一層難しくなります。データベースがXA準拠である関係データベース等であれば、XAによるTwo-phase Commitにより解決できる場合がありますが、XA準拠でないデータベース（例えば、Amazon DynamoDBやAzure Cosmos DB等のNoSQL）においてはこの限りではありません。

Scalar DBはこの課題を汎用的に解決します。Scalar DBはデータベースを抽象化し、その抽象化層を用いてトランザクション機構を実装しているため、特定のデータベースに依存しない形でトランザクションを実現することができます。この仕組みにより、Scalar DBは、複数のデータベースを跨いでデータを読み書きする場合においても、トランザクション一貫性を保証しつつ処理を行うことができます。この仕組みには副次的な利点もあります。Scalar DBのデータベース非依存のトランザクション機構は、トランザクション機構をもたないデータベース（例えば、Cassandra、HBase, DynamoDB, Cosmos DB等）においても、トランザクションを可能とします。加えて、Scalar DBのデータベース抽象化は、アプリケーションのポータビリティを高めます。例えば、MySQLで書かれたScalar DBのアプリケーションは、アプリケーションを変更することなく、Dynamo DBへと移行できます。

さらなる詳細は以下のスライド、もしくはGitHubレポジトリを参照してください。今後のブログにおいても、より詳細な情報を提供していく予定です。

Scalar DL: データベースにおけるビザンチン故障検知ミドルウェア

2つめの課題は、データがデジタル化された際に起きる真正性やアカウンタビリティ（責任追跡性）に関する課題です。現状のデジタルデータは悪意によるコピー、書き換え、削除等を簡単に行えてしまうという問題があります。このような悪意によるデータの改ざんは学術的にはビザンチン故障と呼ばれ、それらの故障に対してどう対処すべきかの議論はこれまで広く行われてきています。

ビザンチン故障耐性（BFT）に関する技術は従来からState Machine Replication（SMR）の領域で研究開発されてきており、近年はBlockchainの文脈においても進展がみられます。ただし、これらの技術は基本的には逐次的な処理に基づいているため、スケーラビリティにおいて課題がありました。つまり、計算資源を増やしても性能が向上しないという問題がありました。学術界のプロジェクト(*1)においては、これらの問題の一部を解決しているものの、これらの技術はまだ実用化されていません。また、BFTにおいては正しさを保証するために最低でも4つ（N>3f）の管理ドメイン（管理組織）が必要であるという実用性に関する別の課題もあります。*2

Scalar DLは上記の課題を独自のアプローチで解決します。まず、Scalar DLは2つの管理ドメインだけを用いてビザンチン故障に対応します。2はビザンチン故障に対応するための下限の管理ドメイン数であり、ビザンチン故障の対応は検知（Byzantine fault detection）に限られるものの、ビザンチン故障に対応するシステムの運用という観点では最も実用性が高い制約であると考えられます。また、Scalar DLの新しいビザンチン故障検知プロトコルは下位のデータ管理システムの並列性やスケーラビリティを損なうことなくビザンチン故障の検知を実現します。加えて、Scalar DLはデータ管理システムに依存しないミドルウェアシステムであるため、多くのデータ管理ソフトウェア（データベースやストレージ）の上で動作することが可能です。

さらなる詳細は以下のスライド、もしくはGitHubレポジトリを参照してください。今後のブログにおいても、より詳細な情報を提供していく予定です。また、Scalar DLに関する学術論文（VLDB’22に採録）も近日中に公開される予定です。

*1: HRDB (SOSP’07), Byzantium (EuroSys’12), Basil (SOSP’21)

*2: ただし、この課題は世間に正しく認識されておらず、結果、1つの管理ドメインでBFT SMRやBlockchainを動かすといった、（期待通りに動作しない）本末転倒なシステム構成が散見されています。

最後に、ScalarはScalar DBとScalar DLの他に、それらを用いてお客様の課題を直接解決するミドルウェア・アプリケーションも開発・提供しています。これらに関しても今後のブログで紹介していく予定です。