Fabricのコンポーネント、構成、ワークフローの決定は、ネットワークの全体的なパフォーマンスに影響します。複数の参加組織がそれぞれのハードウェアやネットワークインフラをネットワーク環境に提供することで、複雑になる可能性があります。Fabricネットワークのパフォーマンスを最適化するために役立つ考慮事項について説明します。各参加組織は、ピアおよびオーダリングサービスノードをホスティングするためのハードウェアを提供することができます。オーダリングサービスノードは、単一の組織が提供することも、複数の組織が提供することもできます。各参加組織は、自らがデプロイするネットワークサービスとアプリケーションのために十分なリソースを提供しなければなりません。Fabricネットワークは大量のディスクI/Oを実行するため、可能な限り高速なディスクストレージを使用する必要があります。ネットワーク接続ストレージを使用する場合は、利用可能な最速のIOPSを選択するようにしてください。一般的に複数のクラスタ、異なるクラウド環境、さらには法的・地理的境界を越えてホストされます。そのため、ノード間の高速ネットワーク接続は不可欠であり、すべてのノードと組織間で最低1Gbpsを確保する必要があります。memory¶ハードウェアに関する最後の考慮事項は、ピアとオーダリングサービスノード、およびピアノードが使用するCouchDBステートデータベースに割り当てるCPUとメモリの量です。割り当てられたリソースの制限内にあることを確認する必要があります。最大使用率に近づくまで、ノードのリソースを増やすのを待ってはいけません。最大作業負荷の一般的なガイドラインは、閾値の70%~80%程度の使用率です。ネットワーク性能は、一般的にピアノードに割り当てられたCPUでスケールするので、各ピア(および使用されている場合はCouchDB)に最大CPU容量を提供することをお勧めします。ステートデータの量が増加すると、特にステートデータベースとしてCouchDBを使用する場合、データベースストレージのパフォーマンスが低下する可能性があります。したがって、ネットワークコンポーネントを継続的に監視し、閾値を超えた場合は調整を行うとともに、時間の経過とともに環境にコンピュートリソースを追加する計画を立てる必要があります。considerations¶ネットワーク全体のパフォーマンスに関するピアの考慮事項には、アクティブチャネル数とノード構成プロパティが含まれます。デフォルトのピアおよびOrdererの構成を以下に示します。各組織がデプロイするピア数が多ければ多いほど、各組織のピア間でトランザクションのエンドース要求を負荷分散できるため、ネットワークの性能は向上するはずです。ゲートウェイピアは現在のブロックの高さに基づいてトランザクションのエンドースを行うピアを選択するため、ピア間でのエンドースの分散状況は容易に予測できません。単一のゲートウェイピアによって行われる作業を予測可能な形で減らすことができます。このゲートウェイピアの選択は、ロードバランサー、クライアントアプリケーションにてコード化されたもの、またはゲートウェイ選択時に使用されるgrpcライブラリによって実現できます。peer¶ピアに十分なCPUがあり、1つのチャネルにしか参加していない場合、ピアが内部でどのようにシリアライズとロックを行っていたとしても、ピアのCPUは65~70%以上になることはありません。ピアが複数のチャネルに参加している場合、ピアはブロック処理の並列性を高めるため、利用可能なリソースを消費します。一般に、最大負荷で動作している各チャネルに対し、利用可能なCPUコアが少なくとも1つあることを確認してください。一般的なガイドラインとして、各チャネルの負荷が高度に競合していない場合(つまり、全チャネルがリソースを同時に使用しない場合)、チャネルの数がCPUコアの数を超えても問題ありません。レコードの範囲またはJSON(リッチ)クエリが返すレコードの総数を制限します。Fabricのクエリ制限の合計はデフォルトで100000です。必要に応じてこのデフォルト値を増やすこともできますが、より多くのクエリスキャンを必要としない代替設計も検討する必要があります。Serviceは、デフォルト500のgatewayService制限を導入しました。このデフォルト値はネットワークのTPSを制限する可能性があるため、より多くの同時リクエストを許可するためにこの値を増やす必要があるかもしれません。considerations¶オーダリングサービスは、Raftコンセンサスを使用してブロックを生成します。コンセンサスに参加するordererの数やブロック生成のパラメータなどの要因は、以下に説明するように、ネットワーク全体のパフォーマンスに影響を与えます。orderers¶すべてのordererがRaftのコンセンサスに貢献するため、オーダリングサービスノードの数はパフォーマンスに影響します。(過半数を超える3つのordererが利用可能な状態を維持する必要がある)、良い出発点となります。オーダリングサービスノードを追加すると、ネットワークのパフォーマンスが低下する可能性があります。オーダリングサービスノードがネットワークのボトルネックになる場合は、各チャネルに固有のオーダリングサービスノードを配置することができます。v2.5以前では、各ordererノードのデフォルトのSendBufferSizeは10に設定されており、ボトルネックの原因となっていました。v2.5では、このデフォルトが100に変更され、スループットが向上しました。configuration¶チャネルのコンフィギュレーション設定は、オーダリングサービスのパフォーマンスにも影響します。チャネルのブロックサイズとタイムアウトパラメータを増加させると、スループットが向上しますが、レイテンシも増加します。以下に説明するように、ブロックあたりのトランザクションを増やし、ブロック生成間隔を長くするようにオーダリングサービスを構成して、パフォーマンス結果をテストすることができます。Bytes)により指定されたブロックサイズと最大トランザクション数に基づいてブロック生成が実行されます。これらのパラメータは、チャネルコンフィギュレーションを作成または更新するときに設定されます。timeout¶BatchTimeout値には、最初のトランザクションが到着してからブロックを生成するまでに待つ時間を秒単位で設定します。この値を低く設定しすぎると、希望するサイズまでバッチが充填されなくなる危険性があります。この値を高く設定しすぎると、ordererがブロックを待つことになり、全体的なパフォーマンスとレイテンシーが低下する可能性があります。一般的なガイドラインは、BatchTimeoutの値を、最低でも(最大メッセージ数÷1秒あたりの最大トランザクション数)に設定することです。count値には、1つのブロックに含めるトランザクションの最大数を設定します。bytes値には、オーダリングサービスが生成する最大のブロックサイズをバイト単位で設定します。bytesの値より大きなトランザクションは生成されません。bytes値の2~10倍にすることが一般的です。注:推奨される最大サイズは、デフォルトのgrpcサイズ制限である100MBに基づく上限値である49MBです。bytes値には、理想的なブロックサイズをバイト単位で設定します。最小のトランザクションサイズ(エンドースを含まないもの)は約1KBです。必要なエンドース1件につき1KBを追加すると、典型的なトランザクション・サイズは約3~4KBになります。countに平均トランザクションサイズの予想値を乗じた値に近い値を設定することが推奨されます。トランザクション実行時、可能な限り、ブロックはこのサイズを超えません。トランザクションは新しいブロックに含まれます。bytes値を超えることはありません。considerations¶アプリケーションアーキテクチャを設計する際、さまざまな選択がアプリケーションとネットワークの両方の全体的なパフォーマンスに影響を与える可能性があります。これらのアプリケーションの考慮事項については、以下で説明します。applications¶CouchDBのパフォーマンスは組み込みのLevelDBよりも明らかに遅く、場合によっては2倍遅くなります。記載されている通り、CouchDBステートデータベースが提供する唯一の追加機能は、JSON(リッチ)クエリです。経由)を許可しないでください。全体的なネットワークパフォーマンスを低下させ、追加のハードウェアリソース(およびコスト)を必要とするという別の制約もあります。JSONクエリは検証時に再実行されないため、Fabricにはファントムリードに対する組み込みの保護機能がありません。(JSONクエリを使用する場合、チェーンコードの実行とブロックの検証の間に状態にレコードが追加されるなどのファントムリードを許容するようにアプリケーションを設計する必要があります)。したがって、高スループットアプリケーションでは、CouchDBにJSONクエリを使用するのではなく、追加のキーに基づく範囲クエリを使用することを検討する必要があります。ストアの使用を検討してください。Fabricピアとネットワークのパフォーマンスに影響を与えません。ユーザによるクエリのニーズにより適合したSQLデータベースや分析サービスなど、オフチェーンストレージに適したデータストアを使用することもできます。CouchDBのパフォーマンスは、ステートデータの量が増加するにつれてLevelDBよりも低下するため、アプリケーションの存続期間中、CouchDBインスタンスに十分なリソースを提供する必要があります。返されるデータの量が無制限になる可能性があるチェーンコードクエリや、返されるデータの量が制限されていてもトランザクションがタイムアウトするほど大量のデータを返すチェーンコードクエリを記述することは避けてください。ベストプラクティスに反するため、返されるデータの量を制限するようにクエリを最適化してください。JSONクエリを使用する場合は、インデックスが付けられていることを確認してください。SDKを大幅に強化しています。ピアゲートウェイサービスでは、スループットが大幅に向上し、クライアントアプリケーションの機能が増え、複雑さが軽減されます。トランザクションシミュレーションに含まれるステートベースのエンドースメントポリシーを満たすために必要なエンドースメントを自動的に収集(試行)します(これは従来のSDKでは不可能です)。ピアゲートウェイサービスでは、クライアントがトランザクションを送信するために維持する必要があるネットワーク接続の数も削減されます。従来のSDKを使用すると、クライアントは組織全体の複数のピアノードとordererノードに接続する必要がある場合があります。クライアントアプリケーションに代わってトランザクションを送信します。必要に応じて、アプリケーションは複数の信頼できるピアをターゲットにでき、高い同時実行性と冗長性を実現できます。サービスに変更すると、クライアントのCPUとメモリのリソース要件も削減されますが、ピアリソース要件は若干増加します。size¶トランザクションとして送信されるデータの量と、トランザクション内のキーに書き込まれるデータの量は、アプリケーションのパフォーマンスに影響します。ペイロードサイズには、データだけが含まれるのではないことに注意してください。Fabricに必要なデータ構造に加えて、クライアントとエンドーシングピアの署名も含まれます。言うまでもなく、大きなペイロードサイズは、どのブロックチェーンソリューションでもアンチパターンです。大きなデータをオフチェーンで保存し、データのハッシュをオンチェーンで保存することを検討してください。Fabric環境で最高のパフォーマンスを示し、次にNodeチェーンコードが続きます。Javaチェーンコードのパフォーマンスは3つの中で最も低く、高スループットのアプリケーションには推奨されません。chaincode¶Nodeは、コードを実行するために単一のスレッドのみを使用する非同期ランタイム実装です。割り当ててもパフォーマンスが向上しない可能性があります(使用可能なリソースに制限があるKubernetes使用時など)。Nodeチェーンコードのパフォーマンスを監視して、vCPUがどれだけ使用されているかを確認することは価値があります。Nodeチェーンコードは自己制限型であり、無制限ではありませんが、Nodeチェーンコードプロセスにリソース制限を割り当てることもできます。GBに制限されていました。Nodeチェーンコードを実行するためにメモリを増やすには、Node実行ファイルにパラメータを渡す必要がありました。v16以降の使用が必須です。v12以降ではデフォルト値を上書きする必要があるケースはほとんどありません。chaincode¶Golangランタイム実装は並行処理に最適です。利用可能なすべてのCPUを使用できるため、チェーンコードプロセスに割り当てられたリソースによってのみ制限されます。チューニングは必要ありません。チェーンコードIDとバージョンが一致する場合、チャネル間でチェーンコードプロセスを再利用します。同じチェーンコードIDとバージョンがデプロイされた2つのチャネルにピアが参加している場合、ピアは両方のチャネルにおいて1つのチェーンコードプロセスのみと対話します。これにより、特に自己制限的なNodeチェーンコードの場合、チェーンコードプロセスに予想以上の負荷がかかる可能性があります。この場合、Goチェーンコードを使用してください。チャネルごとに異なるチェーンコードプロセスを確保することができます。policies¶トランザクションが有効なものとしてコミットされるためには、チェーンコードのエンドースメントポリシーとステートベースのエンドースメントポリシーを満たすために必要な署名が含まれている必要があります。v2.4以降)は、ポリシーを満たすのに十分なピアにのみリクエストを送信します(優先されるピアが利用できない場合は他のピアを試します)。エンドースメントポリシーは、トランザクションが有効としてコミットされるために必要なピアの数(およびその署名)を規定するため、パフォーマンスに影響します。一般的に、プライベートデータコレクション(PDC)を使用するかどうかは、パフォーマンスの観点ではなく、アプリケーションアーキテクチャの観点により決まります。ワールドステートを使用するのではなくPDCを使用してアセットを保存すると、TPSが約半分になることに注意してください。architecture¶アプリケーションを設計するときは、単一のチャネルを利用するか、複数のチャネルを利用できるかを検討してください。(複数のチャネルを使用すると、より多くのピアリソースを使用できるため)。前述のように、CouchDBは高スループットのアプリケーションには推奨されておらず、以下に説明するすべての制限を考慮する必要があります。Resources¶ステートデータベースのサイズが大きくなるにつれて、CouchDBが消費するリソースも増えるため、CouchDBインスタンスが使用するリソースを必ず監視してください。CouchDBステートデータベースを使用する場合、トランザクションのエンドースおよび検証フェーズでの参照遅延がパフォーマンスのボトルネックになることが判明しています。v2.xでは、ピアキャッシュによって、これらのコストのかかる検索の多くが高速なローカルキャッシュ参照に置き換えられます。キャッシュによってJSONクエリのパフォーマンスが向上することはありません。クエリを利用するチェーンコードには、CouchDBインデックスを含めてください。クエリをテストしてインデックスが利用されていることを確認し、インデックスを使用できないクエリは避けてください。スキャンが実行されます。複雑なクエリはインデックスを使用しても時間がかかるため、クエリを最適化してください。クエリの結果が制限されたデータセットになるようにしてください。Fabricによって、返される結果の総数が制限される場合もあります。ピアとCouchDBのログをチェックすることで、クエリにかかる時間や、クエリが「インデックスを作成すべき」というwarningログエントリからインデックスを使用できなかったクエリがあるかどうかを確認できます。クエリに時間がかかる場合は、CouchDBで使用できるCPU/メモリを増やすか、より高速なストレージを使用すると、パフォーマンスが向上する可能性があります。this."などの警告がないか確認してください。これらのメッセージは、スキャンされているドキュメントの数が多いため、インデックスを改善できる余地があることを示しています。update)呼び出しを使用します。一括更新はブロックレベルで実行されるため、ブロックに多くのトランザクションを含めるとスループットが向上します。多くのトランザクションを含めるためにブロックが生成されるまでの時間を長くすると、レイテンシにも影響します。HSM¶FabricネットワークでHSMを使用すると、パフォーマンスに影響します。影響を定量化することはできませんが、HSMのパフォーマンスやネットワーク接続などの変数は、ネットワーク全体のパフォーマンスに影響します。ピア、orderer、クライアントがHSMを使用するように構成した場合、ordererによるブロックの作成、ピアによるエンドースメントとブロックイベント、各クライアントによるリクエストなど、署名を必要とするものはすべてHSMを利用します。HSMは各ノードによって実行される署名の検証には関与しないことに注意してください。単一のトランザクションを定期的に送信すると、ブロック生成パラメータと相関するレイテンシが発生します。100バイトのトランザクションを送信すると、トランザクションの送信からコミットまでの時間は2秒強になります。これはFabricネットワークパフォーマンスの正しいベンチマークではありません。実際のベンチマークは、複数のトランザクションを同時に送信することで取得する必要があります。