"Solana ShredStream 지연 시간이 계속 늘어나요" 원인과 해결책

ERPC에서는 Solana의 실시간 데이터 스트림을 이용하는 고객으로부터 "ShredStream 지연 시간이 점점 증가하다가 결국 멈춘다"는 문의를 자주 받습니다.

이 글에서는 이 문제가 발생하는 주요 원인을 명확히 설명하고, 애플리케이션 성능을 개선할 수 있는 구체적인 해결책을 제시하겠습니다.

현재 ShredStream은 필터링 없이 거의 모든 실시간 데이터를 전송합니다. 이 때문에 클라이언트의 처리 능력이 부족하면 데이터가 쌓이면서 지연 시간이 점차 증가합니다.

주요 원인은 다음과 같습니다.

초기 ShredStream 클라이언트는 TypeScript와 gRPC 프로토콜로 구축되었습니다. 그러나 아직 필터가 구현되지 않은 상태에서 Node.js와 같은 단일 스레드 환경을 사용하면 처리 한계에 빠르게 도달해 지연 시간이 계속 상승합니다.

동일한 머신에서 Rust 클라이언트를 사용할 경우 이러한 문제가 발생하지 않는다는 것을 확인했으며, 이를 통해 단일 스레드 처리의 한계임을 확인했습니다.

이에 대응하여, 저희는 NAPI-RS 기술을 활용해 TypeScript에서 제어권을 유지하면서도 Rust에서 멀티스레드 처리가 가능한 솔루션을 개발했습니다. 이 솔루션은 Solana Stream SDK로 알려져 있으며 오픈소스로 공개되어 있습니다.

Node.js나 TypeScript를 사용 중이시라면 이 SDK 사용을 적극 권장합니다. 최고 성능을 원하신다면 Rust와 같은 네이티브 멀티스레드 언어 사용을 고려해 보시기 바랍니다.

Solana ShredStream을 활용하는 실시간 스트림 애플리케이션은 일반적으로 4코어, 16GB RAM 서버에서 무난하게 동작합니다. 그러나 CPU 클록 속도는 매우 중요합니다. 클록 속도가 낮으면 지연 시간이 점차 증가할 수 있습니다.

수익을 극대화하려는 서버는 종종 코어 수는 많지만 클록 속도가 낮은 구세대 CPU를 사용합니다. 예를 들어 코어 수가 많은(84코어 모델 등) 4세대 AMD EPYC CPU는 일반적으로 기본 클록이 약 2.2GHz이며, 터보 부스트를 효과적으로 활용하지 못하는 경우가 많습니다. Solana 밸리데이터의 권장 최소 요구 사항이 2.8GHz인 만큼, 저희는 고객분들께도 최소 이 정도의 클록 속도를 갖춘 CPU를 채택하실 것을 강력히 권장합니다.

또한 VPS 제공업체는 일반적으로 하나의 물리 서버를 여러 가상 서버로 나누는 "오버커밋(overcommitment)" 방식을 사용합니다. 오버커밋 환경에서는 피크 시간대에 다른 사용자와의 리소스 경합이 자주 발생해 성능에 부정적인 영향을 미칩니다.

ERPC는 최대 4.15GHz의 클록 속도를 갖춘 최신 세대 AMD EPYC CPU 기반 VPS 서버를 제공합니다. 이 서버는 베어메탈 솔루션에 가까운 성능을 제공하여, Solana 실시간 데이터 스트림을 요구하는 워크로드에 완벽하게 적합합니다.

과거에는 고클록 VPS 솔루션이 없어 실시간 성능이 필요한 사용자는 베어메탈 서버를 선택할 수밖에 없었습니다. ERPC의 VPS 제품은 이러한 제약을 해소합니다.

ERPC의 VPS 솔루션은 Solana의 실시간 데이터 스트리밍에 최적화되어 있으며, 많은 고빈도 트레이더와 프로젝트로부터 높은 평가를 받고 있습니다.

이 솔루션은 베어메탈 서버만큼의 리소스는 필요하지 않지만 고성능이 필요한 고객에게 이상적입니다.

VPS 솔루션을 꼭 한번 사용해 보시길 권장드립니다.

무료 체험이나 상세 상담을 원하시면 Validators DAO 공식 Discord를 방문해 주세요.

ERPC는 여러분의 진화하는 요구사항에 부응하고 더욱 향상된 성능을 지원하기 위해 지속적인 연구 개발에 힘쓰겠습니다.

변함없는 성원에 감사드립니다.