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.

ブロックチェーンの可能性と課題 - SIerとしての視点から

7,178 views

Published on

NTTデータ 稲葉高洋様 山下真一様
第1回Hyperledger Tokyo Meetup 2017年3月16日講演

Published in: Technology
  • Be the first to comment

ブロックチェーンの可能性と課題 - SIerとしての視点から

  1. 1. © 2017 NTT DATA Corporation ブロックチェーンの可能性と課題 - SIerとしての視点から - 2017年3月16日 株式会社NTTデータ 稲葉 高洋、山下 真一
  2. 2. 2© 2017 NTT DATA Corporation アジェンダ 1. ブロックチェーンシステム開発の10の論点 2. ブロックチェーンシステム運用の勘所
  3. 3. © 2017 NTT DATA Corporation 3 1. ブロックチェーンシステム開発の10の論点
  4. 4. © 2017 NTT DATA Corporation 4 1. ブロックチェーン製品の選定 2. クラウドかオンプレミスか 3. コストは安くなるか 4. 誰がノードを所有するのか 5. 環境の構築 6. 設計をいかに進めるか 7. データをどのように持つか 8. 製造・試験 9. セキュリティ 10.ネットワークの遅延 ブロックチェーンシステム開発の10の論点
  5. 5. © 2017 NTT DATA Corporation 5 • ブロックチェーン基盤はビジネスモデルに大きな影響を与えるので、ビ ジネス要件に適切なものを選定する必要がある。 • 製品そのものではなく、開発コミュニティあるいは開発企業の規模、運 営方法、活動の活発さ、ライセンス形態、業界での認知度なども考慮す る。 • 製品が有する機能はAP開発コストに影響する。 • 大まかな技術的観点と該当する製品には以下のようなものがある。 1. ブロックチェーン製品の選定 ビジネス要件 対応する製品 パブリックネットワーク / 自律分散型 Bitcoin Core, Ethereum, Sawtooth Lake コンソーシアム指向 / パーミッション型 Fabric, Enterprise Ethereum? BtoC Iroha 相対取引指向 / 公証 (notary) 型 Corda
  6. 6. © 2017 NTT DATA Corporation 6 1. ブロックチェーン製品の機能 PoW PoW Contract 言語:Solidity、他 chaincode 言語:Go、Java PBFT / SBFT PoS Membership services Bitcoin Ethereum Hyperledger Fabric パブリック型 コンソーシアム型 コンセンサスアルゴリズム 偽造防止・暗号化 スマートコントラクト P2Pネットワーク メンバー管理 拡張機能 メンバー管理・認証 周辺機能 運用 監視 ・・・・ 安全対策 Public-key crypto Crypto Hash Public-key crypto Crypto Hash Public-key crypto Crypto Hash Discovery Management Message Format Discovery Management Message Format Discovery Management gRPC, Protocol Buffers ・・・・ 補完していく領域 ブロックチェーン特 有
  7. 7. © 2017 NTT DATA Corporation 7 1. ブロックチェーン製品の機能 パブリック コンソーシアム プライベート ノード型 制限なし 制限可能 制限可能 ブロックチェーン 閲覧 制限なし 制限可能 制限可能 ブロック生成時の高 難易度な仕組み 必須 任意 任意 マイニング報酬 必要 任意 任意 ビットコインは パブリック型 エンタープライズ利用は コンソーシアム型が有力視
  8. 8. © 2017 NTT DATA Corporation 8 • 「ブロックチェーンはクラウドでないとダメなのか」ということはない。 • 一般的なシステムと同様、要件に合わせて選定する。 • 価格、納期 • インフラに要求される柔軟性の程度 • 他のシステムとの連携や組織でのインフラストラクチャポリシー • セキュリティ • データセンタの場所など • ブロックチェーンならではがあるとすると、複数の主体による分散配置 した構成要素が強調動作するための広域ネットワークへの影響がある。 (後述) • 素のサーバに1からブロックチェーン基盤を構築するか、ある程度構築さ れたBaaS的なサービスを利用するか検討する。 • 今後はSaaS的なサービスが増えていくと思われる。その場合、あまりブ ロックチェーンを意識しなくなるだろう。 2. クラウドかオンプレミスか
  9. 9. © 2017 NTT DATA Corporation 9 • 「ブロックチェーンを使えばコストが安くなるんでしょ」 • コストの観点でブロックチェーンが直接影響するのはシステムの一部に 過ぎないので、全体としてみればブロックチェーンによる影響は大きく ないこともある。 • JPXのワーキングペーパー*1によると、ハードウェア、ソフトウェア (パッ ケージ)、保守はコスト削減の可能性があるとしているが、アプリケーショ ンについては差異なしと結論付けている。 • ガートナーの記事*2ではブロックチェーンにかかわる部分はシステム開発全 体の5%未満といわれている。 • ブロックチェーンあるいは分散台帳技術はまだまだ発展途上の技術なの で、POCや各種コンソーシアム活動など成熟した技術と比べると、逆に コストがかかる可能性がある。技術の進歩に追従するためのマイグレー ションにも注意を払う必要がある。 • コスト以外の分散台帳のメリットに注目してプロジェクトを進めるべき である。対改竄性や一貫した台帳情報の共有など。 3. コストは安くなるか *1 JPXワーキング・ペーパー「金融市場インフラに対する分散型台帳技術の適用可能性について」 http://www.jpx.co.jp/corporate/research-study/working-paper/tvdivq0000008q5y-att/JPX_working_paper_No15.pdf *2 Top 10 Mistakes in Enterprise Blockchain Projects http://www.gartner.com/smarterwithgartner/top-10-mistakes-in-enterprise-blockchain-projects/
  10. 10. © 2017 NTT DATA Corporation 10 • 「参加者全員がノードを持つ必要があるのか」というとそうとは限らな い。 • ノードを持つことの利益、あるいは持たないことによる不利益を考慮す る。 • 利益 • 他社に先んじて競争力のあるサービスを提供する • システムの安定的な稼動に寄与する • システムの運用のコストを分担しつつ、相応の影響力を保持する • 自分の好きな場所にデータを置ける • 不利益 • システム上でのサービス提供に影響があるかもしれない • システムの運用がノードを持つ主体の動向に左右される • データの置き場所をコントロールできない • システムによるメリットが大きい主体がノードを持ち、そうでもない主 体は共同で所有する、あるいはサービスだけ利用するということもでき る。 4. 誰がノードを所有するのか
  11. 11. © 2017 NTT DATA Corporation 11 4. 誰がノードを所有するのか A B C D A B C D 均等に所有 E F G 部分的な組合 A BC D 1主体が所有 A 組合が所有 B C D E F G
  12. 12. © 2017 NTT DATA Corporation 12 • Fabricは以前はVagrantを使って構築するようになっていたが、これは結 構ハードルが高かった。 • Vagrantに馴染んだ人、馴染める人は必ずしも多くない。これを理由とした 問い合わせが多かった。できたものの提供も容易ではなかった。 • プロキシ環境対応がドキュメントに少し書いてあるが、絶望的に動かなかっ た。 • Dockerイメージによる配布により、構築が劇的に簡単になった。ただし、 少し凝ったことをするにはDockerの知識が必要になる。 • 将来的にはオフラインインストーラやパッケージ管理システムを通じた 配布も行われるだろう。 • 評価やPOCの実施に当たってはインフラチームの協力や関与を推奨した い。まだまだ導入や環境構築には専門的な知識が必要となる。 • CelloはFabricの環境の運用に有用と考えている。 • Hyperledger Blockchain Explorerは便利だが、もっとよくなる。 EthereumのEthereum Network Stats*1 (eth-netstats)はよくできてい ると思う。 5. 環境の構築 *1 Ethereum Network Stats https://github.com/cubedro/eth-netstats
  13. 13. © 2017 NTT DATA Corporation 13 Ethereum Network Stats (eth-netstats) *1 Ethereum Network Stats https://github.com/cubedro/eth-netstats
  14. 14. © 2017 NTT DATA Corporation 14 • 企画については既存の技術とかなり大きく異なるが、設計についてはそ れほど大きな違いはないとの認識。 • RDMBSとNoSQLはそれぞれ違った知見が必要になるが、既存の技術でもそ の程度の違いは普通にある。 • 大枠では既存の開発標準やノウハウを流用可能。 • 未成熟で変化の激しい技術とどう付き合うかが重要になるので、長大な ウォーターフォールプロセスはリスクが高い。 • ブロックチェーンだけでシステムが完結するわけではないので、既存の 技術とどう組み合わせて責務を分担するかが重要。 • ブロックチェーンは単なるデータベースではないが、ユーザインタラク ションを担わせるのには向かないので、フロントエンドを担う構成要素 が必要となる。 • 巨大なチェーンコードを開発することはできるが、適切なサイズでの分 割を考慮する必要がある。 • 分散環境でプログラム (チェーンコード/スマートコントラクト) を実行 するので、非決定論的挙動を作りこまないようにするのが重要。Fabric 1.0で改善される (はず) だが、根本的には解決できない。 6. 設計をいかに進めるか
  15. 15. © 2017 NTT DATA Corporation 15 • ブロックチェーンは単なるデータベースではない。 • しかし、データベースとしての一面も持つ。 • ブロックチェーンはファイルサーバやオブジェクトストレージではない。 少なくとも現状は。 • 大量のデータを格納する必要がある場合は、リンクやハッシュをブロック チェーンに格納するというのは現時点では無理がない。 • Fabricのワールドステートは非常に単純なKey-Valueストアなので、複雑 な検索には向かない。 • 自前でインデックスのようなものを作る。 • テーブルの機能を使うと多少やりやすい。 • 1.0の機能強化に期待。 • 最初は個別の取引データだけを扱うのがやりやすいかもしれない。 7. データをどのように持つか 取引データの集積 集約データの格納 (残高/口座など) “スマートコントラクト”
  16. 16. © 2017 NTT DATA Corporation 16 • Fabricではチェーンコードの開発にJavaが導入されて圧倒的に扱いやす くなった。 • Javaの経験者は非常に多い。 • Eclipseなどの歴史あるIDEとそのプラグインが使えるのはとても便利。 • テスティングフレームワークやモックフレームワークもそろっている。 • shimに関係する部分のテストツールがあると便利だろう。 • Fabric Composerは現場にすんなり導入できるだろうか。 • EthereumのSolidityは言語仕様に制限が多く、開発ツールも貧弱で開発 が非常に困難。 (SolidityそのものというかEVMに由来する) 8. 製造・試験
  17. 17. © 2017 NTT DATA Corporation 17 • 「ブロックチェーンの何がセキュアなのか」 • 改竄耐性が特徴となる。暗号、ブロックチェーン/ハッシュチェーン、 P2Pネットワーク、コンセンサスアルゴリズムによって成立する。 • ブロックチェーンならばセキュリティの心配がないということはない。 一般的なセキュリティ対策は必要。 • EhtereumのThe DAO AttackやDoS攻撃など 9. セキュリティ •アプリケーションレベルの認証 •アクセス制御 (Application ACLなど) •コンテンツの秘匿化 •機能バグやセキュリティバグを作りこまない アプリケーション •信頼できる製品の採用 •パッチの適用 •適切な設定 •ユーザの棚卸し •安全な暗号アルゴリズムやハードウェア機能の利用 ミドルウェア •ホストセキュリティ •ネットワークセキュリティ •物理セキュリティ インフラ
  18. 18. © 2017 NTT DATA Corporation 18 • 複数のpeerが複数回の通信を行って合意形成を行うので、ネットワーク の遅延は性能に大きな影響を与える。 • 処理性能が重視される場合は、各peerをネットワーク的に近い場所に配 置する必要がある。 • ビジネス要件などによって遠隔地に分散配置する場合は、処理性能への 影響を評価する。 10. ネットワークの遅延 AWSリージョン レスポンスタイム (ms) 東京 28 シンガポール 174 カリフォルニア 240 オレゴン 291 シドニー 309 バージニア 370 アイルランド 573 サンパウロ 658 http://www.denet.ad.jp/technology/2014/01/vol9-aws.htmlから引用
  19. 19. © 2017 NTT DATA Corporation 19 10. ネットワークの遅延 delay proc time note 0 22 same machine 90 370 tokyo - singapore 120 496 tokyo - california 150 606 tokyo - oregon / sydney 175 716 tokyo - virginia 285 1,149 tokyo - ireland 300 1,227 330 1,332 tokyo - São Paulo y = 3.9974x + 15.223 R² = 0.9998 0 500 1,000 1,500 0 50 100 150 200 250 300 350 proc time • Hyperledger Fabric 0.6.1 • 4つのvalidating peerを1つのt2.mediumインスタンスに配置 • 空のJavaチェーンコード • tcコマンドにより擬似的に遅延を発生 • sendBatchとexecDoneSyncの時間差を測定 • バッチサイズは1 • それぞれ1回のみ測定した
  20. 20. © 2017 NTT DATA Corporation 20 2. ブロックチェーンシステム運用の勘所
  21. 21. © 2017 NTT DATA Corporation 21 ブロックチェーンを利用していく上で “良くあるこれまでの” システム基盤とは変わってくる 従来のシステム ブロックチェーン RDBMSや ビッグデータ基盤 APサーバ XXサーバ 各種ソフトウェア 中央集権ではない 管理主体が1組織でなくても良い 一部を止めても大丈夫 中央集権・特定の組織で管理 (信頼性対策、HA、セキュリティ、監視など) 新たな 発想が必要
  22. 22. © 2017 NTT DATA Corporation 22 ブロックチェーンを利用していく上で ブロックチェーンをどのように組み合わせるかも大切 サービス チェーンB チェーンA チェーンC 複数のブロックチェーンを 組み合わせたサービス サービス 異なるブロックチェーン 技術を組み合わせた サービス 技術A 技術B サービス ブロックチェーン技術と 外部システムとの連携
  23. 23. © 2017 NTT DATA Corporation 23 ブロックチェーンを利用していく上での課題 例えば、問題が発生した際の対応は… RDBMSや ビッグデータ基盤 拠点 調査 XX組織管理下 調査 情報収集 対応が容易 従来のシステム 調査? DD組織管理下CC組織管理下 AA組織管理下 BB組織管理下 ブロックチェーン 調査 調査? 問題解決までの 対応が複雑?
  24. 24. © 2017 NTT DATA Corporation 24 ブロックチェーンを利用していく上での課題 例えば、メンテナンスで止める場合 DD組織管理下CC組織管理下 AA組織管理下 BB組織管理下 ブロックチェーン RDBMSや ビッグデータ基盤 XX組織管理下 従来のシステム メンテナンス周知 メンテナンス メンテナンスが事前に周知され 決められた時間で実施 メンテナンス メンテナンスメンテナンス 処理できない… サービスを止めないように メンテナンス時間の調整が必要
  25. 25. © 2017 NTT DATA Corporation 25 ログフォーマットの統一化 メトリクスの統一化 様々なブロックチェーン技術を活用し続けるために ブロックチェーン技術を活用していくために 運用監視環境の共通化や 導入ツール整備 10:00:02 node A1 start. 10:00:20 tx commit 10:10:50 node B1 stop. 14:20:30 node C1 start. 14:20:50 node D1 stop. 15:00:20 tx commit 20:30:40 tx commit 20:30:50 node E2 start. 21:30:20 tx comit 接続ノード数: 20 Tx数: 500 接続ノード数: 10 Tx数: 2000 接続ノード数: 3 Tx数: 10
  26. 26. © 2017 NTT DATA Corporation 26 ブロックチェーン技術を活用していくために ブロックチェーンの隣にいるシステムも重要となる 例えば、、、 大量データの 保存・処理 存在証明
  27. 27. © 2017 NTT DATA Corporation 27 ブロックチェーン技術を活用していくために 利用シーンに応じたルールを決めて運用することが重要 ・ 他者・他組織と利用状況を共有する ・ 問題があった際には、他者・他組織に速やかに連絡する ・ 利用するプロダクトのバグは放置せず、 バージョンアップやパッチ適用について、速やかに協議する ・ ハードフォークが必要となる場合の合意形成と移行手順
  28. 28. Copyright © 2011 NTT DATA Corporation Copyright © 2017 NTT DATA Corporation 本資料に掲載の会社名、製品名またはサービス名は、 それぞれ各社の商標または登録商標です。

×