저지연 RPC 인프라를 구축한 방법

지갑은 사용자의 잔액을 불러옵니다. 트레이딩 앱은 스왑 전에 가스를 추정합니다. 인덱서는 수개월치 히스토리를 한 번에 백필합니다. 이 모든 동작은 하나의 RPC 호출이며, 그 지연 시간의 1밀리초까지도 화면 앞에서 기다리는 실제 사용자가 체감합니다.

RPC 지연은 한 가지 원인으로 발생하지 않으므로 한 가지 방법으로는 해결할 수 없습니다. 요청 경로 오버헤드, 피할 수 있는 내부 네트워크 이동, 비효율적인 라우팅, 갑작스러운 트래픽 급증, 체인 및 노드 운영 지연, 워크로드별 병목, 불완전한 측정에서 비롯됩니다. 하나를 고치고 나머지를 방치하면 병목이 옮겨갈 뿐입니다. 그래서 우리는 지연 문제를 시스템 전체의 문제로 다루고, 우리가 통제할 수 있는 모든 레이어에 투자해, 지원하는 100개 이상의 체인 전반에서 99.99%의 가동률과 평균 50ms 미만의 응답 시간을 기본값으로 유지하고 있습니다.

우리가 만든 것

Alchemy Edge Proxy는 요청 경로 오버헤드를 줄입니다

엣지는 관문입니다. 즉 요청이 처음 닿는, Alchemy가 통제하는 진입점입니다. 요청이 어떤 노드에든 도달하기 전에 연결 설정, TLS 협상, 인증, 라우팅 로직을 거칩니다. 각 단계마다 밀리초가 추가되며, 이 밀리초들은 꼬리 부분, 즉 사용자가 실제로 체감하는 가장 느린 요청들에서 가장 크게 누적됩니다.

Alchemy Edge Proxy는 이 오버헤드를 요청 경로에서 제거하기 위해 만든 레이어입니다. 연결 재사용, 인증, 라우팅 결정을 스택 안쪽이 아니라 관문에서 처리함으로써, 모든 요청이 지불하는 고정 비용을 줄입니다. 그 결과 꼬리 부분에서 최대 7.5배 빠른 RPC를 얻습니다. 더 자세한 내용은 Alchemy Edge Proxy를 참고하세요.

내부적으로 엣지는 마이크로커널 프록시 아키텍처로 동작하며, 이는 Cortex의 일부입니다. 작고 안정적인 코어가 핵심 요청 경로를 담당하고, 인증, 레이트 리밋, 라우팅 같은 모듈은 독립적으로 업데이트됩니다. 엣지는 우리가 처음부터 끝까지 통제하는 핵심 인프라 레이어 중 하나이기 때문에, 다른 누군가의 네트워크를 기다릴 필요 없이 계속 개선할 수 있습니다.

인프라 내부: 더 가까운 배치, 더 똑똑한 라우팅, 안정적인 처리량

요청이 우리 인프라 내부에 들어온 후에도 거리와 하드웨어는 여전히 시간을 소모합니다. 호출을 처리하는 서비스들이 서로 멀리 떨어져 있으면, 실제 작업이 시작되기도 전에 요청은 그 사이를 이동하는 데 밀리초를 소비합니다. 그리고 트래픽이 증가하면 공유 하드웨어는 불규칙한 지연으로 나타나는 변동성을 더합니다.

이 부분에서 Alchemy의 지능형 블록체인 엔진인 Cortex가 핵심 역할을 합니다. Cortex는 우리의 낮은 지연 수치를 뒷받침하는 핵심 인프라 투자이며, 그중 몇 가지 요소가 여기서 중요합니다.

• Kubernetes affinity를 이용한 Pod colocation은 서로 가장 많이 통신하는 서비스들을 같은 머신에 배치해, 요청이 랙을 넘나드는 대신 로컬에 머물도록 합니다.
• Istio의 locality-aware 라우팅은 내부 트래픽을 가장 가까운 서비스 인스턴스로 보내, 실제로 도움이 될 때 인프라 경로를 단축합니다.
• 전 세계에 배포된 수천 대의 베어메탈 서버는 가상화 오버헤드 없이 전용 하드웨어에서 직접 동작해, 고부하 상황에서도 처리량이 일정하게 유지됩니다.
• Java virtual threads는 기존 스레드의 메모리 및 CPU 비용 없이 한 대의 머신이 훨씬 더 많은 동시 요청을 처리할 수 있게 하며, 이것이 지연 증가 없이 급증을 흡수하는 요소입니다.

이 요소들이 합쳐져 사용자가 생각하지는 않지만 항상 체감하는 이동 시간을 줄이고, 물량이 늘어도 성능을 안정적으로 유지합니다.

예측 스케일링은 급증 이전에 용량을 준비합니다

온체인 트래픽은 예의 바르게 증가하지 않습니다. 런칭, 민팅, 또는 시장 이벤트는 몇 초 만에 부하를 몇 배로 늘릴 수 있으며, 급증 이후에 도착하는 용량은 너무 늦게 도착한 용량입니다.

우리의 예측 스케일링 로직은 수요에 반응하는 대신 미리 용량을 준비합니다. CPU, 메모리, 디스크 I/O, 트래픽 패턴 같은 신호를 관찰해 급증이 오기 전에 프로비저닝합니다. Usual이 그 증거입니다. 이들은 초당 30,000건의 요청으로 정점을 찍었고, 첫 한 시간 동안 3,800만 건의 요청을 처리했으며, 36시간 만에 10억 건의 요청을 돌파했지만, 급증 상황에서도 지연이 무너지지 않았습니다.

"Alchemy는 초당 막대한 양의 요청을 처리하면서도 거의 완벽한 가용성을 제공했습니다. 초당 30,000건이 우리의 정점이었고, 그럼에도 여유가 있었습니다. 어떤 문제나 다운타임도 없었습니다. 그것도 촉박한 통보에도 불구하고 말이죠!"

Adli Takkal-Bataille, Usual

AI 기반 플릿 자동화는 노드 운영을 최신 상태로 유지합니다

블록체인은 그 아래에서 계속 변합니다. 클라이언트는 업데이트를 배포하고, 네트워크는 하드포크를 예약하며, 오래된 소프트웨어를 실행하는 노드는 느리거나 잘못된 응답을 제공하는 노드입니다. 이를 수작업으로 처리하면 정확성이 가장 중요한 바로 그 순간에 지연과 위험이 발생합니다.

우리의 노드 플릿은 업그레이드, 테스트, 모니터링을 처리하는 완전 자동화된 에이전틱 시스템으로 관리됩니다. 업데이트는 실시간으로 감지되고 적용되며, 파이프라인에 자동화된 테스트가 내장되어 있어 필수 네트워크 업그레이드와 하드포크를 놓치지 않습니다. 우리가 운영하는 모든 체인에 걸쳐 이를 수작업으로 최신 상태를 유지하는 것은 불가능했을 것입니다. 그래서 이를 자동화했고, 그 덕분에 소수의 선호 체인이 아니라 100개 이상의 체인 전반에서 동일하게 낮은 지연 기준을 유지하고 있습니다. 이 자동화는 Alchemy 플랫폼 전체(RPC APIs, 데이터 API, 롤업, 그 외 개발자 스택 전체)를 뒷받침하는 지능형 블록체인 엔진 Cortex의 일부입니다.

제품별 최적화는 전체 사용자 플로우를 개선합니다

지연은 단일 호출만의 문제가 아닙니다. 실제 제품은 여러 호출을 연결해 사용하며, 플로우의 속도는 가장 느린 연결 고리만큼만 빠릅니다. 사용자가 실제로 체감하는 것은 단일 메서드가 아니라 전체 경로입니다.

Tools for Humanity가 만들고 World Chain 위에서 동작하는 World는 마이닝 소요 시간이 5.5초에서 3.1초로 44% 빨라졌고, alchemy_requestGasAndPaymasterAndData에서의 가스 추정 지연이 약 380ms에서 100ms로 74% 줄었습니다.

"인프라 벤더를 찾을 때 가장 중요했던 것은 엔터프라이즈급 규모와 지원이었습니다. Alchemy는 우리가 필요로 했던 모든 제품 영역에서 압도적인 선두주자였고, 유일하게 합리적인 선택이었습니다."

Steven, Tools For Humanity

Solana 아카이벌 인프라는 무거운 쿼리의 지연을 줄입니다

히스토리 및 아카이벌 쿼리는 그 자체로 어려운 문제입니다. 과거 상태의 넓은 범위를 조회하는 것은 무거운 작업이며, Solana처럼 처리량이 높은 체인에서는 이를 위해 만들어지지 않은 인프라에서는 속도가 크게 떨어질 수 있습니다. 우리는 커스텀 멀티 리전 HBase 아키텍처 위에서, Solana 플랫폼의 일부로 Solana에서 가장 빠른 아카이벌 메서드를 구축했습니다.

Solflare는 바로 이 워크로드를 실제로 운영했고, 최대 20배 빠른 아카이브 쿼리, 대규모 히스토리 쿼리에서 200ms 미만의 응답 시간, 1분 이내에 완료되는 지갑 백필을 확인했습니다.

"Alchemy의 Archival RPC는 일관된 <200ms 응답 시간을 유지하면서도 Solflare의 처리량을 따라잡았습니다."

Dusan K., Solflare

벤치마크 방법론은 속도와 신뢰성을 함께 측정합니다

모든 요청에 실제로 무슨 일이 일어났는지에 대한 정직함 없이는 속도 수치는 아무 의미가 없습니다. 실패하거나 누락된 호출을 감춘 빠른 평균값은 빠른 것이 아니라 오해를 불러일으키는 것입니다.

우리의 벤치마크 방법론은 지연을 성공률 및 실패한 요청과 함께 측정해, 그 수치가 실제 워크로드가 경험하는 바를 반영하도록 합니다. 이는 우리가 스스로에게 적용하는 기준이며, 여러분도 우리에게 요구해주길 바라는 기준입니다. 전체 벤치마크 방법론을 확인할 수 있습니다.

목표: 사라질 만큼 빠른 인프라

가장 좋은 인프라는 아무도 눈치채지 못하는 인프라입니다. 지연이 충분히 낮고 신뢰성이 충분히 높으면, 지갑은 그냥 로드되고, 스왑은 그냥 확인되고, 백필은 그냥 끝납니다. 이 스택의 어떤 레이어도 단독으로 지연 문제를 해결하지 않지만, 모두 합쳐지면 그런 경험을 만들어냅니다.

직접 수치를 확인해보세요. Alchemy 벤치마크 페이지에서 프로바이더들을 비교하고, RPC 성능을 측정하는 방법을 정확히 읽어 결과뿐 아니라 방법론도 직접 판단해보세요. 준비가 되면 무료로 시작하세요.

FAQ

RPC 지연의 원인은 무엇인가요?

RPC 지연은 여러 독립적인 원인에서 비롯됩니다. 진입점에서의 요청 경로 오버헤드, 내부 서비스 간 피할 수 있는 이동, 비효율적인 라우팅, 트래픽 급증, 체인 및 노드 운영 지연, 워크로드별 병목, 불완전한 측정이 그것입니다. 원인이 서로 독립적이기 때문에 단 하나의 수정으로 모든 것을 제거할 수는 없습니다.

하나의 최적화로 RPC 지연을 해결할 수 있나요?

아니요. 한 가지 원인을 고치면 병목이 다음 원인으로 옮겨갈 뿐입니다. 지연을 안정적으로 줄이려면 엣지부터 노드 인프라, 그리고 성능을 측정하는 방식에 이르기까지 요청 경로의 모든 레이어에 투자해야 합니다.

RPC 인프라에서 엣지란 무엇인가요?

엣지는 요청이 도달하는 최초의 프로바이더 통제 진입점, 즉 RPC 트래픽의 관문입니다. 연결 설정, 인증, 라우팅을 스택 안쪽이 아니라 이곳에서 처리하면 모든 요청이 그렇지 않았다면 지불했을 고정 오버헤드를 없앨 수 있습니다.

Alchemy는 RPC 지연을 어떻게 정직하게 측정하나요?

Alchemy는 지연을 단독 평균값이 아니라 성공률 및 실패한 요청과 함께 측정합니다. 이렇게 하면 빨라 보이는 수치가 누락되거나 실패한 호출을 감추는 것을 방지해, 결과가 실제 프로덕션 워크로드가 실제로 경험하는 바를 반영하도록 합니다.

예측 스케일링은 트래픽 급증을 어떻게 처리하나요?

예측 스케일링은 급증이 시작된 후 반응하는 대신 수요에 앞서 용량을 준비합니다. 이것이 Usual이 급증 중에도 지연 저하 없이 초당 30,000건의 요청과 36시간 동안 10억 건 이상의 요청을 유지할 수 있었던 이유입니다.

Solana의 아카이벌 쿼리 성능이 왜 별도의 문제인가요?

아카이벌 쿼리는 넓은 범위의 히스토리 상태를 조회하는데, 이는 그 자체로 무거운 작업이며, Solana의 높은 처리량은 그 범위를 더욱 크게 만듭니다. 목적에 맞게 설계된 아카이벌 인프라가 이런 쿼리를 빠르게 유지하는 핵심이며, Solflare의 최대 20배 빠른 아카이브 쿼리가 이를 보여줍니다.