Planning for a production peer

対象読者:アーキテクト、ネットワークオペレーター、本番のFabricネットワークを設定するユーザーで、Transport Layer Security(TLS)、公開鍵基盤(PKI)、メンバーシップサービスプロバイダー(MSP)に精通している人。

注:「チェーンコード」はピアにインストールされたパッケージを指し、「スマートコントラクト」は組織が合意したビジネスロジックを指します。

ピアノードはFabricネットワークの基本的な要素です。なぜなら、ブロックチェーンネットワークで共有されたプロセスと共有された情報をカプセル化するために使用される台帳とスマートコントラクトをホストするからです。これらの手順は、あなたが既に peer の概念に精通していることを前提としており、ピアに関して行う必要がある様々な決定や、本番Fabricネットワークチャネルをデプロイして参加するためのガイダンスを提供します。教育やテストの目的でネットワークを迅速に立ち上げる必要がある場合は、 Fabric test network を参照してください。

Generate peer identities and Membership Service Providers (MSPs)

このトピックに進む前に、組織の Deploying a Certificate Authority (CA) のプロセスを確認して、組織の管理者とピアのアイデンティティとMSPを生成する必要があります。CAを使用してこれらのアイデンティティを作成する方法については、 Registering and enrolling identities with a CA を参照してください。

「cryptogen」ツールは、本番のシナリオでアイデンティティを生成するために使用すべきではないことに注意してください。

Folder management

MSPと証明書のために多くのフォルダ構造を使用してピアをブートすることは可能ですが、一貫性と再現性のために特定の folder structure を推奨します。これらの手順は、そのフォルダ構造を使用していることを前提としています。

Certificates from a non-Fabric CA

非Fabric CAを使用してアイデンティティを生成することは可能ですが、このプロセスでは、ピアをデプロイする必要があるMSPフォルダを手動で構築する必要があります。そのプロセスについてはここでは説明しません。代わりに、Fabric CAを使用してアイデンティティとMSPフォルダを生成することに焦点を当てます。

Transport Layer Security (TLS) enablement

「man in the middle」攻撃を防ぎ、通信を安全にするために、TLSを使用することはすべての本番ネットワークの要件です。そのため、組織CAでピアアイデンティティを登録するだけでなく、組織のTLS CAでもピアイデンティティを登録する必要があります。これらのTLS証明書は、ネットワークと通信するときにピアによって使用されます。

State database

各ピアは、台帳に記載されているすべての資産(「キー」とも呼ばれる)の現在の値を追跡するステートデータベースを維持しています。サポートされているステートデータベースには、外部CouchDB(データベースのJSONクエリを可能にする)と組み込みGoleveldb(JSONクエリが可能ではない)の2種類があります。データベースの選択は、CouchDBのJSONクエリサポートが必要かどうかによって大きく異なります。JSONクエリが必要ない場合、Goleveldbはピアプロセスに埋め込まれているため、パフォーマンスが向上し、管理が少なくて済みます。チャネル上のすべてのピアは同じステートデータベースを使用する必要があるため、データベースの選択はすでに参加を希望するチャネルによって決定されている可能性があります。

CouchDBを使用しているときにJSONクエリを実行する機能以外は、データベースの選択はスマートコントラクトには見えません。

詳細については State Database options をご覧ください。

Sizing your peer resources

通常、ピアには複数のコンテナが関連付けられています。

  • ピア コンテナ: ピアプロセスをカプセル化して、ピアが属するすべてのチャネルのトランザクションを検証およびコミットします。ピアのストレージには、各チャネルのブロックチェーン(つまりトランザクション履歴)、Goleveldbを使用している場合はステートデータベースを含むローカルデータベース、およびピアにインストールされているチェーンコードが含まれます。ピアのストレージの規模は、チャネルの数、各チャネルの取引の数と規模によって異なります。
  • CouchDB コンテナ (任意): CouchDBをステートデータベースとして使用する場合は、CouchDBコンテナを使用して各チャネルのステートデータベースを保管します。
  • チェーンコード ランチャー コンテナ (任意): チェーンコードごとに別々のコンテナを立ち上げるために使用され、ピアコンテナ内のDocker-in-Dockerコンテナを必要としません。チェーンコードランチャーコンテナは、スマートコントラクトを実際に実行する場所ではないため、ピアとともに配備されていた「スマートコントラクト」コンテナよりも少ないデフォルトリソースが与えられることに注意してください。これは、スマートコントラクトを実行するコンテナの作成を支援するためにのみ存在します。ランチャーによってデプロイされたチェーンコードのコンテナに対して、クラスタで独自の許容量を設定する必要があります。
  • チェーンコード コンテナ: チェーンコードを実行するコンテナ。推奨されるプロセスは、すべて同じチェーンコードをインストールしている同じチャネルに、複数のピアがある場合でも、各チェーンコードを別々のコンテナにデプロイすることです。ですので、チャネルに3つのピアがあり、各ピアにスマートコントラクトをインストールする場合、3つのスマートコントラクトコンテナが実行されます。しかし、これら3つのピアがまったく同じスマートコントラクトを使用する複数のチャネルにある場合は、3つのpodだけが実行されます。

Storage considerations

チェーンコードと台帳(各チャネルに1つ)は、 peer.fileSystemPath パラメータに従ってピアに物理的に保存されます。一方、アイデンティティとMSPは、 peer.mspConfigPath パラメータに従って保存されます(デフォルトでは、両方の場所は /var/hyperledger/production にあります)。 このファイルシステムは、許可されたユーザーのみが保護、セキュリティ、および書き込み可能にする必要があり、 定期的にバックアップする必要があります。ベストプラクティスは、これらのパラメータの両方に外部マウントされたボリュームを使用することに注意してください。これは、ピアを再起動またはアップグレードするときに参照しやすいためです。

ピアを設定するときは、 ledger.state.stateDatabase パラメータを設定して、ステートデータベースをCouchDBとLevelDB(デフォルト)のどちらに保存するかを決定する必要があります。

このトピックではピアバイナリイメージの使用方法に焦点を当てていますが、DockerコンテナでFabricイメージを実行したりKubernetesを使用したりする場合に注意する必要のある重要なストレージの検討事項があります。Dockerコンテナには、コンテナにパスする外部フォルダをマウントするボリュームバインディングマウントが必要です。これは、ストレージが失われないように、コンテナが再起動するときに重要です。同様に、Kubernetesを使用している場合は、ピア用にストレージをプロビジョニングし、Kubernetesのpod deployment YAMLファイルにマッピングする必要があります。

High Availability

ピアを作成する計画の一部として、コンポーネントのダウンタイムを0にするために、組織レベルで戦略を検討する必要があります。これは、冗長コンポーネント、特に冗長ピアを構築することを意味します。0ダウンタウンを確保するには、 別の仮想マシンで 少なくとも1つの冗長なピアが必要です。これにより、クライアントアプリケーションがエンドースメントの提案を連続して送信している間に、ピアはメンテナンスのためにダウンすることができます。

同様に、クライアントアプリケーションは、サービスディスカバリを使用してトランザクションが現在使用可能なピアにのみ送信されるのを保証するように設定する必要があります。各組織から少なくとも1つのピアが利用可能であり、発見されたサービスが使用されている限り、どのエンドースメントポリシーも満たすことができます。各組織の責任は、その組織が所有する少なくとも1つのピアが、参加するすべての組織で常に利用可能であることを確保するために、高可用性戦略が十分に安定していることを確認することです。

Monitoring

すべてのブロックチェーンノードは注意深く監視する必要がありますが、ピアとオーダリングノードを監視することは非常に重要です。イミュータブルであるため、台帳は必然的に成長します。そのため、ストレージを監視し、必要に応じて拡張しなければいけません。ピアのストレージが枯渇した場合は、より大きなストレージ割り当てで新しいピアをデプロイし、台帳を同期させる選択もあります。本番環境では、広く利用可能なツールを使用して、ピアに割り当てられたCPUとメモリも監視する必要があります。トランザクションの負荷に対応しようとするとき、あるいは、比較的単純なタスク(台帳をクエリするなど)を実行するときに、ピアが苦闘しているのが分かったら、リソース割り当てを増やす必要があるかもしれないサインです。

Chaincode

Hyperledger Fabric 2.0以前は、ビルドとチェーンコード起動に使用されていたプロセスはピア実装の一部であり、簡単にカスタマイズすることはできませんでした。ピアにインストールされたすべてのチェーンコードは、ピアでハードコードされた言語固有のロジックを使用して「構築」されていました。このビルドプロセスは、ピアにクライアントとして接続されたチェーンコードを実行するために起動されるDockerコンテナイメージを生成しました。

このアプローチは、チェーンコードの実装を一握りの言語に制限し、デプロイメント環境の一部としてDockerを必須とし、チェーンコードを長期にわたってサーバープロセスとして実行することを妨げ、ピアがチェーンコードコンテナに特権的にアクセスできる必要がありました。

Fabric 2.0からは、外部ビルダーおよびランチャーにより、オペレーターがチェーンコードをビルド、起動、および発見できるプログラムでピアを拡張できます。すでに存在するピアでこのケーパビリティを活用するには、独自のビルドパックを作成し、 core.yaml を変更して新しいexternalBuilder設定要素を含める必要があります。これにより、ピアは外部ビルダーが利用可能であることを知ることができます。

Gossip

ピアは、 gossip data dissemination protocol を活用して、台帳およびチャネルデータをスケーラブルにブロードキャストします。ゴシップメッセージングは継続的であり、チャネル上の各ピアは、他の組織のピアを含む複数のピアから絶えずデータを受信しています(組織横断的なゴシップが有効になっている場合)。

ピアゴシップが動作するためには、4つのパラメータを設定する必要があります。そのうちの3つ --- peer.gossip.bootstrap, peer.gossip.endpoint, peer.gossip.externalEndpoint --- は、ピアのcore.yamlファイルにあります。4つ目は、チャネル設定内のアンカーピアを指定することで組織間のゴシップを有効にします。

ネットワークトラフィックを減らすために、Fabric v2.2では、デフォルトのcore.yamlは、ピア間でゴシップの配布をするのではなく、オーダリングサービスからブロックを取得するように設定されています(プライベートデータは例外で、ゴシップを使用しているピアからピアに送信されます)。ordererからすべてのブロックを取得するには、 core.yaml ファイルで次のパラメータを使用する必要があります。

  • peer.gossip.useLeaderElection = false
  • peer.gossip.orgLeader = true
  • peer.gossip.state.enabled = false

すべてのピアが orgLeader=true (推奨)である場合、各ピアはオーダリングサービスからブロックを取得します。

Service Discovery

どのネットワークでも、ピアノードがメンテナンスのためにダウンしたり、ネットワークの問題で到達不能になったり、ピア台帳がオフラインで遅れたりする可能性があります。このため、Fabricには「ディスカバリサービス」が含まれています。これにより、SDKを使用するクライアントアプリケーションは、エンドースメントのリクエストで対象となる候補のピアを見つけることができます。サービスディスカバリが有効になっていない場合、クライアントアプリケーションがオフラインのピアを対象にすると、要求は失敗し、別のピアに再送信する必要があります。ディスカバリサービスはピア上で実行され、ゴシップのコミュニケーションレイヤによって維持されるネットワークメタデータの情報を使用して、どのピアがオンラインであり、要求の対象となることができるかを検出します。

サービスディスカバリ(およびプライベートデータ)では、ゴシップが有効になっているである必要があります。したがって、この機能を利用するには、 peer.gossip.bootstrap 、 peer.gossip.endpoint 、および peer.gossip.externalEndpoint パラメータを設定し、各チャネルのアンカーピアを使用する必要があります。