Solana 노드: 밸리데이터, RPC 노드, 셀프 호스팅

잔액을 조회하는 지갑, 2년 전 트랜잭션을 가져오는 익스플로러, 계정 업데이트를 소비하는 트레이딩 시스템은 겉보기에는 동일한 Solana 서비스를 사용하는 것처럼 보일 수 있다. 하지만 내부적으로는 서로 다른 인프라에 의존한다.

애플리케이션 팀 입장에서 중요한 질문은 단순히 "Solana 노드를 직접 운영해야 하는가?"가 아니다. "애플리케이션에 어떤 워크로드가 필요하고, 스택의 어느 부분을 직접 운영해야 하는가?"이다.

Solana 인프라의 세 가지 계층은 무엇인가?

Solana 위에서 구축할 때, 모두 Solana 노드에서 파생되는 3가지 유형의 인프라가 있다. 그렇다면 Solana 노드란 무엇인가? 간단히 말해, Solana 노드는 validator 클라이언트 소프트웨어를 실행하는 서버다.

투표 validator는 체인을 보호하고 생성하며, 투표하지 않는 remote procedure call(RPC) 노드는 실시간 상태와 트랜잭션 API를 노출한다. 별도의 아카이브, 인덱싱, 캐싱, 스트리밍 시스템은 표준 노드가 자체적으로 효율적으로 보관하거나 응답할 수 없는 워크로드를 처리한다.

투표 validator가 체인을 보호한다

투표 validator는 합의(consensus)에 참여하며 네트워크가 정규 체인에 합의하도록 돕는다. 또한 리더로 선택되었을 때 블록을 생성한다. 이들의 주된 책임은 동기화 상태를 유지하고, 정확하게 투표하며, 리더 역할을 안정적으로 수행하는 것이다.

애플리케이션은 이 합의에 의존하지만, 대부분의 애플리케이션 요청은 투표 validator에 직접 전송되지 않는다.

RPC 노드가 실시간 애플리케이션 트래픽을 처리한다

RPC 노드는 보통 동일한 validator 클라이언트 소프트웨어를 투표 없이 실행한다. 클러스터를 따라가며 블록을 리플레이하고 현재 계정 상태를 유지하지만, 투표하거나 리더 스케줄에 진입하지 않는다.

대신 Solana의 RPC 인터페이스를 노출한다. 지갑, 거래소, 익스플로러, 봇 등의 애플리케이션은 이 인터페이스를 사용해 체인 데이터를 조회하고, 트랜잭션을 시뮬레이션하고, 트랜잭션을 제출한다.

투표 validator도 기술적으로는 RPC를 노출할 수 있다. 프로덕션 환경에서 운영자는 보통 예측 불가능한 애플리케이션 트래픽이 합의와 블록 생성을 방해하지 않도록 이 인터페이스를 비공개로 두거나 제한한다.

보조 시스템이 특화된 데이터 워크로드를 처리한다

RPC 노드는 Solana의 API를 노출하지만, 프로바이더가 모든 요청에 대해 반드시 실시간 노드에서 직접 응답할 필요는 없다. 다음을 위해 구축된 시스템을 사용할 수 있다:

• 장기 트랜잭션 및 블록 히스토리
• 계정 인덱싱 및 비용이 큰 필터링된 쿼리
• 자주 요청되는 데이터의 캐싱
• 필터링, 버퍼링, 리플레이, 복구 기능을 갖춘 실시간 스트림

이러한 시스템이 처리하는 표준 RPC 메서드의 경우, 애플리케이션은 동일한 API 메서드, 파라미터, 필터, 응답 형식을 계속 사용할 수 있다. 요청에 응답하는 시스템만 달라질 뿐이다. 오래된 히스토리는 실시간 노드에 더 이상 존재하지 않기 때문에 별도의 스토리지에서 제공되며, 비용이 큰 현재 상태 쿼리는 전용 인덱스나 캐시에서 더 효율적으로 처리될 수 있다.

각 Solana 워크로드는 어느 인프라 계층이 처리하는가?

몇 가지 일반적인 애플리케이션 요청을 살펴보자:

• 지갑이 잔액을 확인하거나 트랜잭션을 시뮬레이션한다. 실시간 RPC 노드가 현재 상태에서 직접 응답할 수 있다.
• 익스플로러가 2년 전 트랜잭션을 불러온다. 애플리케이션은 여전히 표준 RPC 메서드를 호출하지만, 실시간 노드에 더 이상 해당 데이터가 없기 때문에 프로바이더는 아카이브 스토리지에서 응답한다.
• 포트폴리오 앱이 대형 프로그램이 소유한 모든 계정을 조회한다. 노드가 상태를 반복적으로 스캔하는 대신, 동일한 RPC 메서드와 필터를 계정 인덱스나 캐시에서 처리할 수 있다.
• 트레이딩 시스템이 발생하는 즉시 모든 계정 또는 트랜잭션 업데이트를 필요로 한다. 지속적인 전달을 위해 스트리밍 인프라를 사용하며, 종종 시점 조회를 위한 RPC와 함께 사용한다.
• 네트워크 운영자가 투표하고 블록을 생성하려 한다. 이는 애플리케이션 RPC 서비스가 아니라 투표 validator가 필요한 경우다.

프로바이더는 이러한 기능 여러 개를 하나의 서비스로 노출할 수 있다. 애플리케이션은 익숙한 인터페이스를 보지만, 그 뒤에서는 서로 다른 시스템이 작업을 처리한다.

Solana 노드는 과거 데이터를 어떻게 제공하는가?

getTransaction, getBlock, getSignaturesForAddress 같은 메서드는 오래된 활동을 조회할 수 있다. 하지만 표준 RPC 노드는 로컬에 제한된 레저 윈도우만 보관한다. 오래된 데이터가 정리(pruning)되고 나면, CPU를 더 추가해도 쿼리가 동작하지 않는다. 해당 데이터가 그 노드에 더 이상 존재하지 않기 때문이다.

심층적인 Solana 아카이브 데이터는 다음을 수행하는 별도의 경로가 필요하다:

1. 실시간 및 과거 소스에서 블록과 트랜잭션을 수집
2. 누락된 데이터를 감지하고 복구
3. 장기 보관과 높은 쿼리 볼륨을 위해 데이터를 저장
4. 해당 스토리지 계층에서 과거 RPC 요청에 응답

이것이 "archive RPC"가 단순히 디스크가 더 큰 일반 노드가 아닌 이유다. 프로덕션 규모에서 프로바이더는 일반적으로 별도의 스토리지 및 쿼리 시스템에서 archive RPC를 제공하며, 이를 익숙한 RPC 인터페이스로 노출한다.

Alchemy에서는 이 제약을 직접 경험했다. 처음에는 Solana 히스토리에 Google Bigtable을 사용했고, 이후 자체 호스팅 HBase 기반으로 아카이브 스택을 재구축했다. 오늘날 각 레코드는 두 번 기록되고, 프로그래밍적으로 검증되며, 완전성을 위해 스캔된다. 시스템이 누락을 발견하면 누락된 항목을 다시 수집한다. getTransaction, getSignaturesForAddress 같은 과거 데이터 조회 메서드는 이제 실시간 RPC 플릿의 로컬 보관에 의존하지 않고 이 최적화된 데이터 계층에서 읽음으로써, 고객이 기대하는 속도와 신뢰성을 제공한다.

getProgramAccounts는 왜 비용이 큰가?

getProgramAccounts은 다른 종류의 한계를 보여준다. 계정 데이터는 현재 상태에 존재하지만, 요청에 응답하려면 방대한 계정 집합을 검색하고 쿼리 시점에 필터를 적용해야 할 수 있다.

노드는 주로 블록을 리플레이하고 현재 체인 상태를 유지하기 위해 계정을 저장한다. 범용 분석 데이터베이스가 아니다. 가끔씩 직접 스캔하는 것은 괜찮을 수 있지만, 프로덕션 트래픽 아래에서 수백만 개의 계정을 반복적으로 스캔하는 것은 느려지고 리소스를 많이 소모하게 된다.

지속적인 워크로드의 경우, 운영자는 계정 업데이트를 계속 소비하면서 쿼리에 적합한 인덱스나 캐시된 뷰를 유지할 수 있다. 그러면 요청은 매번 전체 스캔을 반복하는 대신 준비된 결과를 읽는다.

반복되는 getProgramAccounts 요청은 더 큰 노드가 필요한 문제가 아니라 인덱싱 문제다. 다르게 표현하면, 구분 기준은 "작은 노드 대 큰 노드"가 아니다. 실시간 노드 데이터 서빙과 인덱싱된 데이터 서빙의 차이다.

Geyser와 gRPC 스트리밍은 어떻게 동작하는가?

트레이딩 시스템, 인덱서, 그 밖의 실시간 애플리케이션은 종종 계정, 트랜잭션, 슬롯, 블록 업데이트를 발생하는 즉시 처리해야 한다.

WebSocket 구독은 Solana의 표준 인터페이스의 일부이며 선택된 실시간 이벤트에 잘 작동한다. 더 낮은 지연 시간, 더 높은 처리량, 더 풍부한 필터링이 필요한 워크로드의 경우, Yellowstone gRPC는 HTTP/2 위에 구축된 gRPC를 기반으로 더 높은 성능의 스트리밍 인터페이스를 제공한다.

Agave validator 클라이언트는 투표하지 않는 RPC 노드로 실행될 때를 포함해 Geyser 플러그인을 실행할 수도 있다. Geyser는 노드가 체인을 처리하면서 계정, 트랜잭션, 슬롯, 블록 업데이트를 방출한다. 프로바이더는 Yellowstone 호환 Solana gRPC를 통해 이 데이터를 노출하며, 필터링, 버퍼링, 리플레이, 신뢰성, 다중 노드 전달을 추가할 수 있다.

스트리밍은 RPC를 대체하지 않는다. RPC는 상태에 대한 질문에 답한다. 스트리밍은 상태가 변경되었음을 애플리케이션에 알린다. 많은 프로덕션 시스템이 둘 다 사용한다.

Solana 인프라를 언제 직접 호스팅해야 하는가?

대부분의 애플리케이션 팀은 프로바이더로 시작해야 한다. 자체 호스팅 RPC 노드 하나로는 필요한 모든 사용 사례(내구성 있는 히스토리, 인덱싱된 쿼리, 전 세계에 복제된 API, 데이터 스트림 제공)를 자동으로 충족할 수 없으며, 이를 안정적으로 해내는 것은 많은 작업을 필요로 한다.

인프라에 대한 통제가 제품을 개선하거나 정책 요구사항 때문에 관리형 서비스가 배제되는 경우 직접 호스팅이 타당하다. 예시는 다음과 같다:

• 합의에 참여하는 validator 운영자
• 특정 노드 배치나 트랜잭션 라우팅 제어가 필요한 지연 시간에 민감한 트레이딩 시스템
• 커스텀 Geyser 플러그인, 인덱스, 보관 정책이 필요한 서비스
• 엄격한 컴플라이언스 또는 인프라 통제 요구사항이 있는 조직
• 지속적인 트래픽이 전담 인프라 팀을 정당화할 만큼 큰 플랫폼

핵심 기준은 인프라를 소유하는 것이 하드웨어, 엔지니어링, 온콜 작업의 부담을 능가할 만큼 측정 가능한 이점을 만드는지 여부다.

Solana 인프라를 운영하려면 무엇이 필요한가?

현재 Agave 하드웨어 가이드라인은 프로덕션 트래픽, 이중화, 인접 데이터 시스템을 고려하기도 전에 이미 높은 출발점을 요구한다.

하드웨어는 최소 조건에 불과하다. 현재 Solana의 합의 시스템 아래에서, 투표 validator는 투표 트랜잭션에 하루 최대 약 1.1 SOL을 지출할 수도 있다. 프로덕션 RPC 서비스는 단일 장애점을 피하기 위해 이중화된 노드가 필요하다. 자체 호스팅하며 심층 히스토리, 인덱스, 신뢰성 있는 스트림이 필요한 팀은 이러한 시스템도 함께 운영해야 한다.

Solana 노드는 어떻게 운영하는가?

설정은 명령줄이 아니라 역할에서 시작한다.

1. 워크로드를 선택한다. 배포가 투표할지, RPC를 제공할지, 특화된 데이터 파이프라인에 데이터를 공급할지 결정한다.
2. 호스트를 프로비저닝한다. 현재 CPU, 메모리, 스토리지, 대역폭, 운영체제, 퍼블릭 IP 요구사항을 클라이언트와 역할에 맞춘다.
3. 역할을 설정한다. RPC 운영자는 투표 없이 실행하며 필요한 히스토리, 계정 인덱스, 보관 설정을 선택한다. validator 운영자는 자신의 identity와 vote account를 설정한다.
4. 키와 엔드포인트를 보호한다. 민감한 키는 validator 호스트에 두지 않는다. 퍼블릭 RPC와 WebSocket 엔드포인트는 인증, 속도 제한, 로드 밸런싱 뒤에 둔다.
5. 전체 서비스를 운영한다. 동기화, 디스크, CPU, 네트워크, 프로세스 상태, 애플리케이션 수준 오류를 모니터링한다. 업그레이드, 복구, 페일오버, 남용 대응을 계획한다.

현재 validator 명령어 및 플래그 또는 RPC 노드 설정에 대해서는 유지관리되는 Agave 가이드를 사용하라.

Solana 인프라 프로바이더는 어떻게 평가해야 하는가?

애플리케이션에 필요한 워크로드부터 시작한 다음, 프로바이더가 각각을 어떻게 처리하는지 확인하라.

애플리케이션이 사용할 메서드, 구독, 리전을 벤치마크하라. Solana RPC 프로바이더 가이드는 이러한 기준에 따라 현재 옵션을 비교한다.

핵심 요약

Solana 애플리케이션은 추상적인 의미의 "노드"가 필요한 것이 아니다. 실시간 상태, 트랜잭션 API, 히스토리, 인덱싱된 쿼리, 스트림, 혹은 훨씬 드문 경우에는 합의 참여와 같은 구체적인 기능이 필요하다.

먼저 이러한 워크로드를 파악하라. 그런 다음 스택의 어느 부분을 내부에서 운영할 때 실질적인 이점이 있고, 어느 부분을 관리형 서비스에서 조달하는 것이 더 나은지 결정하라.

Alchemy로 Solana 위에서 구축하기

대부분의 애플리케이션 팀은 자체 RPC 플릿, 아카이브 데이터베이스, 인덱스, 스트리밍 인프라를 운영할 필요가 없다. 우리는 상태와 트랜잭션을 위한 실시간 Solana RPC, 표준 메서드를 통한 제네시스부터의 블록 및 트랜잭션 히스토리, 실시간 스트림을 위한 Yellowstone 호환 gRPC를 제공한다.

Solana 위에서 구축 시작하기, Solana API 퀵스타트를 따라 하거나, 전담 용량과 커스텀 워크로드에 대해 저희 팀과 상담하기를 진행하라.

자주 묻는 질문

Solana 노드란 무엇인가?

Solana 노드는 validator 클라이언트 소프트웨어를 실행하는 서버다. 클러스터를 따라가며 블록을 리플레이하고, 현재 체인 상태를 유지하며, 피어와 통신한다. 투표 validator는 합의와 블록 생성에 참여한다. 투표하지 않는 RPC 노드는 애플리케이션 API를 노출한다.

validator와 RPC 노드의 차이는 무엇인가?

둘 다 체인을 따라가며 리플레이한다. 투표 validator는 합의에 참여하며 리더로 선택되었을 때 블록을 생성할 수 있다. RPC 노드는 투표하거나 리더 스케줄에 진입하지 않는다. 애플리케이션에 실시간 상태와 트랜잭션 API를 제공하는 데 집중한다.

아카이브 노드는 별도의 Solana 노드 유형인가?

보통 그렇지 않다. 심층 트랜잭션 및 블록 히스토리는 일반적으로 디스크가 더 큰 표준 노드가 아니라 RPC 호환 인터페이스 뒤에 있는 별도의 아카이브 데이터 시스템에서 제공된다.

애플리케이션이 validator를 운영해야 하는가?

보통 그렇지 않다. 애플리케이션은 체인을 성립시키기 위해 validator에 의존하지만, 자체 요청은 보통 RPC 노드와 특화된 데이터 서비스로 전달된다. validator 운영은 합의 참여에 필요한 것이지, 일반적인 애플리케이션 접근에 필요한 것이 아니다.

Solana validator 또는 RPC 노드의 하드웨어 요구사항은 무엇인가?

현재 Agave 가이드라인에 따르면 투표 validator는 12코어, 24스레드, 256GB RAM부터 시작한다. 투표하지 않는 RPC 노드는 16코어, 32스레드부터 시작하며, 모든 계정 인덱스를 실행할 경우 512GB RAM이 권장된다. 둘 다 빠른 NVMe 스토리지와 안정적인 네트워킹이 필요하다.

Solana 노드를 운영하려면 SOL이 필요한가?

투표하지 않는 RPC 노드는 투표를 위한 SOL이 필요하지 않다. 투표 validator는 자금이 있는 identity 및 vote account가 필요하며, 현재 합의 시스템 아래에서 투표 트랜잭션 비용을 지불한다.

Solana validator 운영은 수익성이 있는가?

위임된 스테이크, 투표 성과, 커미션, 리더로 선택되었을 때의 트랜잭션 수수료 수익, maximum extractable value 수익, 운영 비용에 따라 달라진다. 위임된 스테이크가 적은 validator는 손익분기점을 넘기기 어려운 경우가 많다. validator 운영은 애플리케이션에 RPC 접근을 제공하는 수단이 아니라 그 자체로 별개의 인프라 사업으로 취급해야 한다.

Solana 노드는 어떻게 운영하는가?

먼저 역할을 선택하고, 현재 클라이언트 요구사항에 맞춰 프로비저닝하고, 투표 또는 RPC 동작을 설정하고, 키와 엔드포인트를 보호한 다음, 모니터링과 페일오버를 추가하라. 지원되는 릴리스와 권장사항이 변경되므로 명령어와 플래그는 최신 Agave 문서를 사용하라.

RPC 노드를 직접 호스팅해야 하는가, 아니면 프로바이더를 사용해야 하는가?

관리형 용량, 과거 데이터, 인덱싱된 메서드, 스트리밍, 페일오버가 필요하지만 이를 직접 운영하고 싶지 않다면 프로바이더를 사용하라. 통제, 커스텀 설정, 물리적 배치, 지속적인 규모, 정책 요구사항이 전담 인프라 팀을 정당화한다면 직접 호스팅하라.