ここがつらいよ、Hyperledger Fabricの商用適用（Blockchain GIG #4発表資料）
Report
Share
•7 likes•4,585 views
![© 2019 NTT DATA Corporation 6
中央集権の問題点
SPOF(Single Point of Failure)の数々
• Ordering Service、Fabric CA、Fabric SDKを冗長化する必要がある
Fabric SDK
Node.js
中央ノード
Fabric CA
Fabric CA
PostgreSQL
Ordering Service
Kafka
Orderer
組織A
Zoo
Keeper
Peer
CouchDB
組織B
Peer
CouchDB
[凡例]
Fabric CA: 証明書発行
Ordering Service: トランザクションの順序制御
Fabric SDK: REST APIの提供
Peer: ブロックの保存、スマートコントラクトの実行
要冗長構成
要冗長構成
要冗長構成](https://image.slidesharecdn.com/hyperledgerfabric-production-release-blockchainig4-nttdata-190913092422/75/hyperledger-fabricblockchain-gig-4-6-2048.jpg?cb=1666782243)
![© 2019 NTT DATA Corporation 17
[宣伝] 9/5(木)テクノロジーカンファレンス開催
NTTデータテクノロジーカンファレンス 2019
• 年に1度、NTTデータの技術部門がまとまって発表を行うカンファレンス
• 場所: 東京コンファレンスセンター・品川 (アレア品川)
• URL: https://oss.nttdata.com/techconf2019/
見どころ
• 基調講演でトヨタ様、Confluent様登場
• Hadoop、Spark、Kafka、PostgreSQLなど
• ブロックチェーンもあります
すでに満席
• 懇親会で声をかけてもらえれば...](https://image.slidesharecdn.com/hyperledgerfabric-production-release-blockchainig4-nttdata-190913092422/75/hyperledger-fabricblockchain-gig-4-17-2048.jpg?cb=1666782243)
ここがつらいよ、Hyperledger Fabricの商用適用（Blockchain GIG #4発表資料）
•7 likes•4,585 views
Report
Share
2019年9月4日開催 Blockchain GIG #4 発表資料 「ここがつらいよ、Hyperledger Fabricの商用適用」 株式会社NTTデータ システム技術本部 安達 仁
More Related Content
What's hot
What's hot(20)
Similar to ここがつらいよ、Hyperledger Fabricの商用適用（Blockchain GIG #4発表資料）
![[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは](https://cdn.slidesharecdn.com/ss_thumbnails/oraclecodetokyo19b-2-2k8soperatorkshigeruv1-190522024836-thumbnail.jpg?width=384&fit=bounds)
Similar to ここがつらいよ、Hyperledger Fabricの商用適用（Blockchain GIG #4発表資料） (20)
![[OracleCodeTokyo2019] Kubernetesで実現する運用自動化の新しいアプローチとは](https://cdn.slidesharecdn.com/ss_thumbnails/oraclecodetokyo19b-2-2k8soperatorkshigeruv1-190522024836-thumbnail.jpg?width=768&fit=bounds)
More from NTT DATA Technology & Innovation
More from NTT DATA Technology & Innovation(20)
![ChatGPTのデータソースにPostgreSQLを使う[詳細版]（オープンデベロッパーズカンファレンス2023 発表資料）](https://cdn.slidesharecdn.com/ss_thumbnails/postgresqlchatgptodc2023nttdata-230830045114-329af13b-thumbnail.jpg?width=768&fit=bounds)
Recently uploaded
Recently uploaded(7)
ここがつらいよ、Hyperledger Fabricの商用適用（Blockchain GIG #4発表資料）
- 1. © 2019 NTT DATA Corporation 2019/9/4 株式会社NTTデータ システム技術本部 安達 仁 ここがつらいよ、 Hyperledger Fabricの商用適用
- 2. © 2019 NTT DATA Corporation 2 アジェンダ 自己紹介 Hyperledger Fabric商用適用の課題と解決策 まとめ
- 3. © 2019 NTT DATA Corporation 3 安達 仁 (あだち じん) email: Jin.Adachi@nttdata.com 所属 NTTデータ システム技術本部 デジタルテクノロジ推進室 ブロックチェーン推進チーム ブロックチェーン基盤の検証・評価 PoCの実施、商用展開 グローバル連携 事業部門お客様 活用事例 環境・カタログ ブロックチェーンCoE （20+国、300名規模の体制） ※ 2019年8月末時点 自己紹介 ここ
- 4. © 2019 NTT DATA Corporation 4 Hyperledger Fabric商用適用の課題
- 5. © 2019 NTT DATA Corporation 5 ブロックチェーンの特徴 非中央集権 • すべてのノードが同じ権限を持つ • データベースサーバのような特権的な ノードが不要 改ざん耐性 • 多数のノードによる合意形成を行う • 改ざんを行うにはすべてのノードの 51%以上の処理能力が必要 透明性 • すべてのノードが同じ台帳情報を持つ • 合意した正当なデータだけを持つ ゼロダウンタイム • 広範囲にノードを分散することでディザ スタリカバリの特性を持つ メリット 低スケーラビリティ • すべてのノードで同じデータを持ち、同じ処 理を行う • ノード数を増やしても性能は向上しない 取引確定までの時間 • 台帳に記録した情報を確定したと見なす までに時間が掛かる • 確率的にしか取引が確定しない デプロイしたアプリを取り消せない • デプロイしたアプリのバグや脆弱性が致命 的な問題につながる 取引の透明性 • 見せたくない情報であっても、台帳情報が 共有されてしまう デメリット
- 6. © 2019 NTT DATA Corporation 6 中央集権の問題点 SPOF(Single Point of Failure)の数々 • Ordering Service、Fabric CA、Fabric SDKを冗長化する必要がある Fabric SDK Node.js 中央ノード Fabric CA Fabric CA PostgreSQL Ordering Service Kafka Orderer 組織A Zoo Keeper Peer CouchDB 組織B Peer CouchDB [凡例] Fabric CA: 証明書発行 Ordering Service: トランザクションの順序制御 Fabric SDK: REST APIの提供 Peer: ブロックの保存、スマートコントラクトの実行 要冗長構成 要冗長構成 要冗長構成
- 7. © 2019 NTT DATA Corporation 7 Ordering ServiceのHAを考える Ordererを複数並べる • ただし、フェイルオーバーや負荷分散は行われない • Connection Profile(network-config.yaml)に複数台のOrdererを設 定しても、1台目のOrdererにしか行かない バックエンドのKafka、ZooKeeperは障害耐性あり Ordering Service Fabric SDK Kafkaクラスタ Orderer Kafka Kafka Kafka Kafka Orderer Orderer ZooKeeperアンサンブル ZK ZK ZK
- 8. © 2019 NTT DATA Corporation 8 Fabric CAのHAを考える Fabric CAを複数並べる バックエンドのDBのHAが必要 • PostgreSQLの場合は、PG-REXで冗長化 Active Fabric CA Fabric SDK PostgreSQL (Act) Pacemakerで プロセス監視 Standby Fabric CA PostgreSQL (Stb) 同期レプリケーション LB フェイルオーバー
- 9. © 2019 NTT DATA Corporation 9 つらい... ブロックチェーンはゼロダウンタイムと言ったな、あれは嘘だ • コンソーシアム型ブロックチェーンはSPOFがありがち • バックエンドのミドルウェアにも注意が必要 ブロックチェーンは非中央集権と言ったな、あれは嘘だ • 管理者が中央ノードを落ちないように管理する • Ordererが止まればすべてが止まる • Raft Ordererに期待？ 運用/監視の機構 • ようやくメトリクスが取れるようになった (v1.4～) 商用適用に必要なもの 「高可用性」「運用/監視」「セキュリティ」
- 10. © 2019 NTT DATA Corporation 10 Hyperledger Fabric商用適用の解決策
- 11. © 2019 NTT DATA Corporation 11 Blockchain on Kubernetes ブロックチェーン基盤をKubernetes上に整備する ブロックチェーン基盤 • 複数のブロックチェーンプロダクトをサポート(Fabric、Ethereum、Quorum) ロギング・監視基盤 • EFK(Elasticsearch、Fluentd、Kibana)を採用 • ログはfluentd、メトリクスはMetricbeatで取得 Kubernetes基盤 監視基盤ブロックチェーン基盤 #1 EFK Pod Elasticsearch Kibana Kubernetes Master Kubernetes Master Kubernetes Master Kubernetes Worker Kubernetes Worker Kubernetes Worker … fluentd fluentd fluentd Hyperledger Fabric ブロックチェーン基盤 #2 Ethereum Orderer CA Peer Geth… Geth Geth … Metricbeat Metricbeat Metricbeat
- 12. © 2019 NTT DATA Corporation 12 Fabric on Kubernetes Fabric on Kubernetes • コンポーネントごとのHA構成は不要 • 自動的に"Pod"を再起動する • "Service"でネットワーク障害、負荷分散に対応する ストレージはGlusterFSを採用 • Ceph or GlusterFS • 消去法で選択... Kubernetes基盤 ブロックチェーン基盤 Kubernetes Service Kubernetes Serviceアプリ Orderer Pod #2 Orderer Pod #1 Fabric SDK Pod #1 Orderer Pod #2再起動 再起動
- 13. © 2019 NTT DATA Corporation 13 Ordering ServiceのHA OrdererのHA • レプリカ = 3で構成 • 同一のOrdererを複製しているため鍵は1つ • "1台目にしか行かない問題"を回避可能 Kafka、ZooKeeperはレプリカを使えない • broker.idやmyidを持つため。Kubernetesのメリットは少なめ Ordering Service Kafkaクラスタ Kafka pod ZooKeeper pod ZooKeeper pod ZooKeeper Pod Kafka pod Kafka pod Kafka Pod Orderer pod Orderer pod Kubernetes基盤 Orderer Pod ReplicaSet: 3 アプリ Service Service Service Service Service Service Service Service ReplicaSet: 1 x4 ReplicaSet: 1 x3
- 14. © 2019 NTT DATA Corporation 14 Fabric CAのHA Fabric CAのHA • Orgごとにレプリカ = 2で構成 • 多重故障を考慮する場合はレプリカ数を増やす PostgreSQLは共有ディスク方式 • ストレージの可用性はGlusterFS x3で担保 Org2 CA Pod CA Pod Kubernetes基盤 ReplicaSet: 2 アプリ Org1 CA Pod PostgreSQL ServiceService Service CA Pod ReplicaSet: 2 PostgreSQL Service GlusterFSクラスタ PV/PVCPV/PVC Org1 PG_DATA Org2 PG_DATA ReplicaSet: 1 ReplicaSet: 1
- 15. © 2019 NTT DATA Corporation 15 まとめ
- 16. © 2019 NTT DATA Corporation 16 まとめ Fabricの商用適用には課題がある • 中央ノードはガッチリ守る • 監視は既存のノウハウで 可用性の確保にはKubernetesが有効 • 個別にHAを組むのはつらい • コンテナ前提で管理する とは言え、ブロックチェーン基盤だけでは何もできない • 商用案件あってこそ 一緒に商用システムを構築しましょう！
- 17. © 2019 NTT DATA Corporation 17 [宣伝] 9/5(木)テクノロジーカンファレンス開催 NTTデータテクノロジーカンファレンス 2019 • 年に1度、NTTデータの技術部門がまとまって発表を行うカンファレンス • 場所: 東京コンファレンスセンター・品川 (アレア品川) • URL: https://oss.nttdata.com/techconf2019/ 見どころ • 基調講演でトヨタ様、Confluent様登場 • Hadoop、Spark、Kafka、PostgreSQLなど • ブロックチェーンもあります すでに満席 • 懇親会で声をかけてもらえれば...
- 18. © 2019 NTT DATA Corporation
Editor's Notes
- 事業会社（日本・海外）
- [メリット] 他のノードに先を越されず改ざんを行うには、51%以上の計算能力が必要。 DBサーバが落ちたら他が正常でも何もできない。これが中央集権。 [デメリット] ブロックは同時に作成されることがあるので、いくつかブロックがつながってはじめて確定、とする必要がある。 いくつかブロックがつながればOKというのも、確率的にこれくらいつながればひっくり返ることはないだろう、というだけの話。
- 中央ノードと言ってよいか微妙ですが、REST APIを受け付けるFabric SDKも冗長化する必要があります。 今回はOrdering Service、Fabric CAを取り上げたいと思います。
- sendTransactionは引数に複数台のOrdererを渡しても、1台目のOrdererにしか行かない
- ボンディングも必要。 Node.jsのHAも必要。
- メトリクスはFabric 1.4からメトリクスが出力されるようになった あと、セキュリティ。 Kubernetesで実現しようと考えた。
- PrometheusとGrafanaが人気だと思うが、ロギング部分が無い。 一通りできるのは他にDataDogがある。 ただより純粋なOSSに近いのはよいと思う。 Prometheusフォーマットのメトリクスは独自に変換。
- AWSでよければRDSやEFSを使うのもありだと思う。 ただ、EFSは性能が悪いので注意が必要。 fioのaggrb(aggregate bandwidth 総合帯域幅)の値 - EFS: 1057KB/s - GlusterFS: 10238KB/s ストレージ仮想化はRook/EdgeFSは試してみたい。 Cephは以前の経験で負荷をかけ続けると応答がなくなる問題があった。
- OrderingServiceの詳細について説明します。 OrdererのPodはレプリカ2に設定します。多重故障を考慮する場合は容易にレプリカ数を増やすことが可能です。 KafkaクラスタもKubernetes上で動かします。Kafkaは4台、ZooKeeperは3台で構成します。 broker.idやmyidを持つため、ReplicaSetは使えない。 Kafka on Kubernetesはまだノウハウが溜まっていないため、より多くの調査が必要になる可能性があります。 KafkaやZooKeeperは、ノードのID(broker.idやmyid)を持つため、ReplicaSetで冗長化することが難しいと考えています。 つまり、KafkaやZooKeeperがクラッシュした場合は、手動でノードの追加が必要になります。
- Fabric CAの詳細について説明します。 CAの構成はOrdering Serviceに近いです。 CAのPodはレプリカ2に設定します。多重故障を考慮する場合は容易にレプリカ数を増やすことが可能です。 CAはOrganizationごとに用意します。 バックエンドのPostgreSQLはKubernetesの外に配置します。 DBのようなシビアな永続化を行うコンポーネントをKubernetes上で動かすのが難しいためです。 RDSのようなサービスやHAクラスタソフトで冗長化する必要があります。
- 基盤だけあっても仕方ない。商用案件あっての安定した基盤。 BaaSは？ - 個人の感想ですが、まだまだ未完成 - 「停止」ができない、エクスポートができない、など
- AWSでよければRDSやEFSを使うのもありだと思う。 ただ、EFSは性能が悪いので注意が必要。 fioのaggrb(aggregate bandwidth 総合帯域幅)の値 - EFS: 1057KB/s - GlusterFS: 10238KB/s ストレージ仮想化はRook/EdgeFSは試してみたい。