本記事では、オープンソースのブロックチェーン基盤の1つであるHyperledger Fabricのv1.4で導入されたConnection Profileについて調べた結果をまとめます。
Connection Profileは、v1.4のWhat’s newでは、アプリケーション開発関係のところで一言だけ触れられている程度の非常に地味な扱いですが、アプリケーション側に対してブロックチェーンネットワークを抽象化するという点や、クライアントSDKがブロックチェーンネットワークへどのようにトランザクションを投げるか規定するという点で、重要な機能、コンセプトだと思います。
Connection Profileとは
Connection Profileは、ブロックチェーンネットワークの各構成要素(組織、チャネル、Peer、Ordererなど)をまとめて記載した定義ファイルです。FabricのSDKが、この定義ファイルに従ってブロックチェーンネットワークにトランザクションを投げてくれるので、アプリケーション開発者は、どのPeerやOrdererに接続すべきかを考慮する必要がなくなり、ビジネスロジックの実装に専念することができるようになります。v1.4以前からも似たような抽象化がある程度されていたと思いますが、Connection Profileの導入によってより洗練されたという印象です。
静的構成と動的構成
Connection Profileは、静的な構成と動的な構成の2つをサポートしています。前者は、存在するPeerなどを全てConnection Profileに記載し、それに基づいてトランザクションを送信するのに対し、後者は、最小限のPeer(本番環境では少なくとも2つ以上を推奨)だけ記載しておき、あとはService Discoveryの機能を用いて動的にConnection Profileの定義を拡充し(e.g., Peer数)、トランザクションを送信します。
Service Discoveryは、チャネルに参加しているPeerの数や、エンドースメントポリシーを問い合わせるためのAPIです。このAPIにより、Connection Profileに問合せ可能なPeerが記載されてさえいれば、あとは自動的に対象Peerを見つけてきてトランザクションを投げてくれるようです。
なお、デフォルトの挙動は動的構成のため、もしService Discoveryをオフにしたい場合は明示的に指定する必要があります。
Endorsing Peerの選択アルゴリズム
Service Discoveryを用いて動的にConnection Profileを構成する場合は、エンドースメントポリシーも自動的に取得して、必要なPeer数を計算しながら賢くトランザクションを投げてくれるようです。このあたりが、v1.x初期の頃はできていなかったように思うので良く改善されているなと思います。
気になるのは、例えば、ある組織の複数のPeerのうち1つだけからエンドースしてもらえば良いという状況下でどのPeerが選択されるのかという点です。ドキュメントのサンプルプロファイルを見る限りは、特に指定項目や関連する記載がなく、お任せのようなのですが、Go SDKのテスト用のプロファイルには、Balancerというオプションがあり、RoundRobinかRandomが選択できるようになっています。
Peerのスペックが均一であれば上記のような選択アルゴリズムで十分だと思いますが、不均一な構成を想定するのであれば、今後、負荷に応じて投げる先を切り替えるなど、ロードバランス的なことができるようになると良いのではないかと思います。