블록체인 지연 및 처리량 이해하기

저자: Lefteris Kokoris-Kogias

출처: paradigm.xyz

편집: ETH中文

사람들은 (블록체인) 시스템을 올바르게 측정하는 방법에 대해 잘 언급하지 않지만, 이는 시스템 설계 및 평가 과정에서 가장 중요한 단계입니다. 시스템에는 여러 가지 합의 프로토콜, 다양한 성능 변수 및 확장성의 균형이 존재합니다.

그러나 지금까지 모든 사람이 동의하는 신뢰할 수 있는 방법은 없으며, 이는 사과와 사과를 비교하는 합리적인 비교를 가능하게 하지 않습니다. 본 문서에서는 데이터 센터화 시스템 측정 메커니즘에서 영감을 받은 방법을 개요하고, 블록체인 시스템을 평가할 때 피할 수 있는 몇 가지 일반적인 오류를 탐구합니다.

핵심 지표 및 상호 작용

블록체인 시스템을 개발할 때, 우리는 두 가지 중요한 지표를 고려해야 합니다: 지연 및 처리량.

사용자가 가장 걱정하는 첫 번째 사항은 거래 지연입니다. 즉, 거래를 시작하거나 지불하고 거래 유효성 정보(예: 거래 시작자가 충분한 돈을 가지고 있는지 확인)를 받는 데 걸리는 시간입니다.

전통적인 BFT 시스템(예: PBFT, Terdermint, Tusk 및 Narwhal 등)에서는 거래가 확인되면 확정되지만, 최장 체인 합의 메커니즘(예: 나카모토 합의, 솔라나/이더리움 PoS)에서는 거래가 블록에 패키징된 후 재구성될 수 있습니다. 결과적으로, 거래가 "k 개 블록 깊이"에 도달할 때까지 기다려야 하므로 지연 시간이 단일 확인 시간보다 훨씬 길어집니다.

둘째로, 시스템의 처리량은 일반적으로 시스템 설계자에게 매우 중요합니다. 이는 시스템이 단위 시간당 처리하는 총 부하로, 일반적으로 초당 거래 수(TPS)로 표현됩니다.

언뜻 보기에는 이 두 가지 핵심 지표가 완전히 반대인 것처럼 보입니다. 그러나 처리량은 초당 거래 수로 도출되고, 지연은 초 단위로 측정됩니다. 자연스럽게 우리는 처리량 = 부하/지연이라고 생각하게 됩니다.

하지만 사실은 그렇지 않습니다. 많은 시스템이 y축에 처리량 또는 지연을 표시하고 x축에 노드 수를 표시하는 그래프를 생성하는 경향이 있기 때문에 이러한 계산 방식의 구현은 불가능합니다. 반대로, 우리는 비선형 방식으로 처리량/지연 지표를 포함하는 더 나은 그래프를 생성할 수 있으며, 이는 그래프를 명확하고 읽기 쉽게 만듭니다.

경쟁이 없을 때, 지연은 일정하며 시스템의 부하를 변경하면 처리량이 변경될 수 있습니다. 이는 낮은 경쟁 상황에서 거래를 전송하는 최소 비용이 고정되어 있고 대기열 지연이 0이기 때문에 "들어오는 것은 무엇이든 바로 나갈 수 있다"는 결과를 초래합니다.

경쟁이 치열한 경우, 처리량은 일정하지만 부하를 변경하면 지연이 발생할 수 있습니다.

이는 시스템이 이미 과부하 상태에 있으며, 더 많은 부하를 추가하면 대기열이 무한히 길어지기 때문입니다. 더 이상한 것은, 지연이 실험 길이에 따라 변하는 것처럼 보이며, 이는 무한히 증가하는 대기열의 인위적인 결과입니다.

이러한 현상은 전형적인 "하키 스틱" 또는 "L자형 그래프"에서 볼 수 있으며, 이는 도착 간격의 분포에 따라 달라집니다(아래에서 논의할 것입니다). 따라서 이 문서의 핵심 요점은, 우리는 핫스팟에서 측정해야 하며, 여기서 처리량과 지연이 우리의 기준에 영향을 미치고, 엣지 영역을 측정할 필요가 없다는 것입니다. 여기서는 처리량과 지연 중 하나만 중요합니다.

측정 방법론

실험을 수행할 때, 실험자는 세 가지 주요 설계 옵션이 있습니다:

1. 오픈 루프 vs. 클로즈드 루프

현재 목표에 대한 요청 흐름을 제어하는 두 가지 주요 방법이 있습니다. 오픈 루프 시스템은 n = ∞ 클라이언트를 기반으로 모델링되며, 이 클라이언트는 비율 λ 및 도착 간격 분포(예: 포아송)에 따라 목표에 요청을 보냅니다. 클로즈드 루프 시스템은 주어진 시간 내에 완료되지 않은 요청의 수를 제한합니다. 오픈 루프 시스템과 클로즈드 루프 시스템의 차이는 특정 배포의 특성으로, 동일한 시스템이 다양한 시나리오에 배포될 수 있습니다.

예를 들어, 키-값 저장소는 오픈 루프 배포에서 수천 개의 애플리케이션 서버에 서비스를 제공하거나, 클로즈드 루프 배포에서 몇 개의 블로킹 클라이언트에만 서비스를 제공할 수 있습니다.

올바른 배포 시나리오를 테스트하는 것은 필수적입니다. 클로즈드 루프 시스템의 지연은 일반적으로 잠재적인 미완료 요청 수에 의해 제한되는 반면, 오픈 루프 시스템은 대기열이 많이 발생할 수 있으므로 지연이 더 길어질 수 있습니다. 일반적으로 블록체인 프로토콜은 임의의 수의 클라이언트가 사용할 수 있으므로, 오픈 루프 환경에서 평가하는 것이 더 정확합니다.

2. 종합 벤치마크의 도착 간격 분포

합성 작업 부하를 생성할 때, 우리는 반드시 질문해야 합니다: 시스템에 요청을 어떻게 제출할 것인가? 많은 시스템은 측정 전에 트랜잭션을 미리 로드하지만, 이는 시스템이 비정상 상태 0에서 실행되기 때문에 측정에 편향을 초래합니다. 또한, 미리 로드된 요청은 주 메모리에 이미 존재하므로 네트워크 스택을 우회합니다.

더 나은 방법은 특정 비율로 요청을 전송하는 것입니다(예: 1000 TPS). 이는 시스템의 용량이 최적으로 사용되기 때문에 L자형 그래프(주황선)가 나타나게 됩니다.

그러나 오픈 시스템은 예측 가능한 방식으로 작동하지 않는 경우가 많습니다. 반대로, 이들은 높은 부하와 낮은 부하의 시간대를 가집니다. 이를 모델링하기 위해 우리는 확률 간격 분포를 사용할 수 있으며, 이는 일반적으로 포아송 분포를 기반으로 합니다. 이는 "하키 스틱" 그래프(파란선)를 초래하며, 평균 속도가 최적 값보다 낮더라도 포아송 폭발로 인해 일부 대기 지연(최대 용량)이 발생할 수 있습니다. 그러나 이는 우리가 시스템이 높은 부하를 처리하는 방법과 부하가 정상으로 회복될 때 시스템이 얼마나 빨리 회복되는지를 볼 수 있게 해줍니다.

3. 워밍업 단계

마지막으로 고려해야 할 점은 측정을 언제 시작할 것인가입니다. 우리는 파이프라인이 시작되기 전에 트랜잭션으로 가득 차기를 원합니다. 그렇지 않으면 미리 가열 지연을 측정해야 합니다. 이상적으로는, 미리 가열 지연의 측정은 워밍업 단계에서의 지연 측정을 통해 이루어져야 하며, 측정 결과가 예상되는 분포를 따를 때까지 진행되어야 합니다.

비교하는 방법

마지막으로 해결해야 할 문제는 시스템의 다양한 배포를 합리적으로 비교하는 것입니다. 마찬가지로, 지연과 처리량이 상호 의존적이기 때문에 우리는 공정한 처리량/노드 수 그래프를 생성하기 어려울 수 있습니다.

최고의 방법은 서비스 수준 목표(SLO)를 정의하고 당시의 처리량을 측정하는 것입니다. 단순히 각 시스템을 최대 처리량으로 밀어붙이는 것(이 경우 지연은 무의미함)보다 더 나은 방법입니다. 처리량/지연 그래프에서 지연 축과 교차하는 SLO 지점에서 수평선을 그리고 교차점을 샘플링하는 것은 시각화의 좋은 방법입니다.

하지만 나는 5초의 SLO를 설정했는데, 그것은 단지 2초가 필요합니다.

누군가는 여기서 부하를 증가시켜 포화점 이후 약간 높은 가용 처리량을 활용하고 싶어할 수 있습니다. 그러나 이는 위험합니다. 시스템이 운영 구성이 부족하면, 예기치 않은 요청 폭발이 시스템을 완전히 포화 상태로 만들고 지연이 급증하여 SLO를 위반하게 됩니다. 본질적으로, 포화점 이후에 운영하는 것은 불안정한 균형을 초래합니다.

따라서 고려해야 할 두 가지 사항이 있습니다:

과도하게 구성된 시스템. 본질적으로, 시스템은 포화점 이하에서 운영되어야 하며, 도착 간격 분포의 폭발을 흡수할 수 있어야 하며, 대기 지연이 증가하지 않아야 합니다.

SLO 아래에 공간이 있다면, 배치 크기를 늘리십시오. 이는 시스템의 주요 경로에서 부하를 증가시키지만 대기 지연을 증가시키지 않으며, 더 높은 지연 균형을 얻기 위해 더 높은 처리량을 제공합니다.

나는 엄청난 부하를 발생시키고 있는데, 지연을 어떻게 측정할까요?

시스템의 부하가 매우 높을 때, 로컬 시계를 접근하고 시스템에 도착하는 각 트랜잭션에 타임스탬프를 추가하려고 하면 결과가 편향될 수 있습니다.

반대로, 두 가지 더 실행 가능한 선택이 있습니다. 첫 번째이자 가장 간단한 방법은 트랜잭션을 샘플링하는 것입니다. 예를 들어, 특정 트랜잭션에는 클라이언트가 타이머를 보관하는 트랜잭션에 마법 숫자(magic number)가 있을 수 있습니다. 제출 시간 이후, 누구나 블록체인을 확인하여 이러한 트랜잭션이 언제 제출되었는지를 확인하고 지연을 계산할 수 있습니다. 이 방법의 주요 장점은 도착 간격 분포에 간섭하지 않는다는 것입니다. 그러나 일부 트랜잭션을 수정해야 하므로 "해킹(hacky)"으로 간주될 수 있습니다.

보다 체계적인 방법은 두 개의 부하 생성기를 사용하는 것입니다. 첫 번째는 주요 부하 생성기로, 포아송 분포를 따릅니다. 두 번째 요청 생성기는 지연을 측정하는 데 사용되며, 그 부하는 훨씬 낮습니다. 시스템의 나머지 부분과 비교할 때, 이 요청 생성기는 단일 클라이언트로 간주될 수 있습니다. 시스템이 각 요청에 응답을 보내더라도(일부 시스템이 수행하는 것처럼, 예를 들어 키-값 저장소), 우리는 모든 응답을 부하 생성기로 쉽게 전송하고 요청 생성기로부터의 지연만 측정할 수 있습니다.

유일하게 까다로운 부분은 실제 도착 간격 분포가 두 개의 랜덤 변수의 합이라는 것입니다. 그러나 두 개의 포아송 분포의 합은 여전히 포아송 분포이므로 수학은 어렵지 않습니다 : )。

요약

대규모 분산 시스템을 측정하는 것은 병목 현상을 식별하고 압력 하에서의 예상 행동을 분석하는 데 매우 중요합니다. 위의 방법을 사용함으로써, 우리는 모두 공통 언어를 향한 첫 걸음을 내딛을 수 있기를 바라며, 이는 궁극적으로 블록체인 시스템이 수행하는 작업과 최종 사용자에 대한 약속에 더 적합하게 만들 것입니다.

향후 작업에서는 이 방법을 기존의 합의 메커니즘에 적용할 계획이며, 관심이 있으시면 Twitter에서 연락해 주세요!