다운타임 제로, 갭 제로: 장애에 강한 Solana gRPC 스트리밍을 구축한 방법

트레이딩 인프라, MEV 서처, 청산 봇, 실시간 인덱서를 구축하는 팀들에게 제품의 속도는 곧 데이터 공급 속도에 달려 있습니다. 스트림에 스파이크가 발생하거나 끊기면 거래를 놓치거나 인덱스가 불완전해집니다.

그래서 우리는 Solana gRPC 스트리밍 제품을 다중 노드 중복 레이어 위에 구축했습니다. 스파이크와 드롭오프가 파이프라인에 도달하기 전에 흡수되도록 해서, 관리형이어야 할 서비스 위에 페일오버 로직을 직접 구현할 필요가 없도록 했습니다. 다음은 우리가 이를 설계한 방식입니다.

Solana에서 gRPC가 중요한 이유

Solana의 데이터 출력량은 막대합니다. 피크 속도 기준 연간 4페타바이트를 넘습니다. JSON-RPC를 통한 전통적인 폴링 방식은 불필요한 오버헤드를 발생시킵니다: 반복적인 요청, 낭비되는 대역폭, 그리고 요청-응답 사이클에 내재된 지연이 그것입니다. 확정되는 즉시 모든 계정 업데이트나 트랜잭션이 필요한 워크로드에는 폴링 방식이 적합하지 않습니다.

Protobuf/HTTP2 기반의 gRPC 스트리밍은 이 모델을 뒤집습니다. 서버는 데이터가 생성되는 즉시 클라이언트로 푸시합니다. 빌더는 필요한 데이터만 정확히 구독할 수 있습니다 — 특정 계정, 프로그램, 트랜잭션 패턴 등 — 그리고 폴링 지연 없이 연속적으로 필터링된 스트림을 받습니다. 블록 타임이 1초 미만이고 데이터 양이 방대한 Solana에서, 이는 최신 데이터를 사용자에게 전달하는 것을 우선시하는 앱에 이상적인 솔루션입니다.

Yellowstone gRPC 인터페이스는 Solana 스트리밍의 사실상 표준이 되었습니다. 빌더들은 Rust, TypeScript, Go 및 .proto 파일을 컴파일할 수 있는 모든 언어로 된 기존 클라이언트 라이브러리를 보유하고 있습니다. 우리는 이 표준을 그대로 활용했기 때문에, Yellowstone 호환 프로바이더로부터의 마이그레이션은 재작성이 아니라 URL 변경만으로 가능합니다.

아키텍처: shred에서 스트림까지

우리의 스트리밍 파이프라인은 4개의 레이어로 구성되며, 각 레이어는 대규모에서도 안정적인 성능을 위해 내장된 중복성을 갖도록 설계되었습니다.

Shred 수집

Shred는 Solana에서 데이터 전파의 기본 단위입니다 — 블록 엔트리의 조각을 담은 MTU 크기의 프레임(~1,280바이트)입니다. 네트워크는 Turbine을 통해 shred를 브로드캐스트합니다. 이는 검증자들이 계층화된 이웃 구조를 통해 데이터를 릴레이하는 다중 홉 프로토콜입니다. Turbine은 빠르지만 확률적입니다. 패킷 손실은 홉을 거치며 누적되고, 트리 깊숙이 위치한 노드는 완전한 블록을 조립하기 전에 갭 복구를 위해 수백 밀리초를 기다려야 할 수 있습니다.

우리는 여러 독립적인 소스로부터 동시에 shred를 수집합니다 — 여기에는 Turbine의 다중 홉 지연을 우회하여 고지분 검증자로부터 직접 shred를 수집하는 서비스들도 포함됩니다. 각 소스는 서로 다른 지리적 경로와 검증자 이웃을 커버합니다. 한 스트림의 갭은 다른 스트림에 의해 채워지며, 이는 더 빠른 블록 조립과 더 적은 복구 사이클을 의미합니다.

이것이 중요한 이유는, 노드가 각 슬롯을 조립하기 위해서는 최소한의 shred 수가 필요하기 때문입니다. 약 250ms 내에 충분한 수를 받지 못하면, 노드는 복구 프로토콜로 폴백합니다 — 피어들로부터 누락된 shred를 요청하는 과정으로, 상당한 지연을 추가합니다. 복구가 시작되기 전에 충분한 shred를 확보하는 것이 핵심입니다. 그래서 우리는 여러 독립적인 소스로부터 수집합니다: 더 넓은 커버리지는 노드가 그 임계값에 더 빨리 도달하고, 엔트리를 더 빨리 조립하며, Geyser 알림을 더 일찍 발생시킨다는 것을 의미합니다. 여기서 절약되는 밀리초 하나하나가 하류로 이어져 파급됩니다.

Richat 엔진

우리 스트리밍 서비스의 핵심에는 Richat이 있습니다. 이는 Solana 노드에서 Geyser 플러그인으로 동작하는 오픈소스 엔진입니다. Agave 클라이언트가 생성하는 대로 계정 업데이트, 트랜잭션 알림, 슬롯 상태, 블록 메타데이터, 엔트리 업데이트를 포착한 뒤, 이를 집계 및 팬아웃 레이어 역할을 하는 Richat 서버로 스트리밍합니다.

핵심 설계 결정은 이것입니다: 각 Richat 서버는 여러 개의 업스트림 Solana 노드에 동시에 연결됩니다. 여러 소스 간의 업데이트를 중복 제거하고, 다운스트림으로 가장 빠른 정상 결과를 전달합니다. 하나의 업스트림 노드가 특정 슬롯에서 뒤처지면, 집계 레이어는 다음으로 빠른 노드로부터 데이터를 제공합니다.

이것이 바로 우리에게 지연 스파이크 감쇠를 가능하게 하는 부분입니다. 단일 노드 배포는 p99와 p999 지연에서 긴 꼬리를 가집니다. 업스트림 노드의 모든 나쁜 순간이 그대로 모든 소비자에게 전달되기 때문입니다. 다중 노드 집계는 이 꼬리를 평탄화합니다 — 빌더의 스트림은 항상 그 순간 가장 성능이 좋은 노드를 반영하며, 단 하나의 노드에 의존하지 않습니다.

빌더의 스트림

빌더는 표준 Yellowstone 클라이언트 라이브러리로 연결합니다. 연결되면 계정 업데이트(프로그램, 소유자, 데이터 슬라이스 필터 포함), 트랜잭션 업데이트(계정 포함/제외 및 서명 필터 포함), 슬롯, 블록, 블록 메타, 엔트리 업데이트를 구독할 수 있습니다. 커밋먼트 레벨(processed, confirmed, finalized), Zstd 압축, 서버 측 킵얼라이브가 모두 네이티브로 지원됩니다.

단일 연결에서 AND/OR 시맨틱으로 여러 개의 동시 구독을 구성할 수 있습니다. 양방향 스트리밍을 통해 빌더는 재연결 없이 구독하고, 수정하고, 취소할 수 있습니다.

재연결 시 재생

짧은 연결 끊김이나 클라이언트 재시작은 피할 수 없는 일입니다. 문제는 그것이 빌더에게 데이터 손실을 초래하느냐입니다.

우리는 Richat의 링 버퍼에 최근 업데이트의 롤링 윈도우를 저장합니다. 클라이언트가 재연결하면, from_slot 파라미터로 구독하여 라이브 스트림을 다시 받기 전에 놓친 모든 데이터를 백필할 수 있습니다. 별도의 백필 파이프라인이 필요 없습니다. 유지해야 할 갭 감지 로직도 없습니다. 소비자와 함께 실행되어야 할 별도의 조정 서비스도 필요 없습니다.

이는 장시간에 걸쳐 갭 없는 스트림이 필요한 빌더들 — 인덱서, 분석 플랫폼, 업데이트를 놓치면 안 되는 상태 기반 소비자를 운영하는 모든 사람 — 에게 더 단순한 운영 모델을 제공합니다.

다음 단계

현재 아키텍처는 종착점이 아니라 출발점입니다. 우리는 다음 사항들을 지속적으로 개발하고 있습니다:

확장된 재생 윈도우. 더 긴 복구 커버리지가 필요한 빌더를 위해 재연결 백필 윈도우를 대폭 확대합니다.

하드웨어 및 네트워크 최적화. 크리티컬 패스 전반의 지연을 줄이기 위한 지속적인 인프라 개선.

추가 리전. 더 많은 빌더와 더 많은 검증자에게 스트림을 더 가깝게 제공하기 위한 커버리지 확대.

전용 배포. 공동 배치와 격리가 선택이 아니라 필수 요건인 소수의 팀을 위한 전용 배포.

시작하기

Alchemy Solana gRPC는 오늘부터 모든 유료 플랜에서 이용 가능하며, TB당 $75부터 시작하고 플랜 제한이나 월 최소 사용량 조건이 없습니다. 이미 Yellowstone 클라이언트를 운영 중이라면, 마이그레이션은 URL 변경만으로 끝납니다.

• 문서 읽기
• 팀에 문의하기
• $20M Solana Fund에 지원하기 — Solana에서 앱을 가속화할 수 있도록 최대 $25k 크레딧 제공.