[Hyperledger Fabric v1.2] 6. Architecture Reference: Service Discovery

해당 글은 Hyperledger Fabric 페이지의 게시글을 번역 및 정리한 자료입니다.

원본 사이트 : https://hyperledger-fabric.readthedocs.io/en/release-1.2/discovery-overview.html

Why do we need service discovery?

피어에 체인 코드를 실행하고 Orderer에게 트랜잭션을 제출하고 트랜잭션 상태에 대해 업데이트하려면 응용 프로그램이 SDK에 의해 공개된 API에 연결합니다.

그러나 SDK는 어플리케이션에 관련 노드를 연결 허가를 하기 위해선 많은 정보가 필요합니다.

채널 Orderer의 CA와 TLS 인증에 또한 IP 주소와 포트 번호에 더하여 관련 endorsement 정책과 어떤 피어가 체인코드를 설치하고 있는가(어플리케이션이 어떤 피어에게 체인코드 제안을 보낼지 알기 때문에)를 알아야합니다.

1.2 버전 이전에는, 정보가 정적으로 인코딩 되었습니다. 그러나 이 버전에선 네트워크 변경(관련 체인코드를 설치한 피어 또는 일시적으로 오프라인 상태인 피어 추가)에 동적으로 대응하지 않습니다.

또한 정적 구성을 사용하면 응용 프로그램이 endorsement 정책 자체의 변경 사항에 대응할 수 없습니다.(새 조직이 채널에 참여할 때 발생할 수 없음)

또한 클라이언트 응용 프로그램은 어떤 피어가 원장을 업데이트했는지를 알 수있는 방법이 없습니다.

결과적으로 응용 프로그램은 장부 데이터가 네트워크의 나머지 부분과 동기화되지 않은 피어에게 제안서를 제출할 수 있습니다.

이로 인해 커밋시 트랜잭션이 무효화되고 결과적으로 자원이 낭비됩니다.

Service Discovery는 동적으로 피어가 필요한 정보를 계산하고, 소모가능한 방식의 SDK를 제공함으로서 이 프로세스를 개선합니다.

How service discovery works in Fabric

응용 프로그램 개발자 / 관리자가 신뢰할 수있는 피어 그룹에 대해 알면 부트 스트랩되어 디스커버리 쿼리에 확실한 응답을 제공합니다.

클라이언트 응용 프로그램이 사용할 좋은 후보 피어는 동일한 조직에 있는 것입니다.

응용 프로그램은 검색 쿼리에 구성 쿼리를 보내고 네트워크의 나머지 다른 노드와 통신하는 데 필요한 정적 정보를 모두 얻습니다.

이 정보는 피어 검색 서비스에 후속 쿼리를 전송하여 언제든지 새로 고칠 수 있습니다.

이 서비스는 애플리케이션이 아닌 피어(peer)에서 실행되며 가십의 커뮤니케이션 레이어가 유지 관리하는 네트워크 메타 데이터 정보를 사용하여 어떤 피어가 온라인 상태인지 파악합니다.

또한 피어의 상태 데이터베이스에서 관련 승인 정책과 같은 정보를 가져옵니다.

서비스 검색을 사용하면 응용 프로그램에서 더 이상 추천 할 피어를 지정할 필요가 없습니다.

SDK는 검색 서비스에 쿼리를 보내어 채널과 체인 코드 ID가 주어지면 어떤 피어가 필요한지를 묻습니다.

발견 서비스는 다음 두 객체로 구성된 디스크립터를 계산합니다.

1. 레이아웃 : 피어 그룹의 목록과 각 그룹의 피어 중 해당하는 양을 선택해야합니다.
2. 그룹 투 피어 매핑 : 레이아웃의 그룹에서 채널의 피어까지 실제로 각 그룹은 개별 조직을 대표하는 피어가 될 가능성이 높지만 서비스 API는 일반적이고 조직을 모르기 때문에 단지 "그룹"으로 인지됩니다.

아래의 코드는 각 조직에 두 개의 피어가 있는 AND(Org1, Org2)의 정책 평가 디스크립터의 예시입니다.

Layouts: [
     QuantitiesByGroup: {
       “Org1”: 1,
       “Org2”: 1,
     }
],
EndorsersByGroups: {
  “Org1”: [peer0.org1, peer1.org1],
  “Org2”: [peer0.org2, peer1.org2]
}

즉, endorsement 정책에서는 Org1의 한 피어와 Org2의 피어가 서명해야합니다. 그리고 이것은(Org1과 Org2 모두에 속한 peer1, peer2) endorse 할 수 있는 조직에서 사용 가능한 피어의 이름을 제공합니다.

그런 다음, SDK가 리스트로부터 임의의 레이아웃을 선택합니다. 위의 예를 들자면, endorsement 정책은 Org1 AND Org2입니다.

만약 OR 정책이었다면, SDK는 둘 중 어느 Org의 피어로부터의 서명이 정책을 충족시기키 때문에 Org1 또는 Org2 둘 중 하나를 임의로 선정했을 것입니다.

SDK가 레이아웃을 선택한 후에 클라이언트 측에 지정된 기준에 따라 레이아웃의 피어 중에서 선택합니다 (SDK는 원장 길이와 같은 메타 데이터에 액세스 할 수 있기 때문에이 작업을 수행 할 수 있습니다). 예를 들어, 레이아웃에서 각 그룹의 피어 수에 따라 다른 사용자보다 높은 원장 높이를 가진 피어를 선호하거나 응용 프로그램이 오프라인 상태임을 발견 한 피어를 제외 할 수 있습니다.

기준에 따라 단일 피어가 더 바람직하지 않은 경우 SDK는 기준을 가장 잘 만족하는 피어를 무작위로 선택합니다.

Capabilities of the discovery service

디스커버리 서비스는 다음의 쿼리에 응답할 수 있습니다.

구성 쿼리 : 채널 엔드포인트와 함께 채널 내 모든 조직의 MSPConfig를 반환합니다.

피어 멤버십 쿼리 : 채널에 가입한 피어를 반환합니다.

Endorsement 쿼리 : 채널에서 주어진 체인 코드에 대한 Endorsement 설명을 반환합니다.

로컬 피어 멤버십 쿼리 : 쿼리에 응답하는 피어의 로컬 멤버 자격 정보를 반환합니다. 기본적으로 클라이언트는 피어가 이 쿼리에 응답할 수 있는 관리자여야 합니다.

Special Requirement

피어가 TLS를 사용하도록 설정되어 실행중인 경우 클라이언트는 피어에 연결할 때 TLS 인증서를 제공해야합니다.

피어가 클라이언트 인증서를 확인하도록 구성되지 않은 경우(clientAuthRequired가 false 인 경우)에 TLS 인증서는 자체 서명 될 수 있습니다.