20191010 Blockchain GIG #5 石原様資料

Copyright 2019 FUJITSU LIMITED
ブロックチェーンPoCにおける
開発リードタイム短縮のポイント
2019/10/10
石原俊 (ishihara.shun@fujitsu.com)
0
Blockchain GIG #5 登壇資料

Copyright 2019 FUJITSU LIMITED
◼ 所属：富士通(株) ソフトウェア事業本部デジタルウェア開発統括部
◼ 名前：石原俊
◼ ブロックチェーン歴：３年（Hyperledger Fabricが中心）
◼ 生まれ：運用管理/監視ミドルウェアの開発
◼ 育ち：運用監視OSSの活用、クラウドサービス化
◼ 趣味：ラーメン二郎巡り
自己紹介
1

ブロックチェーン案件での立ち位置
◼ ミッション
◼ ブロックチェーン基盤をSEが使いやすい状態に仕立てて提供・運用すること
◼ 実際
◼ 短期開発のため、システム/アプリケーションの開発に密に関わることが多い
◼ 上流工程の設計支援、下流工程の構築支援など”よろづや”的な立ち回りも多い
2 Copyright 2019 FUJITSU LIMITED
サーバ・ストレージ・ネットワーク
ブロックチェーン基盤
（Hyperledger Fabric）
使用性向上機能
システム/アプリケーション
統合・PaaS化
自動運用
(設計・開発支援)
(構築支援)
上位
下位
今日のお話の中心
各業種のSE
はここに専念

SEが躓くHyperledger Fabricの壁（1/2）
◼ クライアントアプリケーション⇒BCの連携I/F
◼ 基本的に専用のSDKを使用（node.js/Java/golang）
◼ トランザクションフロー
②リクエスト
Client Peer1 Peer2 Orderer
①リクエスト
③Endorsement返却
④Endorsement返却
⑤永続化依頼
⑧トランザクション情報伝搬
⑦最新情報問い合わせ
⑥順序生成
⑨トランザクション永続化
(ブロック生成) ⑦最新情報問い合わせ
⑧トランザクション情報伝搬
⑨トランザクション永続化
(ブロック生成)
いくつのPeerにリクエストを送ったらいいの？リクエスト先のPeerがダウンしていたらどう扱うべき？
選択・設計に迷う要素が多く、ハードルが高い

SEが躓くHyperledger Fabricの壁（2/2）
◼ チェーンコード（スマートコントラクト）の開発
◼ ブロックチェーンに管理させたいことをプログラムに落としたもの
◼ データストアとしてStateDB（KVS）を持つアプリケーションのようなもの
◼ 基本的には案件ごとに開発する必要がある
StateDB
Chaincode
メソッド1：口座開設
メソッド2：口座閉鎖
…
Client リクエストデータI/O
どういう単位でメソッドを切り分けたらいいの？
KVSのデータモデル設計はどう考えればいい？
〇〇は変更が多発する性質があるのだが、
そのたびにチェーンコードを修正するの？ △△はアプリとチェーンコードどちらに持たせればいい？
どこまで考慮すべきかの線引きが難しく、初期検討に時間がかかる

SEが躓かないための解決策
◼ 使用性向上のための機能を追加、不要な検討・設計から解放
◼ RESTサーバ
•BCクライアント特有の実装を隠蔽、SEは1コールのHTTPリクエストで連携可能に
◼ ユースケース別チェーンコード
•代表的なユースケース（※）に対してチェーンコードをあらかじめ用意、SEは開発不要に
※地域通貨、クーポン/スタンプ、電力取引など
ブロックチェーン基盤（Hyperledger Fabric）
使用性向上機能
RESTサーバユースケース別チェーンコード
SEは通常の外部システムとの連携感覚でシステム開発できるように！
（ここからがトラブルの連続であった…)
システム/アプリケーション

◼ 開発フェーズでの苦労話
トラブル事例①
不自然な画面遷移
Copyright 2019 FUJITSU LIMITED6

事の経緯
◼ スタンプラリーPoCのアプリ開発フェーズにてSEからの相談が発生
◼ アプリとブロックチェーンとの間で何が起こっていたか？
クーポンの発行方法について悩ましい点があるので相談させて貰えないか？
はい。（REST-APIを1コールするだけで良いはずなのに何が悩ましいのだろう…）
実は、クーポンを発行を行うと画面遷移中に不自然な間が出来てしまうのです。
ユースケース別チェーンコードがこちらの想定した通りに使われていなかった
BC
App クーポン発行
TX 想定
クーポン発行
TX 実際

原因
◼ クーポン/スタンプに対する認識の相違
◼ 我々：資産価値のあるもの、事前に購入/交換などで入手
•クーポンの発行 ⇒ 来店前に事前に実施しておくもの
•クーポンの使用 ⇒ 来店時に実施するもの
◼ 現場：資産価値のないもの、新聞広告のように事前に配布
•クーポンの発行 ⇒ イベント前にバッチ処理で実施→来店時に実施するもの
•クーポンの使用 ⇒ 来店時に実施
◼ 真相：クーポンは事前に全員に全種発行しておきたかったが、
バッチ処理時間が膨大になることから、使用シーケンスに含めるしかなかった
◼ 同様の相違は他のシーケンスにも発生
◼ 例）スタンプコンプリート時のシーン（押印・回収・交換をまとめたい、など）
汎用性/一般性を考慮するあまり、トランザクションの単位
（チェーンコードでメソッド化する単位）がプリミティブになりすぎていた

対策①：バルク実行機能の追加（概要）
◼ 基本的な発想
◼ メソッド間での機能重複を避けるため、各メソッドの機能拡張は避ける
◼ １度のコールで複数のチェーンコードメソッドをまとめて実行できるメソッドを追加
◼ 使用イメージ（例：クーポンの連続発行）
◼ Before
•先行トランザクション
•メソッド名：createCoupon
•引数：userA,c001
•後続トランザクション
•メソッド名：createCoupon
•引数：userB,c002
◼ After
•メソッド名：bulkExec
•引数：createCoupon、[userA,c001]、createCoupon、[userB,c002]、…

対策①：バルク実行機能の追加（注意点）
◼ 一度にバルク実行するメソッド群に依存関係が無い事が前提
◼ 原則：後続メソッドは先行メソッドが書き込んだ値を期待した処理を実行できない
•先行メソッドの書き込んだデータが実際に書き込まれるのはコール終了後となるため、
後続メソッドが読み込もうとしても失敗するため
•実行できない例：ユーザAを作成、ユーザAにクーポン発行
◼ 完全な対策には書き込みのキャッシングなどの工夫が必要
◼ 先行メソッドの書き込みをメモリにキャッシュ、後続メソッドはキャッシュ優先で読む
◼ キャッシュの消し忘れに注意！（非決定論的トランザクションの原因に）
Client
Peer
Orderer
TX:createUser(A)
【RWSet】
Write:[]->UA
Write:[]->UA
TX:createCoupon(A,C1)
Read:UA
【RWSet】
Write:[C1]->UA
Deliver Deliver
Write:[C1]->UAバルクだとこれが失敗

対策②：アプリ側で吸収
◼ 基本的な考え方
◼ 処理をまとめる発想を捨て、違和感の無い箇所に分散させる
◼ 違和感を消すために、同期実行と非同期実行を使い分ける
◼ 2種類の実行方式（俗称）
◼ 同期実行方式：Ordererへの永続化依頼後、Peerへのコミットを待ち合わせる
◼ 非同期実行方式：Ordererへの永続化依頼後、待たずに即時復帰する
◼ 実際の工夫例
◼ エンドユーザがトランザクション実行しない可能性の高い時間を利用
クーポン一覧画面
を参照する
気になったクーポンの
詳細を表示する。
実際の店舗で
クーポンを使用する。
Blockchainネットワーク
非同期実行でクーポン発行同期実行でクーポンを使用
この間に
コミットを期待

◼ システムテストフェーズでの苦労話
トラブル事例②
ごくまれに失敗するトランザクション

事の経緯
◼ PoCアプリ開発の終盤、システムテスト工程でSEよりトラブルの報告
◼ ステージング環境にて再現を試みるも、発生条件の特定に難航
◼ 発生するインスタンスを分析、”遅いPeer”が含まれている事が判明
クーポンの発行をロングランで走らせていると、時々トランザクションが失敗します。
はい、調査します。どのようなエラーが出ますか？（書き込み競合かな・・）
発行したはずのクーポンが存在しないというエラーが出ています。
弊社IaaS
再現用Blockchain
インスタンス①
再現用Blockchain
インスタンス②
再現用Blockchain
インスタンス③
再現用Blockchain
インスタンス④
高頻度で発生低頻度で発生

遅いPeerとは何か？
◼ 当時の実装
◼ 起こっていたこと
ELB
Peer_2
Peer_1
REST_1
REST_2
①転送(R1)
②Tx実行(R1)
➆転送(R2)
Ordering
Service③永続化依頼(R1)
リクエスト1(R1)
⑤ブロック取得/
コミット(R1)
➄ブロック取得/
コミット(R1)
④コミット完了待ち(R1) / ⑥コミット通知
⑧Tx実行(R2)
ELB
Peer_2
Peer_1
REST_1
REST_2
①転送(R1)
②Tx実行(R1)
⑥転送(R2)
Ordering
コミット(R1)
⑧ブロック取得/
コミット(R1)
➆Tx実行(R2)
遅延
コミットと順番が前後
データが古いため失敗

なぜ遅いPeerが発生するのか？（想像）
◼ ノードの配置方法はAnti-Affinityポリシーを使用していた
◼ つまり運が悪い（？）と…
出展： https://doc.cloud.global.fujitsu.com/lib/iaas/jp/cdp/CDP/Anti_Affinity.html
Peer1
Orderer
Peer2
遅いPeerの正体
建屋A
建屋B

対策①：遅いPeerを待ってあげる
◼ 変更内容
◼ メリット
◼ 問題事象を完全に解決できる
◼ デメリット
◼ 遅いPeerに引きずられてリクエスト毎の応答性能が低下する
ELB
Peer_2
Peer_1
REST_1
REST_2
①転送(R1)
②Tx実行(R1)
➆転送(R2)
Ordering
コミット(R1)
コミット(R1)
⑧Tx実行(R2)

対策②：ラウンドロビンをやめる
◼ 使用するPeerを１つに固定する（ダウン時は別Peerに切り替え）
◼ メリット
◼ 早いPeerに固定できれば性能面で優位
◼ デメリット
◼ Peerの切り替え時に問題事象が発生する可能性がある
ELB
Peer_2
Peer_1
REST_1
REST_2
①転送(R1)
②Tx実行(R1)
➆転送(R2)
Ordering
Service
③永続化依頼(R1)
コミット(R1)
コミット(R1)
⑧Tx実行(R2)
➈コミット完了待ち(R1)

（参考）公式クライアントラッパーの実装状況
◼ 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を実装して処理を差し替えることは可能

◼ 受け入れフェーズの苦労話
トラブル事例③
隠蔽し過ぎて理解不能なシステム

事の経緯
◼ 完成システムの受け入れに向けてお客様に仕様説明/デモを実施
◼ 随時ブロックの中身を参照するようデモシナリオを改善して再実施
外部仕様は〇〇のようになっております。△△なシナリオを想定したデモをお見せします。
これじゃないんだよね。Blockchainが使われている事を見せてほしい。
今行った操作をブロックで確認します。最新は35番目のブロックですので、この中身をご説明します。
ちょっと待って、何で35番なの？ブロックは1番から始まるんじゃないの？
34番までは前回お見せしたデモによる証跡で、今回のデモには影響しませんので…
既存データがある以上、それが今回のデモに影響している可能性を否定できないのでダメです。
お客様の真意がわからず、やり取りは平行線

お客様の真意はどこにあるか？（仮説）
◼ 我々の想定
◼ RFP回答に対する実装システムの妥当性を確認して頂く場
⇒ Blockchainは内部仕様であるため説明に時間をかけるべきではない
◼ お客様の反応
◼ Blockchainが使われていることを確認したい ⇒ 我々が信用されていない？
◼ 既存Blockがある状態でのデモはNG ⇒ Blockchainを理解頂けていない？
◼ RFPの内容（再確認）
◼ 実施目的：Blockchainを用いて本モデルが実現できることの確認
モデルが実現できたか否かの結果だけではなく、
どのようにして実現されたのかを知りたいのでは？

対策
◼ 基本的な考え方
◼ 「Blockchain=内部仕様だから理解不要」という発想を捨て、最低限は理解頂く
◼ 全てのデータを包み隠さず説明する（説明できないデータは含めない）
◼ 変更点①：理解が揺れがちな重要用語についてデモ前に解説
◼ トランザクション：RDBのもの（処理をまとめる）と混同されがち
◼ チェーンコード（スマートコントラクト）：Webに誇張表現が踊っている
◼ ステート：データの実体はここにある事を理解してもらう
◼ ブロック：ここからデータを読んでいるわけではない事を理解してもらう
◼ 変更点②：高さ1の状態から以後操作毎に現れるブロック全てを解説
◼ Genesisブロック：どのようなコンソーシアムか？
◼ 2番目以降のブロック：どのようなデータを読み込み/書き込みしたか？
どのようにモデルが実現されたのかを理解頂き、無事に受け入れていただけた

（参考）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ツール

まとめ

開発リードタイム短縮のポイント
◼ チェーンコード
◼ 各関数作成単位はアプリの操作単位と揃える方がよい
•ロールバックの考慮だけでなく、エンドユーザの体感性能にも波及する可能性あり
◼ 変更が入りやすいアプリの要件への追従のため、テストセットの作成は必須
◼ アプリ開発者もチェーンコードについて最低限のリテラシを持った方がよい
•縦割り体制だとアプリ開発者が言い負けてしまい、開発工数が膨れ上がることも…
◼ クライアントアプリケーション
◼ クライアントラッパーの利用は慎重に
•簡単に使用できるI/Fのものは何かを諦めているので、何を諦めたかを把握して使う
◼ 必要な可用性と性能はインフラ設計の段階で明確にしておく
•インフラ設計時に性能設計を怠ったツケは全てクライアント側に回ってくる
◼ 全体を通して
◼ インフラ設計～アプリ開発までを数ラウンド回すつもりでいた方がよい
•要件とのミスマッチは結合するまで分からないことも多い

開発リードタイム短縮も大事ですが…
◼ 構想通りのブロックチェーンシステムが出来たか評価しよう
◼ 構想/RFPに対する最小セットの実装になりがち
◼ 最小セットでの検証終了 ≠ 技術検証完了
•（一方で、スコープを広げた検証のためのコンソーシアム作りは常に難しい・・）
◼ ブロックチェーンの役割を知るためにブロックを見よう
◼ どのプレイヤーが取引の信頼を担保したのかの記録がすべてそこにある
⇒ どのような信頼モデルかを読み解く切り口の1つとして有益
◼ 評価してみると…
オーナー
Blockchain
ネットワーク
Blockchain
ネットワーク
オーナー
実はこうかも…
Blockchain
ネットワーク
オーナー

20191010 Blockchain GIG #5 石原様資料

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 20191010 Blockchain GIG #5 石原様資料

Similaire à 20191010 Blockchain GIG #5 石原様資料 (20)

Plus de オラクルエンジニア通信

Plus de オラクルエンジニア通信 (20)

20191010 Blockchain GIG #5 石原様資料