HYPERLEDGER FABRIC - Developing Applications - Application design elements - Connection Options

HYPERLEDGER FABRIC - Developing Applications - Application design elements - Connection Options

 

독자 : Architects, administrators, application and smart contract developers

 

Connection Options은 gateway가 네트워크와 상호작용 하는 방식을 정확하게 제어하기 위해 connection profile과 함께 쓰입니다.

gateway를 사용하면 application이 네트워크 토폴로지보다 비즈니스로직에 집중할 수 있습니다.

 

이번 주제에서는 다음을 다룰 것입니다.

• Why connection options are important
• How an application uses connection options
• What each connection option does
• When to use a particular connection option

 

Scenario (Why connection options are important)

connection option은 gateway의 동작의 특정 측면을 명시합니다.

gateway는 많은 이유에서 중요하며, 주요 이유는 application이 네트워크의 많은 구성요소들의 상호작용을 관리하는 동시에 비즈니스 로직과 smart contract에 집중할 수 있습니다.

connection option이 동작을 제어하는 상호 작용 지점들입니다. 이러한 옵션은 텍스트에 자세히 설명되어있습니다.

 

connection option의 한가지 예인 issue application에서 사용되는 gateway는 Isabella ID를 사용하여 pepernet 네트워크에 트랜잭션을 제출하는 것을 명시합니다.

다른 하나는 gateway가 MagnetoCorp의 트랜잭션이 반환된 제어로 커밋되었는지 확인하기 위해 모든 세 노드를 위해 기다려야 한다는 것입니다.

Connection options를 사용하면 application은 네트워크와 gateway의 상호작용의 정확한 행동을 명시할 수 있습니다.

gateway가 없으면 application은 더 많은 작업을 필요로 하므로, gateway는 시간을 절약해주고, application의 가독성을 높이며 오류 발생 가능성을 줄입니다.

 

Usage (How an application uses connection options)

application에서 사용가능한 전체 connection option을 살펴보겠습니다.

먼저 sample MagnetoCorp issue application에서 어떻게 명시하는지 봅시다.

const userName = 'User1@org1.example.com';
const wallet = new FileSystemWallet('../identity/user/isabella/wallet');

const connectionOptions = {
  identity: userName,
  wallet: wallet,
  eventHandlerOptions: {
    commitTimeout: 100,
    strategy: EventStrategies.MSPID_SCOPE_ANYFORTX
    }
  };

await gateway.connect(connectionProfile, connectionOptions);

identity와 wallet 옵션이 connectionOptions 객체의 속성임을 알 수 있습니다.

각각 이전에 선언된 userName과 wallet이라는 변수를 받고 있습니다.

eventHandlerOptions 옵션과 이 옵션을 비교해보세요.

eventHandlerOptions는 commitTimeout: 100 (measured in seconds)와 strategy: EventStrategies.MSPID_SCOPE_ANYFORTX 두가지 값을 가지고 있습니다.

 

connectionOptions는 connectionProfile에 대한 보완으로 gateway에 전달됩니다.

네트워크는 connection profile에 의해 식별되고, 옵션은 gateway가 그것과 어떻게 상호작용하는지 정확히 명시합니다.

사용가능한 옵션을 살펴보러 갑시다.

 

Options (What each connection option does)

사용 가능한 옵션들의 목록입니다.

• wallet은 application대신 gateway에서 사용되는 wallet을 식별합니다. 1번지점을 보면 wallet은 application에 의해 지정되지만, 실제로는 게이트웨이는 wallet에서 ID를 식별합니다.
  
  wallet은 명시되어야하며, 파일 시스템, 인메모리, HSM 또는 데이터베이스에 관계없이 사용할 지갑의 유형 결정이 제일 중요합니다.
• identity는 wallet으로부터 application에서 사용할 사용자의 ID입니다. 2a지점을 보면 사용자 ID는 applicaion에 의해 명시되어있고, 2b에서 application의 사용자를 Isabella라고 표현합니다. ID는 실제로는 gateway에 의해 검색됩니다.
  
  예를 들어, Isabella의 ID는 다른 MSP (2c, 2d)에서 그녀가 MagnetoCorp에서 왔고 그 안에서 특정 역할을 가지고 있음을 식별하기 위해 사용됩니다. 이러한 두 가지 사실은 리소스에서 그녀의 권한(예를 들어 원장을 읽고 쓰는)을 그에 따라 결정합니다.
  
  사용자 ID는 명시되어야합니다. ID는 Hyperledger Fabric이 허가된 네트워크라는 개념의 기본입니다. 리소스위에서 그들의 제어를 결정하는 application, peer, orderer에 포함된 모든 행위자는 ID를 가지고 있어야합니다. 멤버십 서비스 주제(Key Concepts » Membership Service Provider (MSP))안에서 이 개념에 대해 더 알아볼 수 있습니다.
• clientTlsIdentity는 wallet(3a)로부터 검색되는 ID입니다. 그리고 gateway와 peer, orderer과 같은 다른 채널 구성요소 사이에서 보안 통신(3b)에 사용됩니다.
  
  ID가 사용자 ID와 다르다는 것을 기억하세요. clientTlsIdentity가 보안 통신에서 중요하지만 범위가 보안 네트워크 통신을 넘어 확장되지 않기 때문에 사용자 ID만큼 기본은 아닙니다.
  
  clientTlsIdentity는 선택사항입니다. 프로덕션 환경에서 설정하는 것이 좋습니다. 이러한 ID는 매우 다양한 의미와 수명주기를 갖기 때문에 언제나 다른 clientTlsIdentity를 identity에 사용해야합니다. 예를 들어, clientTlsIdentity가 손상되었다면, 너의 ID를 안전하게 분리 보관하세요.
• eventHandlerOptions.commitTimeout은 선택사항입니다. 이것은 application에 제어가 반환되기 전에 어떤 peer(4a)에 의해 커밋되는 트랜잭션을 gateway가 기다려야하는 최대 시간을 명시합니다. 알림에 사용할 peer의 집합은  eventHandlerOptions.strategy 옵션에 의해 결정됩니다. commitTimeout이 명시되지 않았다면, gateway는 300초의 timeout을 사용할 것입니다.
• eventHandlerOptions.strategy는 선택사항입니다. 이것은 gateway가 트랜잭션이 커밋되었다는 알림을 듣기위해 사용하는 peer의 집합을 지정합니다. 예를 들어, 그것의 조직으로부터 단일 peer 또는 모든 peer 수신 여부입니다. 다음 값 중 하나를 사용할 수 있습니다.
  • EventStrategies.MSPID_SCOPE_ANYFORTX 는 사용자의 조직안에서 any peer를 listen합니다. 우리의 예에서, 4b를 확인해보세요. MagnetoCorp의 peer1, peer2, peer3 중 하나라도 gateway에 알림이 갑니다.
  • EventStrategies.MSPID_SCOPE_ALLFORTX 가 default값입니다. 사용자 조직안의 모든 피어를 listen합니다. 우리의 예에서 4b를 확인해보세요. MagnetoCorp의 모든 peer(peer1, peer2, peer3)는 gateway에 알림을 보냅니다. 피어들이 사용가능하고 알려지고 발견된 경우에만 계산됩니다. 중지되거나 실패한 peer들은 포함되지 않습니다.
  • EventStrategies.NETWORK_SCOPE_ANYFORTX 는 전체 네트워크 채널안에서 any peer를 listen합니다. 우리의 예에서, 4b와 4c를 확인해보세요. MagnetoCorp의 peer 1-3 또는 DigiBank의 peer 7-9 중 하나라도 gateway에 알람이 갑니다.
  • EventStrategies.NETWORK_SCOPE_ALLFORTX 는 전체 네트워크 채널의 모든 peer를 listen합니다. 우리의 예에서, 4b와 4c를 확인해보세요. MagnetoCorp와 DigiBank의 모든 peer는 gatesay에 알려야합니다. peer들이 사용가능하고 알려지고 발견된 경우에만 계산됩니다. 중지되거나 실패한 peer들은 포함되지 않습니다.
  • < PluginEventHandlerFunction > 사용자가 정의 이벤트 핸들러 이름입니다. 이것을 사용하면 사용자는 그들의 이벤트 핸들러 로직을 정의할 수 있습니다. 플러그인 이벤트 핸들러를 정의하는 방법과 예제 핸들러(github.com/hyperledger/fabric-sdk-node/blob/master/test/integration/network-e2e/sample-transaction-event-handler.js)를 살펴보세요.
    
    사용자 정의 이벤트 핸들러는 매우 구체적인 이벤트 핸들러 요구가 있는 경우에만 필요합니다. 일반적으로 기본 제공 이벤트 중 하나면 충분합니다. 사용자 정의 이벤트 핸들러의 예로는 조직의 peer 중 절반 이상이 커밋된 트랜잭션을 확인하기위해 기다리는 것입니다.
    
    만약 사용자 정의 이벤트 핸들러를 만들었다면, application 로직에 영향을 주지 않습니다. 꽤 분리되어있기 때문입니다. 핸들러는 처리중에 SDK에 의해 호출됩니다. 호출할 시기를 결정하고 결과를 이용하여 이벤트 알림에 사용할 peer를 선택합니다. SDK의 처리가 완료되면 application은 제어권를 받습니다.
    
    만약 사용자 정의 이벤트 핸들러가 만들어지지 않았다면, 기본 값은 EventStrategies가 사용됩니다.
• discovery.enabled 는 선택사항이고 true와 false값을 가지고 있습니다. 기본 값은 true입니다. 게이트웨이가 service discovery(Architecture Reference » Service Discovery)를 사용하여 connection profile에 지정된 네트워크 토폴로지를 확장하는지 아닌지를 결정합니다. 6 지점을 확인해보세요. peer들의 가십 정보는 gateway에 의해 사용됩니다.
  
  이 값은 INITIALIIZE-WITH-DISCOVERY 환경 변수에 의해 true, false로 재정의됩니다.
• discovery.asLocalhost 는 선택사항이고 true와 false값을 가지고 있습니다. 기본 값은 true입니다. service discovery 중에 발견된 IP주소가 도커 네트워크에서 로컬 호스트로 변환되는지 여부를 결정합니다.
  
  일반적으로 개발자는 peer, orderer, CA같은 그들의 네트워크 구성요소에 대해 도커 컨테이너를 사용하지만, 도커 컨테이너 자체에서 실행되지 않는 application을 작성합니다. 이게 true가 기본 값인 이유입니다. 프로덕션 환경에서 application은 네트워크 구성 요소와 동일한 방식으로 도커 컨테이너에서 실행될 가능성이 높으므로 주소 변환이 필요하지 않습니다. 이 경우 application은 명시적으로 false로 지정하거나 환경변수를 재정의하여 사용해야합니다.
  
  이 값은 DISCOVERY-AS-LOCALHOST 환경 변수에 의해 true 혹은 false로 재정의됩니다.

 

Considerations (When to use a particular connection option)

connection option을 선택하는 방법을 결정할 때 아래 고려 사항은 유용합니다.

• eventHandlerOptions.commitTimeout 과 eventHandlerOptions.strategy 는 함께 작동합니다. 예를 들어, commitTimeout: 100 과 strategy: EventStrategies.MSPID_SCOPE_ANYFORTX는 gateway가 커밋된 트랜잭션을 확인하기 위해 any peer를 100초 동안 기다릴 것이라는 의미입니다. 반면에 strategy: EventStrategies.NETWORK_SCOPE_ALLFORTX는 gateway가 모든 조직의 모든 peer를 100초동안 기다릴 것이라는 의미입니다.
• eventHandlerOptions.strategy: EventStrategies.MSPID_SCOPE_ALLFORTX의 기본값은 조직의 모든 peer가 트랜잭션을 커밋할 때까지 기다립니다. application은 모든 그들의 peer가 원장의 최신 사본을 가지고 있는지 확신하여 동시성 이슈(Architecture Reference >> Architecture Origins)를 최소화할 수 있기 때문에 좋은 기본값입니다.
  
  그러나, 조직의 peer의 수가 증가하면 모든 peer를 기다릴 필요가 없습니다. 이 경우 플러그형 이벤트 핸들러를 사용하는게 더 효율적인 전략일 수 있습니다. 예를 들어, 모든 원장이 동기화될 것이라는 안전한 가정하에 동일한 peer의 집합은 트랜잭션을 제출하거나 알람을 듣는데 사용할 수 있습니다.
• service discovery는 clientTilsIdentity을 설정해야합니다. application과 정보를 교환하는 peer는 자신이 신뢰하는 엔티티와 정보를 교환하고 있다는 확신이 필요하기 때문입니다. 만약 clientTlsIdentity가 설정되지 않은 경우, discovery와 설정 여부와 관계없이 discovery가 준수되지 않습니다.
• 비록 application은 gateway와 연결할 때 connection option을 설정할 수 있지만, 이러한 옵션은 관리자에 의해 재정의되는 것은 필수적입니다. 옵션은 시간이 지남에 따라 달라질 수 있는 네트워크 상호작용과 관련있기 때문입니다. 예를 들어, 네트워크 성능에 대한 service discovery 사용의 영향을 이해하려고 하는 관리자.
  
  좋은 접근은 gateway에 대한 연결을 구성할 때 application이 읽는 configuration 파일 내의 application 을 정의하는 것입니다.
  
  discovery 옵션은 관리자에 의해 enabled 와 asLocalHost 가 재정의되기가 자주 요구되기 때문에 편의에 의해 환경 변수 INITIALIIZE-WITH-DISCOVERY와 DISCOVERY-AS-LOCALHOST가 제공됩니다. 관리자는 applicaion의 프로덕션 런타임 환경에서 이를 설정해야합니다. 이는 대부분 도커 컨테이너일 가능성이 높습니다.

 

 

 

출처 ]

hyperledger-fabric.readthedocs.io/en/release-1.4/developapps/connectionoptions.html