속도와 안정성을 위해 RPC를 튜닝하는 방법

저희는 성능에 집착하며 플랫폼을 더욱 최적화하기 위해 끊임없이 세부 조정을 하고 있습니다. 최근 대용량 RPC 응답을 압축하는 방식을 변경했는데, 그 변경의 한 부분이 Worldchain에 특히 큰 영향을 미쳤습니다. 대용량 호출에 대한 압축된 응답이 이제 약 33% 더 빠르게 반환되며, 이는 전체 블록 읽기와 다른 무거운 호출이 더 빨라지고, 성능이 더 안정적이며, 트래픽 증가를 수용할 여유가 더 생긴다는 것을 의미합니다.

GOAWAY 프레임이란?

HTTP/2 상에서 높은 처리량의 워크로드를 운영한다면, GOAWAY 프레임을 직접 찾아본 적이 없더라도 이미 알고 있을 것입니다. GOAWAY는 서버가 클라이언트에게 연결에서 새 스트림 열기를 중단하라고 알리는 신호로, 보통 서버가 부하를 줄이고 있을 때 발생합니다. 클라이언트 입장에서는 GOAWAY가 몰아서 발생하면 연결이 불안정해지는 것으로 나타납니다. 스트림이 끊기고, 요청이 새 연결에서 재시도되며, 테일 레이턴시가 올라갑니다.

GOAWAY가 줄어든다는 것은 더 안정적인 연결, 더 적은 재시도, 더 빠른 서비스를 의미합니다. 그래서 고객의 GOAWAY 카운트가 급격히 떨어지면, 업스트림 어딘가에서 여유가 크게 늘어난 것입니다. 이 경우, 그 여유는 CPU였습니다.

압축이 실행되던 위치

저희 네트워크를 떠나기 전, 모든 RPC 응답은 압축될 수 있습니다. 대부분의 HTTP 클라이언트는 Accept-Encoding: gzip 헤더를 보내 이를 요청하며, 저희 자체 node-gateway를 포함한 대부분의 웹 서버는 이 헤더를 자동으로 따릅니다. 이는 저희가 구축한 특별한 기능이 아니라 표준 동작입니다. 전체 블록 읽기나 큰 eth_getLogs 결과 집합 같은 대용량 페이로드의 경우, 압축은 네트워크로 전송되는 바이트 수를 의미 있게 줄여줍니다. 인터넷 대역폭은 한정되어 있기 때문에 이는 중요합니다.

node-gateway에서 압축을 하는 것은 오랫동안 합리적이었습니다. node-gateway는 IO 바운드 서비스로, 고객 또는 저희 자체 노드로부터의 네트워크 호출을 기다리는 데 대부분의 시간을 쓰기 때문에 역사적으로 CPU 여유가 있었습니다. 압축은 CPU 바운드 작업이며, 그 비용은 응답 크기에 비례해 커집니다. 규모가 커지면서 압축은 게이트웨이가 수행하는 작업 중 가장 바쁘고 레이턴시에 민감한 작업 중 하나가 되었고, 모든 요청을 라우팅하고 서빙하는 데 필요한 것과 같은 CPU를 두고 경쟁하게 되었습니다.

게이트웨이가 과부하 상태가 되면 게이트웨이가 하는 모든 작업이 동시에 느려집니다. 그리고 부하 상태에서 게이트웨이에 걸리는 CPU 압박은 정확히 연결 차단과 GOAWAY 프레임을 유발하는 조건입니다.

무엇을 변경했나?

저희는 데이터 압축이 실행되는 위치를 node-gateway에서 서비스 메시 내 Istio 프록시로 옮겼습니다. node-gateway는 더 이상 응답을 압축하지 않습니다. 그 작업은 이제 Istio 프록시에서, 이에 더 적합한 인프라 상에서 다른 단계로 실행됩니다. 이로써 Alchemy의 node-gateway는 속도와 안정성 최적화에 집중할 수 있고, Istio가 압축 단계를 담당합니다.

결과적으로 고객에게 전달되는 압축된 응답은 동일하지만, 더 효율적으로 처리할 수 있는 곳에서, 성능을 좌우하는 홉에서의 사이클 경쟁 없이 생성됩니다. 같은 스택, 같은 출력, 단지 더 나은 위치에서 처리될 뿐입니다.

이것이 여러분에게 의미하는 것

대용량 호출에 대한 압축된 응답이 이제 약 33% 더 빠르게 반환됩니다(P95 레이턴시가 약 35% 개선됨). 이는 세 가지로 나눌 수 있습니다.

더 안정적인 연결. 요청을 처리하는 홉이 CPU를 두고 경쟁하지 않으면 부하 차단이 중단되어, GOAWAY, 스트림 끊김, 강제 재시도가 줄어듭니다. 이것이 Worldchain에서 나타난 결과로, 연결 오류가 시간당 약 1,500건에서 약 100건으로 줄었습니다.

무거운 호출에 대한 더 빠른 응답. Istio 프록시에서 압축을 처리하면 대용량 응답의 첫 바이트가 더 빨리 나갈 수 있습니다. 전체 블록 읽기나 큰 eth_getLogs 결과 집합 같은 대용량 페이로드의 경우, 이는 응답의 첫 청크가 도착하기까지의 시간이 줄어드는 것을 의미합니다.

더 많은 여유 공간. 저희는 성능을 좌우하는 바로 그 홉에서 상당한 CPU 용량을 확보했습니다. 이 개선은 요청 단위로 유지되므로, 트래픽이 늘어나도 계속 유지됩니다. 혜택을 받기 위해 여러분이 변경할 것은 없습니다. 이미 여러분이 보내는 모든 요청 아래에서 작동하고 있습니다.

왜 중요한가

RPC 제공자를 빠르고 안정적으로 만드는 대부분의 요소는 이런 홉처럼 눈에 보이지 않는 곳에서 일어납니다. 하나의 서비스가 잘못된 작업을 덜 하도록, 올바른 위치에서 하도록 바꾼 것만으로 하룻밤 사이에 더 안정적인 연결과 더 빠른 응답으로 이어졌고, 고객 측에서는 아무것도 바꿀 필요가 없었습니다.

이는 저희의 서빙 경로를 개선하기 위한 지속적인 노력의 한 부분입니다. Alchemy에서 구축을 시작하세요.