1. 概要
Amazon Quantum Ledger Database（QLDB）は、「データ整合性」「完全性」「検証可能性」が不可欠なSoR（System of Record）アプリケーションに相性の良い台帳管理専用データベースです。弊社が取り組んでいるブロックチェーン文脈においても、上記の３要素については金融文脈だけではなく、物流やサプライチェーンにおけるトレーサビリティにおいて重要であると考えています。
2. QLDBとブロックチェーンの違い
上記の３要素を満たすような分散台帳を選ぶ際に、ethereum, Hyperledger Fabric, Corda, miyabiといったブロックチェーンを利用することが真っ先に考えられますが、その中でどのような特徴やユースケースがあるのかを検討しています。
QLDBの特徴としては下記が挙げられます。QLDBは分散台帳でもブロックチェーンでもなく、トランザクションの承認が複数ノードで必要ではないため、ブロックチェーンで想定される信頼されない複数の関係者がアクセスするようなビザンチン障害耐性アプリケーションには向いておらず、あくまでデータの監査性が重要なプリケーションで強みを発揮すると考えられます。
・ブロックチェーンの2〜3倍のトランザクションを実行できる（未検証）
・データが追記のみ可能なジャーナルに書き込まれる
・ジャーナルに含まれるドキュメントデータが正しく変更されていることを暗号学的に検証できる
・PrivateLinkに統合されているため、VPCを跨いだとしてもAWSネットワーク内部で完結することができる
・スマートコントラクトが実装できない
・PartiQLを利用してクエリが実行できる
・自動的にスケーリングするのでパフォーマンスチューニングが不要
2.1 ジャーナルとステートデータベース
ジャーナルは、トランザクションデータと関連するメタデータを保存す
る、イミュータブルな追加専用データ構造と説明されています。具体的には、PartiQLのステートメントとブロック情報、リビジョン情報などのメタデータを持ち、１ブロックに対して複数のトランザクションが格納できるようになっています。
RDBMSやKVSのような従来のデータベースにおいては常に最新のデータを保持するという仕組みになっており、とある瞬間のデータを保存しておくためにはスナップショットを作成しておくことが一般的です。
それと比較して、QLDBではジャーナルファーストでという形で、まずはジャーナルデータを書き込み、それによるステートの変化をステートデータベースに書き込んでおくという形になります。加えて、ステートデータベースは現在のステート情報と過去のバージョン情報を保持しているため、とあるブロックにおけるデータの情報が取得できるようになっています。
このことによって、従来のデータベースでは難しかった、ある時点でのデータを簡単に取得できるようになっています。これは権利移転情報などの履歴データへのアクセスが頻繁に発生するような用途に向いていると考えられます。
2.2 ジャーナルファーストの向き不向き
ジャーナルを介してステートデータベースが更新されるため、即時性が必要であり、頻繁にデータが更新され、更に最新情報のみが重要であるデータに関してはオーバーヘッドが大きいため不向きです。
実際のサービスにおいては、価値移転履歴や売買履歴、在庫情報などのデータ改ざんが許されないデータや特定のリビジョンにおけるデータを参照したいものを選定して格納すると良いと考えられます。
また、通常のブロックチェーンと比較してパフォーマンスは高いとは言われているものの、RDBMSなどと比較して明らかにスループットが低いため、参照系のパフォーマンス改善として、次に挙げるQLDB StreamingによるIndexingを利用することが良いのではないかと考えています。
3. QLDB Streaming
QLDB Streamingに関しては、こちらのScrapboxにて検証しています。
結論としては、QLDB Streamingに関してはジャーナルデータをKinesis Data StreamsにてS3やLambda経由でDynamoDBに書き込んでおくことによって、いわゆるIndexing（台帳のデータのキャッシング）をしておく用途として使うことが有用であるということが分かりました。
今後の発展として、ジャーナルデータをクロスリージョンレプリケーションすることが可能になり、関係者のAWSアカウント上のLedgerにレプリケーションができ、その整合性を管理できるようになればより監査性を担保できるようになるのではないかと期待しています。
実際運用を見据えたアーキテクチャにおいては、下記のような構成でKinesis Data Streamsから取得したジャーナルデータをDynamoDBに保存しておくことによって、次に示すQLDB Data Verificationを用意に実施することも可能になります。
4. QLDB Data Verification
QLDB Data Verificationに関しても、こちらのScrapboxで検証しています。
QLDBにおけるデータ検証はマークルツリーを用いて暗号学的に行っていいます。AWS上の検証機能だけではなく、上記QLDB Streamingで受け取ったジャーナルデータを保持しておき、それをSDKを利用するなどして途中で改ざんされていないということを検証できます。
5. 結論
現状のQLDBを利用することによって、「複数の事業者を跨がない、データ整合性、完全性、検証可能性をマネージドサービスで担保したSoRアプリケーションが比較的容易に構築できる」ということが言えると考えられます。
今後、QLDB Streamingによるクロスリージョンレプリケーションによって、更に複数の事業者が関係する監査性が高いサービスが構築できるのではないかと予想しています。
6. 今回検証で利用したコードや参考文献
検証用 GitHub Project（随時追加予定）
QLDBの特徴（公式ドキュメント）
QLDB Developer Guide（英語）
https://docs.aws.amazon.com/qldb/latest/developerguide/what-is.html
