Alchemy는 어떻게 Solana에서 가장 빠른 아카이브 메서드를 구축했는가

작년 말, 저희는 Solana를 위한 새로운 제품을 발표했습니다. 이 제품의 핵심 기능 중 하나는 archival 메서드의 성능으로, 시중의 다른 어떤 솔루션보다 최대 20배 빠릅니다.

Alchemy의 Solana 제품을 사용하면 개발자는 표준 JSON RPC 인터페이스를 통해 유례없는 속도로 과거 트랜잭션, 블록, 서명을 조회할 수 있습니다. 이는 쉽게 만들어진 것이 아니며, 이 글에서는 어떻게 구현했는지 설명합니다.

Solana의 archival 메서드란 무엇인가?

Solana에서 archival 메서드는 getTransaction, getBlock, getSignaturesForAddress처럼 과거 블록체인 데이터를 조회하는 RPC 호출을 말합니다.

이러한 archival 엔드포인트는 온체인 앱의 기반입니다. 지갑, 인덱서, 분석 서비스, 익스플로러 등 다양한 서비스가 이 과거 데이터를 활용해 사용자에게 더 풍부한 정보를 제공하고 일관된 경험을 구축합니다.

하지만 Solana에서 archival 데이터에 접근하는 것은 악명 높을 정도로 어렵습니다. 데이터셋은 방대하고, 서로 깊이 연결되어 있으며, 조회에 상당한 연산이 필요합니다. 대부분의 개발자에게 이 엔드포인트는 지연과 불일치 문제가 가장 먼저, 그리고 가장 심각하게 드러나는 지점입니다.

Solana archival 메서드의 성능 문제

현재 대부분의 Solana 인프라는 Google Bigtable과 validator 기반 RPC 노드를 결합한 방식으로 운영됩니다.

이 스택은 배포가 쉬워서 많은 팀이 선택하지만, 규모 확장에는 적합하지 않습니다. CPU 사용량이 많고 메모리를 많이 소모하며, 대규모 배치 요청 처리에 어려움을 겪습니다. 대규모로 조회할 경우 이런 메서드는 처리량을 제한하고 앱 속도를 크게 떨어뜨리거나, 심지어 응답에서 데이터가 누락되기도 합니다.

이 때문에 신뢰받는 제공업체조차도 과거 데이터를 조회할 때 불완전하거나 지연된 응답을 반환하는 경우가 많습니다. 개발자 입장에서는 이러한 블록 누락과 느린 호출이 곧바로 앱 내 오류로 이어집니다.

저희는 이 문제를 해결하고자 했습니다. 단순히 하드웨어를 늘리는 방식이 아니라(물론 하드웨어도 추가했지만), 인프라 아키텍처 자체를 개선하는 방식으로요.

Google Bigtable에서 겪은 최적화의 어려움

다른 많은 Solana 인프라 제공업체와 마찬가지로, 저희도 Google Bigtable로 시작했고 시간이 지나면서 앞서 언급한 성능 문제를 발견했습니다. 이 문제는 두 가지 요인으로 더욱 심화되었습니다.

첫째, Solana 블록의 크기가 큽니다. Bigtable은 행 크기가 약 1KB일 때 가장 좋은 성능을 냅니다. 하지만 Solana의 트랜잭션 데이터나 계정 상태는 이보다 훨씬 큰 경우가 많습니다. 큰 바이너리 객체를 가져오려면 Google의 기본 스토리지(Colossus)에서 더 많은 I/O가 필요합니다.

둘째, 비용 문제가 있었습니다. 클라우드 데이터베이스는 비용이 많이 듭니다. Solana의 많은 데이터(예: 투표 트랜잭션)는 특별히 가치가 크지 않아서, 이를 클라우드에 계속 보관하는 것은 경제적으로 합리적이지 않습니다. 게다가 Google Bigtable은 사용량 기반 과금 방식이라 더 높은 RPS를 제공하는 데 부담이 크고 유연성도 떨어집니다.

이런 한계에도 불구하고 저희는 이 구조에서 몇 가지 최적화를 시도했습니다. 예를 들어 트랜잭션 조회를 최적화했습니다. Google Bigtable의 기본 설정에서는 getTransaction으로 트랜잭션 하나를 요청하면, 서명으로 블록 ID를 찾기 위해 tx 테이블에 쿼리를 한 번 보냅니다. 그런 다음 단일 트랜잭션을 반환하기 위해 모든 블록을 가져옵니다. 원격 클라우드 데이터베이스에서 이렇게 작은 데이터를 반환하는 데 너무 많은 작업이 필요한 셈입니다.

이 흔한 요청을 더 효율적으로 처리하기 위해, 저희는 tx-full라는 추가 테이블을 도입했습니다. 이 테이블에는 블록에 대한 참조뿐 아니라 트랜잭션 전체를 저장합니다. 이는 응답 시간을 크게 개선했지만, 데이터센터의 원격 지리적 위치로 인한 지연 증가는 여전히 남아 있었습니다.

기본 스택에 맞춰 최대한 노력했음에도 개발 속도는 매우 느렸습니다. 전체 RPC 노드/validator에서 단순한 쓰기 작업 하나를 하는 것도 큰 부담이었습니다. 변경할 때마다 노드를 완전히 재시작해야 했고, 이 과정은 30분에서 몇 시간까지 걸렸습니다. 데이터베이스가 지리적으로 가까이 있지 않고 일부 파라미터를 제어할 수 없다는 점도 모든 것을 더 어렵고 비용이 많이 들게 만들었습니다. 많은 시도 끝에, 저희는 데이터 수집부터 RPC 서버 자체까지 전체 스택을 다시 작성하는 것이 낫다고 판단했습니다.

저희의 해결책: 재작성된 스택

이 작업을 시작할 때 저희의 주요 목표는 개발 속도를 높이는 것이었습니다. 이는 데이터를 쓰고 서빙하는 무거운 RPC 노드를 없앤다는 뜻이었습니다. 대신 데이터 쓰기와 서빙을 작고 독립적인 서비스로 분리하고, 자체 호스팅하는 오픈소스 데이터베이스로 전환했습니다.

이 새로운 시스템은 다음을 제공합니다:

• 하드웨어와 소프트웨어의 공동 최적화: 디스크 레이아웃부터 메모리 접근까지 스택의 모든 계층이 처리량을 최대화하고 연산 오버헤드를 최소화하도록 조정되어 있습니다.
• 다중 리전 데이터 분산: archival 데이터는 전 세계적으로 분산되어 있어, 요청이 어디서 오든 낮은 지연 시간으로 접근할 수 있습니다.
• 삼중 검증 수집: 각 레코드는 두 번 기록되고, 프로그램적으로 정확성을 검증받으며, 완전성을 지속적으로 스캔합니다.
• 자가 복구 파이프라인: 불일치가 발견되면, 블록당 최대 30~50개의 관련 주소를 교차 검증하여 누락된 항목을 자동으로 재수집함으로써 데이터 무결성을 보장합니다.

이제 이 솔루션의 각 부분을 살펴보겠습니다. 이 코드는 오픈소스로 공개되어 있습니다(이 코드는 DexterLab의 저장소에 있으며, 이 회사는 작년 Alchemy에 인수되었습니다).

ArchivalRPC

저희는 archival 서비스를 처음부터 다시 만들어, 몇 초 만에 시작하거나 재시작할 수 있는 훨씬 더 성능이 뛰어난 서비스로 전환했습니다. 전체 RPC 노드를 사용할 때 겪었던 30분에서 몇 시간에 이르는 구동 시간에 비하면 극적인 개선입니다.

데이터 직렬화 및 역직렬화에는 여전히 동일한 공식 Solana 라이브러리를 사용하므로, 이 서비스는 앞으로의 변경 사항과도 항상 호환됩니다. 즉, 새로운 커스텀 스택을 사용하더라도 데이터 자체는 전혀 변경하지 않으며, 처리 과정에서 데이터가 손상되지 않도록 보장합니다.

또한 데이터베이스에 의존하는 가벼운 서비스이기 때문에 수요에 따라(단 몇 초 만에) 쉽게 확장할 수 있고, 대규모 트래픽도 처리할 수 있습니다. 이는 트래픽이 급격히 변하는 애플리케이션에 특히 유용하며, 단일 DB 인스턴스만으로도 데이터베이스 구성에 따라 최대 100,000~200,000 RPS까지 처리할 수 있습니다.

ArchivalRPC 인제스터

이 스택 부분은 여러 소스에서 Solana 데이터를 가져와 데이터베이스 계층에 기록하는 역할을 합니다. 새 인스턴스를 부트스트랩할 때 사용하는 원시 gzip 블록 아카이브 같은 대량 임포트와, Kafka 같은 시스템에서 오는 실시간 스트림을 모두 처리합니다.

또한 인제스터에 세밀한 제어 기능을 내장하여, 인스턴스가 저장할 데이터 유형을 정확히 선택할 수 있게 했습니다(예: 블록만, 서명만, 트랜잭션만, 또는 이들의 조합). 이 선택적 수집 모델은 단일 장애 지점을 줄이고 신뢰성을 높이며, 사용 사례에 따라 스토리지 비용을 최적화할 수 있는 유의미한 수단을 제공합니다.

Hbase

읽기 및 쓰기 성능을 개선한 후, 저희는 다음 과제인 클라우드 데이터베이스 지연 시간에 집중했습니다. ArchivalRPC는 처음부터 여러 스토리지 백엔드를 지원하도록 설계되어 있어서 대안을 탐색하기가 수월했습니다.

최종적으로 HBase를 선택했습니다. 이는 BigTable을 대체할 수 있는 오픈소스 자체 호스팅 솔루션으로, 데이터베이스를 RPC 서버와 같은 위치에 둘 수 있게 해주어 스토리지 지연 시간을 사실상 0에 가깝게 만들 수 있었습니다. 이 구현을 통해 기존 데이터 모델과 구현 원칙을 그대로 사용할 수 있었고, 아키텍처적 위험을 추가하지 않으면서도 성능상의 이점을 얻을 수 있었습니다.

하지만 HBase의 장점에도 불구하고 몇 가지 문제에 부딪혔습니다. 예를 들어, Solana 블록의 큰 크기를 처리하기 위해 처음에는 HBase의 BucketCache을 사용해 보려고 했습니다. 이는 off-heap 메모리나 빠른 SSD를 보조 캐시 계층으로 구성하여 더 많은 데이터를 "warm" 상태로 유지할 수 있는 기능입니다.

하지만 결국 BucketCache이 신뢰할 수 없다는 것을 알게 되었습니다. 데이터의 무작위성과 빠른 변화 속도 때문에 시스템 속도가 느려졌습니다. 대신 저희는 대용량 데이터 처리를 위한 다른 방식을 채택했습니다. 실제로 블록을 저장하는 방식 자체를 바꾼 것입니다. 이런 큰 데이터 구조를 처리하도록 설계되지 않은 데이터베이스에 전체 블롭을 저장하는 대신, 데이터베이스에는 메타데이터만 저장하고 이 메타데이터가 CAR 파일을 가리키도록 했습니다. CAR 파일은 어떤 스토리지에든 둘 수 있고 확장성이 매우 뛰어납니다.

서비스 최적화와 다중 리전 분산

수백만, 심지어 수십억 건의 요청까지 확장 가능한 솔루션을 구축하려면 스택 전반에 걸친 최적화가 필요했습니다. 단순히 하나의 데이터베이스 아키텍처를 다른 것으로 교체하는 것만으로는 원하는 성능을 얻을 수 없었습니다. 다양한 하드웨어에서 여러 배포 방식을 시도하고, 여러 아키텍처를 테스트해야 했습니다. 시간이 지나면서 수집 및 서빙 서비스를 개선하여 원하는 결과를 얻었습니다.

대량의 요청을 처리하도록 하드웨어와 소프트웨어를 최적화하는 것이 저희가 해결해야 했던 과제 중 하나였습니다. 또 다른 과제는 지연 시간과의 싸움이었습니다. 무거운 archival 호출의 경우, 전 세계적으로 일관되게 빠른 응답을 보장하려면 하드웨어를 여러 리전으로 확장해야 지연 시간을 통제할 수 있다는 것을 알게 되었습니다.

이 다중 리전 구성은 가용성도 향상시키며 더 높은 신뢰성 기준을 유지하는 데 도움이 됩니다. 장애는 피할 수 없기 때문에, 여러 지리적 리전에 걸친 대체 옵션을 마련해두면 한 리전에 장애가 발생해도 고객에게 계속 서비스를 제공할 수 있습니다. 이 동일한 다중 리전 구성은 확장과 트래픽 분산에도 도움이 됩니다. 한 리전이 용량 한계에 도달하면 배포를 확장하면서 트래픽을 다른 리전으로 돌릴 수 있습니다.

삼중 검증 수집

이 제품의 많은 작업이 성능 개선에 관한 것이었지만, 그것은 절반에 불과합니다. Solana archival 메서드에서 지속적으로 발생하는 문제 중 하나는 데이터가 통째로 누락되는 경우가 많다는 점입니다. 저희는 시스템의 신뢰성을 개선해야 했습니다.

Bigtable 기반의 많은 제공업체는 수집 파이프라인이 확장되면서 블록, 서명, 트랜잭션을 소리 없이 누락시킵니다. 이런 누락은 validator에서 기본 데이터 수집이 작동하는 방식 때문에 발생합니다. 재시작할 때마다 데이터 쓰기에 공백이 생길 수 있습니다.

여러 validator가 동일한 데이터를 기록하는 방식에 묶여 있다 해도, 데이터가 올바르게 기록되고 있는지 확인하는 이차 검증이 없다면 데이터 일관성은 보장되지 않습니다. 그리고 이 인프라를 사용하는 개발자 입장에서는 다운스트림에서 문제가 발생하기 전까지 데이터가 누락된 사실조차 알 수 없습니다.

저희 인프라는 설계 자체로 이 문제를 방지합니다. 데이터를 기록한 후, 저희는 모든 레코드를 읽는 이차 파이프라인을 실행하여 데이터를 지속적으로 검증하고, 불일치가 발견되면 자동으로 복구합니다. 초기 부트스트랩 이후에는 데이터베이스 전체를 검사하며, 실시간에 가까운 방식으로 실제 쓰기 작업에 대한 검사도 계속 진행합니다.

저희는 단순히 더 빠른 데이터를 만든 것이 아니라, 신뢰할 수 있는 데이터를 만들었습니다.

자가 복구 파이프라인

signatures처럼 복잡한 데이터의 경우, 폴백 메서드를 신뢰할 수 없습니다. 즉, 앞서 설명한 삼중 검증 프로세스만으로는 충분하지 않을 때가 있습니다.

이를 해결하기 위해, 저희는 프로그램적 검증을 사용하여 블록당 최대 30~50개 주소에 걸쳐 트랜잭션을 교차 검증합니다. 시스템이 불일치를 감지하면, 백업 및 복구 프로세스가 누락된 항목을 자동으로 복구합니다.

이 프로세스는 진실의 원천 역할을 하는 블록을 가져와, 그 블록에서 모든 주소-서명 관계를 추출하는 방식으로 진행됩니다. 여기서 HBase를 스캔하는 비용을 최적화하기 위해, 연속된 슬롯의 넓은 범위에 걸쳐 주소별로 이 매핑을 누적한 뒤 개별 키 기반 쿼리 대신 스캔 쿼리를 수행합니다. 그런 다음 결과를 비교하여 SIGS 클러스터의 공백을 식별합니다.

이런 공백을 발견하면, 해당 블록을 인덱싱 파이프라인(해당 데이터 유형에 맞는 kafka 토픽)으로 다시 전송하여 재인덱싱합니다. 또한 공백이 채워지지 않으면 이 작업을 반복하는 일관성 검사 프로세스를 추가했으며, 실패 상태가 계속되면 결국 저희 팀에 알림이 갑니다.

이러한 이중화와 자가 복구 덕분에, Solana의 과거 데이터에 있어 저희 메서드를 가장 완전하고 일관된 소스로 신뢰할 수 있습니다.

이 작업이 처리량으로 이어진 결과

이 모든 작업은 실질적인 처리 용량으로 이어졌습니다:

• getTransaction의 경우 리전당 100,000 RPS
• getSignaturesForAddress의 경우 리전당 50,000 RPS
• getBlock의 경우 리전당 2,000 RPS

저희는 Solana 제품에 대한 투자를 계속하고 있으며, 더 나은 신뢰성과 지연 시간을 위해 곧 더 많은 리전으로 확장할 예정입니다. 이는 시작에 불과합니다.

직접 사용해 보기

Solana에서 archival 메서드를 직접 사용해 보고 싶다면, 대시보드 계정을 생성하여 API 키를 발급받아 무료로 시작할 수 있습니다. 그런 다음 문서에서 Solana 엔드포인트를 살펴볼 수 있습니다.

자주 묻는 질문

Solana의 archival 메서드란 무엇인가요?

Archival 메서드는 getTransaction, getBlock, getSignaturesForAddress처럼 과거 블록체인 데이터를 조회하는 RPC 호출입니다. 이 엔드포인트를 통해 개발자는 표준 JSON RPC 인터페이스로 과거 트랜잭션, 블록, 서명에 접근할 수 있습니다.

Solana archival 메서드는 왜 일반적으로 느린가요?

대부분의 Solana 인프라는 Google Bigtable에서 운영되는데, 이는 CPU 사용량이 많고 메모리를 많이 소모하며 대규모 배치 요청 처리에 어려움을 겪습니다. 이 스택은 규모 확장을 위해 설계되지 않았기 때문에 처리량을 제한하거나 성능을 저하시키고, 심지어 응답에서 데이터가 누락될 수 있습니다.

Alchemy의 Solana archival 메서드는 얼마나 빠른가요?

Alchemy의 archival 메서드는 다른 솔루션보다 최대 20배 빠르며, getTransaction의 경우 리전당 100,000 RPS, getSignaturesForAddress의 경우 50,000 RPS, getBlock의 경우 2,000 RPS의 처리 용량을 갖추고 있습니다.

Alchemy는 데이터 완전성과 신뢰성을 어떻게 보장하나요?

저희는 삼중 검증 수집 방식을 사용합니다. 각 레코드는 두 번 기록되고, 프로그램적으로 정확성을 검증받으며, 완전성을 지속적으로 스캔합니다. 자가 복구 파이프라인은 블록당 최대 30~50개의 관련 주소를 교차 검증하여 누락된 항목을 자동으로 재수집합니다.

Alchemy는 Solana archival 데이터에 어떤 데이터베이스를 사용하나요?

저희는 HBase를 사용합니다. 이는 오픈소스 자체 호스팅 데이터베이스로, 데이터를 RPC 서버와 같은 위치에 두어 스토리지 지연 시간을 사실상 0에 가깝게 만들 수 있습니다. 이를 통해 성능을 개선하고 비용을 절감하기 위해 Google Bigtable을 대체했습니다.

Alchemy는 큰 Solana 블록 크기를 어떻게 처리하나요?

Alchemy는 데이터베이스에 전체 블록을 저장하는 대신, CAR 파일을 가리키는 메타데이터만 저장합니다. CAR 파일은 어떤 스토리지에든 둘 수 있고 확장성이 매우 뛰어납니다. 이 방식은 Solana 블록의 큰 크기를 더 잘 처리할 수 있게 해줍니다.

Alchemy는 왜 archival 스택 전체를 처음부터 다시 만들었나요?

전체 RPC 노드를 사용하는 기본 스택은 재시작하는 데 30분에서 몇 시간이 걸려 개발 속도가 느리고 비용이 많이 들었습니다. Alchemy는 데이터 쓰기와 서빙을 몇 초 만에 재시작할 수 있는 작은 서비스로 분리하여 수요에 따라 확장할 수 있게 했습니다.

Alchemy는 전 세계적으로 낮은 지연 시간을 어떻게 유지하나요?

Archival 데이터는 여러 리전에 걸쳐 전 세계적으로 분산되어 있어, 요청이 어디서 오든 낮은 지연 시간으로 접근할 수 있습니다. 이 다중 리전 구성은 가용성도 향상시키며, 수요가 높은 시기에 트래픽을 분산하는 데도 도움이 됩니다.