전용 블록체인 인프라의 작동 방식

대부분의 프로덕션 워크로드는 공유 블록체인 RPC 인프라에서 문제없이 동작한다. 하지만 소수의 워크로드는 그렇지 않다. 시퀀서(롤업의 트랜잭션 순서 지정 서비스)까지의 왕복 지연 시간이 주문이 다음 블록에 포함되는지 여부를 결정하는 트레이딩 데스크. 어떤 공유 제공업체도 호스팅하지 않는 커스텀 EVM 트레이서로 시뮬레이션 엔진을 운영하는 보안 업체. 컴플라이언스 팀이 다른 고객의 워크로드와 하드웨어를 공유하는 것을 승인하지 않는 규제 대상 핀테크.

이런 워크로드에는 전용 블록체인 인프라가 답이다.

Dedicated는 동일한 인프라를 단일 테넌트로 범위를 한정한 것이다. RPC 스택, 데이터 서비스, API는 동일하지만, 용량, 호스트, 런타임은 오롯이 고객의 것이 된다. Blockaid 같은 팀은 Alchemy Dedicated Clusters를 사용해 고객이 요구하는 성능과 일관성으로 3,120억 달러 이상의 자산을 보호하고 있다.

이 차이가 좁은 범위의 워크로드에 대해서는 dedicated가 값어치를 하도록 만들고, 그 외 모든 경우에는 shared가 올바른 기본 선택이 되도록 만든다. 유용한 질문은 dedicated가 더 나은지가 아니다. 여러분의 워크로드가 shared 인프라가 설계된 범위를 벗어났는지 여부다.

전용 블록체인 인프라란?

전용 블록체인 인프라는 단일 테넌트 RPC 및 인덱싱 클러스터다. 하나의 워크로드를 위해 예약된 하드웨어에서 실행되는 블록체인 노드, 라우팅 인프라, 데이터 서비스의 집합을 말한다. 기본적으로 API 표면은 shared 인프라와 동일하므로, 기존 통합은 코드 변경 없이 그대로 이전할 수 있다. 커스터마이징은 이 표면을 대체하는 것이 아니라 확장하는 것이다: 커스텀 트레이서와 바이너리, 원하는 리전 선택, 요청당 과금 대신 용량 기반 과금 등이다.

일반적인 클러스터는 다음을 포함한다:

• 체인용 풀 노드 풀. 고객의 피크 요청률에 맞춰 크기를 정하고, 노드 재시작 중 트래픽이 끊기지 않도록 노드 하나를 추가로 둔다. 이를 N+1 패턴이라고 부른다.
• 히스토리 상태 접근을 위한 선택적 아카이브 노드. 최근 블록만이 아니라 제네시스부터의 전체 상태를 제공한다.
• 노드 풀 앞단의 엣지 프록시와 로드 밸런서. 모든 요청을 받아 어느 노드가 처리할지 결정하는 라우팅 레이어 역할을 한다.
• 관측 스택. 보통 노드 상태, 요청 지연 시간, 오류율을 보여주는 Grafana 대시보드다.
• 클러스터가 감당하도록 사이징되지 않은 트래픽 스파이크에 대비한 shared 인프라로의 페일오버 경로.

이 인프라는 shared 제공업체가 내부적으로 운영하는 것과 같은 형태다. 차이는 임대 방식이다. Dedicated는 용량이 한 고객에게 전적으로 할당되고, 런타임을 고객이 직접 설정할 수 있으며, 데이터 경로가 다른 고객의 워크로드와 공유되지 않는다는 것을 의미한다.

워크로드에 전용 인프라가 필요한 경우는 언제인가?

네 가지 워크로드 패턴이 shared 인프라의 한계를 넘어선다.

커스텀 트레이서와 바이너리

EVM 트레이서는 트랜잭션 실행을 계측하는 함수다. 내부 콜 트레이스, 스토리지 읽기, 구조체 로그, revert 이유를 추출한다. callTracer, prestateTracer 같은 표준 트레이서는 대부분의 분석 요구를 충족한다. 하지만 보안 도구, 시뮬레이션 엔진, 포렌식 플랫폼은 더 많은 것을 필요로 한다: 내부 스키마에 맞춘 커스텀 자바스크립트 트레이서, 또는 shared 제공업체가 절대 노출하지 않는 실행 상태를 드러내는 수정된 geth, erigon 바이너리다.

이런 것들을 shared 호스트에서 실행하는 것은 호스트에게도 테넌트에게도 안전하지 않다. 시뮬레이션 및 보안 업체들이 dedicated 클러스터를 운영하는 이유다.

리전 종속적 지연 시간

대부분의 애플리케이션 트래픽에서는 몇 번의 추가 네트워크 홉이 눈에 띄지 않는다. 하지만 초당 수십 건의 요청을 보내고 그 하나하나를 신경 써야 하는 워크로드에서는, 클라이언트와 노드, 시퀀서 사이의 물리적 거리가 트랜잭션이 제때 처리되는지를 좌우할 수 있다.

고빈도 트레이딩, 오라클 피드, 그리고 트랜잭션이 블록에 순서대로 들어가는 방식에서 가치를 추출하는 봇인 MEV 서처는 바로 이 마진에서 경쟁한다. Dedicated 클러스터를 사용하면 고객이 시퀀서나 소비자와 같은 리전에 노드 풀을 배치할 수 있다.

규제상의 격리

일부 컴플라이언스 프레임워크는 단일 테넌트 컴퓨팅을 요구한다. 고객 데이터 분리에 관한 SOC 2 Type II 통제, 특정 은행 및 증권 규제, 대형 금융기관의 내부 리스크 검토는 종종 동일한 요구사항으로 수렴한다: 다른 어떤 고객의 워크로드도 같은 호스트에서 실행되어서는 안 된다는 것이다.

Shared 인프라는 설계상 여러 고객을 같은 호스트에서 실행한다. Dedicated 인프라는 그렇지 않다.

제한 없는 쿼리 범위

Shared RPC 제공업체는 클러스터를 쿼리 폭탄으로부터 보호하기 위해 eth_getLogs 범위를 제한한다. 사용자의 최근 트랜잭션을 조회하는 지갑에는 문제가 없으며, 대부분의 분석 워크로드가 원시 eth_getLogs 대신 인덱싱된 Data API로 라우팅되는 이유이기도 하다.

하지만 대규모 히스토리 범위의 원시 로그를 스캔해야 하는 익스플로러, 인덱서, 체인 분석 팀에게는 이 제한이 병목이 된다. Dedicated 클러스터는 이 제한을 해제할 수 있는데, 이 제한이 존재하는 이유가 다른 테넌트를 보호하기 위함이고, 단일 테넌트 클러스터에는 보호할 다른 테넌트가 없기 때문이다.

빠른 참고용 결정 기준:

워크로드가 네 가지 dedicated 패턴 중 어디에도 해당하지 않는다면, shared 인프라가 거의 항상 더 저렴하고 단순하며 빠르게 구축할 수 있다.

Dedicated 클러스터는 어떻게 동작하는가?

Dedicated 클러스터의 아키텍처는 결국 여섯 가지 선택으로 귀결된다: 이 박스에서 다른 누가 같이 돌아가는지, 박스가 어디에 있는지, 몇 대인지, 상태에 대해 어떻게 합의하는지, 어떤 소프트웨어를 실행하는지, 그리고 어떻게 과금하는지.

단일 테넌트 격리

단일 테넌트는 고객의 노드가 해당 고객의 워크로드를 위해 예약된 컴퓨팅에서 실행됨을 의미한다. 실무적으로 컴플라이언스 검토에서는 워크로드 격리, 접근 통제, 감사 가능성, 키 관리에 대한 문서화를 요구하는 경우가 많다.

격리가 실질적으로 배제하는 것은 다음과 같다. Shared 호스트의 노이지 네이버가 고객의 테일 레이턴시를 저하시킬 수 없다. 이웃이 없기 때문이다. 다른 테넌트로부터의 사이드 채널 유출이 고객의 프로세스에 도달할 수 없다. 컴플라이언스 검토자는 "제공업체가 워크로드를 분리해 둘 것이라고 믿는다"는 말 대신 문서화된 통제를 제시할 수 있다.

리전별 배포

클라이언트에서 RPC 노드까지의 지연 시간은 네트워크 거리에 의해 제한된다. 대부분의 애플리케이션 트래픽에서는 이것이 눈에 띄지 않는다. 지연에 민감한 요청을 빈번히 보내는 워크로드의 경우, 노드를 스택, 사용자, 시퀀서, 밸리데이터에 더 가깝게 배치하는 것이 경쟁력 있는 제품과 느린 제품을 가르는 차이가 될 수 있다.

우리는 197개국의 고객에게 서비스를 제공하며, Dedicated Clusters를 사용하면 워크로드에 필요한 리전에 노드 풀을 배치할 수 있다. 주요 사용자 지리별로 클러스터를 하나씩 두는 경우든, 특정 롤업의 시퀀서와 같은 위치에 하나를 두는 경우든 마찬가지다. 트레이드오프는 운영상의 부담이다: 리전이 늘어날수록 모니터링하고, 패치하고, 비용을 지불해야 할 클러스터가 늘어난다. 대부분의 워크로드는 한두 개면 충분하다.

N+1 이중화와 페일오버

Dedicated 클러스터는 고객의 목표 용량에 예비 노드 하나를 더해 실행한다. 어떤 노드가 성능 저하를 겪거나 재시작되면, 트래픽은 고객이 알아채지 못하는 사이 예비 노드로 이동한다. 이것이 N+1 패턴으로, 단일 노드 장애 시에도 가용성을 잃지 않아야 하는 모든 서비스에 대한 표준적인 형태다.

더 어려운 질문은 부하가 클러스터의 용량을 초과할 때 어떻게 되느냐다. 여기에는 두 가지 실제 사례가 있다: 체인이 바빠져서 클러스터의 요청량이 급증하는 체인 혼잡 상황, 그리고 캠페인, 이벤트, 또는 통합 출시로 인한 고객 트래픽 급증이다. 정상 부하에 맞춰 사이징된 클러스터는 큰 스파이크 상황에서 속도 제한에 걸릴 수 있다.

여기에는 두 가지 아키텍처적 해법이 있다. 하나는 클러스터를 피크에 맞춰 사이징하는 것으로, 대부분의 시간 동안 유휴 용량에 대해서도 비용을 지불해야 한다. 다른 하나는 shared 인프라로의 자동 페일오버다: 클러스터가 포화 상태가 되면 429 응답을 반환하는 대신 트래픽이 제공업체의 shared 플릿으로 넘어간다. 고객은 동일한 API, 동일한 인증, 동일한 응답 형태를 그대로 유지한다. 페일오버가 더 효율적인 패턴이지만, 이를 위해서는 dedicated 제공업체가 일류 수준의 shared 인프라도 함께 운영해야 한다.

블록 단위의 완벽한 일관성

로드 밸런싱된 노드 풀 내의 서로 다른 노드들은 최신 블록에 대해 수백 밀리초 동안 의견이 다를 수 있다. 가장 빠른 노드는 블록 N을 보고, 가장 느린 노드는 여전히 N-1에 머물러 있다. 잔액을 조회하는 지갑에게는 이것이 눈에 띄지 않는다. 하지만 서로 다른 노드를 통해 같은 블록을 두 번 읽고 일관되지 않은 상태를 받는 트레이딩 봇에게는 실질적인 버그다.

블록 단위의 완벽한 일관성이란 클러스터가 노드 풀 전체에 걸쳐 일관된 체인 상태 뷰를 반환하여, 상태를 유지하는 클라이언트가 오래되거나 상충하는 읽기 결과를 보지 않도록 하는 것을 의미한다. 이 트레이드오프는 클러스터가 속도뿐 아니라 정확성에도 최적화된다는 것이며, 이는 워크로드가 최신 체인 상태를 바탕으로 결정을 내릴 때 가장 중요하다.

커스텀 트레이서와 바이너리

Dedicated 런타임을 사용하면 고객은 커스텀 자바스크립트 트레이서를 실행하거나, 패치된 geth 빌드를 배포하거나, 클라이언트를 교체하거나, shared 제공업체가 전역적으로 고정하는 클라이언트 설정을 수정할 수 있다. Shared 제공업체는 이 표면을 노출할 수 없는데, 클라이언트 버전이나 설정을 바꾸면 해당 호스트의 모든 테넌트에 영향을 미치기 때문이다.

이것이 시뮬레이션, 포렌식, 분석 제품이 만들어질 수 있는 기반이 되는 역량이다. 이들 제품의 가치는 표준 트레이서 인터페이스가 노출하지 않는 실행 상태를 추출하는 데서 나온다. Dedicated 런타임이 없다면 이 제품은 존재할 수 없다.

용량 기반 과금

Shared 인프라는 일반적으로 호출당 컴퓨트 유닛을 기준으로 요청당 과금하며, 무거운 메서드에는 배수를 적용한다. Dedicated 인프라는 클러스터당 과금한다: 고객이 보내는 요청 수와 무관하게 약정된 용량에 대해 고정된 월 요금을 부과한다.

이 모델은 예측 가능한 피크 부하를 가지고 있어서 그렇지 않으면 규모에 따라 shared 컴퓨트 유닛을 대량으로 소진하게 될 워크로드에 적합하다. Dedicated 클러스터에서는 추가 요청 하나의 한계 비용이 워크로드가 클러스터의 한도에 도달하기 전까지는 0이다. 워크로드별 특정 임계값을 넘으면, dedicated가 여는 다른 역량들을 고려하기 전이라도 용량 기반 과금이 요청당 과금보다 저렴할 수 있다.

Shared가 올바른 기본 선택인 경우는 언제인가?

Shared와 dedicated 인프라 중 하나를 선택할 때 고려해야 할 것은 세 가지다. 트레이드오프에 대한 더 깊은 설명은 Node RPC와 Dedicated Clusters 중 선택하기에 대한 개요를 참고하라.

Dedicated가 RPC 스택 자체를 본질적으로 더 빠르게 만들지는 않는다

밑바탕이 되는 RPC 스택은 동일하므로, 조용한 시스템에서의 단일 요청 벤치마크만으로는 전체 그림을 알 수 없다. Dedicated는 클러스터가 워크로드에 더 가깝게 배치될 때 지연 시간을 개선하며, 격리가 지속적인 부하 아래에서 P99(가장 느린 1%의 요청)를 보호할 때 예측 가능성을 개선한다.

여러 제공업체에 걸친 shared RPC 성능에 대한 최신 공개 데이터는 Alchemy의 RPC provider benchmarks를 참고하라.

멀티 리전 shared가 단일 리전 dedicated보다 더 잘 버틸 수 있다

단일 리전 클러스터를 마비시키는 리전 단위 클라우드 장애는 전 세계적으로 분산된 shared 플릿에서는 거의 눈에 띄지 않는다. 실용적인 배포 방식은 핵심 리전에서는 dedicated를, 전역 기본값으로는 shared를 병행하는 것이다.

네 가지 패턴 테스트는 엄격하다

워크로드가 커스텀 런타임, 리전 요구사항, 규제상 격리, 쿼리 범위 제한 중 어느 하나에도 해당하지 않는다면, shared가 더 저렴하고 단순하며 대체로 더 안정적이다. Dedicated로의 전환은 대개 선호가 아니라 필연적인 요구에 의해 이루어진다.

Alchemy는 전용 블록체인 인프라를 어떻게 지원하는가?

대부분의 워크로드는 shared로 시작해서 계속 shared에 머무른다. 우리의 RPC API와 Data API는 dedicated를 구동하는 것과 동일한 Cortex 플랫폼 위에서 동작하며, 무료 티어를 제공하고 계약이나 최소 약정이 필요 없다. 대시보드에서 API 키를 발급받아 몇 분 안에 요청을 보내기 시작할 수 있다.

워크로드가 네 가지 패턴, 즉 커스텀 트레이서, 리전 요구사항, 규제상 격리, 쿼리 범위 제한 중 하나에 해당하게 되면, Alchemy Dedicated Clusters는 동일한 인프라 위에서 단일 테넌트 용량을 제공한다. 우리는 커스텀 트레이서와 바이너리, 리전별 배포, shared로의 자동 페일오버를 갖춘 N+1 이중화, 블록 단위의 완벽한 일관성, 첫날부터 제공되는 Grafana 대시보드, 그리고 규제 환경을 위한 SOC 2 Type II 준수 인프라를 지원한다. 과금은 요청당 사용량이 아니라 프로비저닝된 용량을 기준으로 하므로, 예측 가능한 부하를 가진 팀은 고정된 월간 인프라 비용을 기준으로 계획을 세울 수 있다.

Dedicated 클러스터는 여러분의 워크로드에 맞춰 범위를 한정한 동일한 인프라다. Shared 인프라로 충분하다면 shared를 계속 사용하라. 만약 여러분의 워크로드가 그럴 수 없는 소수에 해당한다면, 우리 팀과 이야기해 보라.

FAQ

전용 블록체인 인프라와 shared RPC의 차이는 무엇인가?

Shared RPC는 관리형 플릿 전반에 걸쳐 여러 고객을 함께 운영한다. 전용 블록체인 인프라는 런타임, 용량, 데이터 경로를 하나의 워크로드를 위해 예약한다. API 표면은 동일하게 유지될 수 있지만, dedicated는 단일 테넌트 격리, 커스텀 런타임 옵션, 리전별 배치, 용량 기반 과금을 추가한다.

전용 Ethereum 노드에서 커스텀 트레이서를 실행할 수 있는가?

가능하다. Dedicated 클러스터는 단일 테넌트이므로, shared 엔드포인트가 호스팅할 수 없는 커스텀 트레이서를 실행할 수 있다. 표준 callTracer와 prestateTracer와 함께, dedicated 런타임에서는 자체 JavaScript 트레이서나, 표준 인터페이스가 노출하지 않는 실행 상태를 드러내는 수정된 geth 또는 erigon 바이너리를 배포할 수 있다. 보안, 시뮬레이션, 포렌식 팀이 dedicated를 운영하는 이유다. 이들의 제품은 shared 인프라가 전역적으로 고정하는 트레이싱에 의존한다.

전용 인프라는 프라이빗 RPC 엔드포인트와 같은 것인가?

항상 그런 것은 아니다. 프라이빗 RPC 엔드포인트는 shared 인프라 상의 고객 전용 URL이나 접근 정책을 의미할 수 있다. 전용 인프라는 여기서 더 나아가, 노드 풀과 이를 뒷받침하는 런타임을 한 고객의 워크로드를 위해 예약한다.

팀이 전용 인프라를 피해야 할 때는 언제인가?

워크로드가 커스텀 바이너리, 규제상 격리, 리전 특정 배치, 또는 비정상적으로 큰 원시 쿼리 범위를 필요로 하지 않는다면 전용 인프라를 피하라. 이런 경우 shared RPC가 대체로 더 단순하고, 저렴하고, 탄력적이며, 빠르게 구축할 수 있다.

Dedicated와 shared 인프라를 함께 운영할 수 있는가?

가능하다. Dedicated Clusters를 사용하는 대부분의 팀은 하이브리드 구성으로 운영한다: 엄격한 요구사항이 있는 체인이나 워크로드에는 dedicated를, 나머지 모든 것에는 shared RPC를 사용한다. API가 동일하므로, 두 가지 사이에서 워크로드를 옮기는 것은 대체로 엔드포인트와 라우팅에 관한 결정일 뿐이다.

Dedicated 클러스터의 과금은 어떻게 이루어지는가?

Dedicated 클러스터는 요청당 사용량이 아니라 프로비저닝된 용량을 기준으로 과금된다. 가격은 체인, 노드 유형, 처리량, 리전, 포함된 기능에 따라 달라진다. 지속적으로 높은 부하를 가진 워크로드의 경우, 고정 용량 과금이 요청당 과금보다 예측하기 쉬울 수 있다.

Dedicated 클러스터는 얼마나 빨리 프로비저닝될 수 있는가?

프로비저닝 소요 시간은 체인, 클라이언트, 리전, 설정에 따라 달라진다. 요구사항이 표준적이라면 일부 클러스터는 빠르게 배포될 수 있다. 커스텀 바이너리, 특수 하드웨어, 새로운 리전 같은 더 복잡한 구성에는 더 많은 계획이 필요하다.