Hyperledger Caliper Architecture

* 본 포스팅은 하이퍼레저 캘리퍼 docs를 번역한 내용으로, 번역 과정에서 잘못된 부분이 있을 수 있습니다.

상세 내용은 하단 링크를 참조 부탁드리며, 잘못된 내용에 대한 피드백은 언제든 환영합니다 : ) 

https://hyperledger.github.io/caliper/docs/2_Architecture.html

Architecture

Architecture

 

Adaptation Layer

Adaptation Layer는 기존 블록체인 시스템을 캘리퍼 프레임워크에 통합하는데 사용됩니다. 각 어댑터는 블록체인의 native SDK나 RESTful API를 사용해 'Caliper Blockchain NBIs'를 구현합니다. 하이퍼레저 패브릭 1.0과 소투스가 현재 지원되며 이더리움 및 다른 블록체인 시스템도 지원 예정입니다.

 

 

Interface & Core Layer

인터페이스 및 코어 레이어는 핵심 기능을 구현하고 상위 애플리케이션을 위한 인터페이스를 제공합니다. 네 종류의 NBI가 제공됩니다.

• Blockchain operating interfaces: 벡엔드 블록체인에 있는 스마트 컨트랙트를 배포하거나, 컨트랙트를 호출하거나, 원장의 상태를 쿼리하는 것 등의 동작을 포함합니다.
• Resource Monitor: 모니터를 시작 혹은 중지하고 CPU, 메모리, 네트워크 IO 등 벡엔드 블록체인 시스템의 리소스 사용 상태를 가져오는 작업을 포함합니다. 현재 두 종류의 모니터를 제공하며, 하나는 로컬 / 원격 도커 컨테이너의 상태를 확인하는 것이고, 또 다른 하나는 로컬 프로세스의 상태를 확인하는 것입니다. 추후에 더 많은 모니터들이 구현될 예정입니다.
• Performance Analyzer: 미리 정의된 성능 수치 (TPS, 지연, 성공률 등) 를 읽고 벤치마크 결과를 출력합니다. 주요 지표는 블록체인 NBIs를 호출하는 동안 기록됩니다. 예를 들어 생성 시간, 트랜잭션 커밋 시간, 트랜잭션 결과 등이 있습니다. 이러한 들은 결과를 생성하는 데 사용됩니다.
• Report Generator: 테스트 결과를 HTML 로 생성하는 기능을 포함합니다.

 

 

Application Layer

애플리케이션 레이어는 일반적인 블록체인 시나리오를 테스팅하는 것을 포함합니다. 각 테스트는 벡엔트 블록체인 네트워크와 테스트 인자를 정의하는 환경설정 파일을 갖고 있습니다. 이 테스트는 블록체인 시스템의 성능을 테스느하는데 사용할 수 있습니다.

기본 블록체인 엔진은 개발자들이 프레임워크를 이해하고 스스로 빠르게 테스트를 할 수 있도록 구현되어 있습니다. 벤치마크 엔진을 어떻게 사용하는지는 이후에 설명합니다. 물론, 개발자들은 프레임워크 없이 NBIs를 직접 사용해 테스트를 할 수도 있습니다.

 

 

Benchmark Engine

 

 

Configuration File

두 종류의 환경설정 파일이 사용됩니다. 하나는 벤치마크 설정 파일인데, 워크로드같은 벤치마크 인자를 정의합니다. 또 다른 하나는 블록체인 설정 파일로 SUT와 상호작용하는 것을 돕는데 필요한 정보를 정의합니다.

아래는 벤치마크 설정 파일 예입니다.

test:
  name: simple
  description: This is an example benchmark for caliper
  clients:
    type: local
    number: 5
  rounds:
  - label: open
    txNumber:
    - 5000
    - 5000
    - 5000
    rateControl:
    - type: fixed-rate
      opts: 
        tps: 100
    - type: fixed-rate
      opts:
        tps: 200
    - type: fixed-rate
      opts:
        tps: 300
    arguments:
      money: 10000
    callback: benchmark/simple/open.js
  - label: query
    txNumber:
    - 5000
    - 5000
    rateControl:
    - type: fixed-rate
      opts:
        tps: 300
    - type: fixed-rate
      opts:
        tps: 400
    callback" : benchmark/simple/query.js
monitor:
  type:
  - docker
  - process
  docker:
    name:
    - peer0.org1.example.com
    - http://192.168.1.100:2375/orderer.example.com
  process:
  - command: node
    arguments: local-client.js
    multiOutput: avg
  interval: 1

• test: 테스트 메타데이터와 지정된 워크로드에 대한 다수의 테스트 수행을 정의합니다.
  • name&description: 사람이 읽을 수 있는 형태의 벤치마크에 대한 이름 및 설명입니다. 이는 리포트 생성기가 테스트 리포트를 생성할 때 사용합니다.
  • clients: 클라이언트 타입 및 관련 인자를 정의합니다. 'type' 속성은 'local' 혹은 'zookeeper' 이어야 합니다.
    1. local: 이 경우, 로컬 프로세스가 fork되어 블록체인 클라이언트처럼 행동합니다. fork된 클라이언트 수는 'number' 속성에 정의되어야 합니다.
    2. zookeeper: 이 경우, 클라이언트는 다른 머신에 위치하며 마스터 주키퍼를 통해 태스크를 수행합니다. 주키퍼 서버 주소 및 주키퍼 클라이언트에 의해 로컬에서 실행되어 시뮬레이팅할 블록체인 클라이언트 수가 정의되어야 합니다. 주키퍼 환경설정의 예는 아래와 같습니다.
       "type" : "zookeeper",
       "zoo" : {
           "server" : "10.229.42.159:2181",
           "clientPerHost" : 5
       }
  • label: 테스트에 대한 힌트입니다. 예를 들어, 성능을 테스트하기 위해 주로 사용될 트랜잭션을 언급하기 위해 트랜잭션 이름을 라벨 이름으로 사용할 수 있습니다. 또한 이 값은 blockchain.getContext()의 컨텍스트 이름으로 사용됩니다. 예를 들어, 개발자가 다른 패브릭 채널에 대해 성능을 측정하고 싶을 때, 다른 패브릭 채널에 대해 각각 다른 라벨로 테스트를 수행할 수 있습니다.
  • txNumber: 각 테스트 차수에서 수행될 다른 트랜잭션 수를 배열로 정의합니다. 예를 들어, [5000, 400]은 총 5000개의 트랜잭션이 첫 번째 차수에서생성될 것이며 두 번째 테스트에서는 400개가 생성될 것임을 의미합니다.
  • txDuration: 각 테스트 차수에서 실행할 시간을 배열로 정의합니다. 예를 들어 [150, 400]은 두 번의 테스트가 진행될 것을 의미하며, 첫 번째는 150초동안, 두 번째는 400초 동안 수행될 것임을 의미합니다. txNumber와 함께 지정하면 txDuration 옵션이 우선 적용됩니다.
  • rateControl: 각 테스트 차수에서 벤치마크 테스트를 하는 동안 사용자가 정의한 rate control을 배열로 정의합니다. 정의하지 않을 경우 기본 값은 'fixed-rate'이며 이는 벤치마킹을 1 TPS rate로 설정합니다. 정의되었다면, rate control 메카니즘이 존재해야 하며, 어느 메시지가 보내지고, 혹은 메세지 속도 프로파일을 지정하는 데 사용할 수 있는 옵션이 제공 것입니다. 각 테스트 차수에서 txNumver나 txDuration이 정의되어 있다면 이에 대응하는 rate control item을 rateControl 배열에 갖고 있어야 합니다. 사용 가능한 속도 컨트롤러 및 사용자 정의 속도 컨트롤러에 대한 사항은 Rate Controller 섹션을 참고하세요.
  • trim: 테스트 리포트에 포함되는 warm-up 및 cool-down 단계를 제거하기 위해 클라이언트 결과에 트리밍 기능을 수행합니다. 이 기능을 지정했다면, 트림 옵션은 차수 별 측정을 고려합니다. 예를 들어 txNumber가 30으로 수행된다면 각 클라이언트로 부터 온 초기 30개의 트랜잭션과 제일 마지막 30개의 트랜잭션 결과는 결과 통계를 생성할 때 무시됩니다. txDuration이 사용된 경우, 초기 및 마지막 30초의 결과는 무시됩니다.
  • arguments: 사용자 정의 테스트 모듈로 전달되는 인자를 정의합니다.
  • callback: 이 테스트 차수에서 사용되는 사용자 정의 모듈을 정의합니다. 더 자세한 사항은 User Defined test module 섹션을 참고하세요.
• monitor: 리소스 모니터 유형과 모니터 객체, 모니터링 시간 간격을 정의합니다.
  • docker: 도커 모니터는 로컬 혹은 원격 호스트에 있는 도커 컨테이너를 모니터링하는데 사용됩니다. Docker Remote API는 원격 컨테이너의 상태를 수집하는데 사용됩니다. 예약된 컨테이너 이름이 'all'인 경우 호스트의 모든 컨테이너는 모니터링 됩니다. 위의 예제에서, 모니터가 초 당 두 개의 컨테이너 상태를 수집한다면, 하나는 로컬 컨테이너인 'peer0.org1.example.com'이고 다른 하나는 '192.168.1.100'에서 도커 리스닝 포트가 2375인 원격지 컨테이너 'orderer.example.com' 입니다.
  • process: 프로세스 모니터는 로컬 프로세스를 모니터할 때 사용됩니다. 예를 들어, 사용자는 블록체인 클라이언트를 시뮬레이팅할 때 리소스 사용량을 모니터하기 위해 이 모니터를 사용할 수 있습니다. 'command'와 'argument' 속성은 프로세스를 정의합니다. 'multiOutput' 속성은 여러 프로세스일 경우 정의합니다. 'avg'는 이 프로세스들의 리소스 사용량에 대한 평균값을 나타내며 'sum' 은 총 합계를 나타냅니다.
  • others: 구현중

 

Master

마스터는 3단계로 구성된 기본 테스트를 구현한다.

• Preparing stage: 이 단계에서, 마스터는 블록체인 환경설정 파일로 내부 블록체인 객체를 생성하고 초기화한다. 또 환경설정에 정의된 스마트 컨트랙트를 배포하고 벡엔드 블록체인 시스템의 리소스 사용량을 모니터링하기위한 모니터 객체를 시작한다.
• Testing stage: 이 단계에서, 마스터는 벤치마크 환경설정 파일에 따라 테스트를 수행하기 위해 루프를 시작한다. 작업은 정의된 워크로드에 따라 생성되고 클라이언트들에게 할당된다. 클라이언트들로부터 수집된 성능 통계는 이후 분석을 위해 저장된다.
• Reporting stage: 각 테스트 차수로부터 클라이언트들에게서 수집된 결과가 분석된다. 이는 자동으로 HTML 형태의 리포트를 생성한다. 리포트 샘플은 다음과 같다.

 

Clients

Local Clients

이 모드에서 마스터는 로컬에 실제 테스팅 작업을 수행하는 여러 개의 클라이언트(자식 프로세스)를 포크하기위해 Node.js 클러스터 모듈을 사용한다. Node.js는 기본적으로 단일쓰레드이므로, 로컬 클러스터는 멀티코어머신에서 클라이언트의 성능을 향상시키기 위해 사용될 수 있다.

전체 워크로드는 자식 프로세스들에게 동등하게 나뉘어서 할당된다. 자식 프로세스는 벡엔드 블록체인과 상호작용할 수 있는 임시로 생성된 컨텍스트를 사용해 블록체인 클라이언트처럼 행동한다. 컨텍스트는 보통 클라이언트의 신원 및 암호화 정보를 가지고 있으며 이는 테스팅 작업이 끝나면 반환된다.

• 하이퍼레저 패브릭에서 컨텍스트는 또한 특정 채널에 바인딩될 수 있다. 이 관계는 패브릭 환경설정 파일에 정의된다.

클라이언트는 사용자가 정의한 테스팅 로직을 갖고 있는 테스트 모듈을 호출한다. 모듈에 대해서는 이후에 설명한다.

로컬 클라이언트는 첫 번째 테스트 차수가 시작될 때 한 번만 시작될 수 있으며, 테스트가 모두 끝나면 삭제된다.

 

Zookeeper Clients

이 모드에서 여러 개의 주키퍼 클라이언트는 독립적으로 실행된다. 주키퍼 클라이언트는 실행된  테스팅 작업을 모니터링하기위해 스스로 등록한다. 테스트가 끝나면 성능 통계 결과를 갖고 있는 znode가 생성된다.

주키퍼 클라이언트는 또한 여러 개의 자식 프로세스 (로컬 클라이언트) 를 포크하여 위 테스팅 작업을 실질적으로 수행한다.

더 자세한 내용은 Zookeeper Client Design 섹션에서 확인할 수 있다.

 

 

User Defined Test Module

테스트 모듈은 트랜잭션을 생성하고 제출하는 함수가 구현된 것이다. 이렇게 함으로써 개발자들은 자신의 테스팅 로직을 구현할 수 있고, 이를 벤치마크 엔진에 통합할 수 있다.

세 가지 함수가 구현 및 export 되며, 모든 함수들은 약속된 객체를 반환한다.

• init: 각 테스트 차수가 시작할 때 클라이언트에 의해 호출되며, 주어진 블록체인 객체, 컨텍스트, 사용자 지정 인자를 벤치마크 환경설정 파일에서 읽어온다. 블록체인 객체 및 컨텍스트는 이후 사용을 위해 저장되어야 하며 다른 초기 작업은 여기서 실행된다.
• run: 실제로 트랜잭션이 생성 및 제출되며, 이 때 캘리퍼의 블록체인 API를 사용한다. 클라이언트는 워크로드에 따라 이 함수를 반복적으로 호출한다. 각 호출에서 하나의 트랜잭션만 제출되는 것을 추천하지만, 필수 사항은 아니다. 여러 개의 트랜잭션이 매번 제출되면 실제 워크로드는 구성된 워크로드와 다를 것이다. 함수는 비동기 방식으로 실행되어야 한다.
• end: 각 테스트 차수의 끝에 호출되며 모든 클리닝 작업은 여기서 수행된다.