【プライベートブロックチェーンが未来を作る】ブロックチェーンとRDBの一貫性

ハイブリッドアーキテクチャという現実解

ブロックチェーンが人気を博してきたとはいえ、システム開発現場の主流は依然としてRDB(Relational Database)である。

ブロックチェーンを採用すると決めたとしても、ほとんどのケースでスモールスタート、つまり、ある一部分だけをブロックチェーン化するにとどまり、それ以外の部分は従来通りRDBで処理することになると思われる。

いわゆるRDBとブロックチェーンのハイブリッドアーキテクチャである。

ハイブリッド型アーキテクチャでは、データの一貫性に注意が必要だ。

障害発生時にRDBとブロックチェーンの間でデータ不整合が発生しないか、データリストアの復旧タイミングが揃っているか、例外発生時のロールバック機能によって、RDBだけ過去に戻ったりしないか等、様々な視点で一貫性の維持に注意を払わなければならない。

事前対策が大事！

ブロックチェーンはその改ざん耐性が仇となり、データの補正が極めて大変なテクノロジーである。

スマートコントラクトが使える場合、データ補正専用のスマートコントラクトをリリースして、プログラム経由でデータを補正しなければならない。RDBのSQLによるデータ補正と比べると、数倍のコストがかかると思えばいい。

そのため、データ不整合を起こさない仕組みを設計初期から考えておいたほうがよい。

ポイントは3つある。

1. 可能な限りデータの棲み分けを行い、1トランザクションでRDBとブロックチェーンの双方を更新することを避ける。

データ設計については、以前書いたNOTEを参考にしてほしい。データモデル設計をいかにうまくできるかが、ブロックチェーン開発の最大の肝である。

2. やむなく双方を更新しなければならない場合、RDBに格納したデータとブロックチェーンに格納したデータを紐付ける共通キーを発行しておく。

例えば、RDBにインサートしたときのサロゲートキーをブロックチェーンにも持たせる。


3. 2で発行した共通キーを基に、逆取引(相殺取引)を行うスマートコントラクトを実装しておく。

Hyperledger Fabricであれば、deleteState()を使ってワールドステートから削除してもいいと思う。


ブロックチェーンを採用するのであれば、すべての処理をブロックチェーンで完結させるほうが圧倒的に簡単である。

しかし現実問題、開発現場はそうなっていないし、オフチェーン取引も拡大しつつある。
ブロックチェーンとそれ以外のデータストアの一貫性は今後も重要な検討課題になっていくのではないだろうか。