Zenn
🦁

Hyperledger Fabricのドキュメントを読む（本番ネットワークのデプロイ）

2022/05/06に公開
Hyperledger Fabric
idea

https://hyperledger-fabric.readthedocs.io/en/release-2.4/deployment_guide_overview.html#dg-step-one-decide-on-your-network-configuration

※ 以降の文章は、上記ドキュメントの英語を日本語にし自分なりの解釈を加えたものです。

  • このガイドでは、本番環境にFabricネットワークを構築する際の適切なシーケンスやベストプラクティス、デプロイ時に留意する考慮事項について記載する。
  • 単一の個人の観点から、全体的なプロセスとしてのネットワークの構築について記載していることに注意。
  • 多くの場合、本番環境は1人の個人によって設定されるのではなく複数の個人によって設定される。
  • Fabricネットワークをデプロイするプロセスは複雑であり、公開鍵インフラストラクチャと分散システムの管理について理解していることを前提とする。
  • スマートコントラクトやアプリケーション開発者の場合、本番レベルのFabricネットワークをデプロイするこの専門知識は必要ない。
  • しかし、効果的なスマートコントラクトやアプリケーションを開発するためには、ネットワークがどのようにデプロイされているかを知っておく必要がある場合がある。
  • テストするための開発環境が必要な場合は、チュートリアルを参照すること。
  • チュートリアルのテストネットワークは、本番環境を想定したものではないため本番環境では使用してはいけない。

手順:

  1. ネットワーク構成を決定する
  2. リソース用のクラスターを構築する
  3. CAを構築する
  4. CAを使用してIDとMSPを作成する
  5. PeerとOrdererノードをデプロイする
    6. Peerのデプロイ
    7. Ordererのデプロイ

Step1: ネットワーク構成を決定する

  • ブロックチェーンネットワークの構造はユースケースにより異なる。
  • ここではいくつかのシナリオについて検討していく。
  • 本番環境では、セキュリティ・リソース管理・高可用性が求められる。
    • 高可用性を満たすために必要なノード数は？
    • ディザスタリカバリとデータの格納場所のニーズを満たすデータセンターはどこか？
    • 秘密鍵やルートの安全を保つためにはどうすればよいか？
  • 上記に加え、以下に考慮事項のサンプルを示す。
    • 認証局の構成。
      • Peer（数、チャンネルの数）やOrderer（ノード数、所有者）について決定しなければならない全体的な決定の一部として、組織のCAがどのようにデプロイされるかを決定する必要がある。
      • 本番ネットワークではTLSを使用する必要がある。そのためにはTLS CAを設定し、TLS証明書を生成する必要がある。
      • これについては Step3 で詳しく説明する。
    • 組織単位を使用するか否か。
      • 一部の組織では特定のIDと単一のCAによって作成されたMSPを分離するために組織単位を確立する必要がある場合がある（例えば、製造業者は出荷部門用に1つの組織単位を、品質管理部門用に別の組織単位を必要とする場合がある）。
      • 「Node OU」の概念とは別のものであることに注意。
    • データベースタイプ。
      • ネットワーク内の一部のチャネルでは状態DBとしてのCouchDBが理解できる方法ですべてのデータをモデル化する必要がある場合があるが、速度を優先する他のネットワークではすべてのPeerがLevelDBを使用することを決定する場合がある。
      • CouchDBはキーと値にいくつかのデータ制限があるため、チャネルにはCouchDBとLevelDBの両方を使用するPeerを含めるべきではない（LevelDBで使用できるキーと値がCouchDBでは使用できない場合がある）。
    • システムチャネルを作成するかどうか。
      • Ordererノードは「システムチャネル」（アプリケーションチャネルを作成できる）と呼ばれる管理チャネルの構成ブロックでブートストラップしたり、必要に応じて単に起動してアプリケーションに参加させることもできる。
      • 推奨される方法は、構成ブロックなしでブートストラップすることである。
    • チャネルとプライベートデータ。
      • 一部のネットワークでは、チャネルが特定のトランザクションのプライバシーと分離を確保するための手段として最良である場合がある。
      • チャネル数を少なくして、必要に応じてPrivate Dataを使うほうがニーズにあっていると判断する人もいるかもしれない。
    • コンテナオーケストレーション
      • 他のユーザーがこれらのプロセスの一部を組み合わせると決定する一方で、ユーザーが異なれば、コンテナーオーケストレーションについて異なる決定を下し、ピアプロセス、ロギング、CouchDB、gRPC通信、およびチェーンコード用に個別のコンテナーを作成する場合もある。
    • チェーンコードのデプロイ方法
      • 組み込みのビルドと実行のサポート、外部ビルダーとランチャーを使用したカスタマイズされたビルドと実行、または外部サービスとしてチェーンコードを使用してチェーンコードをデプロイする選択肢がある。
    • ファイアウォールの使用
      • 本番環境では、他の組織のコンポーネントにアクセスする必要がある場合があり、ファイアウォールと高度なネットワーク構成を使用する必要がある場合がある。
      • 例えば、Fabric SDKを使用するアプリケーションではすべての組織のすべての承認PeerへのアクセスとすべてのOrdererへのアクセスが必要になる。
      • 同様にPeerは新しいブロックを受信しているチャネルのOrdererにアクセスする必要がある。
  • さらに、ネットワークを効率的に運用するために管理システム（Kubernetesなど）に関する専門知識が必要になる。
  • 同様に、ネットワークの構造がユースケースや業界の法規制に合致するように設計する必要がある。

Step2: リソース用のクラスターを構築する

  • 一般的には、Fabricはデプロイや管理の方法に依存しない。
  • 例えば、ラップトップにPeerをデプロイして管理することもできる。
  • 上記はいくつかの理由から非推奨ではあるが、Fabricにはそれを禁止するものはない。
  • ローカル環境（あるいはファイアウォールの背後）やクラウド環境にコンテナをデプロイできる限り、コンポーネントを立ち上げて相互に接続できるはずである。
  • しかし、KubernetesはFabricネットワークをデプロイ・管理するための便利なツールを多数備えている。
  • このステップでは、範囲をバイナリに限定し、DockerデプロイまたはKubernetesを使うときに適用できる手順を紹介する。
  • ただし、コンポーネントをデプロイする場合は十分なリソースがあることを確認する必要がある（必要なサイズはユースケースによって大きく異なる）。
  • 例えば、単一のPeerを複数の大容量チャネルに参加させる場合は、単一のチャネルのみに参加する場合よりもはるかに多くのCPUとメモリが必要になる。
  • 大まかな目安としては、1つのOrdererに割り当てる予定の約3倍のリソースをPeerに割り当てるように計画する（後述するように、Ordererは少なくとも3つ、最適には5つのノードを配置することが推奨されている）。
  • 同様に、CAに必要なリソースは、Peerに必要なリソースの約10分の1である。
  • また、クラウドプロバイダーでストレージを設定しないと、PersistentVolumesおよびPersistentVolumeClaimを設定できないため、クラスターにストレージを追加する必要がある。
  • 永続ストレージを使用すると、MSP、台帳、インストールされたチェーンコードなどのデータがコンテナファイルシステムに保存されなくなり、コンテナが破壊された場合にそれらが破壊されるのを防ぐことができる。
  • 実証用の環境を用意し、負荷がかかった状態でテストを行うことで、必要なリソースをより深く理解できるようになる。

インフラの管理の考慮事項

シークレットオブジェクトを使用して重要な構成ファイルをクラスターに安全に保存する

  • KubernetesのSecretについてはKubernetesのドキュメントを参照すること。
  • ハードウェアセキュリティモジュール（HSM）または暗号化された永続ボリューム（PV）を使用する選択肢もある。
  • 同様に、Docker Hubなどのサービスでプライベートリポジトリを使用し独自のバックエンドコンテナーに接続することを推奨する。
  • その場合、ログイン情報をKubernetesのSecretに保存し、コンポーネントをデプロイする際にyamlファイルに含める必要がある。

クラスターに関する考慮事項とノードのサイズ設定

  • Step2の上記では、ノードのサイズ設定について考える方法について説明した。
  • ユースケースとロバストな開発期間は、PeerやOrdererノード、CAのサイズを正しく知る唯一の方法である。

ボリュームのマウント方法

  • ノードがデプロイされている場所の外部に、ノードに関連するボリュームをマウントすることを推奨。
  • これにより、例えば、クラッシュしたノードまたはコンテナーを再起動する際に、暗号リソースを再デプロイ・再生成せずにこれらのボリュームにアクセスすることができるようになる。

リソースの監視方法

  • それぞれのノードで使用されるリソースとクラスターにデプロイされているリソースを監視するための戦略と方法を確立することが重要である。
  • Peerをより多くのチャネルに参加させると、CPUとメモリの割り当てを増やす必要が生じる可能性がある。
  • 同様に、StateDBと台帳のために十分なストレージスペースがあることを確認する必要がある。

Step3: CAを構築する

  • Fabricネットワークに最初に構築すべきコンポーネントはCAである。
  • これは、ノード自体をデプロイする前にノードに関連付けられた証明書（ノードだけでなく、ノードを管理できるユーザーを識別する証明書も）を作成する必要があるためである。
  • これらの証明書を作成するためにはFabricCAを使用する必要はないが、FabricCAはコンポーネントと組織を適切に定義するために必要なMSP構造も作成する。
  • ユーザーがFabricCA以外のCAを使用する場合、ユーザーは自分でMSPフォルダーを作成する必要がある。

enrollment CA

  • 1つのCA（または中間CAを使用している場合はそれ以上。中間CAについては後述）は、組織の管理者・その組織のMSP・その組織が所有するノードの証明書（enrollmentというプロセスを経て）を生成するために使用される。
  • CAは追加のユーザーの証明書も発行する。
  • IDのenrollingにおける役割のため、このCAはenrollment CAまたはecert CAと呼ばれることもある。

TLS CA

  • もう1つのCAは、トランスポート層セキュリティ（TLS）での通信を保護するために使用される証明書を生成する。
  • このCAは、TLS CAと呼ばれる。
  • これらのTLS証明書は中間者攻撃を防ぐ方法としてアクションにアタッチされる。
  • TLS CAはノードの証明書の発行にのみ使用され、そのアクティビティが完了するとシャットダウンできることに注意する。
  • ユーザーは一方向（クライアントのみ）のTLSと、双方向（サーバーとクライアント）のTLSを使用するオプションがある（後者は相互TLSと呼ばれる）。
  • ネットワークでTLSを使用すること（推奨）は、enrollment CAを導入する前に決めておく必要があるため（このCAを設定するyamlファイルにTLSを有効にするフィールドがある）、最初にTLS CAを導入しenrollment CAの起動時にそのルート証明書を使用する必要がある。
  • このTLS証明書はenrollment CAに接続してユーザーとノードのIDのを登録する際にfabric-caクライアントによっても使用される。

中間CA

  • 組織に関連するすべての非TLS証明書は単一のルートCA（すなわち、それ自体が信頼のルートであるCA）によって作成することはできるが、セキュリティを高めるため組織はルートCA（あるいは最終的にルートCAにつながる他の中間CA）によって作成された中間CAを使用することを決めることができる。
  • ルートCAが侵害されると、信頼ドメイン全体（管理者、ノード、および証明書を生成したCAの証明書）が崩壊するため、中間CAはルートCAの公開を制限するための便利な方法である。
  • 中間CAを使用するかどうかはユースケースにより異なる。（必須ではない）
  • なお、LDAPを導入している企業で既存のインフラにID管理のレイヤーを追加したくない場合は、Fabricネットワーク上のIDをを管理するように構成することも可能である。
  • LDAPはディレクトリのすべてのメンバーを効果的に事前登録し、指定された基準に基づいて登録できるようする。

【推奨】 本番ネットワークではenroll用に組織ごとに最低1つのCAをデプロイし、TLS用に別のCAをデプロイする

  • 例えば、1つの組織に関連付けられた3つのPeerと、orderer組織に関連付けられたOrdererノードをデプロイする場合、少なくとも4つのCAが必要になる。
  • CAのうち2つは相手組織用（相手、管理者、通信、組織を代表するMSPのフォルダ構成の登録証明書とTLS証明書を生成）、残りの2つはOrder組織用となる。
  • ノードは、enrollment CAとTLS CAの両方に登録することに注意する。
    • enrollment CA: ノードが自己の行為に署名しようとする際にそれを識別する署名証明書を取得する。
    • TLS CA: ノードが通信の認証に使用するTLSを証明書を取得する。
  • 組織CAとTLSCAをセットアップし、それらの管理者IDを登録する方法の例については、FabricCA導入ガイドを参照する。
  • 導入ガイドでは、Fabric CAクライアントを使用して、CAのセットアップ時に必要なIDを登録する。

Step4: CAを使用してIDとMSPを作成する

  • CAを作成したら、それらを使用して組織に関連するIDおよびコンポーネントの証明書（MSPで表される）を作成できる。
  • 組織ごとに少なくとも次のことを行う必要がある。

管理者IDをregister&enrollしMSPを作成する

  • 組織に関連付けられるCAをを作成したら、それを使用して最初にユーザーを登録し次にIDを登録できる（ネットワーク上のすべてのエンティティで使用される証明書ペアを生成する）。
  • 最初のステップでは、IDのユーザー名とパスワードがCAの管理者によって割り当てられる。
  • 属性や所属をIDに指定することもできる（例えば組織の管理者に必要なadminロール）。
  • IDを登録すると、ユーザー名とパスワードを使用してenrollができる。
  • CAはこのIDに対して、2つの証明書を生成する。
    • ネットワークの他のメンバーが知っている公開証明書（signcertまたはpublic certと呼ばれる）
    • IDが実行するアクションに署名するために使用される秘密鍵（keystoreフォルダに格納）
  • CAは証明書を発行するCAの公開証明書とCAの信頼のルートを含むMSPと呼ばれるフォルダーのセットも生成する。
  • このMSPは管理者のIDに関連する組織を定義していると考えることができる。
  • 組織の管理者がノードの管理者でもある場合（これは典型的な例である）、ローカルMSPを作成するときにノードの管理者の証明書を使用しなければならないため、ノードのローカルMSPを作成する前に組織の管理者のIDを作成する必要がある。

ノードIDをregister&enrollする

  • 組織管理者IDの登録と同様、ノードIDはenrollment CAとTLS CAの両方に登録される必要がある。
  • enrollment CAにノードを登録するときに、ノードに管理者またはユーザーのロールを与える代わりに、ノードにpeerまたはordererのロールを与える。
  • 管理者IDと同様、このIDにも属性や所属を割り当てることができる。
  • IDに割り当てられた権限はローカル（ノード）レベルでのみ関連するため、ノードのMSPは「ローカルMSP」と呼ばれる。
  • このMSPはノードIDの作成時に生成され、ノードのブートストラップ時に使用される。

Step5: PeerとOrdererノードをデプロイする

  • 証明書とMSPを作成したら、ノードを作成する準備はほぼ完了である。
  • ノードをデプロイする有効な方法はいくつかある。
  • ノードをデプロイする前に、その構成ファイルをカスタマイズする必要がある。
  • このファイルはcore.yamlと呼ばれ、ordererノードの設定ファイルはorderer.yamlと呼ばれる。
  • 構成を調整するには、主に3つの選択肢がある。
    1. バイナリにバンドルされているyamlファイルを編集する。
      • メリット: ノードを停止もしくは再起動するたびに変更を保持できる。
      • デメリット: 新しいバイナリバージョンにアップグレードするときにカスタマイズしたオプションを新しいyamlファイルに移植する必要がある（新しい形式のyamlが必要になる）
    2. デプロイする際に環境変数のオーバーライドを使用する。
    3. CLIコマンドでフラグを指定する。
  • yamlファイルで指定するパラメータと環境変数は対応関係にある。
    • 例えば、peer.localMSPidというパラメータはCORE_PEER_LOCALMSPIDという環境変数で表される。

Peerの作成

  • Peerはチャネルのメンバーである組織によって所有される（このため、これらの組織はピア組織と呼ばれることもある）。
  • それらはOrdererや他のPeerに接続し、スマートコントラクトがインストールされていて、台帳が保存されている場所でもある。
  • core.yamlのパラメータは以下である。
Identifiers
  • 関連するローカルMSPおよびTLS証明書へのパスだけでなく、Peerの名前（Peer IDと呼ばれる）やPeerを所有する組織のMSP IDも含まれる。
Addresses and paths
  • Peerは他のPeerやコンポーネントと相互作用するため、設定で一連のアドレスを指定する必要がある。
  • この設定には、Peer自体が他のコンポーネントによって検出されるアドレスとチェーンコードが検出されるアドレス（外部チェーンコードを使用している場合）が含まれる。
  • 同様に、台帳の場所（およびStateDBの種類）と外部ビルダーへのパス（外部チェーンコードを使用する場合）を指定する必要がある。
  • また、エンドポイントの設定を通じてPeerの正常性とパフォーマンスを監視するためのメソッドを設定できる操作とメトリックが含まれる。
Gossip
  • Fabricネットワークのコンポーネントはgossipプロトコルを使用して相互に通信する。
  • このプロトコルを介して、それらは検出サービスによって検出され、ブロックとプライベートデータを相互に配布することができる。
  • Gossip通信はTLSを使用して保護されている。

Ordererの作成

※ Ordererノードを追加することはできるが、ここではOrdererを作成するプロセスのみ説明する。

  • Ordererは承認されたっトランザクションを文字通り「整列する」責任があり、Peerはそれを検証して台帳にコミットする。
  • PeerとOrdererの主な違いは、本番ネットワークでは複数のOrdererノードが連携してチャネルのOrderサービスを形成する点である（これらのノードは「コンセントセット」とも呼ばれる）。
  • そのため、ノードレベルとクラスターレベルの両方で重要な決定が必要である。
  • これらのクラスターの決定の一部は、アプリケーションチャネルのジェネシスブロックを生成するために使用されるconfigtx.yamlで行われる（orderer.yamlではない）。
  • orderer.yamlのパラメータは以下である。
Identifiers
  • 関連するローカルMSPおよびTLS証明書へのパスだけでなく、Peerの名前（Peer IDと呼ばれる）やPeerを所有する組織のMSP IDも含まれる。
Addresses and paths
  • Ordererは他のコンポーネントと相互作用するため、設定で一連のアドレスを指定する必要がある。
  • この設定には、Peer自体が他のコンポーネントによって検出されるアドレスとチェーンコードが検出されるアドレス（外部チェーンコードを使用している場合）が含まれる。
  • 同様に、台帳の場所（およびStateDBの種類）と外部ビルダーへのパス（外部チェーンコードを使用する場合）を指定する必要がある。
  • また、エンドポイントの設定を通じてPeerの正常性とパフォーマンスを監視するためのメソッドを設定できる操作とメトリックが含まれる。

Discussion