히스토리 로그 조회 속도 개선기

인덱서, DEX 애그리게이터, 온체인 모니터링 시스템을 만드는 팀에게 앱이 어디서 느려지는지 물어보면, 대답은 거의 항상 같다: 범위가 큰 eth_getLogs이다.

수천 또는 수십만 개 블록을 스캔해 하나의 질문에 답하는 호출이다. 지난달 이 컨트랙트로 들어온 transfer는 무엇인가? 이 범위에서 상태가 바뀐 풀은 어디인가? 출시 이후 이 주소에서 어떤 이벤트가 발생했는가? 이런 조회는 실제 애플리케이션의 근간을 이루며, 동시에 멈추기 가장 쉬운 조회이기도 하다. 그래서 우리는 이를 처리하는 엔진을 다시 만들었고, 모든 리전에서 p99 기준 2배 이상 빠르게 만들었다. 그 과정을 소개한다.

eth_getLogs란 무엇이고 왜 중요한가?

eth_getLogs은 스마트 컨트랙트가 실행되면서 발생시키는 이벤트, 즉 토큰 transfer, swap, approval, 또는 컨트랙트가 정의한 임의의 커스텀 이벤트를 반환하는 JSON-RPC 메서드다. 컨트랙트 주소, 이벤트 시그니처나 인덱싱된 토픽 값(예: Transfer나 Approval), 그리고 fromBlock와 toBlock로 지정하는 블록 범위로 필터링한다. 간단히 말해, 무엇을 찾을지와 얼마나 거슬러 올라갈지를 알려주면 일치하는 모든 이벤트를 반환한다.

이것이 Ethereum에서 이벤트 기반 인덱싱의 기반이다. 이 메서드가 없다면 원하는 트랜잭션을 찾기 위해 모든 트랜잭션을 일일이 스캔해야 할 것이다. 이 메서드가 있으면 활동 및 transfer 피드, approval 모니터링, 그리고 실시간이든 과거 데이터든 어떤 이벤트 인덱서든 구축할 수 있다. 우리가 서비스하는 메서드 중 가장 많이 쓰이고 운영상 중요한 메서드 중 하나다. logs와 topics가 처음이라면, eth_getLogs에 대한 심층 분석에서 요청과 응답 구조를 예제와 함께 다룬다.

이 메서드의 나머지 특성이 엔지니어링 과제를 결정짓는다. 많은 프로바이더가 한 번에 쿼리할 수 있는 블록 수를 제한한다. 인덱서는 컨펌을 기다려 체인 재구성(reorg)을 처리해야 한다. 토픽 필터는 인덱싱된 필드만 매칭하므로, 인덱싱되지 않은 인자는 raw 데이터에서 디코딩해야 한다. 그리고 체인 헤드 근처의 호출은 지연 시간에 민감해서, 잘못된 노드 타입으로 라우팅되면 오류나 빈 응답이 발생할 수 있다.

지연 시간에 가장 큰 영향을 미치는 요소는 범위 크기다. 블록 하나를 요청하면 즉시 응답이 온다. 과거 데이터를 재생하는 인덱서나 몇 주에 걸쳐 컨트랙트를 감시하는 모니터라면 범위가 금방 넓어지고, 쿼리 비용도 그에 따라 올라간다. 이 지점부터 지연 시간은 오차 범위가 아니라 고객이 얼마나 빠르게 개발할 수 있는지를 좌우하는 요소가 된다.

이 메서드는 모두가 제공한다. 그 뒤에 있는 엔진에 대해 이야기하는 곳은 적은데, 그 엔진을 다시 만드는 일은 비용이 많이 들고 대부분의 프로바이더가 해내지 못했기 때문이다.

p99 지연 시간이 평균 지연 시간보다 중요한 이유는?

문제가 되는 수치는 평균이 아니다. p99다: 모든 요청을 빠른 순서부터 느린 순서로 정렬했을 때, p99는 100개 중 가장 느린 한 개다. 평균은 이를 숨긴다. 99개의 요청을 60밀리초에 처리하고도 100번째 요청이 1초 가까이 걸리는 것을 볼 수 있다.

그 가장 느린 요청이 대시보드를 멈추게 하거나 인덱서를 체인보다 뒤처지게 만드는 요청이며, 바로 사용자가 지켜보고 있는 요청이다. 평균 지연 시간은 멀쩡해 보여도 테일(tail)이 조용히 워크로드를 망가뜨릴 수 있다. 인덱서와 모니터를 운영하는 팀에게는 이 테일이 곧 워크로드다.

eth_getLogs를 어떻게 최적화했는가?

기존 엔진을 튜닝하는 대신, 이 메서드를 처리하는 스토리지와 쿼리 엔진을 처음부터 다시 만들었다.

이런 호출을 빠르게 만드는 방법은 몇 가지가 있다. 쿼리 파라미터를 조정하거나, 캐시를 추가하거나, 허용하는 범위를 제한하거나, 같은 하드웨어를 더 많이 투입하는 방법이다. 대부분은 근본을 바꾸지 않은 채 약간의 여유만 만들어낼 뿐이다.

우리는 더 깊이 들어갔다. 과거 로그 조회를 다른 워크로드와 똑같이 취급하는 범용 매니지드 데이터베이스에 의존하는 대신, getLogs 접근 패턴, 즉 매우 큰 데이터셋에 대한 빠른 필터링 스캔에 특화된 스토리지와 쿼리 레이어를 직접 운영하는 전용 인프라 위에서 구동한다.

우리는 기존 시스템에 노브 하나를 조정하거나 캐시를 덧붙이지 않았다. 고객이 가장 많이 사용하는 핵심 호출 중 하나의 근간이 되는 엔진에 메서드 단위로 투자했다. 이는 비용이 많이 드는 메서드별 인프라 작업이며, 그 개선이 평균이 아니라 테일에서 드러나는 이유이기도 하다.

결과는 어떤가?

핵심은 간단하다: 모든 리전에서 p99 기준 2배 이상 빠르다.

인덱서나 모니터를 운영한다면, 워크로드를 망가뜨리는 지연 시간은 p99다. 평균이 나아지는 것도 좋지만, 대시보드를 반응성 있게 유지하고 인덱서를 체인과 나란히 유지시키는 것은 테일의 개선이다.

이미 상당한 규모로 이를 운영하는 팀들이 그 효과를 체감하고 있다. 가장 큰 암호화폐 거래소 중 한 곳은 자체 노드 운영과 비교해 우리 엔진에서의 과거 로그 조회를 벤치마킹했고, 자신들의 워크로드에서 큰 폭의 p99 개선을 측정했다. 이는 우리 대시보드가 아니라 고객 자체 계측 도구로 확인된, 프로덕션 환경에서의 증거다.

이것이 당신에게 의미하는 바는?

인덱싱, 애그리게이션, 모니터링을 위해 과거 로그 조회에 의존하는 애플리케이션이라면, 모든 리전에서 더 빠른 조회와 대폭 개선된 p99 테일을, 이 메서드를 위해 우리가 새로 만든 인프라 위에서 얻게 된다. 실제로 적용할 때 알아두면 좋은 몇 가지:

1. 종량제와 엔터프라이즈 플랜에서 eth_getLogs은 Ethereum, Base, Optimism, Arbitrum, Polygon, Robinhood를 비롯한 주요 체인에서 단일 쿼리로 무제한 블록 범위를 지원하므로, 과거 데이터를 재생할 때 직접 페이지네이션을 구현할 필요가 없다.
2. 체인 헤드에서의 로그라면, WebSocket 구독이 새 로그를 발생 즉시 전달해주므로 eth_getLogs는 원래 목적인 과거 데이터 조회에만 사용하면 된다.
3. 통합 방식은 아무것도 바뀌지 않는다. 같은 메서드, 같은 요청 형태를, 더 빠른 엔진이 처리할 뿐이다.

메서드 단위로 투자한다는 것의 핵심은, 당신의 워크로드를 정의하는 바로 그 조회를 위해 엔진을 튜닝했다는 점이다. 무료 Alchemy 계정을 생성하고 인덱서를 우리 쪽으로 연결해 직접 계측해서 차이를 확인해보라.

자주 묻는 질문

eth_getLogs는 무엇을 반환하는가?

필터 조건, 즉 컨트랙트 주소, 이벤트 시그니처와 인덱싱된 토픽 값, 블록 범위에 일치하는 이벤트 로그 배열이다. 각 로그에는 발생시킨 주소, 토픽, 데이터 페이로드, 그리고 어느 블록과 트랜잭션에서 나온 것인지가 포함된다. 전체 요청/응답 스펙은 API 레퍼런스를 참조하라.

인덱서에게 p99 지연 시간이 평균 지연 시간보다 중요한 이유는?

인덱서는 요청을 순차적으로 또는 배치 단위로 처리하기 때문에, 가장 느린 요청이 속도를 결정한다. 평균이 낮아도 테일이 길면 인덱서가 느린 1%에 주기적으로 멈추고, 체인 헤드보다 뒤처지며, 오래된 데이터를 제공하게 된다. p99는 정확히 그런 요청들을 측정한다.

Alchemy에서 단일 eth_getLogs 호출로 조회할 수 있는 블록 범위는?

무료 티어에서는 쿼리당 10개 블록이다. 종량제와 엔터프라이즈 플랜에서는 Ethereum, Base, Optimism, Arbitrum, Polygon, Worldchain, BNB 등 여러 체인에서 블록 범위가 무제한이며, 응답은 150MB로 제한된다. 체인별 상세 표는 eth_getLogs 레퍼런스에 있다.

대규모 과거 데이터 쿼리를 빠르게 유지하려면 어떻게 해야 하는가?

가능한 한 좁게 필터링하라. 블록 범위만이 아니라 필요한 컨트랙트 주소와 이벤트 토픽을 명시하라. 무제한 범위를 지원하지 않는 체인에서 매우 넓은 범위를 조회해야 한다면, 쿼리를 더 작은 단위로 나눠라. 그리고 앞으로 발생할 새 로그에 대해서는 폴링 대신 WebSocket 구독을 사용하라.