Planning for an ordering service¶
対象読者:アーキテクト、ネットワークオペレーター、Transport Layer Security(TLS)に精通した本番Fabricネットワークを設定するユーザー、公開鍵基盤(PKI)およびメンバーシップサービスプロバイダー(MSP)。
オーダリングサービスの概念、実装、およびトランザクションでオーダリングサービスが果たすロールの概要については、 The Ordering Service のコンセプトトピックを参照してください。
Hyperledger Fabricネットワークでは、ノードまたはノードの集合が「オーダリングサービス」と呼ばれるものを形成します。これは文字通りトランザクションをブロックに順序付け、ピアが検証して台帳にコミットします。これによりFabricは、このような順序付けがすべてのノードによって行われるEthereumやBitcoinのような、他の分散型のブロックチェーンとは異なります。
テストおよび開発目的でのみ使用されるFabricネットワーク (test network など)は、1つのノードのみで構成されるオーダリングサービス(これらのノードは通常「orderer」または「オーダリングノード」と呼ばれます)を特徴とすることが多いのに対して、本番ネットワークは少なくとも3つのノードでより堅牢なデプロイを必要とします。このため、デプロイガイドでは、3つのノードのオーダリングサービスを作成する方法について説明します。デプロイすべきノード数の詳細については、 Cluster considerations を参照してください。
Generate ordering node identities and Membership Service Providers (MSPs)¶
このトピックに進む前に、組織内の管理者およびオーダリングノードのアイデンティティおよびMSPを生成するために、組織でデプロイする認証局(CA)のプロセスを確認する必要があります。CAを使用してこれらのアイデンティティを作成する方法については、 Registering and enrolling identities with a CA を参照してください。ベストプラクティスは、オーダリングノードごとに個別のノードのアイデンティティを登録およびエンロールし、ノードごとに異なるTLS証明書を使用することに注意してください。
cryptogen ツールでは、本番のシナリオを使用してアイデンティティを生成すべきではないことに注意してください。
このデプロイガイドでは、すべてのオーダリングノードが同じオーダリング組織によって作成され、所有されることを前提としています。ただし、オーダリングサービスの作成中とオーダリングサービスの作成後の両方において、複数の組織がノードをオーダリングサービスに提供することは可能です。
Folder management¶
MSPと証明書に対していくつかのフォルダ構造を使用してオーダリングノードをブートストラップすることは可能ですが、一貫性と再現性を保つために、 Registering and enrolling identities with a CA で説明されているフォルダ構造をお勧めします。必須ではありませんが、これらの手順では、そのフォルダ構造を使用していることを前提としています。
Certificates from a non-Fabric CA¶
非Fabric CAを使用してアイデンティティを生成することは可能ですが、このプロセスでは、MSPフォルダとその組織が必要とするオーダリングサービスを手動で作成する必要があります。そのプロセスについてはここでは説明せず、代わりにFabric CAを使用してアイデンティティとMSPフォルダを生成することに焦点を当てます。
Transport Layer Security (TLS) enablement¶
「中間者」攻撃を防止し、安全な通信を行うために、TLSの使用はすべての本番ネットワークの要件です。そのため、オーダリングノードアイデンティティを組織のCAに登録するだけでなく、組織のTLS CAを使用してオーダリングノードの証明書を作成する必要があります。これらのTLS証明書は、ネットワークと通信するときにオーダリングノードが使用します。
Creating the system channel genesis block¶
注:「同意者」とは、特定の時間に特定のチャネルにサービスを提供するノードを指します。各チャネルについて、「同意者」は、システムチャネルで利用可能なオーダリングノードのサブセットであることもあります。
すべてのオーダリングノードは、システムチャネルからのコンフィギュレーションブロック(システムチャネル「ジェネシスブロック」またはそれ以降のコンフィギュレーションブロック)でブートストラップする必要があります。このガイドでは、新しいオーダリングサービスを作成し、システムチャネルジェネシスブロックからオーダリングノードをブートストラップすることを想定しています。
この「システムチャネル」はオーダリングサービスが実行する特別チャネルで、とりわけ、アプリケーションチャネルを作ることができるピア組織のリスト(このリストは「コンソーシアム」として知られています)などが含まれています。このシステムチャネルへは、ピアまたはピア組織によって参加することはできませんが(したがって、コンフィギュレーショントランザクション以外のトランザクションを作成することはできません)、アプリケーションチャネルに含まれるのと同じ設定パラメータが多く含まれています。アプリケーションチャネルは、チャネル作成プロセス中に変更されない限りこれらの設定値をデフォルトで継承するため、システムチャネルジェネシスブロックを作成するときは、ネットワークのユースケースを念頭に置くように注意してください。
オーダリングサービスを作成する場合は、 configtx.yaml で必要なパラメータを指定し、 configtxgen ツールを使用して、システムチャネルジェネシスブロックを作成する必要があります。
システムチャネルにノードを追加する場合、ベストプラクティスはシステムチャネルの最新のコンフィギュレーションブロックを使用してブートストラップします。同様に、アプリケーションチャネルの同意者に追加されたオーダリングノードは、そのチャネルの最新のコンフィギュレーションブロックを使用してブートストラップされます。
Fabricバイナリと一緒に出荷される configtx.yaml は、 sample configtx.yaml found here と同じであり、特定の望ましいポリシーとパラメータを指定するために使用される同じチャネルの「プロファイル」を含んでいることに注意してください(例えば、システムチャネル内の同意者となるどのオーダリングノードがアプリケーションチャネルで使用されるかを指定するために使用できます)。チャネルを作成する場合(ordererシステムチャネルまたはアプリケーションチャネルのいずれか)、チャネル作成コマンドで特定のプロファイルを名前で指定します。そのプロファイルは、 configtx.yaml で指定された他のパラメータとともに、コンフィギュレーションブロックをビルドするために使用されます。
システムチャネルとアプリケーションチャネルを作成するために、これらのプロファイルの1つを変更する必要があります(他に何もない場合は、サンプルの組織名を変更する必要がある可能性があります)。Raftオーダリングサービスを作成するには、 etdraft の OrdererType を指定する必要があります。
システムチャネルジェネシスブロックとアプリケーションのチャネルの作り方の詳細については、 tutorial on creating a channel をご覧ください。
Creating profiles for application channels¶
システムとすべてのアプリケーションチャネルの両方が、 configtx.yaml ファイルを使用して構築されます。したがって、configtx.yamlを編集してシステムチャネルのジェネシスブロックを作成するときは、このネットワーク上に作成されるアプリケーションチャネルのプロファイルを追加することもできます。ただし、各チャネルに対して任意の同意者セットを定義できますが、 アプリケーションチャネルに追加されたすべての同意者は、最初はシステムチャネルの一部である必要があります 。システムチャネルの一部でない同意者は指定できません。また、同意者セットのリーダーを管理することはできません。リーダーは、オーダリングノードが使用する etdraft プロトコルによって選択されます。
Sizing your ordering node resources¶
オーダリングノードはステートデータベースやチェーンコードをホストしないため、オーダリングノードは通常、それに関連付けられた単一のコンテナのみを持ちます。ピアに関連付けられた「ピアコンテナ」と同様に、このコンテナは、トランザクションを順序づける順序付けプロセスを、そのオーダリングノードが同意者であるすべてのチャネルのブロックにカプセル化します(特定の場合にはオーダリングノードはアクションも検証します)。オーダリングノードストレージは、ノードが同意者であるチャネル全体のブロックチェーンを含みます。
論理的なレベルでは、各チャネルのすべての「同意者セット」は別個のオーダリングサービスであり、「アライブ」メッセージおよび他の通信が複製されることに注意してください。これは各ノードに必要なプロセッサとメモリに影響します。同様に、同意者セットのサイズと各ノードが必要とするリソースの量との間には直接的な関係があります。これは、Raftオーダリングサービスでは、ノードがトランザクションの順序づけで連携しないためです。他のノードによって選出された「リーダー」である1つのノードは、すべての順序付けおよび検証機能を実行し、その後、決定を他のノードに複製します。その結果、同意者セットの規模が拡大するにつれて、リーダーノードのトラフィックと負荷が増加し、同意者セットを横断する通信が増加します。
詳細は Cluster considerations にあります。
Cluster considerations¶
デプロイするのに必要なノード数の詳細については、 Raft をご覧ください。
Raftはリーダーベースのプロトコルであり、1つのリーダーがトランザクションを検証し、ブロックを順序付けし、データをフォロワに複製します。Raftは、Raftノードの過半数がオンラインである限りRaftクラスタは利用可能を維持するという、定足数の概念に基づいて動作します。
一方、デプロイされたRaftノードが多いほど、より多くのノードが失われる可能性がありますが、ノードの過半数は依然として利用可能です(ノードの過半数が利用可能でない限り、クラスタはブロックの処理と作成を停止します)。例えば、5つのノードクラスタは2つのノードのダウンに耐えることができ、7つのノードクラスタは3つのノードのダウンに耐えることができます。
しかし、オーダリングサービスを正しく機能させるためには、リーダーがすべてのノードと通信する必要があるため、ノードが多いほど通信オーバーヘッドが大きくなります。ノードがリーダーとの接続を失ったと考えられる場合、この通信の損失がネットワークまたは処理の遅延のみによるものであっても、リーダーの選択をトリガーするように設計されています。不必要なリーダーの選出は、リーダーの通信オーバーヘッドを増大させるだけであり、クラスターの負担を徐々に増大させます。そして、オーダリングノードが参加する各チャネルは、論理的には別々のRaftインスタンスであるため、100チャネルに参加するordererは、実際には1つのチャネルでオーダリングノードとして100倍の仕事をしています。
これらの理由から、数十ノード以上のRaftクラスタでは、顕著なパフォーマンス低下が見られるようになります。クラスタが約100ノードに達すると、定足数の維持に問題が発生します。デプロイに問題が発生する段階は、ネットワーク速度や利用可能な他のリソースなどの要因に依存し、より大きな通信オーバーヘッドを緩和するために使用できるティック間隔などのパラメータがあります。
オーダリングサービスの最適なオーダリングノード数は、最終的にはユースケース、リソース、およびトポロジーによって異なります。しかし、3、5、7、または9つのノードのクラスターが最も一般的であり、ordererごとのチャネルは約50を超えません。
Storage considerations and monitoring¶
オーダリングノードに割り当てるべきストレージは、予想されるトランザクションスループット、ブロックのサイズ、ノードが結合されるチャネルの数などの要因によって異なります。ニーズはユースケースによって異なります。ただし、ベストプラクティスは、ノードが使用できるストレージを綿密に監視することです。また、オートスケーラを有効にすることもでき、インフラストラクチャで許可されている場合は、ノードにより多くのリソースが割り当てられます。
オーダリングノードのストレージが使い果たされた場合、より大きなストレージ割り当てを持つ新しいノードをデプロイし、関連する台帳と同期できるようにするオプションもあります。複数のオーダリングノードが使用できる場合は、各ノードがほぼ同数のチャネル上の同意者であることを確認します。
本番環境では、広く利用可能なツールを使用して、オーダリングノードに割り当てられたCPUとメモリも監視する必要があります。もし、オーダリングノードが維持しようと奮闘しているのが確認できたら(例えば、何も必要ないときにリーダーの選出を要求しているかもしれません。)、それはリソース割り当てを増やす必要があるかもしれないというサインです。