Solana gRPC 성능: 공개 벤치마크 방법론

Solana 성능 수치의 가치는 그 뒤에 있는 측정 방법에 달려 있습니다. 리전, 기간, 테스트 설정이 빠진 지연 시간 수치는 검증할 수도, 비교할 수도, 재현할 수도 없습니다.

이 글에서는 Solana gRPC 스트림을 측정하는 방법을 문서화하고, 그 측정으로 얻은 수치를 공개하며, 어떤 엔드포인트(저희 엔드포인트 포함)를 대상으로든 테스트를 재현할 수 있는 전체 설정을 함께 제공합니다.

왜 방법론을 공개하나요?

지연 시간 수치 하나만으로는 테스트를 어디서 실행했는지, 무엇을 구독했는지, 어떤 커밋먼트 레벨이었는지, 어느 기간에 측정했는지 알 수 없습니다. Solana에서는 이런 세부 사항이 수치를 결정합니다. 블록은 1초 이내에 도착하고, 스트리밍 엔드포인트 간 차이는 몇 밀리초에 불과합니다. 저희는 이미 요청 벤치마크의 측정 규칙을 공개하고 있으며, 이 글은 Solana 스트리밍에 대해 같은 작업을 합니다.

요청 벤치마크는 누구나 같은 요청을 보내 직접 확인해 볼 수 있습니다. 스트림은 검증하기가 더 어렵습니다. 프로바이더가 특정 순간의 체인 활동을 빠르고, 빠짐없이, 순서대로 전달했는지 확인하려고 그 순간을 다시 재생할 수는 없습니다. 방법론이 공개되어 있으면 개발자는 특정 주체를 신뢰하는 대신 자신의 워크로드로 테스트를 다시 실행할 수 있습니다.

이 벤치마크는 무엇을 측정하나요?

스트리밍 성능은 세 가지 별개의 질문으로 나뉩니다. 데이터가 언제 도착하는지, 데이터가 모두 도착하는지, 연결이 끊기면 어떻게 되는지입니다. 이 벤치마크는 첫 번째 질문에 리전별로 답합니다.

• 네트워크 왕복 시간(p50). 러너에서 엔드포인트까지 30회 연결한 TCP 연결 시간의 중앙값입니다. 대부분 지리적 거리에 따라 결정되므로, 데이터가 오가기 전에 사용자 위치가 얼마의 비용을 만드는지 보여줍니다.
• 전달 편차(p90, p99). 느린 메시지나 최악의 경우의 메시지가 해당 실행에서 가장 빠른 전달보다 몇 밀리초 늦게 도착하는지를 나타냅니다. 시스템이 가장 나쁜 순간에 체감하는 것은 꼬리 구간입니다. 청산 모니터에게는 일반적인 업데이트가 빨랐다는 사실이 중요하지 않습니다. 정작 중요한 업데이트 하나가 늦게 도착했다면 말입니다.

두 지표 모두 리전별로 보고하며, 단일 글로벌 평균으로 보고하지 않습니다.

시계를 신뢰하지 않고 스트림의 시간을 어떻게 측정하나요?

요청의 시간을 측정하는 것은 쉽습니다. 한 머신이 요청을 보내고 응답을 받으므로, 시계 하나로 전체 왕복을 측정할 수 있습니다.

스트림에서는 이런 편리함이 사라집니다. 이벤트는 검증자에서 발생해 프로바이더의 인프라를 거쳐, 다른 데이터센터에 있는 다른 머신의 구독자 프로세스에 도착합니다. 이제 시계가 두 개 관여하며, 서로 다른 머신의 시계는 둘 다 NTP를 사용하더라도 몇 밀리초씩 어긋날 수 있습니다. 잘 운영되는 엔드포인트 간 전달 차이는 그보다 작을 수 있으므로, 단순한 타임스탬프 계산은 성능 대신 시계 오차를 측정하게 될 수 있습니다.

저희 엔드포인트는 모든 메시지에 생성 시각을 기록하고, 러너는 메시지 도착 시각에서 그 값을 뺍니다. 이 뺄셈은 두 시계를 비교하는 것이므로, 러너는 매 실행 전후로 자신의 시계를 공개 시간 서버와 대조합니다. 그래도 작은 고정 오차가 남을 수 있습니다. 각 메시지를 해당 실행에서 가장 빠른 전달 기준으로 보고하면 이 오차가 제거됩니다. 고정된 시계 오차는 모든 메시지를 같은 양만큼 이동시키므로 뺄셈에서 상쇄되기 때문입니다. 왕복 시간 열은 보정이 필요 없습니다. 러너가 각 TCP 연결을 자신의 시계로 측정하기 때문입니다.

이 수치는 검증자에서 사용자 프로세스까지의 전체 시간을 알려주지 않으며, 프로바이더 순위를 매기지도 않습니다. 순위를 매기려면 같은 머신에서 두 스트림을 비교하는 다른 테스트가 필요하며, 이는 재현 섹션에서 다룹니다.

측정의 정확성을 지키는 두 가지 세부 사항이 있습니다. 첫째, 커밋먼트 레벨은 가장 이른 확인 단계인 processed로 고정합니다. 커밋먼트 레벨을 섞으면 이벤트 생애 주기의 서로 다른 시점을 측정하게 되기 때문입니다. 둘째, 체인 자체의 블록 타임스탬프는 계산에서 완전히 제외합니다. Solana는 1초 이내에 블록을 생성하지만 블록 타임스탬프는 초 단위까지만 표시되므로, 밀리초 단위의 차이를 보기에는 너무 거칩니다.

테스트 실행은 어떻게 구성되나요?

이 글의 모든 수치는 다음과 같은 구성의 실행에서 나왔습니다. 설정이 바뀌면 기존 수치를 수정하지 않고 새 날짜로 수치를 다시 공개합니다.

• 테스트 대상 스트림: 실행당 하나의 Yellowstone 호환 gRPC 트랜잭션 스트림.
• 관찰 계정: 트랜잭션 양이 많아 선택한 Pump의 AMM 프로그램 PumpSwap, pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA.
• 커밋먼트 레벨: 모든 실행에서 processed.
• 샘플 크기: 리전당 20,000건의 트랜잭션.
• 측정 지점: 6개 클라이언트 리전(미국 동부, 미국 서부, 유럽 서부, 유럽 중부, 싱가포르, 도쿄)의 Fly 머신에서 실행되는 러너. 각 러너에서 엔드포인트까지의 왕복 시간도 결과에 포함됩니다. 커피숍에서 실행한 벤치마크는 커피숍을 측정하기 때문입니다.
• 클라이언트: geyserbench의 Rust latency 예제를 TLS를 통해 기본 클라이언트 설정으로 실행. 아래 재현 섹션에서 확인할 수 있습니다.
• 기간: 2026년 10월 14일~16일. 공개하는 모든 표에는 해당 결과를 만든 실행의 날짜가 표시됩니다.

결과는 어떤가요?

각 리전의 클라이언트에서 측정한 Solana gRPC 스트림의 전달 동작입니다. 각 행은 2026년 10월 14일~16일에 processed 커밋먼트로 단일 스트림에서 실행한 20,000건의 트랜잭션입니다.

p50 열은 러너에서 엔드포인트까지의 네트워크 왕복 시간 중앙값입니다. p90과 p99 열은 느린 메시지나 최악의 경우의 메시지가 해당 실행에서 가장 빠른 전달보다 몇 밀리초 늦게 도착하는지를 보여줍니다.

p50은 사용자 위치에 따른 거리 비용으로, p90과 p99는 전달이 얼마나 안정적인지로 읽으면 됩니다. 어느 쪽도 검증자부터의 전체 엔드투엔드 지연 시간은 아닙니다. 자신의 기대치를 가늠하는 올바른 방법은 자신의 리전에 해당하는 행을 보는 것입니다. 프랑크푸르트의 개발자라면 가장 빠르게 측정된 리전 쪽으로 치우친 글로벌 평균이 아니라 유럽 중부 행을 봐야 합니다. Solana gRPC를 출시했을 때 저희는 이 주장의 초기 버전(us-east-1에서 측정했을 때 대안 대비 평균 5~15ms 더 빠른 전달)을 공개했습니다. 이 표는 그 단일 리전, 일대일 비교 스냅샷의 멀티 리전 후속편이며, 다르면서도 상호 보완적인 지표를 사용합니다.

어떻게 재현하나요?

Rust와 Solana gRPC에 접근할 수 있는 Alchemy API 키가 필요합니다(퀵스타트에서 사전 요구 사항을 확인하세요). 명령어는 세 개입니다.

이 명령은 Solana gRPC 스트림 하나를 열고, 트랜잭션이 많은 계정에서 processed 커밋먼트로 20,000건의 트랜잭션을 관찰한 뒤, 엔드포인트까지의 네트워크 왕복 시간 중앙값과 p50, p90, p99 메시지가 가장 빠른 전달보다 몇 밀리초 늦게 도착하는지를 출력합니다. 관심 있는 리전의 서버에서 실행하고 위 표와 비교해 보세요.

저희는 Pump의 AMM 프로그램인 PumpSwap, pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA를 사용했습니다. 트랜잭션 양이 매우 많아 20,000건의 트랜잭션이 빠르게 도착하므로 적합한 선택입니다. 다른 프로그램을 관찰하거나 더 짧은 테스트를 실행하려면 ACCOUNT에 프로그램 주소를, N에 트랜잭션 수를 설정하세요.

하나의 프로바이더를 측정하는 대신 두 프로바이더를 비교하려면, 같은 머신에서 두 스트림을 실행하고 각 트랜잭션을 어느 쪽이 먼저 전달하는지 기록하세요. 공개된 geyserbench는 두 엔드포인트를 모두 나열한 단일 설정 파일로 이 작업을 수행하고, 각 엔드포인트가 트랜잭션을 먼저 감지한 빈도를 보고합니다.

이 테스트를 실행했는데 저희 수치와 상당히 다른 결과가 나온다면 알려 주세요. 그것을 확인하기 위해 방법론을 공개한 것입니다.

이 벤치마크가 측정하지 않는 것은 무엇인가요?

다음 세 가지는 의도적으로 이 벤치마크의 범위에서 제외했습니다.

• 스트림 신뢰성. 이것은 지연 시간 벤치마크입니다. 누락된 이벤트, 연결 끊김, 재연결 시간, 재연결 후 백필은 측정하지 않으므로, 이에 대해서는 긍정적으로도 부정적으로도 아무것도 말해주지 않습니다. 애플리케이션이 갭 없는 전달에 의존한다면 직접 테스트하세요. 저희 엔드포인트는 48시간의 히스토리(400,000개 이상의 슬롯)를 보관하며, 재연결하는 클라이언트는 from_slot으로 이를 리플레이할 수 있습니다.
• 트랜잭션 랜딩. 트랜잭션을 블록에 포함시키는 것은 자체 인프라와 자체 장애 모드를 가진 쓰기 경로의 문제입니다. 여기서는 이에 대해 아무것도 다루지 않습니다.
• 요청/응답 읽기. JSON-RPC 메서드를 폴링하는 것은 장애 모드가 다른 별개의 접근 패턴이며, 저희의 공개 RPC 벤치마크가 자체 공개 규칙으로 요청 트래픽을 별도로 다룹니다.

자주 묻는 질문

Alchemy의 Solana gRPC는 얼마나 빠른가요?

어디서 측정하느냐에 따라 다르며, 그래서 Alchemy는 하나의 글로벌 수치가 아니라 리전별 지연 시간 분포를 공개합니다. 위의 리전별 표는 명시된 날짜에 공개 방법론으로 산출한 네트워크 왕복 시간과 p90, p99 전달 편차를 보여줍니다. 엔드포인트까지의 네트워크 왕복 시간은 미국 동부의 1.8 ms부터 유럽 서부의 21.9 ms까지이며, p99 메시지는 리전에 따라 가장 빠른 전달 대비 6.8~23.6 ms 이내에 도착합니다.

Solana gRPC 지연 시간은 어떻게 측정하나요?

각 리전의 클라이언트가 processed 커밋먼트로 gRPC 스트림 하나를 열고, 트랜잭션 양이 많은 프로그램에서 20,000건의 트랜잭션을 관찰하며, 각 메시지의 도착 시각을 저희 엔드포인트가 메시지를 생성한 시각과 비교합니다. 결과는 리전별로 해당 실행에서 가장 빠른 전달 대비 p90, p99 지연으로 보고하며, 클라이언트에서 엔드포인트까지의 네트워크 왕복 시간 중앙값을 함께 제공합니다.

Alchemy의 Solana gRPC 벤치마크를 재현할 수 있나요?

네. 테스트는 geyserbench의 latency 예제로 실행되며, 정확한 명령어는 이 글에 공개되어 있습니다. 서비스를 제공하는 리전의 서버에서 processed 커밋먼트로 실행하고, 측정한 백분위수를 리전별 표와 비교하세요. 두 프로바이더를 비교하려면 geyserbench로 같은 머신에서 두 엔드포인트를 나란히 실행할 수도 있습니다.

벤치마크는 어떤 커밋먼트 레벨을 사용하나요?

모든 실행은 Solana의 가장 이른 커밋먼트 레벨인 processed로 구독합니다. 커밋먼트 레벨을 섞으면 생애 주기의 서로 다른 시점에서 이벤트를 측정하게 되어 백분위수가 의미를 잃습니다. 프로덕션 애플리케이션에서는 confirmed나 finalized를 선호할 수 있습니다. 이 방법론은 커밋먼트를 일정하게 유지해 리전과 실행 간에 수치를 비교할 수 있도록 합니다.

다른 프로바이더와의 비교인가요?

아니요. 이 글은 Alchemy가 자체 Solana gRPC 성능을 측정하고 공개하는 방법을 문서화한 것입니다. 다른 프로바이더도 자체 벤치마크를 공개하고 있으며, 이 분야에 공개된 방법론이 늘어나는 것은 모두에게 좋은 일입니다. 재현 섹션은 중요한 비교를 여러분의 워크로드에서 직접 실행할 수 있도록 마련한 것입니다.

Solana 데이터 스트리밍 시작하기

저희 Solana gRPC 스트리밍은 Yellowstone과 호환되므로, 기존 클라이언트를 연결하는 데는 재작성이 아니라 URL 변경만 필요합니다. 가격은 TB당 $75이며 월 최소 사용량이 없고, Yellowstone gRPC 문서에서 퀵스타트를 확인할 수 있습니다. Solana에서 개발하는 팀은 $20M Solana Fund를 통해 최대 $25k의 크레딧을 신청할 수도 있습니다. 원한다면 벤치마크부터 실행해 보세요. 그러라고 만든 것입니다.