大塚紳一郎, 2019年12月
2003年、株式会社野村総合研究所に新卒で入社。ミッションクリティカルシステムにおけるOracle Databaseの構築、運用、コンサルティングに関して15年以上の経験を持つ。毎年サンフランシスコで開催される世界最大のテクノロジーイベント「Oracle OpenWorld」を含む各種イベントでの講演多数。Autonomous DatabaseがGAされた年にOracle ACE Associateになれたことに運命を感じており、Oracleデータベース管理者の今後のロールモデルの構築に携わりたいと考え日々活動中。最新の登壇タイトルは「Boosting your career through Oracle Cloud Infrastructure 2018 Certified Architect Associate.」
こんにちは、NRIの大塚です。今回はMICRO DATA領域の連載6回目です。
テーマとするPaaSはOracle Blockchain Platform Cloud Serviceです。
今回はMICRO DATA編のまとめを行いたいと思います。
今回以下のようなPaaS(Oracle Blockchain Platform Cloud Service)を活用したシステムを構築しました。
このシステムを用いてOracle Blockchain Platform Cloud ServiceはGUIベースの専用管理コンソールを持つ、ユーザーフレンドリーなサービスであることの確認ができました。
図:専用管理コンソールのトップ画面
図:チェーンコードの管理画面
図:ノードの管理画面
図:Hyperledger Fabricのパラメータ設定画面
その他にもNetwork管理や、チャネル管理、Developer Toolsなど充実したユーザ支援機能を持っています。
今回の連載で構築した環境を活用して実施した、もう一段深い内容の検証結果をご紹介します。
検証ポイントは、Oracle Blockchain Platform Cloud Serviceが標準的なHyperledger Fabricを独自に拡張した箇所の中から3つを抽出しました。
検証ポイントの説明
Oracle Blockchain Platform Cloud Serviceは標準のHyperledger Fabricとの最も大きな相違点の1つとしてREST Proxyが挙げられます。REST ProxyはHyperledger Fabric SDKを内包しています。標準のHyperledger Fabric構成でのクライアントアプリはHyperledger Fabric SDKベースで作成し、gRPCによる通信を行うことになります。この点は非常に学習コストが高いと考えます。一方のOracle Blockchain Platform Cloud Serviceは、標準的なRESTアプリを用いることができます。デバッグに要する時間なども考えると圧倒的に効率的です。
またHyperledger Fabric SDKのバージョン管理が不要である点も特筆点です。これはつまりgRPCで接続するための環境設定が不要であるということです。gRPCで接続するための環境設定は、バージョンごとに変更が多く、マニュアルの解読が必要でした。以上からアプリ開発者のことを良く考えてサービス化されていると感じました。 補足:従来のgRPCも利用可能です。
Oracle Blockchain Platform Cloud Serviceは標準のHyperledger FabricとWorld StateのDatabaseが違います。標準のHyperledger FabricはLevel DBもしくはCouch DBから、どちらかを選択します。それに対して、Oracle Blockchain Platform Cloud ServiceはBerkeley DBです。SQLでのリッチクエリを用いることができるだけでなく、ファントムリードの発生を防ぐことができます。
ブロックチェーンのためのデータモデリングに関して1つ目のお話をします。
ブロックチェーン上のデータは削除することができません。ですので、削除が必要な情報は登録すべきではありません。(個人情報など)。また、複雑なデータも性能の観点から登録すべきではありません。以上のことからブロックチェーンには普遍的かつ、シンプル化されたデータを登録することになるのですが、それではシステムとして成立することはできません。そのため、RDBMSとセットでブロックチェーンを稼動させることになります。
削除が必要なマスタデータや複雑な構造を持つデータはRDBMSに格納することがベストプラクティスです。 アプリケーションはRDBMSとブロックチェーンの両方からデータを取得することになります。そうなると、問題となってくるのはトランザクション制御です。ブロックチェーンはRDBMSと違い、ロックという考え方はありません。そのため、トランザクション制御がRDBMSと異なります。Hyperledger Fabricはトランザクションを検証→確定という2段階で行います。そのため、検証と確定の間に別のトランザクションが割り込む余地があるのです。
Oracle Blockchain Platform Cloud ServiceはWorld StateにBerkeley DBを採用しています。
Berkeley DBはトランザクションの割り込みに対する耐性があり、ファントムリードの検出が可能です。
実際にアプリケーションを作成して検証してみると以下のような結果が得られました。
標準のHyperledger Fabric | 検証結果:ファントムリードの発生を検知できず、意図しない状態となってしまった |
Oracle Blockchain Platform Cloud Service | 検証結果:READ_CONFLICTを検知出来た。 アプリケーションは、トランザクションの割り込みが発生していることが分かる為、処理を中断し、トランザクションをリトライするなどの対処が可能だった |
ブロックチェーンのためのデータモデリングに関して2つ目のお話をします。
ブロックチェーンは従来のRDBMSと比較して性能が出ません。それはブロックチェーンの構造からも明らかであり、性能観点でもRDBMSとブロックチェーンとのハイブリッド構成が現実的です。
性能上問題になりそうな複雑な構造を持つデータはRDBMSに格納し、かつブロックチェーンに格納するデータは可能な限りスリム化することが必要です。このとき用いるRDBMSはブロックチェーンに搭載しないデータを格納するという意味でオフチェーンDBと呼ばれることがあります。
それでもまだブロックチェーンの特性上注意が必要な性能の観点があります。それは履歴(History)の参照です。 チェーンで繋がれたブロックをすべて遡る必要がある履歴参照はブロックチェーンの構造上、チェーンが長くなるにつれて劣化していくと言われています。
Oracle Blockchain Platform Cloud Serviceは対策としてブロックチェーンの履歴情報を外部のRDBMSにコピーする機能を備えています。この機能はRich History Databaseと呼ばれていて、履歴データのレプリカを外部のRDBMSに作ることができます。
つまり、履歴データの検索はブロックチェーンに対してではなく、RDBMSに対して行うことができます。
実際のアプリケーションを用いて、その効果を検証したいと思います。
性能評価の結果を記載しますが、測定の条件やアプリケーションの作りで結果は大きく異なります。ですので、 あくまで参考情報としてお読みください。ここでお伝えしたいのはブロックチェーンの特性としてチェーンされたブロックを遡る行為がチェーンの長さに依存して性能劣化していくことと、Oracle Blockchain Platform Cloud Serviceが持つその事象への対策機能であるRich History Databaseの効果です。
シナリオ
~1回目~
①新規ユーザ01の作成。新規ユーザ01は100円を保有
②送金。新規ユーザ01から既存ユーザAに10円送金(既存ユーザAの取引履歴が1つ増える)
③既存ユーザAの全履歴を表示
④終了
~2回目~
①新規ユーザ02の作成。新規ユーザ02は100円を保有
②送金。新規ユーザ02から既存ユーザAに10円送金(既存ユーザAの取引履歴がさらに1つ増える)
③既存ユーザAの全履歴を表示
④終了
以降同様に500回繰り返し
このシナリオを以下の2つのケースで実施し、Oracle Blockchain Platform Cloud Serviceが持つ対策機能の効果を確認したいと思います。
図:ケース① 直接ブロックチェーンネットワークのStateDBに履歴を問い合わせる場合
図:ケース② Rich History Databaseに履歴を問い合わせる場合
実際の実装を下図に示します。
結果
※性能評価の結果は、測定の条件やアプリケーションの作りで結果は大きく異なります。ですので、あくまで参考情報としてお読 みください。ここでお伝えしたいのはブロックチェーンの特性としてチェーンされたブロックを遡る行為がチェーンの長さに依存 して性能劣化していくことと、Oracle Blockchain Platform Cloud Serviceが持つその事象への対策機能であるRich History Databaseの効果です。
ブロックチェーンシステムのデータ配置について考えてみたいと思います。総括すると以下のようになるかと思います。
フルマネージドのサービスである ユーザーフレンドリーなGUIコンソール、トポロジー解析や、トランザクション量に応じた課金モデルなどBlockchain as a Serviceというイメージどおりのフルマネージドサービス 実利用を追及している Hyperledger Fabricを独自に拡張しており、実利用を目指した仕上がりとなっている以下3点の実機検証を行い成熟度の高さを確認できました ① SDK管理負荷軽減/アプリケーション開発生産性の向上を目指したREST Proxy機能 ② ファントムリードを検知し、従来のRDBMSに近い感覚での実装にするためにBerkeley Databaseを採用 ③ 全履歴データ参照性能を改善し、 Blockchainデータ活用範囲の拡大を目指したRich History Database機能
以上がMICRO DATAのお話となります。いかがでしたでしょうか?
データモデリングやトランザクション制御などはOracleデータベース管理者である皆さまの得意分野だと思います。
新しい時代のシステム構築も引き続き牽引していってください。
MICRO DATA編はここまでといたします。読んで頂きありがとうございました。
謝辞
Oracle Blockchain Platform Cloud Serviceの検証を支えてくださった日本オラクルの大橋さん、中村さん、瀬尾さん、五嶋さん、金本さん、そして、私達Oracleデータベース管理者の憧れであるOracle Technology Networkへの執筆機会をくださった日本オラクルの豊竹さんに、この場をお借りして深く感謝申し上げます。ありがとうございました。
※Oracle Blockchain Platform Books:
https://docs.oracle.com/en/cloud/paas/blockchain-cloud/books.html
※What's Oracle Blockchain Platform:
https://docs.oracle.com/en/cloud/paas/blockchain-cloud/user/whats-oracle-blockchain-cloud-service.html
※Get Started Using Samples:
https://docs.oracle.com/en/cloud/paas/blockchain-cloud/user/get-started-using-samples.html
※About the REST APIs:
https://docs.oracle.com/en/cloud/paas/blockchain-cloud/rest-api/index.html
※Use the REST APIs to Develop Applications:
https://docs.oracle.com/en/cloud/paas/blockchain-cloud/user/use-rest-apis-develop-applications.html
※Create the Rich History Database:
https://docs.oracle.com/en/cloud/paas/blockchain-cloud/user/create-rich-history-database.html#GUID-F09873B0-98F6-430D-947C-299A5AD8CCCB
Keys to the Oracle Cloud indexページ▶▶
AutonomousDatabaseを無期限 / 無料(Always Free)で使用可能になりました。
Cloudをまだお試しでない方は、無料トライアルをご利用下さい。