엣지 레이어가 Alchemy의 RPC를 더 빠르게 만드는 방법

Alchemy는 서드파티 CDN으로 RPC 트래픽을 받는 대신 베어메탈 위에서 자체 엣지 계층을 운영합니다. 지리적 근접성 기반 DNS가 각 요청을 가장 가까운 Alchemy 리전(US East, US West, EU Central, Southeast Asia)으로 해석하며, 리전별 헬스 체크가 사용자의 조치 없이 트래픽을 다음으로 가까운 리전으로 자동 페일오버합니다. 2025년 10월 배포 이후 APAC의 P99 지연 시간은 150ms에서 20ms로 줄었습니다.

매년 수조 달러 규모의 가치가 블록체인 인프라를 통해 이동합니다. Solana에서의 DeFi 스왑, Ethereum에서의 스테이블코인 전송, Polygon에서의 예측 시장 정산: 이러한 거래들은 모두 노드에 도달하기 전 여러 네트워킹 계층을 거치는 RPC 호출에 의존합니다. 금융 활동이 온체인에서 실행될 때, 그 경로상의 매 밀리초는 위험에 노출된 돈입니다.

100개 이상의 블록체인 네트워크에서 수조 건의 요청을 처리하는 인프라 제공자에게, 사용자와 데이터 센터 사이의 계층이야말로 성능의 승패가 갈리는 지점입니다. 그 계층이 바로 엣지입니다. 그리고 2025년 하반기, Alchemy는 이를 처음부터 다시 구축했습니다.

온체인 금융에서 RPC 지연 시간이 중요한 이유는 무엇인가요?

블록체인 사용자와 애플리케이션은 전 세계에 분산되어 있습니다. 싱가포르의 트레이딩 봇, 프랑크푸르트의 지갑 앱, 버지니아의 DeFi 프로토콜 백엔드까지 모두 블록체인 상태를 읽고 거래를 제출하기 위해 RPC 호출을 실행합니다. 이러한 호출이 빨리 처리될수록 경험은 더 좋아집니다.

DeFi에서 지연 시간은 곧바로 실행 품질로 이어집니다. 느린 eth_call은 오래된 가격 데이터를 의미합니다. 거래 제출 지연은 더 나쁜 체결 또는 거래 실패를 의미합니다. 지갑 애플리케이션의 경우, 로딩 시간이 100ms 늘어날 때마다 사용자를 온체인에 머물게 하는 경험이 저하됩니다.

하지만 지연 시간은 방정식의 절반에 불과합니다. 안정성도 그만큼 중요합니다. RPC 제공자가 모든 트래픽을 단일 서드파티 CDN을 통해 라우팅한다면, 그 CDN은 단일 장애 지점이 됩니다. 장애가 발생하면 모든 네트워크, 모든 고객, 모든 요청이 함께 중단됩니다.

Alchemy Edge Proxy란 무엇인가요?

Edge Proxy는 Alchemy의 RPC 인프라로 들어가는 현관문이라고 생각하면 됩니다. Ethereum 상태를 읽든, Solana 계정을 조회하든, Base에서 거래를 제출하든 모든 API 요청은 이 인그레스 계층을 통과한 뒤 그 뒤에 있는 서빙 인프라에 도달합니다.

Alchemy는 오랫동안 이 현관문 역할로 주요 CDN을 사용했습니다. CDN이 업계에서 널리 선택되는 데는 이유가 있습니다: DDoS 방어, 지리적 라우팅, WAF 규칙, SSL 종료 기능을 기본으로 제공하기 때문입니다. 대부분의 웹 애플리케이션에는 이 정도 구성으로 충분합니다. CDN은 지난 20년간 전자상거래부터 스트리밍까지 모든 것의 기본 인그레스 계층 역할을 해왔고, 그럴 만한 자격이 있습니다.

온체인 금융은 요구 사항이 다릅니다. RPC 트래픽은 버스트성이 강하고, 지연 시간에 민감하며, 지리적으로 전 세계에 걸쳐 있고, 일반적인 웹 트래픽과는 다른 방식으로 보안이 중요합니다. 세 개의 체인에서 병렬로 상태를 읽는 트레이딩 봇은 CDN이 마케팅 페이지를 50개 도시에서 캐싱할 수 있는지 신경 쓰지 않습니다. 그것이 신경 쓰는 것은 eth_call을 실행하고 응답을 받기까지의 시간입니다. 잔액을 동기화하는 지갑은 SQL 인젝션 방어를 위한 WAF 규칙이 필요하지 않습니다. 가장 가까운 엣지 노드와 한 자릿수 밀리초 안에 완료되는 TLS 핸드셰이크가 필요합니다. 파생상품 거래소에서 포지션을 정산하는 프로토콜은 서드파티 CDN의 장애 대응 시간을 자신의 가동 시간의 한계로 받아들일 수 없습니다.

이러한 요구를 충족하기 위해, 저희는 베어메탈 위에 커스텀 엣지 프록시를 구축했습니다: 높은 처리량과 낮은 지연 시간이 필요한 블록체인 RPC 트래픽을 위해 처음부터 목적에 맞게 설계된 인그레스 계층입니다. 이는 여러 글로벌 리전에 걸쳐 Alchemy가 직접 관리하는 인프라 위에서 동작하며, CDN 계층의 모든 보호 기능을 네트워크별로 조정 가능한 동등하거나 더 강력한 계층으로 대체하고, 핵심 서빙 경로에서 서드파티 의존성을 완전히 제거합니다.

2025년 10월 배포에서 APAC의 P99 지연 시간은 150ms에서 20ms로, 중앙값 지연 시간은 약 35ms에서 약 5ms로 줄었으며, 이는 100개 이상의 네트워크에서 측정한 결과입니다.

Alchemy Edge Proxy는 어떻게 동작하나요?

Edge Proxy 아키텍처는 여러 글로벌 리전(US East, US West, EU Central, Southeast Asia 등)의 전용 베어메탈 서버에서 실행되는 두 개의 핵심 컴포넌트로 구성됩니다.

Istio Ingress Gateway

첫 번째 컴포넌트는 데이터 플레인으로 Envoy를 사용하는 Istio Ingress Gateway입니다. 이는 TLS 종료, 연결 관리, 요청 프록싱을 처리합니다. Envoy는 Lyft, Google Cloud, AWS App Mesh에서 대규모 트래픽을 처리하는 데 사용되는 것과 동일한 프록시입니다. 비동기 논블로킹 C++ 코어, HTTP/2 멀티플렉싱, 사전에 워밍업된 업스트림 연결 풀 덕분에 높은 처리량과 낮은 지연 시간이 요구되는 인그레스에 적합합니다.

Edge Proxy Control Plane (EPCP)

두 번째 컴포넌트는 ext_authz 필터로서 Envoy와 나란히 실행되는 커스텀 컨트롤 플레인입니다. 들어오는 모든 요청에 대해 EPCP는 다음을 평가합니다:

• URL, 헤더, 대상 블록체인 네트워크에 따라 요청을 어디로 라우팅할지
• 해당 요청에 사용 가능한 백엔드 클러스터는 무엇인지(예: 아카이브 노드 클러스터, AWS 기반 서비스, 리전별 엔드포인트)
• 보안 또는 규정 준수 사유로 요청을 차단해야 하는지
• 헬스 체크를 통해 로컬 리전에서 정상 작동 중인 네트워크는 무엇인지

그런 다음 EPCP는 Envoy에 요청을 어디로 전달할지 알려주는 라우팅 헤더를 주입합니다. 이 설계는 핫 패스를 빠르게 유지하면서(Envoy가 프록싱을 담당) 라우팅 로직은 유연하고 동적으로 구성 가능하게 유지합니다.

요청 처리 흐름

일반적인 성공 요청이 시스템을 통과하는 방식은 다음과 같습니다:

1. 클라이언트가 *.g.alchemy.com로 RPC 요청을 보냅니다.
2. 지리 기반 DNS가 요청을 가장 가까운 Edge Proxy 리전으로 해석합니다.
3. Istio Ingress Gateway가 요청을 받아 ext_authz를 통해 EPCP에 전달합니다.
4. EPCP는 요청을 검증(OFAC 확인, 보안 규칙)하고, 목적지 클러스터를 결정한 뒤 라우팅 헤더를 반환합니다.
5. Istio가 요청을 적절한 백엔드로 전달합니다.
6. 응답이 클라이언트로 직접 반환됩니다.

지리 기반 DNS 라우팅

Edge Proxy는 지리적 근접성 기반 DNS 해석을 사용합니다. 이는 DNS 계층이 체인이나 네트워크에 관계없이 동작한다는 의미입니다: Ethereum 메인넷 요청과 Solana 메인넷 요청 모두 동일한 리전의 Edge Proxy로 해석됩니다. Edge Proxy 자체가 네트워크 인식 라우팅을 내부적으로 처리합니다.

이 설계에는 여러 장점이 있습니다:

• 최종적으로 필요한 블록체인 네트워크와 무관하게, DNS 해석과 TLS 핸드셰이크가 가장 가까운 엣지 위치에서 이루어집니다.
• 새로운 블록체인 네트워크를 추가하는 데 DNS 변경이 전혀 필요하지 않습니다.
• 리전별 헬스 체크는 Edge Proxy 수준에서 실행됩니다. Edge Proxy 리전이 비정상 상태가 되면 DNS는 자동으로 다음으로 가까운 리전으로 페일오버됩니다.

동적 구성

Edge Proxy는 내부 구성 플랫폼에서 라우팅 구성을 가져옵니다. 이를 통해 재배포 없이 런타임 변경이 가능합니다:

리전을 비워야 하거나, 네트워크 재라우팅이 필요하거나, 새로운 보안 규칙을 적용해야 할 때, 구성 업데이트는 실행 중인 프록시를 건드리지 않고 전파됩니다.

CDN 없이 보안 모델은 어떻게 동작하나요?

CDN 의존성을 제거한다는 것은 모든 보안 보호 기능을 처음부터 다시 구축해야 한다는 의미였습니다. Edge Proxy는 CDN의 보호 기능을 계층적 접근 방식으로 대체합니다:

핵심은 이렇습니다: 이러한 보호 기능은 CDN보다 약하지 않습니다. 오히려 더 정밀합니다. Alchemy는 모든 계층을 직접 관리하고, 네트워크별로 임계값을 조정할 수 있으며, 문제가 발생했을 때 서드파티의 장애 대응 시간에 의존하지 않습니다.

Alchemy Edge Proxy는 어떤 결과를 가져왔나요?

Edge Proxy는 2025년 10월 3주에 걸쳐 100개 이상의 블록체인 네트워크에 배포되었으며, 고객 측 마이그레이션은 전혀 필요하지 않았습니다. 결과는 즉각적이었습니다.

지연 시간

고객 측 텔레메트리에서도 다양한 워크로드에 걸쳐 비슷한 수준의 개선이 나타났으며, 지연 시간에 가장 민감한 워크로드에서 가장 큰 개선 폭을 보였습니다.

현재 공개된 제공자 데이터를 확인하려면 체인, 리전, 공통 메서드별 RPC 지연 시간 벤치마크를 비교해 보세요.

안정성

이전의 CDN 기반 구성이었다면 업스트림 장애에 노출되었을 동일한 기간 동안, Alchemy의 인프라는 영향을 받지 않고 운영되었습니다.

다른 인프라 접근 방식과 비교하면 어떨까요?

블록체인 API 인프라의 인그레스를 처리하는 데는 일반적으로 세 가지 접근 방식이 있습니다:

커스텀 엣지 프록시는 직접 연결이 가진 지연 시간 이점과 CDN이 가진 보호 및 트래픽 유연성을 결합하면서도, 어느 쪽의 벤더 의존성이나 비용 확장 문제도 겪지 않습니다.

일부 RPC 제공자는 CDN 없는 엣지 솔루션을 출시했지만, 이러한 전환은 대부분 고객이 폐기 마감일 이전에 새 엔드포인트로 마이그레이션해야 하는 방식으로 이루어졌습니다. Alchemy Edge Proxy는 고객의 조치 없이도 동등하거나 더 큰 성능 개선을 이루어냈습니다.

자주 묻는 질문

글로벌 엣지 네트워크가 가장 뛰어난 RPC 제공자는 어디인가요?

트래픽이 어디에서 발생하는지에 따라 달라지므로, 순위보다는 구조를 비교하는 것이 유용합니다. 어떤 제공자든 확인할 점은 네 가지입니다: 인그레스 계층이 제공자의 자체 인프라인지 임대한 서드파티 CDN인지, 몇 개의 리전을 어디에서 운영하는지, 리전 간 페일오버가 자동인지 직접 구성해야 하는지, 그리고 전 세계 평균이 아니라 내 리전에서 측정한 지연 시간이 얼마인지입니다.

Alchemy는 US East, US West, EU Central, Southeast Asia의 전용 베어메탈 서버에서 커스텀 엣지 프록시를 운영하며, 이전에 서빙 경로에 있던 서드파티 CDN을 대체했습니다. 이 의존성을 제거했기 때문에 외부 벤더의 장애 대응 시간이 Alchemy 자체 가동 시간의 한계가 되지 않습니다. 리전별 최신 측정치는 실시간 RPC 지연 시간 벤치마크에서 확인하세요.

별도 설정 없이 멀티 리전 RPC 페일오버를 제공하는 제공자는 어디인가요?

확인해야 할 부분은 "별도 설정 없이"입니다. 직접 구성하면 페일오버를 지원하는 제공자는 많지만, 이는 이미 동작하는 페일오버와는 다른 제품입니다.

Alchemy에서는 페일오버가 자동이며 설정이 필요 없습니다: 리전별 헬스 체크가 Edge Proxy 수준에서 실행되고, 리전이 비정상 상태가 되면 DNS가 트래픽을 다음으로 가까운 리전으로 페일오버합니다. 각 리전에는 명시적인 순서의 폴백 목록이 있으므로, 트래픽은 임의로 해석되는 대신 정해진 경로를 따릅니다. 이 과정이 DNS와 인그레스 계층에서 일어나기 때문에 애플리케이션에서 구성할 것이 없으며, 2025년 10월 이 계층이 100개 이상의 네트워크에 배포될 때에도 마이그레이션이 필요하지 않았습니다.

RPC에서 지리 기반 DNS 라우팅은 어떻게 동작하나요?

Alchemy는 지리적 근접성 기반 DNS 해석을 사용합니다. *.g.alchemy.com로 보낸 요청은 가장 가까운 엣지 리전으로 해석되며, DNS 계층은 의도적으로 체인과 무관하게 설계되었습니다. Ethereum 메인넷 요청과 Solana 메인넷 요청은 동일한 리전의 엣지 프록시로 해석되고, 엣지 프록시가 네트워크 인식 라우팅을 내부적으로 처리합니다.

여기서 두 가지 결과가 따릅니다. 요청이 최종적으로 어떤 체인을 필요로 하든 DNS 해석과 TLS 핸드셰이크는 가장 가까운 엣지 위치에서 이루어지며, 왕복 시간 절감의 대부분이 여기서 나옵니다. 또한 새로운 블록체인 네트워크를 추가하는 데 DNS 변경이 전혀 필요하지 않으므로, 네트워크 지원 범위와 라우팅은 서로 독립적으로 확장됩니다.

리전에 장애가 발생하면 내 트래픽은 어떻게 되나요?

리전별 헬스 체크는 Edge Proxy 수준에서 지속적으로 실행됩니다. 리전이 비정상으로 표시되면 DNS는 해당 리전으로의 해석을 중단하고, 임의로 선택하는 대신 리전별로 구성된 순서의 폴백 목록에 따라 다음으로 가까운 리전으로 트래픽을 보냅니다.

라우팅 구성은 런타임에 내부 구성 플랫폼에서 가져오므로, 프록시를 재배포하거나 재시작하지 않고도 리전을 비우거나, 네트워크를 재라우팅하거나, 보안 규칙을 적용할 수 있습니다. 애플리케이션 입장에서는 달라지는 것이 없습니다: 같은 엔드포인트가 다른 리전에서 서빙되며 계속 동작합니다.

가장 빠른 블록체인 인프라 위에서 구축하세요

Alchemy의 Edge Proxy는 글로벌 금융 활동의 요구에 맞춰 구축된 플랫폼의 한 부분입니다. 테일 지연 시간에서 최대 7.5배 빠른 RPC, 100개 이상의 지원 네트워크, 여러 대륙에 걸친 멀티 리전 배치, 그리고 조치가 필요 없는 성능 향상까지, 이 모든 것이 Alchemy의 RPC 엔드포인트에 기본으로 포함되어 있습니다.

DeFi 프로토콜, 지갑, 결제 애플리케이션, 또는 금융 기관을 위한 온체인 인프라를 구축하고 있든, 성능과 안정성은 기본 전제 조건입니다. 지원되는 전체 체인 목록을 확인하거나, Alchemy 개발자 문서를 살펴보거나, 무료 계정을 생성하여 구축을 시작하세요.