Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ブロックチェーンPoCにおける開発リードタイム短縮のポイント

145 views

Published on

ブロックチェーンPoCの支援の中で取り組んできた開発リードタイム短縮施策について、Hyperledger Fabricでの事例を題材に成功例/失敗例をご紹介します。

講演者 : 石原 俊 氏 富士通株式会社 ソフトウェア事業本部
2019年12月5日開催 Hyperleger Tokyo Meetup にて講演

Published in: Technology
  • Be the first to comment

  • Be the first to like this

ブロックチェーンPoCにおける開発リードタイム短縮のポイント

  1. 1. Copyright 2019 FUJITSU LIMITED ブロックチェーンPoCにおける 開発リードタイム短縮のポイント 2019/12/05 石原 俊 (ishihara.shun@fujitsu.com) 0 Hyperledger Tokyo Meetup 登壇資料
  2. 2. Copyright 2019 FUJITSU LIMITED  所属:富士通(株) ソフトウェア事業本部 デジタルウェア開発統括部  名前:石原 俊  ブロックチェーン歴:3年(Hyperledger Fabricが中心)  生まれ:運用管理/監視ミドルウェアの開発  育ち:運用監視OSSの活用、クラウドサービス化  趣味:ラーメン二郎巡り 自己紹介 1
  3. 3. ブロックチェーン案件での立ち位置  ミッション  ブロックチェーン基盤をSEが使いやすい状態に仕立てて提供・運用すること  実際  短期開発のため、システム/アプリケーションの開発に密に関わることが多い  上流工程の設計支援、下流工程の構築支援など”よろづや”的な立ち回りも多い 2 Copyright 2019 FUJITSU LIMITED サーバ・ストレージ・ネットワーク ブロックチェーン基盤 (Hyperledger Fabric) 使用性向上機能 システム/アプリケーション 統合・PaaS化 自動運用 (設計・開発支援) (構築支援) 上位 下位 今日のお話の中心 各業種のSE はここに専念
  4. 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. 5. SEが躓くHyperledger Fabricの壁(2/2)  チェーンコード(スマートコントラクト)の開発  ブロックチェーンに管理させたいことをプログラムに落としたもの  データストアとしてStateDB(KVS)を持つアプリケーションのようなもの  基本的には案件ごとに開発する必要がある 4 Copyright 2019 FUJITSU LIMITED StateDB Chaincode メソッド1:口座開設 メソッド2:口座閉鎖 … Client リクエスト データI/O どういう単位でメソッドを切り分けたらいいの? KVSのデータモデル設計はどう考えればいい? 〇〇は変更が多発する性質があるのだが、 そのたびにチェーンコードを修正するの? △△はアプリとチェーンコードどちらに持たせればいい? どこまで考慮すべきかの線引きが難しく、初期検討に時間がかかる
  6. 6. SEが躓かないための解決策  使用性向上のための機能を追加、不要な検討・設計から解放  RESTサーバ •BCクライアント特有の実装を隠蔽、SEは1コールのHTTPリクエストで連携可能に  ユースケース別チェーンコード •代表的なユースケース(※)に対してチェーンコードをあらかじめ用意、SEは開発不要に ※地域通貨、クーポン/スタンプ、電力取引など 5 Copyright 2019 FUJITSU LIMITED ブロックチェーン基盤(Hyperledger Fabric) 使用性向上機能 RESTサーバ ユースケース別チェーンコード SEは通常の外部システムとの連携感覚でシステム開発できるように! (ここからがトラブルの連続であった…) システム/アプリケーション
  7. 7.  開発フェーズでの苦労話 トラブル事例① 不自然な画面遷移 Copyright 2019 FUJITSU LIMITED6
  8. 8. 事の経緯  アプリ開発フェーズにてSEからの相談が発生  アプリとブロックチェーンとの間で何が起こっていたか? 7 Copyright 2019 FUJITSU LIMITED クーポンの発行方法について悩ましい点があるので相談させて貰えないか? はい。(REST-APIを1コールするだけで良いはずなのに何が悩ましいのだろう…) 実は、クーポンを発行を行うと画面遷移中に不自然な間が出来てしまうのです。 ユースケース別チェーンコードがこちらの想定した通りに使われていなかった BC App クーポン発行 TX 想定 クーポン発行 TX 実際
  9. 9. 原因  クーポン/スタンプに対する認識の相違  我々:資産価値のあるもの、事前に購入/交換などで入手 •クーポンの発行 ⇒ 来店前に事前に実施しておくもの •クーポンの使用 ⇒ 来店時に実施するもの  現場:資産価値のないもの、新聞広告のように事前に配布 •クーポンの発行 ⇒ イベント前にバッチ処理で実施→来店時に実施するもの •クーポンの使用 ⇒ 来店時に実施  真相:クーポンは事前に全員に全種発行しておきたかったが、 バッチ処理時間が膨大になることから、使用シーケンスに含めるしかなかった  同様の相違は他のシーケンスにも発生  例)スタンプコンプリート時のシーン(押印・回収・交換をまとめたい、など) 8 Copyright 2019 FUJITSU LIMITED 汎用性/一般性を考慮するあまり、トランザクションの単位 (チェーンコードでメソッド化する単位)がプリミティブになりすぎていた
  10. 10. 対策①:バルク実行機能の追加(概要)  基本的な発想  メソッド間での機能重複を避けるため、各メソッドの機能拡張は避ける  1度のコールで複数のチェーンコードメソッドをまとめて実行できるメソッドを追加  使用イメージ(例:クーポンの連続発行)  Before •先行トランザクション •メソッド名:createCoupon •引数:userA,c001 •後続トランザクション •メソッド名:createCoupon •引数:userB,c002  After •メソッド名:bulkExec •引数:createCoupon、[userA,c001]、createCoupon、[userB,c002]、… 9 Copyright 2019 FUJITSU LIMITED
  11. 11. 対策①:バルク実行機能の追加(注意点)  一度にバルク実行するメソッド群に依存関係が無い事が前提  原則:後続メソッドは先行メソッドが書き込んだ値を期待した処理を実行できない •先行メソッドの書き込んだデータが実際に書き込まれるのはコール終了後となるため、 後続メソッドが読み込もうとしても失敗するため •実行できない例:ユーザAを作成、ユーザAにクーポン発行  完全な対策には書き込みのキャッシングなどの工夫が必要  先行メソッドの書き込みをメモリにキャッシュ、後続メソッドはキャッシュ優先で読む  キャッシュの消し忘れに注意!(非決定論的トランザクションの原因に) 10 Copyright 2019 FUJITSU LIMITED 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バルクだとこれが失敗
  12. 12. (参考)非決定論的トランザクションの主原因  他ノードと値の同一性が保証されない値の書き込み  内部でランダム値やタイムスタンプを採取し・書き込んだ場合に発生  リードキャッシュの実装(※Hyperledger Fabric特有)  getStateの代わりにメモリからキャッシュ値を読み込む処理を実装している、かつ、  トランザクション実行ごとにリクエスト対象のノード群が異なる場合に発生 11 Copyright 2019 FUJITSU LIMITED Peer2 Peer1 Client Write:2019-03-22T15:36:17,095634462+0900 Write:2019-03-22T15:36:17,095634431+0900 ノードの実行環境における システム時刻のズレにより、 書き込んだ値の不一致が発生 Peer2 Peer1 Client Peer3 Read:UserA ※UserAをキャッシュ Read:UserA ※UserAをキャッシュ Peer2 Peer1 Client Peer3 Read:なし ※UserAをキャッシュから取得 Read:UserA ※UserAをキャッシュ キャッシュの有無により、 読み込み有無の 不一致が発生
  13. 13. 対策②:アプリ側で吸収  基本的な考え方  処理をまとめる発想を捨て、違和感の無い箇所に分散させる  違和感を消すために、同期実行と非同期実行を使い分ける  2種類の実行方式(俗称)  同期実行方式:Ordererへの永続化依頼後、Peerへのコミットを待ち合わせる  非同期実行方式:Ordererへの永続化依頼後、待たずに即時復帰する  実際の工夫例  エンドユーザがトランザクション実行しない可能性の高い時間を利用 12 Copyright 2019 FUJITSU LIMITED クーポン一覧画面 を参照する 気になったクーポンの 詳細を表示する。 実際の店舗で クーポンを使用する。 Blockchainネットワーク 非同期実行でクーポン発行 同期実行でクーポンを使用 この間に コミットを期待
  14. 14.  システムテストフェーズでの苦労話 トラブル事例② ごくまれに失敗するトランザクション Copyright 2019 FUJITSU LIMITED13
  15. 15. 事の経緯  アプリ開発の終盤、システムテスト工程でSEよりトラブルの報告  ステージング環境にて再現を試みるも、発生条件の特定に難航  発生するインスタンスを分析、”遅いPeer”が含まれている事が判明 14 Copyright 2019 FUJITSU LIMITED クーポンの発行をロングランで走らせていると、時々トランザクションが失敗します。 はい、調査します。どのようなエラーが出ますか?(書き込み競合かな・・) 発行したはずのクーポンが存在しないというエラーが出ています。 弊社IaaS 再現用Blockchain インスタンス① 再現用Blockchain インスタンス② 再現用Blockchain インスタンス③ 再現用Blockchain インスタンス④ 高頻度で発生低頻度で発生
  16. 16. 遅いPeerとは何か?  当時の実装  起こっていたこと 15 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. 17. なぜ遅いPeerが発生するのか?(想像)  ノードの配置方法はAnti-Affinityポリシーを使用していた  つまり運が悪い(?)と… 16 Copyright 2019 FUJITSU LIMITED 出展: https://doc.cloud.global.fujitsu.com/lib/iaas/jp/cdp/CDP/Anti_Affinity.html Peer1 Orderer Peer2 遅いPeerの正体 建屋A 建屋B
  18. 18. 対策①:遅い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. 19. 対策②:ラウンドロビンをやめる  使用するPeerを1つに固定する(ダウン時は別Peerに切り替え)  メリット  早いPeerに固定できれば性能面で優位  デメリット  Peerの切り替え時に問題事象が発生する可能性がある 18 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)
  20. 20. (参考)公式クライアントラッパーの実装状況  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を実装して処理を差し替えることは可能 19 Copyright 2019 FUJITSU LIMITED
  21. 21.  受け入れフェーズの苦労話 トラブル事例③ 隠蔽し過ぎて理解不能なシステム Copyright 2019 FUJITSU LIMITED20
  22. 22. 事の経緯  完成システムの受け入れに向けてお客様に仕様説明/デモを実施  重点:外部仕様の理解(典型的なシナリオベースのデモ)  結果:NG(理由:ブロックチェーンを利用している事が分からない)  随時ブロックの中身を参照するようデモシナリオを改善して再実施  重点:ブロックチェーンが使われている事の証明(前回+α)  結果:NG(理由:ブロックチェーンが初期状態から始まっていない) 21 Copyright 2019 FUJITSU LIMITED お客様の真意がわからず、やり取りは平行線 Block0 Block1 Block2 Block8 Block9 Blockn 環境構築時に発生 リハーサル時に発生 デモ時に発生(説明対象) 顧客提供部分 コマンドA コマンドB クラウド環境 Blockchain ネットワーク APIゲートウェイ インターネット (https) 実演対象 ブラックボックス
  23. 23. お客様の真意はどこにあるか?(仮説)  我々の想定  顧客要求事項に対応した実装システムの妥当性を確認して頂く場 ⇒ Blockchainは内部仕様であるため説明に時間をかけるべきではない  発生した要望  Blockchainが使われていることを確認したい ⇒ 我々が信用されていない?  既存Blockがある状態でのデモはNG ⇒ Blockchainを理解頂けていない?  システム開発の背景(再確認)  実施目的:Blockchainを用いて本モデルが実現できることの確認 22 Copyright 2019 FUJITSU LIMITED モデルが実現できたか否かの結果だけではなく、 どのようにして実現されたのかを知りたいのでは?
  24. 24. 対策  基本的な考え方  「Blockchain=内部仕様だから理解不要」という発想を捨て、最低限は理解頂く  全てのデータを包み隠さず説明する(説明できないデータは含めない)  変更点①:理解が揺れがちな重要用語についてデモ前に解説  トランザクション:RDBのもの(処理をまとめる)と混同されがち  チェーンコード(スマートコントラクト):Webに誇張表現が踊っている  ステート:データの実体はここにある事を理解してもらう  ブロック:ここからデータを読んでいるわけではない事を理解してもらう  変更点②:高さ1の状態から以後操作毎に現れるブロック全てを解説  Genesisブロック:どのようなコンソーシアムか?  2番目以降のブロック:どのようなデータを読み込み/書き込みしたか? 23 Copyright 2019 FUJITSU LIMITED どのようにモデルが実現されたのかを理解頂き、無事に受け入れていただけた
  25. 25. (参考)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ツール 24 Copyright 2019 FUJITSU LIMITED
  26. 26. まとめ Copyright 2019 FUJITSU LIMITED25
  27. 27. 開発リードタイム短縮のポイント  チェーンコード  各関数作成単位はアプリの操作単位と揃える方がよい •ロールバックの考慮だけでなく、エンドユーザの体感性能にも波及する可能性あり  変更が入りやすいアプリの要件への追従のため、テストセットの作成は必須  アプリ開発者もチェーンコードについて最低限のリテラシを持った方がよい •縦割り体制だとアプリ開発者が言い負けてしまい、開発工数が膨れ上がることも…  クライアントアプリケーション  クライアントラッパーの利用は慎重に •簡単に使用できるI/Fのものは何かを諦めているので、何を諦めたかを把握して使う  必要な可用性と性能はインフラ設計の段階で明確にしておく •インフラ設計時に性能設計を怠ったツケは全てクライアント側に回ってくる  全体を通して  インフラ設計~アプリ開発までを数ラウンド回すつもりでいた方がよい •要件とのミスマッチは結合するまで分からないことも多い 26 Copyright 2019 FUJITSU LIMITED
  28. 28. 開発リードタイム短縮も大事ですが…  構想通りのブロックチェーンシステムが出来たか評価しよう  構想/RFPに対する最小セットの実装になりがち  最小セットでの検証終了 ≠ 技術検証完了 •(一方で、スコープを広げた検証のためのコンソーシアム作りは常に難しい・・)  ブロックチェーンの役割を知るためにブロックを見よう  どのプレイヤーが取引の信頼を担保したのかの記録がすべてそこにある ⇒ どのような信頼モデルかを読み解く切り口の1つとして有益  評価してみると… 27 Copyright 2019 FUJITSU LIMITED オーナー Blockchain ネットワーク Blockchain ネットワーク オーナー 実はこうかも… Blockchain ネットワーク オーナー
  29. 29. No Block, No Life

×