More Related Content
Similar to 20191010 Blockchain GIG #5 石原様資料 (20)
More from オラクルエンジニア通信 (20)
20191010 Blockchain GIG #5 石原様資料
- 1. Copyright 2019 FUJITSU LIMITED
ブロックチェーンPoCにおける
開発リードタイム短縮のポイント
2019/10/10
石原 俊 (ishihara.shun@fujitsu.com)
0
Blockchain GIG #5 登壇資料
- 2. Copyright 2019 FUJITSU LIMITED
◼ 所属:富士通(株) ソフトウェア事業本部 デジタルウェア開発統括部
◼ 名前:石原 俊
◼ ブロックチェーン歴:3年(Hyperledger Fabricが中心)
◼ 生まれ:運用管理/監視ミドルウェアの開発
◼ 育ち:運用監視OSSの活用、クラウドサービス化
◼ 趣味:ラーメン二郎巡り
自己紹介
1
- 4. SEが躓くHyperledger Fabricの壁(1/2)
◼ クライアントアプリケーション⇒BCの連携I/F
◼ 基本的に専用のSDKを使用(node.js/Java/golang)
◼ トランザクションフロー
3 Copyright 2019 FUJITSU LIMITED
②リクエスト
Client Peer1 Peer2 Orderer
①リクエスト
③Endorsement返却
④Endorsement返却
⑤永続化依頼
⑧トランザクション情報伝搬
⑦最新情報問い合わせ
⑥順序生成
⑨トランザクション永続化
(ブロック生成) ⑦最新情報問い合わせ
⑧トランザクション情報伝搬
⑨トランザクション永続化
(ブロック生成)
いくつのPeerにリクエストを送ったらいいの? リクエスト先のPeerがダウンしていたらどう扱うべき?
選択・設計に迷う要素が多く、ハードルが高い
- 5. SEが躓くHyperledger Fabricの壁(2/2)
◼ チェーンコード(スマートコントラクト)の開発
◼ ブロックチェーンに管理させたいことをプログラムに落としたもの
◼ データストアとしてStateDB(KVS)を持つアプリケーションのようなもの
◼ 基本的には案件ごとに開発する必要がある
4 Copyright 2019 FUJITSU LIMITED
StateDB
Chaincode
メソッド1:口座開設
メソッド2:口座閉鎖
…
Client リクエスト データI/O
どういう単位でメソッドを切り分けたらいいの?
KVSのデータモデル設計はどう考えればいい?
〇〇は変更が多発する性質があるのだが、
そのたびにチェーンコードを修正するの? △△はアプリとチェーンコードどちらに持たせればいい?
どこまで考慮すべきかの線引きが難しく、初期検討に時間がかかる
- 9. 原因
◼ クーポン/スタンプに対する認識の相違
◼ 我々:資産価値のあるもの、事前に購入/交換などで入手
•クーポンの発行 ⇒ 来店前に事前に実施しておくもの
•クーポンの使用 ⇒ 来店時に実施するもの
◼ 現場:資産価値のないもの、新聞広告のように事前に配布
•クーポンの発行 ⇒ イベント前にバッチ処理で実施→来店時に実施するもの
•クーポンの使用 ⇒ 来店時に実施
◼ 真相:クーポンは事前に全員に全種発行しておきたかったが、
バッチ処理時間が膨大になることから、使用シーケンスに含めるしかなかった
◼ 同様の相違は他のシーケンスにも発生
◼ 例)スタンプコンプリート時のシーン(押印・回収・交換をまとめたい、など)
8 Copyright 2019 FUJITSU LIMITED
汎用性/一般性を考慮するあまり、トランザクションの単位
(チェーンコードでメソッド化する単位)がプリミティブになりすぎていた
- 10. 対策①:バルク実行機能の追加(概要)
◼ 基本的な発想
◼ メソッド間での機能重複を避けるため、各メソッドの機能拡張は避ける
◼ 1度のコールで複数のチェーンコードメソッドをまとめて実行できるメソッドを追加
◼ 使用イメージ(例:クーポンの連続発行)
◼ Before
•先行トランザクション
•メソッド名:createCoupon
•引数:userA,c001
•後続トランザクション
•メソッド名:createCoupon
•引数:userB,c002
◼ After
•メソッド名:bulkExec
•引数:createCoupon、[userA,c001]、createCoupon、[userB,c002]、…
9 Copyright 2019 FUJITSU LIMITED
- 12. 対策②:アプリ側で吸収
◼ 基本的な考え方
◼ 処理をまとめる発想を捨て、違和感の無い箇所に分散させる
◼ 違和感を消すために、同期実行と非同期実行を使い分ける
◼ 2種類の実行方式(俗称)
◼ 同期実行方式:Ordererへの永続化依頼後、Peerへのコミットを待ち合わせる
◼ 非同期実行方式:Ordererへの永続化依頼後、待たずに即時復帰する
◼ 実際の工夫例
◼ エンドユーザがトランザクション実行しない可能性の高い時間を利用
11 Copyright 2019 FUJITSU LIMITED
クーポン一覧画面
を参照する
気になったクーポンの
詳細を表示する。
実際の店舗で
クーポンを使用する。
Blockchainネットワーク
非同期実行でクーポン発行 同期実行でクーポンを使用
この間に
コミットを期待
- 15. 遅いPeerとは何か?
◼ 当時の実装
◼ 起こっていたこと
14 Copyright 2019 FUJITSU LIMITED
ELB
Peer_2
Peer_1
REST_1
REST_2
①転送(R1)
②Tx実行(R1)
➆転送(R2)
Ordering
Service③永続化依頼(R1)
リクエスト1(R1)
リクエスト2(R2)
⑤ブロック取得/
コミット(R1)
➄ブロック取得/
コミット(R1)
④コミット完了待ち(R1) / ⑥コミット通知
⑧Tx実行(R2)
ELB
Peer_2
Peer_1
REST_1
REST_2
①転送(R1)
②Tx実行(R1)
⑥転送(R2)
Ordering
Service③永続化依頼(R1)
リクエスト1(R1)
リクエスト2(R2)
⑤ブロック取得/
コミット(R1)
⑧ブロック取得/
コミット(R1)
④コミット完了待ち(R1) / ⑥コミット通知
➆Tx実行(R2)
遅延
コミットと順番が前後
データが古いため失敗
- 17. 対策①:遅いPeerを待ってあげる
◼ 変更内容
◼ メリット
◼ 問題事象を完全に解決できる
◼ デメリット
◼ 遅いPeerに引きずられてリクエスト毎の応答性能が低下する
16 Copyright 2019 FUJITSU LIMITED
ELB
Peer_2
Peer_1
REST_1
REST_2
①転送(R1)
②Tx実行(R1)
➆転送(R2)
Ordering
Service③永続化依頼(R1)
リクエスト1(R1)
リクエスト2(R2)
⑤ブロック取得/
コミット(R1)
➄ブロック取得/
コミット(R1)
④コミット完了待ち(R1) / ⑥コミット通知
⑧Tx実行(R2)
④コミット完了待ち(R1) / ⑥コミット通知
- 18. 対策②:ラウンドロビンをやめる
◼ 使用するPeerを1つに固定する(ダウン時は別Peerに切り替え)
◼ メリット
◼ 早いPeerに固定できれば性能面で優位
◼ デメリット
◼ Peerの切り替え時に問題事象が発生する可能性がある
17 Copyright 2019 FUJITSU LIMITED
ELB
Peer_2
Peer_1
REST_1
REST_2
①転送(R1)
②Tx実行(R1)
➆転送(R2)
Ordering
Service
③永続化依頼(R1)
リクエスト1(R1)
リクエスト2(R2)
⑤ブロック取得/
コミット(R1)
➄ブロック取得/
コミット(R1)
④コミット完了待ち(R1) / ⑥コミット通知
⑧Tx実行(R2)
➈コミット完了待ち(R1)
- 19. (参考)公式クライアントラッパーの実装状況
◼ CLI(peer chaincode invoke)
◼ --waitForEvent オプションの有無で制御
•指定あり:認識しているPeerの全てを待つ
•指定なし:一切待たない
◼ SDK(fabric-network)
◼ 接続時に指定するDefaultEventHandlerStrategiesの値で制御
•MSPID_SCOPE_ALLFORTX:自組織内の認識しているPeerの全てを待つ
•MSPID_SCOPE_ANYFORTX:自組織内の認識しているPeerのうち1台を待つ
•NETWORK_SCOPE_ALLFORTX:チャネル内の認識しているPeerの全てを待つ
•NETWORK_SCOPE_ANYFORTX:チャネル内の認識しているPeerのうち1台を待つ
◼ 独自のEventHandlerStrategiesを実装して処理を差し替えることは可能
18 Copyright 2019 FUJITSU LIMITED
- 21. 事の経緯
◼ 完成システムの受け入れに向けてお客様に仕様説明/デモを実施
◼ 随時ブロックの中身を参照するようデモシナリオを改善して再実施
20 Copyright 2019 FUJITSU LIMITED
外部仕様は〇〇のようになっております。△△なシナリオを想定したデモをお見せします。
これじゃないんだよね。Blockchainが使われている事を見せてほしい。
今行った操作をブロックで確認します。最新は35番目のブロックですので、この中身をご説明します。
ちょっと待って、何で35番なの? ブロックは1番から始まるんじゃないの?
34番までは前回お見せしたデモによる証跡で、今回のデモには影響しませんので…
既存データがある以上、それが今回のデモに影響している可能性を否定できないのでダメです。
お客様の真意がわからず、やり取りは平行線
- 22. お客様の真意はどこにあるか?(仮説)
◼ 我々の想定
◼ RFP回答に対する実装システムの妥当性を確認して頂く場
⇒ Blockchainは内部仕様であるため説明に時間をかけるべきではない
◼ お客様の反応
◼ Blockchainが使われていることを確認したい ⇒ 我々が信用されていない?
◼ 既存Blockがある状態でのデモはNG ⇒ Blockchainを理解頂けていない?
◼ RFPの内容(再確認)
◼ 実施目的:Blockchainを用いて本モデルが実現できることの確認
21 Copyright 2019 FUJITSU LIMITED
モデルが実現できたか否かの結果だけではなく、
どのようにして実現されたのかを知りたいのでは?
- 23. 対策
◼ 基本的な考え方
◼ 「Blockchain=内部仕様だから理解不要」という発想を捨て、最低限は理解頂く
◼ 全てのデータを包み隠さず説明する(説明できないデータは含めない)
◼ 変更点①:理解が揺れがちな重要用語についてデモ前に解説
◼ トランザクション:RDBのもの(処理をまとめる)と混同されがち
◼ チェーンコード(スマートコントラクト):Webに誇張表現が踊っている
◼ ステート:データの実体はここにある事を理解してもらう
◼ ブロック:ここからデータを読んでいるわけではない事を理解してもらう
◼ 変更点②:高さ1の状態から以後操作毎に現れるブロック全てを解説
◼ Genesisブロック:どのようなコンソーシアムか?
◼ 2番目以降のブロック:どのようなデータを読み込み/書き込みしたか?
22 Copyright 2019 FUJITSU LIMITED
どのようにモデルが実現されたのかを理解頂き、無事に受け入れていただけた
- 24. (参考)Blockの参照に便利なツール
◼ Events client
◼ Hyperledger Fabric公式のサンプルイベントクライアント
◼ 流れてくるBlockを「tail -f」でログを追うかのように捕捉/出力可能
◼ Go言語の開発環境さえあればビルド・実行可能
◼ その他
◼ peer channel fetch / configtxlator proto decode コマンド
•Hyperledger Fabric公式のCLIツール
•1件ずつBlockを取得・デコードを実施するような使い方
•デコードが甘く、Blockの可読性が低い点に注意
◼ Blockchain Explorer
•Hyperledgerプロジェクト謹製のGUIツール
•収集データの蓄積にRDBが必須となるため、セットアップが若干手間
◼ 各社BC PaaS謹製のGUIツール
23 Copyright 2019 FUJITSU LIMITED