워크플로에 맞게 RPC 제공업체를 벤치마크하는 방법

RPC 제공업체는 자신의 워크로드에 맞춘 벤치마크를 근거로 골라야 한다. 우리는 우리 자신을 포함해 제공업체를 꾸준히 벤치마크하고, 많은 팀이 같은 일을 하는 것도 봐 왔다. 요청을 보내는 것은 쉬운 부분이다. 어려운 부분은 무엇을 측정할지 정하고, 실제로 의사결정을 걸 수 있는 결과를 내는 테스트를 만드는 것이다.

그래서 우리는 방법론을 글로 정리했고, 그것을 실행하는 Alchemy rpcbench를 만들었다. 앱이 실제로 호출하는 메서드로, 자신의 머신에서 임의의 RPC 제공업체 집합을 벤치마크하는 단일 바이너리다. 방법론 자체는 이미 쓰고 있는 어떤 도구로도 적용할 수 있다.

측정할 가치가 있는 것은 세 가지다. 부하 상태의 지연, 블록 지연, 데이터 일관성이다. 각각 시스템의 다른 부분을 망가뜨리고, 한 가지에 강한 제공업체가 다른 한 가지에서는 뒤처질 수 있으므로, 혼합 점수는 당신에게 중요한 하나를 묻어 버린다. 앱이 실제로 호출하는 것을, 앱이 실행되는 곳에서 측정하라.

RPC 제공업체를 벤치마크할 때 무엇을 측정해야 하는가?

부하 상태의 지연, 블록 지연, 데이터 일관성을 각각 따로 측정하고 따로 보고한다.

데이터 일관성은 대부분의 팀이 한 번도 테스트하지 않는 항목이다. 어떤 제공업체는 메서드마다 다른 백엔드에서 응답하고, 그 백엔드들이 항상 함께 진행되지는 않는다. 그래서 제공업체가 새 헤드를 알리는 동안 같은 블록의 로그는 불완전하게 돌아올 수 있다. 책이 서가에 꽂히기 전에 목록부터 갱신하는 도서관을 떠올리면 된다. 목록에는 신간이 들어왔다고 나오지만, 서가는 비어 있다.

이 중 무엇을 먼저 측정해야 하는가?

앱이 데이터로 하는 일에 맞는 것부터 시작한다. 새 블록에 반응해 행동한다면 블록 지연이다. 블록이 도착하는 순간 그 블록의 로그나 상태를 읽는다면 데이터 일관성이다. 그 외에는 부하 상태의 지연이다. Valantis, Aave, RedStone, Struct 같은 팀이 각자 다른 것을 측정하는 벤치마크를 돌리는 것을 봐 왔다.

그런 다음 제공업체를 메서드 하나씩 비교한다. 평균적으로 더 빠른 제공업체도 앱이 가장 많이 보내는 단일 호출에서는 더 느릴 수 있기 때문이다. 그 차이가 전부다. 스프레드가 닫힌 뒤 도착한 견적은 느린 견적이 아니다. 놓친 체결이다.

신뢰할 수 있는 RPC 벤치마크는 어떻게 실행하는가?

지연을 측정하려면 고정된 일정으로 요청을 보낸다. 흔한 설계는 요청을 보내고, 응답을 기다린 뒤, 다음 요청을 보내는 방식인데, 이렇게 하면 제공업체가 버거워지기 시작하는 바로 그때 조용히 요청을 덜 보내게 된다. 테스트가 버텨야 할 순간에 오히려 힘을 빼는 셈이라, 찾으려던 성능 저하가 데이터에 나타나지 않는다. 대신 고정된 클록에 맞춰 보내고, 각 전송이 그 클록보다 얼마나 밀렸는지 추적한다. 자신의 머신이 뒤처지면, 그 숫자는 머신을 설명하는 것이다.

실행 준비

실행

블록 지연은 예외다. "누가 이 블록을 먼저 알렸는가"는 모든 제공업체를 같은 순간에 지켜볼 때만 의미가 있고, 블록당 작은 메시지 하나이므로 대역폭을 두고 경쟁할 일이 없다.

결과 읽기

Alchemy rpcbench란 무엇인가?

Alchemy rpcbench는 위의 방법론 전체를 자신의 머신에서, 자신의 키로 실행하는 단일 바이너리다. 요청은 설정 파일에 있는 엔드포인트로만 보내고, 생성된 HTML 보고서는 사용자에게 직접 전달된다.

우리가 이것을 만든 이유는 방법론을 글로 쓰는 것이 쉬운 절반이기 때문이다. 위의 규칙 하나하나를 제대로 구현하는 데 며칠이 걸리고, 대부분은 잘못 구현해도 드러나지 않는다. 측정 도구로서는 최악의 조합이다.

기본값은 출발점일 뿐이다. workload: 섹션으로 자신의 파라미터와 메서드를 넣을 수 있다.

요청률 단계, 실행 시간, 타임아웃, 블록 지연 측정 구간도 마찬가지로 설정할 수 있고, 사전 점검 단계에서 부하가 머신을 떠나기 전에 실행 비용을 요청 수, 시간, 대역폭으로 산정한다. 이 비용은 Alchemy 컴퓨트 유닛 기준이므로, 규모를 가늠하는 용도로 읽으면 된다.

모든 실행은 JSON 파일, CSV 집계, 독립 실행형 HTML 대시보드를 생성한다. 근거를 댈 수 없는 숫자는 내놓지 않는다. 부족한 샘플, 스로틀링된 제공업체, 뒤처진 머신은 모두 상단에 표시된다.

검증을 통과한 실행은 다음 네 가지를 이 순서대로 제공한다.

이 방법론이 알려 주지 않는 것

• 한 리전의 결과는 다른 리전에 대해 아무것도 말해 주지 않는다. 시스템이 다른 곳에서 실행된다면, 그곳에서 실행하라.
• 블록 지연은 실제 체인 팁이 아니라 테스트한 제공업체 중 가장 빠른 곳을 기준으로 한 상대값이다.
• 메서드는 하나씩 실행되므로, 실행 결과가 실제 트래픽 구성을 재현하지는 않는다.
• 한 번의 실행은 데이터 포인트 하나다. 체인 전반의 문제를 포함해 측정값에 영향을 주는 요인이 많으므로, 성능에 대한 확실한 신호를 얻으려면 여러 번 실행할 것을 강력히 권장한다.
• Alchemy rpcbench는 EVM 네트워크 전용이며, 실행당 하나의 네트워크를 지원한다.

Alchemy rpcbench는 어떻게 이용할 수 있는가?

Alchemy rpcbench는 비공개 알파 단계다. 이 양식을 작성해 이용을 신청하라!

이미 가진 도구로 직접 만들고 싶다면, 위의 방법론이 전부다. 어느 쪽이든 좋다. 최종적으로 판단의 근거가 되는 숫자가 당신이 직접 만든 숫자이기만 하면 된다.

자주 묻는 질문

RPC 제공업체는 어떻게 비교해야 하는가?

시스템이 실행되는 리전에서, 시스템이 실제로 호출하는 메서드로, 모든 제공업체에 같은 워크로드를 실행한다. 고정된 일정으로 보내고, 제공업체를 하나씩 테스트하며, 블록 하나를 고정해 모두가 같은 질문에 답하게 한다. 결과는 메서드별로, 모든 지연 수치 옆에 실패 및 요청 한도 초과 건수를 두고 읽은 뒤, 다른 시간대에 반복한다. 직접 만들고 싶지 않다면 Alchemy rpcbench 이용을 위해 문의하라.

RPC 지연, 블록 지연, 데이터 일관성은 어떻게 다른가?

지연은 보낸 요청에 제공업체가 응답하는 데 걸리는 시간이다. 블록 지연은 새 블록이 생겼다고 알려 주는 데 걸리는 시간이다. 데이터 일관성은 그렇게 알린 순간 그 블록의 로그, 영수증, 트랜잭션을 제공할 수 있는지 여부다. 제공업체는 세 가지 모두에 강할 수도 있고, 하나에 강하고 다른 하나에 뒤처질 수도 있다. 그래서 이 셋은 별도의 열에 두어야 한다.

제공업체가 만든 벤치마크 도구의 결과를 믿을 수 있는가?

그렇다. 그리고 우리 말을 그대로 믿을 필요도 없다. Alchemy rpcbench에는 상대하는 제공업체에 따라 분기하는 코드 경로가 없으므로, 제공업체별 타임아웃이나 재시도가 숨을 곳이 없다. README에 있는 감사 프롬프트로 아무 코딩 에이전트에게 클론한 저장소를 확인시키면 대신 검사해 준다. 도구는 자신의 머신에서, 자신의 키로 실행되며, 결과는 출력 폴더를 벗어나지 않는다.

단일 종합 성능 점수로 RPC 제공업체를 골라야 하는가?

아니다. 종합 점수는 가중치를 대신 정해 버리는데, 올바른 가중치는 애플리케이션에 따라 달라진다. 이력을 백필하는 인덱서와 블록과 경주하는 차익거래 봇이 제공업체에 요구하는 것은 거의 겹치지 않는다. 구축하는 것에 맞는 항목을 읽고, 그다음 메서드별로 읽어라.

RPC 벤치마크는 어디에서 실행해야 하는가?

애플리케이션이 실행되는 리전에서 실행한다. RPC 지연은 클라이언트와 제공업체 사이의 네트워크 경로에 크게 좌우되므로, 노트북이나 배포하지 않는 클라우드 리전에서 실행한 벤치마크는 프로덕션 트래픽이 지나가지 않는 경로를 측정하게 된다.

RPC 벤치마크를 실행하는 데 얼마나 걸리는가?

실행 시간은 테스트 설정에 따라 다르지만, 기본 설정으로는 약 두 시간이 걸린다. 테스트를 설정하고 실행을 시작하는 데는 10분이 채 걸리지 않는다. Alchemy rpcbench에 포함된 설정은 Ethereum에서 제공업체당 280,000건의 요청을 7개 메서드와 3개 요청률 단계에 걸쳐 약 48분 동안 보내고, 블록 지연 측정 구간이 한 시간을 더한다. 제공업체는 차례로 실행되므로, 지연 측정 단계는 테스트하는 제공업체 수에 비례해 길어진다. 신뢰도에는 샘플이 필요하므로 오후 한나절을 잡아 두라.

RPC 제공업체를 벤치마크하려면 WebSocket 엔드포인트가 필요한가?

지연 측정에는 필요 없다. 블록 지연과 데이터 일관성에는 필요하다. 둘 다 eth_subscribe와 newHeads 구독에 의존하기 때문이다. 블록 지연은 각 블록을 누가 먼저 알렸는지 측정하므로, 제공업체도 최소 두 곳이 필요하다.

어떤 RPC 제공업체를 테스트할 수 있는가?

테스트하는 체인에 EVM JSON-RPC 엔드포인트를 가진 제공업체라면 어디든 가능하다. URL과 키는 사용자가 제공하며, 방법론이나 도구의 어떤 부분도 제공업체가 누구인지에 의존하지 않는다.

Alchemy는 자체 RPC 벤치마크를 공개하는가?

그렇다. 우리의 벤치마크 페이지에는 지금 바로 읽을 수 있는 제공업체 비교가 지속적으로 게시된다. Alchemy rpcbench는 자신의 애플리케이션 워크로드로, 애플리케이션이 실행되는 리전에서 직접 결과를 만들기 위한 도구다.