Architecture
개요
캘리퍼는 여러 블록체인 플랫폼에 적용가능한 일반적 벤치마크 실행 프레임워크이다. 캘리퍼는 오늘날의 인기 있는 모니터링 및 인프라 솔루션과 쉽게 통합될 수 있도록 확장성(scalability and extensibility)있게 디자인되었다. 따라서 캘리퍼 아키텍처는 처음에는 다소 복잡해 보일 수 있다.
이 페이지는 캘리퍼 아키텍처의 복잡성을 한 단계씩 쉽게 이해하도록 하는 것을 목표로 한다. 이 페이지 마지막에서는 캘리퍼의 전반적인 개념과 API에 익숙해져야 한다. 읽어나가며 다른 보다 기술적인 문서 페이지에 대한 레퍼런스를 찾을 수 있다. 캘리퍼 기본 개념에 익숙해지고 나면 자유롭게 해당 페이지들을 탐색해 보자.
조감도
가장 단순한 형태에서, 캘리퍼는 특정한 system under test(SUT)에 대한 워크로드를 생성하고, 그 결과를 지속적으로 모니터링하는 서비스이다. 마지막으로, 캘리퍼는 관찰된 SUT 응답에 기초한 레포트를 생성한다. 이 단순화된 관념은 아래 그림에 묘사된다.
캘리퍼는 벤치마크를 구동하기 위해, 사용된 SUT와 독립적으로 몇 가지 입력을 필요로 한다. 아래 서브섹션은 이 입력들에 대한 짧은 개요를 설명한다.
벤치마크 구성 파일
벤치마크가 실행되어야 하는 방식을 설명하는 파일이다. 이것은 캘리퍼에게 얼마나 많은 라운드가 실행되어야 하는지, TX rate가 얼마나 제출되어야 하는지, 어떤 모듈이 TX 내용을 생성하는지를 말해 준다. 이 파일은 또한 SUT 모니터링에 대한 정보를 담고 있다.
이 파일을 캘리퍼의 흐름 조정자로 여길 수 있다. 대부분의 파트에서, 이 설정은 SUT와 독립적이다. 따라서 여러 SUT 타입이나 버전에 대한 여러 벤치마크를 수행할 때 쉽게 재사용할 수 있다.
참고
벤치마크 구성 파일에 대한 더 기술적인 소개는 관련 페이지를 보자.
네트워크 구성 파일
네트워크 구성 파일의 내용은 SUT 특정적이다. 이 파일은 보통 SUT 토폴로지를 설명한다. 즉, 노드가 어디 있는지 (엔드포인트 주소), 어떤 신원/클라이언트가 네트워크에 존재하는지, 그리고 어떤 스마트 컨트랙트가 캘리퍼와 상호작용할지 정한다.
네트워크 구성 파일의 정확한 스트럭처를 관련 SUT 커넥터 문서에서 볼 수 있다(커넥터에 대해 이 페이지에서도 나중에 다룰 것이다):
워크로드 모듈
워크로드 모듈은 벤치마크의 두뇌이다. 캘리퍼는 일반적인 벤치마크 프레임워크이므로, 어떤 구체적인 벤치마크 구현도 가지고 있지 않다. 캘리퍼가 주어진 라운드에 대한 TX(트랜잭션)들을 스케줄링할 때, TX 컨텐츠를 생성하고 제출하는 것은 라운드의 워크로드 모듈의 작업이다. 각 라운드는 서로 다른 관련된 워크 모듈을 가지고 있으므로, 단계/동작에 따라 워크로드 구현을 분리하는 것이 쉬워야 한다.
워크로드 모듈은 단순히 주어진 팩토리 함수를 export 해야 하는 NodeJS 모듈이다. 그 이외의 워크로드 모듈 로직은 임의적일 수 있다. Nodejs로 무엇이든 코딩해 넣을 수 있다.
참고
더 기술적인 소개는 관련 페이지를 참고하자.
벤치마크 아티팩트
서로 다른 벤치마크와 구동방식에 따라 다양한 추가적인 아티팩트가 벤치마크 구동을 위해 필요할 수 있다. 이것들은 보통 아래를 포함한다:
- SUT와 상호작용하기 위해 필수적인 암호화 자료
- 캘리퍼가 배포하기 위한 스마트 컨트랙트 소스 코드 (SUT 커넥터가 해당 기능을 지원하는 경우)
- 워크로드 모듈에 먼저 설치된 서드파티 패키지
추가적인 필수 아티팩트는 SUT 커넥터 구성 페이지를 참고하자.
참고
여기서부터는 소개된 캘리퍼 입력을 간단히 벤치마크 아티팩트로 말하고, 위 도해에서 본 데이터베이스 심볼로 표시할 것이다.
다중 플랫폼 지원
캘리퍼 아키텍처에 대해 자세히 알아보기 전에 캘리퍼가 어떻게 여러 SUT 타입들을 지원하는지 살펴보자. 캘리퍼는 서로 다른 SUT 타입 특질을 감추기 위해 커넥터 모듈을 사용하고, 캘리퍼 (와 확장) 모듈에 대한 통합된 인터페이스를 제공한다.
SUT 커넥터는 워크로드 모듈과 내부 캘리퍼 모듈에 대한 단순화된 인터페이스를 제공한다. 따라서 캘리퍼는 "커넥터/SUT 초기화" 같은 단순한 작업 실행 요청을 할 수 있고, 나머지는 커넥터 구현이 처리할 수 있다. 초기화 중 수행되는 정확한 일들은 종종 네트워크 구성 파일의 내용에 의해 (그리고 SUT가 지원하는 원격 관리 작업에 의해) 결정된다.
참고
커넥터 구성 방법에 대한 기술적으로 자세한 내용은 관련 페이지를 참고하자.
캘리퍼 프로세스
캘리퍼는 확장성(scalability)를 extensibility/flexibility와 함께 중요한 목표로 생각한다. 단일 머신으로부터의 워크로드 생성은 머신의 자원을 빨리 고갈시킨다. 워크로드 비율을 평가되는 SUT의 확장성 및 성능에 워크로드를 맞추기 위해서는(비슷한 수준으로 만들기 위해서는) 분산 접근 방식이 필요하다.
따라서, (프레임워크로서) 캘리퍼는 두 가지 다른 서비스/프로세스로 구성된다. 단일 매니저 프로세스와 다수의 워커 프로세스들이다.
- 매니저 프로세스는 (지원된다면) SUT를 초기화시키고 벤치마크 구동을 조정하고 (즉, 구성된 라운드를 스케줄링하고) 관찰된 TX 통계에 기초한 성능 보고서 생성을 통제한다.
- 워커 프로세스들은 상호독립적으로 실제 워크로드 생성을 수행한다. 한 워커 프로세스가 호스트 머신의 한계에 도달한다고 하더라도, 더 많은 워커 프로세스들 (여러 머신에 위치한)을 사용하면 캘리퍼 워크로드 비율을 크게 증가시킬 수 있다. 결론적으로 워커 프로세스는 캘리퍼 확장성의 중추이다.
설명된 설정은 아래에 도해된다.
참고
여기서는 당분간 프로세스 간 메시징과 같은 분산 아키텍처의 기술적 세부 사항을 무시할 것이다. 이후 세션에서 이 주제로 돌아올 것이다.
매니저 프로세스
캘리퍼 매니저 프로세스는 전체 벤치마크 구동을 조정한다. 이것은 아래에 묘사된 그림과 같은 사전 정의된 몇 단계를 거친다.
- 첫 단계에서 캘리퍼는 네트워크 구성 파일로부터 시작 스크립트를 (만약 존재한다면) 실행시킨다. 이 단계는 주로 로컬 캘리퍼와 SUT 배포에 유용하다. 이는 해당 단계가 한 단계에서 네트워크와 캘리퍼를 실행하는 편리한 방법을 제공하기 때문이다.
참고
SUT 배포는 캘리퍼가 담당하지 않는다. 기술적으로, 캘리퍼는 오직 이미 구동중인 SUT에 연결될 뿐이다. SUT가 시작 스크립트를 통해 시작되었다고 해도 그렇다.
- 두 번째 단계에서, 캘리퍼는 SUT를 초기화한다. 여기서 수행되는 작업은 SUT 및 SUT 커넥터의 케이퍼빌리티에 크게 의존한다(달려 있다). 예를 들어 하이퍼레저 패브릭 커넥터는 이 단계를 채널 생성/가입과 신규 사용자 기재/등록에 사용한다.
- 세 번째 단계에서, 캘리퍼는 SUT에 스마트 컨트랙트를 배포한다. SUT와 커넥터가 (하이퍼레저 패브릭 커넥터처럼) 그와 같은 조작을 지원한다면.
- 네 번째 단계에서 캘리퍼는 워커 프로세스들을 통해 구성된 라운드들을 스케줄링하고 실행시킨다. 이 단계에서 워커들을 통한 워크로드 생성이 이루어진다.
- 다섯 번째 단계에서, 라운드 실행 및 레포트 생성 후, 캘리퍼는 네트워크 구성 파일로부터 (만약 존재한다면) 클린업 스크립트를 실행시킨다. 이 단계는 주로 로컬 캘리퍼와 SUT배포에 유용하다. 이는 이것이 네트워크와 모든 임시 아티펙트를 해제하는 간편한 방법을 제공하기 때문이다.
SUT가 이미 배포되고 초기화된 경우 캘리퍼가 라운드 실행에만 필요하다. 운 좋게도, 각 단계를 실행시킬것인지 여부를 하나씩 구성할 수 있다. 자세한 내용은 플로우 컨트롤 설정을 보자.
위 그림은 벤치마크 실행의 고수준 단계만을 보여준다. 모니터와 워커 프로세스 옵저버 컴포넌트와 같은 일부 구성 요소는 단순화를 위해 생략되엇다. 이 컴포넌트들의 목적과 구성을 배우려면 모니터와 옵저버 문서 페이지를 참조하자.
워커 프로세스
(유저의 관점에서) 흥미로운 일이 워커 프로세스 내부에서 일어난다. 워커 프로세스는 매니저 프로세스가 다음 라운드 실행에 대한 정보를 워커 프로세스로 보낼 때 (앞 섹션의 4번째 단계) 주목할 만한 작업을 시작한다. 워커 프로세스의 중요한 구성요소는 아래 도표에서 볼 수 있다.
워커 프로세스는 워크로드 생성 루프에서 대부분의 시간을 보낸다. 이 루프는 중요한 두 단계로 구성되어 있다.
1. 레이트 컨트롤러가 다음 TX(트랜잭션)을 활성화하기를 기다린다. 레이트 컨트롤러를 지연 회로처럼 생각하자. 어떤 레이트 컨트롤러가 사용되느냐에 따라, 컨트롤러는 다음 TX 활성화 전에 (비동기적 방식으로) 워커 실행을 지연/정지시킨다. 예를 들어, 초당 고정된 50 TX 비율이 구성되면, 레이트 컨트롤러는 각 TX 사이에 200ms동안 정지시킨다.
참고
각 라운드의 레이트 컨트롤러는 벤치마크 구성 파일에서 구성될 수 있다. 사용가능한 레이트 컨트롤러는 레이트 컨트롤러 페이지를 보자.
- 레이트 컨트롤러가 다음 TX를 활성화시키면, 워커는 워크로드 모듈에 대한 컨트롤을 제공한다. 워크로드 모듈은 TX 매개변수들을 어셈블링하고 (SUT와 스마트 컨트랙트 API에 따라 달라진다) SUT 커넥터의 간단한 API를 호출하여 (SUT의 SDK에 사용될) TX 리퀘스트를 SUT로 전송한다.
참고
각 라운드의 워크로드 모듈은 벤치마크 구성 파일에서 구성된다. 워크로드 모듈의 기술적 디테일은 워크로드 모듈 페이지를 보자.
워크로드 루프 동안, 워크로드 프로세스는 매니저 프로세스에 진행 업데이트를 전송한다. 매니저에 보고되는 진행은 caliper-progress-reporting-enabled와 caliper-progress-reporting-interval 설정 키로 구성하고 활성화할 수 있다. 세부 내용은 기본 런타임 설정을 보자.
프로세스 분산 모델
아키텍처 논의의 마지막 부분은 워커 프로세스 관리를 이해하는 것이다. 워커 프로세스가 어떻게 시작되는지와 매니저와 워커 프로세스 간에는 어떤 메시징 방법이 사용되는지를 기반으로, 아래 분산/배포 모델이:
1. 매니저 프로세스와 프로세스 간 통신(IPC)을 사용하여 동일한 호스트에 자동으로 워커 프로세스들을 생성
2. 매니저 프로세스와 원격 메시징 메커니즘을 이용해 동일한 호스트에 자동으로 워커 프로세스들을 생성
3. 매니저 프로세스와 원격 메시징 메커니즘을 이용해 임의의 수의 호스트들에서 워커 프로세스들을 시작
하는것을 구별할 수 있다.
세번째 방법은 훨씬 복잡한 시나리오이긴 하지만, 첫 두 방법은 캘리퍼와 친숙해지고 점진적으로 세번째 방식으로 옮겨갈 수 있도록 도울 것이다.
모듈식 메시지 전송
아래 도표에서 보이는 것과 같이, 캘리퍼가 내부적으로 메시징을 처리하는 방식에 따라 다양한 배포 접근 방식이 가능하다.
내부 캘리퍼 모듈은 그 내용이 메시지 전송 방식과 독립적인, 사전 정의된 메시지만 처리한다. 프로세스 간 메시지 전송 모듈은 교환가능하므로, 다양한 커뮤니케이션 방식을 사용할 수 있다.
아래 두 설정 키로 배포 모델이 구성된다:
caliper-worker-remote:false로 설정되면(기본값), 매니저 프로세스는 필요한 수의 작업자 프로세스를 로컬로 생성한다. 위 모델 중 모델 1 또는 2가 생성된다.caliper-worker-communication-method:process(기본값) 또는mqtt를 값으로 가질 수 있다. 사용될 메시지 전송 구현을 결정한다.process통신은 첫 모델과 연관되어 있고,mqtt는 모델 2와 3을 나타낸다.
아래 표는 여러 모델을 요약하고 어떻게 모델을 선택할지 보여준다:
remote value | method value | 관련 배포 모델 |
|---|---|---|
false | process | 1. 로컬 워커와 프로세스 간 통신 |
false | mqtt | 2. 로컬 워커와 원격 메시징 기반 통신 |
true | mqtt | 3. 원격 워커와 원격 메시징 기반 통신 |
true | process | 유효하지 않음. 원격 통신에 IPC가 적용되지 않음 |
참고
메시징 전송 구성에 대한 기술적 디테일은 메신저 페이지를 보자.
프로세스 간 통신
설치 및 사용 페이지의 예시는 모두 IPC 접근 방식을 사용한다. 이것이 기본 동작이기 때문이다. 설정은 아래 도표에 그려져 있다.
caliper launch manager CLI 커맨드가 매니저 프로세스를 시작하고, 차례로 구성된 수 만큼의 워커 프로세스가 자동으로 생성된다(caliper launch worker CLI 커맨드를 사용한다). 이 프로세스 간 통신은 IPC로, 부모-자식 프로세스 관계에 사용가능한 Node.js 내장 메서드를 활용한다.
이것이 캘리퍼의 가장 단순한 배포 모델이다. 어떤 추가적인 구성이나 서드파티 메시징 컴포넌트도 요구하지 않는다. 따라서 캘리퍼를 처음 사용하거나, 여전히 프로젝트의 벤치마크 아티팩트를 조립하고 있거나, 빠른 테스트가 필요할 때 사용하는 것이 이상적이다.
아쉽게도 이 모델은 단일 호스트 사용을 강제한다. 따라서 오직 호스트의 수직 확장만 가능하다는 점에서 확장성 문제가 있다.
로컬 메시지 브로커 통신
완전 분산형 설정을 위한 디딤돌로서, 두 번째 배포 모델은 IPC를 서드파티 메시징 솔루션으로 대체한다. 여전히 사용자로부터 워커 프로세스 관리는 숨겨져 있다. 아래 도표에 해당 설정이 도해되어 있다.
전과 마찬가지로 caliper launch manager CLI 커맨드가 매니저 프로세스를 시작하고, 차례로 구성된 수 만큼의 워커 프로세스가 자동으로 생성된다(caliper launch worker CLI 커맨드를 사용한다). 하지만, 메시징은 별도의 컴포넌트를 통해 일어난다. 이 컴포넌트는 캘리퍼 프로세스가 엔드포인트에 접근할 수 있는 한 어디에나 배포할 수 있다.
아쉽게도, 이 모델은 캘리퍼 프로세스의 측면에서는 단일 호스트 제약이 있다. 하지만 이것은 유용한 모델이다. 벤치마크 아티팩트가 배치되었을 때 배포를 다음 단계로 끌어올리기에 유용하다. 메시징 컴포넌트를 성공적으로 통합하면 완전 분산형 캘리퍼 설정으로 이동할 준비가 된다.
분산 메시지 브로커 통신
워커 프로세스를 스스로 관리할 때, 캘리퍼의 잠재력이 완전히 발휘된다. 이 시점에서는 caliper launch worker CLI 커맨드를 사용해, 원하는 만큼 여러 워커를 여러 호스트에서 시작할 수 있다. 설정은 아래 도표에서 도해된다.
완전 분산형 배포는 워커 프로세스의 수평 확장을 가능하게 한다. 이는 도달가능한 워크로드 비율을 크게 증가시킨다. 많은 캘리퍼 프로세스를 쉽게 관리하기 위하여, 몇몇 자동 배포/관리 솔루션을 활용할 수 있다. 예를 들면 Docker Swarm이나 Kubernetes를 사용할 수 있다. 캘리퍼 도커 이미지의 유연성은 이러한 통합을 쉽게 해 준다.
하지만, 고려해야 할 몇가지 주의사항이 있다.
1. 필수 벤치마크 아티팩트를 캘리퍼 프로세스에 배포하는 작업은 스스로 해야 한다. 서로 다른 인프라스트럭처 솔루션이 이를 위해 서로 다른 수단을 제공하므로, 선호하는 공급 업체의 문서를 확인하자.
2. 분산 시스템에 적절한 네트워크를 설정하는 것은 언제나 어렵다. 캘리퍼 프로세스가 구성된 메시징 컴포넌트와 SUT 컴포넌트에 엑세스할 수 있는지 확인하자.
3. 단일 호스트로 여러 캘리퍼 워커 프로세스를 구동할 수 있을 것이다. 워커 분산(또는 컨테이너 관리 솔루션을 위한 리소스 요구사항 설정) 시 워커가 구성된 TX 스케줄링 정확성을 유지할 수 있을 만큼 충분한 자원을 할당받았는지 확인하자.
라이선스
The Caliper codebase is released under the Apache 2.0 license. Any documentation developed by the Caliper Project is licensed under the Creative Commons Attribution 4.0 International License. You may obtain a copy of the license, titled CC-BY-4.0, at http://creativecommons.org/licenses/by/4.0/.
