Solana's Read Layer, 재구축: Quicknode 의 인메모리 캐시 내부 살펴보기

Quicknode

2026년 5월 5일 — 읽는 데 13분 소요

공유하기

선호하는 소스로 추가

Solana 개발자들은 대량의 데이터를 반환하거나 전체 계정 집합을 스캔해야 하는 메서드를 사용할 때 난관에 부딪히게 됩니다. getProgramAccounts 속도가 제한되거나 비활성화됩니다. getLargestAccounts 결코 반환되지 않습니다. 근본 원인은 구조적인 문제입니다. Agave RPC 노드는 쓰기 작업에 최적화된 시스템이며, 리소스 소모가 큰 읽기 메서드의 처리 속도를 제한하는 것은 정책상의 선택이 아니라 필수적인 조치입니다. 결국 애플리케이션은 블록체인 제공업체의 인프라 한계를 우회하기 위해 순전히 존재하는 재시도 로직, 캐싱 계층, 폴링 간격 등을 통해 이를 보완하게 됩니다.

더 넓은 생태계에서 이제야 이 문제를 해결하기 시작하고 있는 반면, Quicknode 는 Solana 생태계에 실제로 필요한 읽기 계층을 이미 구축해 놓았습니다. 2년에 걸친 반복적인 개발 과정, 전용 인메모리 아키텍처, 그리고 Agave의 기본 설정보다 10배에서 1,000배 이상 빠른 성능을 자랑합니다.

Quicknode 고객이라면 이러한 혜택을 별도로 신청할 필요가 없습니다. endpoint 를 통해 이미 해당 혜택이 제공되고 있습니다.

Solana 의 ‘Read Layer’에 내재된 구조적 문제

Agave RPC 노드는 트랜잭션을 처리하고, 합의에 도달하며, 원장을 업데이트하기 위해 설계되었습니다. 이 노드들이 관리하는 계정 상태는 해당 프로세스의 부산물일 뿐, 읽기 최적화된 저장소가 아닙니다. 쿼리 플래너도 없고, 기본 제공되는 보조 인덱스도 없으며, 읽기 및 쓰기 I/O가 분리되어 있지도 않습니다.

하드웨어 확장만으로는 이 문제를 해결할 수 없습니다. 읽기 쿼리와 합의 작업이 동일한 시스템에서 동일한 CPU를 놓고 경쟁하기 때문에, 하드웨어를 늘린다고 해도 경합 현상을 해소하지 못한 채 검증자급 비용(768GB RAM, 고속 NVMe, 고대역폭 네트워킹)을 부담해야 합니다.

RPC 노드를 더 추가하면 문제가 더욱 악화됩니다. 노드가 늘어나면 Solana 의 가십(gossip) 및 터빈(turbine) 네트워크에 부하가 가중되어, 실제로 이를 필요로 하는 검증자(validator)들의 상태 전파 속도가 느려집니다. 검증자 아키텍처를 통해 읽기 계층을 확장하면 쓰기 계층의 성능이 적극적으로 저하됩니다.

데이터 페이지 분할은 일관성 문제를 야기할 수 있습니다. 페이지 사이에 새로운 블록이 삽입되면, 응답의 기반이 되는 계정 상태가 읽기 도중에 변경됩니다. 대규모 결과 집합을 순차적으로 처리하는 애플리케이션은 읽기를 완료하기도 전에 데이터가 이동한 상태로 데이터를 수신하게 됩니다.

Quicknode 가 어떻게 더 나은 읽기 계층을 구축했는지

Quicknode 이 문제를 조기에 파악하고, 읽기 워크로드를 검증기에서 분리하여 전용 인프라를 통해 처리하도록 했습니다. 현재 트래픽을 처리하는 아키텍처는 이러한 노력의 세 번째 결과물입니다. 각 단계마다 데이터에 한 걸음 더 가까워지면서, 가치를 더하지 않고 지연 시간만 증가시키는 추상화 계층을 제거해 왔으며, 이러한 작업은 현재도 계속되고 있습니다.

1차 반복: 관계형 데이터베이스

첫 번째 시도에서는 기존의 접근 방식을 따랐습니다. 즉, 계정 상태와 원장 데이터를 관계형 데이터베이스로 전송하고, 인덱스를 생성한 뒤 이를 대상으로 쿼리를 실행하는 방식이었습니다. 이를 통해 리소스 경합 문제가 즉시 해결되었습니다. 검증자들은 합의 도출에 집중할 수 있었고, 별도의 시스템이 읽기 작업을 처리했습니다. 하지만 관계형 데이터베이스는 Solana 의 규모에서는 무시할 수 없는 오버헤드를 수반합니다. 쿼리 계획 수립, 행 잠금, WAL(Write-Ahead Logging) 관리, 자동 진공(autovacuum), 그리고 디스크 기반 스토리지의 고유한 지연 시간이 바로 그것입니다. 400밀리초마다 블록을 생성하는 블록체인의 경우, 읽기 지연 시간 1마이크로초는 매일 수백만 건의 요청에 걸쳐 누적됩니다. Solana 의 트래픽이 증가함에 따라, 디스크 I/O가 극복해야 할 다음 한계로 대두되었습니다.

2차 반복: 특수 목적의 고성능 데이터베이스

다음 단계는 스키마 자체부터 시작되었습니다. equipe 는 Solana 의 실제 액세스 패턴에 맞추기 위해 데이터 모델을 단순화하고 비정규화하여, 더 이상 효율성이 떨어지는 관계형 구조를 제거했습니다. 이러한 구조 재편을 통해, 관계형 접근 방식에서 발생하는 쿼리 계획, 행 잠금, 사전 쓰기(write-ahead)와 같은 오버헤드 없이, 쓰기 집약적인 데이터 수집과 저지연 포인트 읽기를 위해 설계된 고성능 NoSQL 데이터베이스로의 전환이 가능해졌습니다.

처리량과 지연 시간이 모두 눈에 띄게 개선되었으며, 대규모로 관계형 시스템을 운영할 때 발생하던 운영상의 문제들(오토바큐엄 중단, 잠금 경합 급증, WAL 부풀어오름)이 사라졌습니다.

3차 반복: 완전 메모리 내 아키텍처

다음 단계로 나아간 동기는 달랐다. 디스크 기반 시스템은 아무리 잘 튜닝되어 있더라도 피할 수 없는 한계가 있다. 바로 모든 읽기 작업이 결국 RAM보다 몇 배나 더 느린 저장 매체에 의존하게 된다는 점이다. 이 한계를 극복하기 위해서는 읽기 경로 자체가 디스크를 벗어나야만 했다.

현재 아키텍처는 읽기 경로에서 디스크를 완전히 배제합니다. AccountsDB의 상태 정보는 메모리에 저장되며, Solana 의 특정 쿼리 패턴에 맞춰 특별히 설계된 맞춤형 데이터 구조를 통해 인덱싱됩니다. 쿼리 플래너도, B-트리 탐색도, 페이지 캐시 미스도 없습니다. 단지 미리 인덱싱된 데이터에 대한 직접적인 메모리 액세스만 이루어집니다.

완전한 인메모리 아키텍처로의 전환은 ‘순수한 읽기 성능’이라는 단일 목표를 달성하기 위해 의도적으로 내린 결정이었습니다.

LedgerDB(모든 슬롯의 블록, 트랜잭션 및 메타데이터의 이력 기록을 저장함) 캐시는 동일한 설계 철학을 따르지만, 저장 전략은 다릅니다. Solana 의 원장 데이터는 용량이 너무 커서 메모리에 전부 담을 수 없기 때문에 계층형 설계를 사용합니다. 즉, 체인 최상단(tip-of-chain) 데이터는 메모리에 상주하도록 유지되고, 이력 데이터는 해당 워크로드에 최적화된 고성능 분산 데이터베이스에서 제공됩니다.

작동 원리: Quicknode 의 인메모리 캐시

Quicknode Solana 의 캐시는 외부 의존성 없이 모든 체인 최상위 메서드를 처리하는 독립적인 단일 바이너리 파일입니다. 오직 과거 원장 조회 시에만 외부 데이터베이스에 접근합니다.

AccountsDB(모든 계정의 현재 상태를 저장함) 캐시는 완전히 메모리 내에 존재하며, 이를 빠르게 만드는 설계상의 선택은 우연이 아닙니다. 네 가지 메커니즘이 서로 연동되어 읽기 및 쓰기 경로에서 발생할 수 있는 모든 불필요한 지연 요인을 제거합니다.

체인보다 한 발 앞서

데이터의 최신성은 성능상의 특성이며, 이는 어떤 읽기 요청이 도착하기 전부터 시작됩니다. 캐시는 shred-stream 데이터 소스에서 직접 데이터를 수집하며, 완전히 구성된 블록을 기다리는 일반적인 Agave RPC 노드에 비해 계정 업데이트 정보를 200~400ms 더 빨리 수신합니다. 이러한 업데이트는 저지연 쓰기 경로( near 의 잠금 없는 설계를 적용한 메모리 내 쓰기)를 통해 처리되므로, 수집 오버헤드에 의해 상쇄되지 않고 종단 간에 이 선점 효과가 유지됩니다.

이러한 복합적인 효과는 팁(tip)에서 측정할 수 있습니다. 실제 트래픽 환경에서 캐시의 최신 관측 가능한 슬롯은 유사한 구성의 Agave RPC 노드보다 일관되게 1~2 슬롯 앞서 나갑니다. 트레이딩 시스템, MEV, 청산 엔진, 실시간 대시보드 등 ‘현재 상태가 어떻게 되는가’가 핵심인 워크로드의 경우, 이는 실시간 상태에 기반해 조치를 취하는 것과 이미 오래된 데이터에 기반해 조치를 취하는 것의 차이를 의미합니다.

사용자 정의 데이터 구조

계정 조회, 토큰 쿼리, 프로그램 계정 필터링을 지원하는 인덱스는 벤치마크를 통해 선정된 저수준 데이터 구조로 구축됩니다. 이는 가장 일반적인 선택이 아니라, 시스템에서 실제로 발생하는 액세스 패턴에 대해 가장 빠른 성능을 보인 구조입니다. 공유 상태는 가능한 한 최소한의 잠금만 사용하여, 동시 읽기 작업들이 서로 간섭하지 않도록 합니다.

하드웨어에 최적화됨

이 시스템은 데이터 수집, 색인 생성 및 쿼리 처리를 전용 CPU 코어에 할당하여 컨텍스트 전환 오버헤드를 최소화하고, 각 구성 요소의 특정 할당 프로필에 따라 메모리 할당기를 선택함으로써 부하 발생 시 메모리 조각화를 줄임으로써 하드웨어 활용도를 극대화합니다.

사전 계산

가능한 경우, 시스템은 계정 상태가 입력될 때 파생 뷰(공급 집계, 정렬된 계정 목록, 필터링된 프로그램 캐시 등)를 미리 계산하여 유지합니다. 이를 통해 CPU 부하가 지연 시간에 민감한 읽기 경로에서 처리량 중심의 쓰기 경로로 전환됩니다. 쿼리는 절대 계산을 유발하지 않으며, 이미 존재하는 결과를 읽기만 합니다. 17ms getSupply 벤치마크에서 나타나는 반응은 바로 이 메커니즘이 실제로 작동하는 모습입니다. 즉, 쿼리가 도착할 때 이미 집계 결과가 존재한다는 것입니다.

getProgramAccounts: 가장 어려운 문제

getProgramAccounts 겉보기에는 간단해 보이는 작업을 수행합니다. 바로 이 프로그램이 소유한 계정 중 지정된 필터 조건에 맞는 모든 계정을 반환하는 것입니다. 문제는 이를 효과적으로 색인화하기가 어렵다는 점입니다. 해당 프로그램은 배포된 수천 개의 프로그램 중 어느 것이든 될 수 있으며, 각 프로그램은 고유한 계정 스키마를 가지고 있습니다.

필터는 일반적으로 memcmp 특정 바이트 오프셋에서 수행되는 연산으로, 프로그램의 내부 데이터 배열을 알고 있을 때만 의미가 있는 오프셋입니다. A memcmp 오프셋 32는 SPL 토큰에서는 한 가지 의미를 가지지만, DEX 프로그램에서는 완전히 다른 의미를 가집니다.

이 모든 경우에 통용되는 보편적인 인덱싱 전략은 없습니다. 인덱싱 getProgramAccounts 효율적으로 처리하려면 각 프로그램의 계정 구조를 파악해야 합니다. Quicknode 의 인덱서는 두 가지 전략을 결합하여 이 문제를 해결합니다:

기본적으로 인덱싱된 프로그램

트래픽이 많고 작동 방식이 잘 알려진 소수의 프로그램에 대해, Quicknode 은 계정이 업데이트될 때마다 전용 네이티브 인덱스를 지속적으로 구축하고 유지 관리합니다. 이 프로그램들은 Solana 트래픽의 대부분을 차지하는 SPL 토큰(레거시), SPL 토큰-2022, 스테이크 프로그램입니다.

계정 구조는 이미 파악되어 있고, 고객이 사용하는 필터 패턴도 알려져 있으며, Quicknode 에서는 이러한 세부 사항을 직접 활용할 수 있도록 인덱스를 설계했습니다. 이 인덱스들은 프로그램이 관리하는 계정 수가 수백만 개에 달하더라도 1밀리초 미만의 시간 내에 쿼리를 처리하며, 대부분의 getProgramAccounts 가장 인기 있는 검색어들이 소수의 프로그램에 집중되어 있기 때문에 트래픽이 발생합니다.

동적 인덱싱 프로그램

그 외의 모든 경우, 즉 모든 맞춤형 DeFi 프로토콜, 지난주에 배포된 모든 프로그램, 모든 틈새 사용 사례에 대해서는 인덱서가 동적 전략을 사용합니다. 호출자가 특정 프로그램에 대한 필터 조합을 처음 요청하면, 캐시는 즉시 새로운 인덱스를 자동으로 생성합니다. 이 첫 번째 요청은 최적화되지 않은 상태로 실행됩니다. 인덱서는 응답하기 전에 프로그램의 계정을 스캔하고 인덱스를 구축해야 하므로, 호출자는 캐시를 예열하는 일회성 비용을 부담하게 됩니다. 그리고 그 콜드 패스조차도 Agave보다 빠릅니다.

동일한 필터에 대한 이후의 모든 요청은 온체인에서 계정 정보가 변경될 때마다 최신 상태를 유지하는, 실시간으로 점진적으로 관리되는 캐시에서 처리됩니다. 업데이트는 네이티브 인덱싱 프로그램을 구동하는 것과 동일한 스트리밍 파이프라인 flow 을 통해 이루어지므로, 캐시된 뷰는 실제 상황과 결코 어긋나지 않습니다.

그 시점부터는 페이로드 크기나 프로그램의 인기에 관계없이 지연 시간이 사실상 일정하게 유지됩니다. 10개의 계정을 반환하는 필터와 100만 개의 계정을 반환하는 필터는 모두 동일한 수준의 응답 속도를 보입니다. 이는 필요한 작업이 이미 완료되었기 때문입니다. 응답은 요청마다 다시 계산되는 것이 아니라, 미리 조립된 메모리에서 직접 스트리밍됩니다.

새로운 프로그램은 배포되는 당일부터 지원됩니다. 스키마 통합이나 수동 구성이 필요하지 않으며, 엔지니어링 equipe 팀이 지원을 추가할 때까지 기다릴 필요도 없습니다. 새로운 프로그램을 처음으로 조회하는 클라이언트가 인덱싱을 시작하면, 그 이후의 모든 클라이언트가 그 혜택을 누릴 수 있습니다.

네이티브 인덱스는 실제 트래픽의 대부분에 대해 최고의 성능을 제공합니다. 동적 인덱싱 기능은 어떤 프로그램이나 필터 패턴도 지원되지 않는 경우가 없도록 보장합니다.

p50

p99

getProgramAccounts 이는 AccountsDB 환경에서 가장 어려운 문제이므로, 별도의 최적화 전략이 적용됩니다. 그 외의 모든 작업(포인트 조회, 집계, 토큰 쿼리, 블록 및 슬롯 메타데이터)은 동일한 메모리 내 상태에서 처리되며, 동일한 설계 원칙을 따릅니다. 즉, 가능한 경우 사전 계산하고, 읽기 경로에서는 잠금 없이 처리하며, 스캔 대신 단일 조회로 해결합니다.

이 기능이 실제 운영 환경에서 제공하는 이점

그 결과, 주요 메서드뿐만 아니라 AccountsDB의 모든 메서드가 동시 처리 부하 하에서도 메모리 내 처리 속도로 실행됩니다. 트래픽이 증가하거나 계정 집합이 커짐에 따라 부하 하에서 성능이 저하되는 지원되는 메서드는 없습니다.

아래 수치는 동일한 네트워크상의 기존 Agave 검증자와의 벤치마킹 결과를 바탕으로 한 것입니다. 이러한 성능 차이는 하드웨어의 우월성 때문이 아니라 아키텍처적 차이에서 비롯된 것입니다.

간단한 점 조회 작업의 경우, getAccountInfo, getBalance, 그리고 getTokenAccountBalance, Quicknode 의 인덱서는 Agave와 2~4ms 수준에서 비슷한 성능을 보입니다. 이러한 메서드의 핫 패스는 단일 인덱스 기반 읽기 작업입니다. 응답 시간은 계정 집합에 비례하여 증가하는 작업량이 아니라 네트워크 왕복 시간에 주로 좌우됩니다. 집계, 정렬된 뷰 또는 유효성 검사기가 관리하지 않는 보조 인덱스가 필요한 메서드의 경우 성능 차이가 나타납니다.

다음 세 가지 결과가 특히 눈에 띕니다:

getTokenLargestAccounts USDC의 경우, Agave는 거의 100초가 소요됩니다. 요청이 발생할 때마다 검증자는 SPL 토큰 프로그램 전체를 일일이 훑어보고, 발행처별로 필터링하고, 정렬한 뒤, 캐시된 결과나 정렬된 인덱스 없이 상위 20개를 반환해야 합니다. Quicknode 의 인덱서는 발행처별로 정렬된 집합을 유지하며, 잔액이 변경될 때마다 점진적으로 업데이트됩니다.

getLargestAccounts Agave에서는 5분 이내에 완료되지 않습니다. 검증기는 요청이 들어올 때마다 전체 계정 집합에 대해 정렬된 집계 결과를 처음부터 다시 계산합니다. Quicknode 의 인덱서는 이를 실행 중인 인덱스로 유지합니다.

getTokenAccountsByDelegate Agave에서는 지원되지 않습니다. Quicknode 의 인덱서는 이를 한 자릿수 밀리초 단위로 처리합니다.

지연 시간 수치는 개별 요청 속도를 나타냅니다. 동시 처리 상황은 이와 다르지만, 마찬가지로 중요합니다. 하나의 Agave가 getTokenLargestAccounts 쿼리 처리 시간이 97초가 소요되면, 해당 요청이 서비스 슬롯을 점유하게 되어 그 뒤를 따르는 모든 쿼리가 지연됩니다. 즉, 하나의 느린 요청이 연쇄 반응을 일으켜 동시 접속한 모든 호출자에게 지연 시간 급증을 초래합니다.

Quicknode의 인덱서는 그러한 오류가 발생하지 않습니다. mode. 모든 쿼리는 미리 구축된 인메모리 인덱스에서 처리되므로, 단일 요청이 너무 오래 실행되어 동시 트래픽을 방해하는 일이 없습니다. 지속적인 부하가 가해질 때, AccountsDB 캐시는 초당 수만 건의 요청을 처리하면서 P50 지연 시간을 10ms 미만으로 유지하며, 처리량은 계정 집합 크기나 쿼리 복잡도가 아닌 하드웨어 용량에 의해 제한됩니다.

모든 메서드의 처리 시간이 10ms 미만인 것은 아닙니다. 기본적으로 인덱싱된 집합 외부의 프로그램에 대한 콜드 요청의 경우, 첫 호출 시 구독이 설정되고 필터링된 캐시가 채워지는 동안 11~40초의 초기화 비용이 발생합니다. 동일한 필터에 대한 이후의 모든 요청은 메모리 내의 웜 캐시에서 처리됩니다.

대규모 스테이크 프로그램 쿼리는 중간 범위를 잘 보여줍니다. Marinade의 81K개 스테이크 계정은 Quicknode 의 인덱서에서는 약 1초 만에 처리되는 반면, Agave에서는 6.7초가 소요됩니다. 인덱스 조회 속도는 빠르지만, 그 정도의 처리량에서 응답을 조립하고 직렬화하는 데는 상당한 CPU 부하가 발생합니다.

Raydium V4 규모(약 705,000개 계정, 약 869MB의 JSON)에서의 응답은 또 다른 한계에 부딪혔습니다. 첫 바이트까지 걸리는 시간은 1.5초이며, 전체 데이터 전송에는 더 오랜 시간이 소요되는데, 이는 869MB의 데이터를 네트워크를 통해 전송하는 데 따르는 물리적 한계 때문입니다.

전반적으로 성능이 획기적으로 향상되었습니다. 모든 메서드가 기본 Agave 검증기보다 10배에서 1,000배 더 빠르게 실행됩니다. 단일 메서드 부하 테스트에서, 단일 인스턴스는 350,000 getTransaction 초당 요청 수, 지연 시간 40ms 미만, 120,000 getAccountInfo 초당 요청 수, P50 기준 20ms 미만.

AccountsDB와 LedgerDB 캐시를 합치면, 프로덕션 RPC 트래픽의 약 95%와 Solana JSON-RPC 사양의 약 90%를 처리합니다.

이것이 결승선이 아닙니다

오늘날 우리가 보고 있는 결과는 2년에 걸친 반복적인 개선의 산물입니다. 이것이 최종 형태는 아닙니다. Quicknode 는 Solana 의 읽기 계층에 지속적으로 투자하고 있습니다. 아키텍처는 계속해서 더 빨라질 것이며, 메서드 커버리지도 지속적으로 확대될 것입니다. 또한 개발자가 필요로 하는 것과 인프라가 제공하는 것 사이의 격차를 좁히기 위한 노력은 멈추지 않을 것입니다.

결론

Solana읽기 및 쓰기 워크로드는 근본적으로 서로 다른 문제입니다. 따라서 근본적으로 다른 아키텍처가 필요합니다. Quicknode 는 Solana 생태계에 실제로 필요한 읽기 계층을, 성능을 타협하지 않은 채 2년에 걸쳐 처음부터 구축했습니다. 이 인프라에 대한 지속적인 개선은 선택 사항이 아닙니다. 이는 모든 Quicknode Solana endpoint 가 이미 제공하고 있는 것입니다.

Quicknode 에서 ‘ Solana ’endpoint 를 생성하고, 바로 이 워크로드를 위해 특별히 설계되고 지속적으로 최적화된 리드 레이어에서 빌드 작업을 시작하세요.