Hyperledger Fabricでの開発段階でハマりがちな落とし穴とは？

　日本オラクル株式会社は4月4日、エンタープライズ領域でのブロックチェーン活用を検討しているユーザーや技術者向けの勉強会「Blockchain GIG」を開催した。本セミナーは数か月に一度というペースで定期開催され、今回が第2回目となる。今回は概念実証から商用展開まで手がけるエンジニアらが、エンタープライズのブロックチェーン活用について、さまざまな視点から講演を行った。

　本稿では、日本オラクルの中村岳氏によるイントロダクション「エンタープライズブロックチェーンをはじめよう」と、アクセンチュア株式会社の山田昌嗣氏が、商用展開まで手がけて直面した問題と解決策を語った「バックエンド業務まで見据えたHLFシステムの設計ポイント」をまとめる。

オラクル中村氏講演「エンタープライズブロックチェーンをはじめよう」

日本オラクル株式会社・クラウドプラットフォームソリューション統括 Cloud Platformソリューション本部の中村岳氏

　ガートナーによると、ブロックチェーンは「幻滅期」に差し掛かっている。「幻滅期」の語感は良くないが、悪い意味ではないと中村氏は解説し、「我々の実感としてもその通り」と述べる。「幻滅期」はその技術が確立され、過度な期待が薄まり、正確な仕様の把握が進んだ頃合い。リアルなユースケースが生まれ始める時期を指すという。同誌の統計によると、「ビッグ・データ」や「クラウド・コンピューティング」といったものが、先んじて幻滅期を過ぎ、社会実装が進められている技術だ。

「ブロックチェーンは幻滅期へ？」ガートナー発表「日本におけるテクノロジのハイプ・サイクル：2018年」より

　エンタープライズのブロックチェーン活用においては、後発の事業が先行事例を参考にできるようになったため、的を射たユースケースの検討が増加しているという。一方で、コンソーシアム（合弁会社）の作り方や運営といった部分では、手法が確立されていないことが多く、ユースケースの検討から実際のシステム構築へ至る道のりは依然として険しい。

　そういった背景にあって、オラクルはブロックチェーンに限らず、さまざまなエンジニア向けに「Oracle Code Tokyo Night」「Oracle Cloud Hangout Cafe」（略称：OCHa Cafe）という2つの勉強会を開催している。本セミナーも前者に含まれる勉強会シリーズの一つだ。いずれも参加費無料で、オラクルのオフィスにて定期的に開催されている。

　本題に戻り、中村氏はエンタープライズ向けブロックチェーンに求められる3要素を解説する。1つ目は「データ公開範囲の限定」で、コンソーシアム外にデータを公開しないのはもちろん、内部でもさらに公開範囲を細分化できるとよいとのこと。2つ目は「非機能要件」で、当然必要となるセキュリティや耐障害性。3つ目は「基盤としての将来性」だ。いざ本番利用が始まってから、その基盤が廃れてしまった際に切り替えは容易ではないため、ある程度の実績や信頼性は必要だという。

　パブリック（パーミッションレス）型とプライベート（パーミッションド）型のブロックチェーンを比較する。エンタープライズでの利用は後者が主流である。パブリックでは参加者に匿名性があるが、プライベート型は参加者の現実とのIDが認証された許可制をとる。プライベート型はメンバーが明らかであるという特性を生かして、PoWなどの演算処理を必要としない分、パブリックよりも高速にトランザクション処理を実現できる。

　プライベート型ブロックチェーンおよびDLT（分散台帳技術）の代表例として、「Hyperledger Fabric」「Enterprise Ethereum」「Corda」の3つがある。中村氏の談では、最もユースケースが多く、実運用が進んでいるのがHyperledger Fabric（以下、HLF）とのこと。オラクルは、HLFをベースとしたPaaS（Platform as a Service）「Oracle Blockchain Platform Could Service」を提供している。

代表的なブロックチェーン/DLT基盤の仕様比較表

　Hyperledger Fabricは、2019年1月にv1.4をリリース。LTS（長期保証）版として、2020年1月までサポートを行う。安定版の登場により、さらなる参入企業の増加が期待できると中村氏は述べた。また、アップデートを続けるv2.x系では、ゼロ知識証明、ネイティブトークンへの対応や、RAFT、Simplified Byzantine Fault Tolerance （SBFT）といったコンセンサスアルゴリズムなどの拡張機能が予定されるという。

アクセンチュア山田氏講演「バックエンド業務まで見据えたHLFシステムの設計ポイント」

アクセンチュア株式会社・テクノロジー コンサルティング本部　テクノロジーアーキテクチャ グループ マネジャーの山田昌嗣氏

　2番目に講演を行ったのはアクセンチュアの山田氏。金融機関向けにHLFベースのブロックチェーンプロダクトを開発し、商用展開している。今回山田氏は、その開発・運用の経験を通じて発見した、HLFでの設計上の落とし穴とその回避方法を知見として共有する。

　金融機関などのエンタープライズシステムで、ブロックチェーンに求められる主要素は2つあると山田氏は言う。高速にデータを記録・取得する性能と、記録したデータを抽出して活用する機能だ。ブロックチェーンの特長として記録する方ばかり焦点が当たっているが、エンタープライズでは「記録した後の設計が重要になる」と氏は語る。

エンタープライズシステムの要件

　前提として、HLFでいうスマートコントラクトを、Chaincodeと呼ぶ。CouchDBは、HLFのノード外部のデータベースとして用いられるステートDB。格納したJSONデータは、設定されたIndexなどを活用して多彩な検索を行うことができる。

「大量書き込み時に参照が遅くなる」問題

　先の2要素に関して、性能を突き詰める上でスケーラビリティの問題が発生したという。金融機関では、ポイントの付与などで絶えず大量の「記録」が発生する。その間には他のユーザーのデータ「参照」といった、他のオンライン処理すべてが遅延してしまうのだ。

　この「大量書き込み時に参照が遅くなる」問題は、いくつかの要因がある。問題の発生時、CouchDBとChaincodeの接続部分がシングルスレッドになっており、トランザクションが終了しない限り次のトランザクションが確立しない。要はノード1つあたり1個ずつしかトランザクションを送り出せないため、詰まっている状態だ。もう1つは、CouchDB上のIndex深度が深くなった際、IndexリビルドによってChaincodeとCouchDB間の通信が低速化するという。

　この問題には、できるだけ早くノードを解放することで解決を図ったという。本来、すべてのノードがリクエストを検証しているが、リクエストの内容によって使用するノードを制限する仕組みを取り入れる。制御サーバーによって、すべてのノードが使用中にならないように作業を振り分けることで、通信の詰まりを低減したという。

大量データ書き込みで参照が遅くなる問題の対応策

　一方、CouchDBのIndexリビルドによる低速化は、データ設計に依存する。リビルドの間隔やデータ投入時の多重度など、パラメータの見直しでいくつものパターンを試行錯誤して最適解を得たという。

ほしいデータを全量取り出せない問題

　次にぶつかったのは、一定期間内のデータをすべて抽出しようとすると失敗する問題だという。Chaincodeを経由して、ブロックチェーンやCouchDBから大量のデータを取り出すことができないという問題だ。

　HLFのネットワーク保護機能が要因となる。HLFは保全のためネットワーク上の転送量に100MBという制限がある。一度に大量のデータを取り出そうとすると、この保護機能が障害となってしまうわけだ。同時に、この問題においてはノード側の負荷も検証する必要があるという。

ほしいデータを全量取り出せない問題

　この問題にはデータを分割取得することでHLFのネットワーク制限を回避する。まず、Chaincode側で分割データを圧縮する。圧縮したデータをブロックチェーン経由でクライアントに渡す。これを繰り返して、最後にクライアント側で分割・圧縮されたデータを結合することで、問題を回避できたという。

ほしいデータを全量取り出せない問題の対応策

　また、Chaincodeの記述から可能な限り文字数を削ることも有効であったという。たとえば変数名を短縮して数バイト削るだけでも、100万回データ取得すれば相応の容量となる。数バイトの努力がネットワークの最適化につながるというわけだ。