空谷に吼える

ブロックチェーン／DLTまわりのなにかしらを書いていく所存

Hyperledger FabricのGossip関連の基本的な情報のまとめ

Hyperledger Fabric ブロックチェーン

Hyperledger Fabric（HLF）のGossipプロトコルに関するLeader、Anchorってなんだっけってのいつも忘れるのでまとめておきます。

Hyperledger FabricでのGossipあれこれ

以下に基本的な情報をまとめていきます。ここには載せてない細かい設定項目がたくさんあるんですが、シビアなチューニングをしない限りはサンプル値やデフォルト値のままにしといて特に問題ないと思います。

Gossipの用途

HLFではGossipプロトコルによるメッセージングを以下4つの用途で使用しています。

  1. Peerの所在およびアイデンティティ情報、また、Channelの所属情報の拡散

  2. Channel内でのPeer間でのブロックの同期

  3. 新規に追加されたPeerへのPeer-to-Peerでの台帳データの伝播によるキャッチアップ

  4. Private Dataの伝播

Leader Peer

上述のうち「2. Channel内でのPeer間でのブロックの同期」に関わる要素です。

Ordering ServiceからあるChannelのブロックを各Peerへ配布する際、Ordering ServiceからすべてのPeerにブロック（を含むメッセージ）が必ずしも直接届けられるわけではありません。各Organizationの配下でそのChannelに所属しているPeerのうち、ひとつ～複数のPeerが代表してOrdering Serviceから直接ブロックをPullして受け取ります。この代表PeerをLeader Peerと呼びます。

そのOrganization内でLeader Peer以外にそのChannelに所属しているPeerが他にあれば、Leader PeerからGossipによってブロックが配布されます。

Leader Peerの選定方式

あるPeerが常にLeader Peerであると静的に選定しておくStatic方式と、ある種の選挙方式により動的にLeader Peerが（通常は）Organization内＆Channel内の組み合わせにつきひとつ選定されるDynamic方式があります。これらに関する設定は以下いずれかの方法でPeerごとに指定されます。

  1. core.yamlファイルで設定
peer:
    # Gossip related configuration
    gossip:
        useLeaderElection: true
        orgLeader: false
  1. Peerの環境変数で設定（core.yamlはこちらで上書きされる）
export CORE_PEER_GOSSIP_USELEADERELECTION=true
export CORE_PEER_GOSSIP_ORGLEADER=false

useLeaderElectionをtrueにしておくとDynamic方式でのLeader候補として設定されます。orgLeaderをtrueにすると、そのPeerがStaticなLeaderとして設定されます。両方falseにしておくとそのPeerはLeaderになろうと＝Ordering Serviceからブロックを受け取ろうとしません（stand-byモード）。なお両方trueにした場合にどうなるかはドキュメントに書いておらずソースコード読まないとならないんで調べていません。

複数PeerをStatic Leaderにしておくこともできますし、なんならすべてのPeerをStatic Leaderにしておくこともできるんですが、そうするとOrdering Serviceとの通信が増えてしまって帯域を無駄に使うことになるのであんまり良いやり方ではないようです。というかよほどシビアなパフォーマンスチューニングをしているなどの事情がなければ、耐障害性や設定のシンプルさの面ですべてのPeerをDynamic方式を使用するよう設定しておいたほうがよいと思われます。

Anchor Peer

他のOrganization配下のPeerについて、Peerの所在およびアイデンティティ情報、また、所属するChannelの情報をやり取りするために使われるのがAnchor Peerです。各Organizationが、Channelごとに配下のそのChannelに参加するPeerのうちゼロ～複数をAnchor Peerに設定します。Anchor Peerには自身のOrganizationおよび他のOrganizationのPeerの最新の情報が保持され、他の（OrganizationのPeerを含め）他Peerにその情報を提供します。

少なくともChannel内のいずれかのOrganization配下のPeerひとつがAnchorに設定されていないと正しくChannel内のPeerの情報が共有されません。この場合Private Dataが機能しなくなるなどの害が生じるため、確実にChannelごとにひとつ以上のAnchorが設定されているようにしましょう。耐障害性などを考えると、基本的にはOrganizationごと×Channelごとの組み合わせでひとつのAnchorを設定しておくのがよいでしょう。

Anchor PeerはChannelに関する各Organizationごとの設定なのでconfig.jsonに書くことになります。以下のようなかたちで記述します。

              "AnchorPeers": {
                "mod_policy": "Admins",
                "value": {
                  "anchor_peers": [
                    {
                      "host": "peer0.org1.example.com",
                      "port": 7051
                    }
                  ]
                }

参照公式情報