노드 플릿을 15배 빠르게 재구축하는 방법

저희 안정성 작업의 대부분은 설계상 눈에 보이지 않습니다. RPC 요청을 보내면 몇 밀리초 안에 응답을 받고, 그 응답을 처리한 머신에 대해서는 전혀 생각하지 않습니다. 원래 그래야 하는 방식입니다. 하지만 그 요청 하나의 뒤에는 여러 리전에 걸쳐, 여러 체인을 대상으로, 중단 없이 계속 건강한 상태를 유지해야 하는 블록체인 노드 플릿이 있습니다. 이 규모에서 플릿을 건강하게 유지하는 일은 결국 데이터 이동 문제이며, 대부분의 사람들이 예상하는 것보다 훨씬 큰 문제입니다.

이 글은 이를 해결하기 위해 저희가 진행한 구체적인 투자 하나를 다룹니다: 자체 구축한 고대역폭 병렬 데이터 전송 시스템과, 저희 머신 간 전용 프라이빗 네트워크입니다. 이 둘을 함께 사용하면 노드 스토리지를 예전보다 훨씬 짧은 시간에 재구축할 수 있습니다. 이는 무엇보다도 안정성에 대한 투자이며, 안정성은 하드웨어 장애가 발생했을 때도 지연 시간을 낮고 일정하게 유지시켜 주는 요소입니다. 이는 고객이 저희 노드 인프라를 기반으로 신뢰하는 가용성 보장을 이루는 하나의 의도된 요소이며, 지연 시간을 방어하는 방법 전체를 설명하는 것은 아닙니다.

이 주장의 솔직한 버전은 다음과 같습니다: 이것이 평상시에 개별 RPC 호출을 더 빠르게 만들지는 않습니다. 요청 경로에 포함되어 있지 않기 때문입니다. 이것이 하는 일은 머신이 실패했을 때, 즉 지연 시간이 가장 위태로워지는 순간에 복구를 빠르고 안정적으로 만드는 것입니다. 그래서 맞습니다, 중요한 시점인 엣지 케이스에서는 낮은 지연 시간을 뒷받침합니다.

실제로 복구하는 것은 무엇인가?

직접적으로 답할 필요가 있습니다. "복구"라는 말이 여러 의미를 가질 수 있기 때문입니다. 이는 노드 상태(노드가 요청에 응답하는 데 필요한 디스크상의 블록체인 데이터셋)를 건강한 하드웨어로 복원하는 것을 의미합니다. 개별적으로 실패한 요청, 진행 중이던 데이터, 혹은 물리적 하드웨어 자체를 복구하는 것이 아닙니다.

저희는 다음 세 가지 상황에서 이를 사용합니다:

• 노드가 실패하거나 성능이 저하될 때. 하드웨어나 디스크가 불안정해지면 대체 노드를 세우고 전체 체인 상태를 빠르게 로드해야 합니다.
• 용량을 추가할 때. 특정 체인의 트래픽이 늘어나 서비스할 건강한 노드가 더 필요해지며, 각 노드는 트래픽을 받기 전에 완전한 데이터셋을 갖춰야 합니다.
• 새로운 체인이나 리전을 가동할 때. 새 노드는 빈 상태로 시작하며, 쓸모 있어지려면 테라바이트 단위의 상태가 필요합니다.

세 경우 모두 병목 지점은 동일합니다: 크고 계속 성장하는 데이터셋을 새 하드웨어에 빠르고 안정적으로 올리는 것입니다.

왜 블록체인 노드를 재구축하는 것이 데이터 이동 문제인가?

블록체인 풀 노드나 아카이브 노드는 작은 존재가 아닙니다. 체인에 따라 디스크상의 상태는 수백 기가바이트에서 수 테라바이트 범위에 이르며, 매일 계속 늘어납니다. 위에서 언급한 상황 중 하나가 발생할 때마다, 그 상태를 빠르게 새 하드웨어에 옮겨야 합니다.

이를 수행하는 느린 방법은 두 가지입니다. 네트워크에서 동기화하여 노드가 피어들로부터 히스토리를 재생하게 하는 방법인데, 큰 체인의 경우 며칠이 걸릴 수 있습니다. 아니면 이미 운영 중인 건강한 노드에서 상태를 복사하는 방법도 있습니다. 복사는 처음부터 동기화하는 것보다 훨씬 빠르므로, 저희는 이 경로를 최적화합니다.

문제는, 테라바이트 단위를 복사하는 작업도 한 번에 노드 하나씩, 공유 네트워크 경로를 통해, 이런 규모를 위해 만들어지지 않은 도구로 수행하면 여전히 느리다는 것입니다.

rsync란 무엇이고, 왜 그 한계를 넘어서게 되었나?

저희는 처음부터 새로운 것을 만든 것이 아닙니다. 수년간 머신 간 파일 복사 및 동기화를 위한 표준 유닉스 도구인 rsync을 사용했습니다.

무엇인가. rsync은 한 머신에서 다른 머신으로 파일을 복사하며, 반복 실행에 있어 영리하게 동작합니다: 롤링 체크섬 델타 알고리즘을 사용해 파일 전체를 다시 복사하는 대신 변경된 부분만 전송합니다. 검증된 도구이며 어디에나 쓰이고, 델타 전송 방식 덕분에 증분 복사가 저렴합니다. 두 머신 간 데이터셋을 동기화하는 용도로는 이만한 것이 없습니다.

어디서 한계에 부딪혔는가. rsync는 두 호스트 간 파일을 동기화하도록 설계된 것이지, 시간 압박 속에서 테라바이트 단위를 새 하드웨어로 옮기기 위해 설계된 것이 아닙니다. 저희 규모에서는 명확한 한계에 부딪혔습니다: 처리량입니다. 단일 rsync 스트림은 대체로 직렬적으로 동작하며, 저희가 운영하는 빠른 네트워크와 스토리지 하드웨어를 거의 포화시키지 못해서, 가용 대역폭의 상당 부분이 그대로 놀게 됩니다. 플릿 규모에서는 이렇게 낭비되는 용량이 누적되어 노드당 몇 시간의 재구축 시간과 실질적인 운영 부담으로 이어집니다. rsync가 잘못된 것은 아닙니다. 저희가 그것이 만들어진 용도를 넘어선 것뿐입니다. 그래서 저희는 처음부터 하나의 목적, 즉 하드웨어가 허용하는 만큼 빠르게 방대한 데이터셋을 새 노드로 옮기는 것을 위해 설계된 전송 도구를 직접 만들었습니다.

어떻게 하는가: 전용 프라이빗 네트워크와 병렬 전송 도구

저희는 이 문제를 두 방향에서 동시에 공략했습니다: 도로와 차량입니다.

도로: 전용 프라이빗 네트워크

저희는 대용량 노드 데이터 전송을 프로덕션 트래픽을 처리하는 경로와 분리된, 저희 머신 간 전용 프라이빗 네트워크로 옮겼습니다.

복사 작업이 이 프라이빗 네트워크에서 이루어지는 순간 두 가지가 달라집니다. 첫째, 대용량 전송이 더 이상 프로덕션 요청 트래픽과 경쟁하지 않으므로, 대규모 재구축이 고객 대상 지연 시간을 위험에 빠뜨리지 않습니다. 둘째, 노드 간 높고 예측 가능한 대역폭을 확보합니다: 전송 도구가 활용하도록 만들어진 순수 용량으로, 초당 수십 기가비트에 이릅니다.

차량: 목적에 맞게 만든 병렬 전송 도구

저희 자체 도구는 하나의 일만 합니다: 건강한 소스 머신에서 목적지 머신으로 노드 상태 전체 디렉터리를 최대한 빠르게 밀어 넣는 것입니다. 이 설계는 단일 직렬 복사로는 대부분 놀게 될 고대역폭 링크를 포화시키는 데 초점을 맞추고 있습니다. 이를 실현하는 세 가지 아이디어가 있습니다:

• 많은 병렬 연결. 하나의 스트림 대신 전송은 다수의 동시 TCP 연결을 통해 이루어져, 프라이빗 네트워크의 대역폭을 실제로 채울 수 있습니다.
• 매우 큰 파일 분할. 단일 다중 테라바이트 상태 파일은 하나의 연결에서 병목이 되므로, 설정 가능한 크기 임계값을 초과하는 파일은 바이트 오프셋 기준으로 청크로 분할되고, 각 청크는 병렬로 각자의 연결을 통해 전송됩니다. 목적지에서는 각 청크를 파일 내 올바른 오프셋에 바로 기록합니다.
• 작은 파일 일괄 처리 및 큰 파일 우선 처리. 많은 작은 파일들은 전송당 오버헤드를 상쇄하기 위해 함께 묶이고, 가장 큰 파일들이 먼저 시작되어 가장 오래 걸리는 전송이 즉시 진행됩니다.

오케스트레이션: Ansible과 AWX

빠른 전송 도구는 사람이 명령어를 일일이 입력하지 않고도 여러 머신에서 안정적으로 실행할 수 있어야 비로소 유용해집니다. 저희는 여러 서버에서 정의된 작업을 실행하는 Ansible로 재구축을 오케스트레이션하며, 이는 작업 및 스케줄링 제어 플레인인 AWX를 통해 관리됩니다.

그 결과 재구축은 반복 가능하고 감사 가능한 작업이 됩니다: 대상을 선택하고, 워크플로우를 실행하면, 시스템이 매번 일관된 결과로 프라이빗 네트워크를 통해 병렬로 상태를 전달합니다.

저희 솔루션은 rsync보다 얼마나 빠른가?

저희 도구는 1015배 빠릅니다. 단일 스레드 rsync는 노드 상태를 초당 100200MB로 이동시킵니다. 저희의 병렬화된 전송은 초당 2~3GB를 유지합니다.

이 속도 차이는 실제 재구축에서 중요하게 드러납니다. 한 프로덕션 실행에서 저희는 13개 노드(소스 1개, 목적지 12개)로 구성된 Base Mainnet 플릿을 재구축했으며, 실제 데이터 전송은 약 35분 만에 완료되었고, 프라이빗 네트워크 설정 및 해제를 포함한 전체 워크플로우는 약 1시간 27분에 완료되었으며, 실패와 도달 불가능한 노드는 0건이었습니다. 기존의 노드별 접근 방식은 동일한 종류의 재구축을 몇 시간에 걸친 고된 작업으로 만들었습니다.

Alchemy에서 이것이 여러분에게 가능하게 하는 것

이는 기반 계층의 능력이므로, 그 이점은 저희 노드 플릿 위에서 실행되는 모든 제품에 미칩니다. 메커니즘은 항상 동일합니다(하드웨어 장애가 부하를 집중시켜 테일 지연 시간을 끌어올리기 전에 치유됩니다). 하지만 이것이 각 제품별로 여러분에게 어떤 의미인지 살펴보겠습니다.

• Node & RPC API(Alchemy의 RPC API): 노드 장애가 발생해도 p95/p99 응답 시간이 안정적으로 유지됩니다. 성능이 저하된 노드가 생존 노드들에 과부하를 주기 전에 교체되기 때문입니다. 사용자에게 느린 요청 급증이 줄어듭니다.
• 데이터 및 인덱싱 API(Transfers, Balances, Token, Webhooks): 백엔드 노드가 재구축될 때 소비하는 데이터의 공백과 지연이 줄어듭니다. 복구가 몇 시간이 아니라 짧은 시간에 끝나기 때문입니다. 더 신뢰할 수 있는 데이터를 더 빨리 얻게 됩니다.
• Rollups 및 체인 서비스: 전용 또는 앱 전용 체인의 용량 복구가 더 빨라져서, 단일 하드웨어 장애가 앱에 오랜 성능 저하 기간으로 이어지지 않습니다.

이는 실질적인 일관성 향상입니다: 힘든 순간을 짧고 드물게 만들어 여러분의 경험을 빠르게 유지합니다.

눈에 보이지 않는 사람들에게 왜 중요한가

여러분의 애플리케이션과의 연결 고리는 여기 있습니다. 노드가 성능 저하를 겪거나 실패하면 그 트래픽은 남은 건강한 노드들로 옮겨가야 합니다. 대체 노드를 재구축하는 데 시간이 오래 걸리면, 그 부담이 생존 노드들에 더 오래 머무르고, 집중된 부하는 바로 _테일 지연 시간_을 끌어올리는 원인이 됩니다: 가장 느린 요청으로 드러나는 p95와 p99 응답 시간입니다. (이 현상에 대한 고전적인 다룸은 Dean과 Barroso의 The Tail at Scale을 참고하십시오.) 빠른 복구는 이 시간을 줄여줍니다. 플릿은 성능 저하가 여러분 쪽에서 느린 응답으로 체감되기 전에 치유됩니다.

이것이 저희가 장애에 대비해 계획한다고 말할 때 의미하는 바입니다. 저희는 머신이 계속 가동될 것이라고 가정하지 않습니다. 실패할 것이라고 가정하고, 그 실패가 작게 유지되고 복구가 빠르게 유지되도록 투자합니다. 이 전송 시스템과 그 뒤에 있는 프라이빗 네트워크는 그러한 투자 중 하나입니다: 저희 데이터센터의 하드웨어 문제가 결코 여러분 앱의 지연 시간 문제로 번지지 않도록 하는 것이 유일한 임무인 인프라입니다.

여러분은 아마 이 중 어떤 것도 알아차리지 못할 것입니다. 그것이 핵심입니다.

더 큰 그림: 빠르면서, 스트레스 상황에서도 빠른

상태가 좋은 날 좋은 지연 시간 수치를 내세우는 것은 쉽습니다. 더 어려운 주장, 실제로 프로덕션에서 중요한 주장은 문제가 발생했을 때도 빠른 상태를 유지하는 것입니다. 낮은 지연 시간은 단순히 안정적인 상태의 속성이 아닙니다. 이는 장애 도중 시스템이 어떻게 동작하는지, 그리고 얼마나 빨리 회복하는지에 대한 속성입니다. 이것이 애초에 저희가 이기종의 중복된 노드 인프라를 운영하는 이유이기도 합니다.

이는 저희가 그것을 방어하는 방법의 일부입니다: 복구 경로에 대한 의도적인 투자로, 여러분이 의존하는 응답 시간이 모든 것이 정상일 때뿐 아니라 새벽 3시에 머신이 다운되어 아무도 알아차리기 전에 재구축되어야 할 때도 유지되도록 합니다.

이것이 저희가 스스로에게 요구하는 기준입니다. 그래서 Alchemy에서의 성능 작업은 두 머신 사이에서 테라바이트를 얼마나 빨리 옮길 수 있는지까지 깊숙이 내려갑니다.

자주 묻는 질문

이것이 제 RPC 요청을 더 빠르게 만드나요?

평상시에는 아닙니다. 이는 여러분의 요청 경로에 포함되어 있지 않습니다. 하지만 가장 중요한 순간, 즉 하드웨어가 실패했을 때 여러분의 지연 시간을 보호합니다. 건강한 노드를 빠르게 재구축함으로써, 집중된 부하가 p95/p99를 끌어올리는 것을 막아, 스트레스 상황에서도 가장 느린 요청이 빠르게 유지됩니다.

정확히 무엇을 복구하나요?

노드 상태입니다 - 노드가 요청을 처리하는 데 필요한 디스크상의 블록체인 데이터셋입니다. 저희는 이를 실패한 노드 교체, 용량 추가, 또는 새로운 노드나 리전 가동에 사용합니다. 개별 요청이나 물리적 하드웨어를 복구하지는 않습니다.

그냥 rsync를 사용하면 안 되나요?

rsync은 두 머신 간 파일 동기화에 매우 뛰어나며, 저희도 수년간 사용했습니다. 하지만 단일 rsync 스트림은 대체로 직렬적이라서, 플릿 규모에서는 저희 네트워크와 스토리지 하드웨어를 포화시키지 못해 노드당 몇 시간의 재구축 시간이 누적됩니다. 저희 도구는 전송을 여러 병렬 연결로 실행하고, 매우 큰 파일을 그 연결들에 걸쳐 분할해서 전용 프라이빗 네트워크의 전체 대역폭을 활용합니다.

빠른 노드 복구가 어떻게 지연 시간을 개선하나요?

노드가 실패하면 그 부하는 남은 건강한 노드들로 옮겨갑니다. 재구축이 오래 걸릴수록, 그 집중된 부하가 사용자가 가장 느린 요청으로 체감하는 p95와 p99 응답 시간인 테일 지연 시간을 더 오래 끌어올립니다. 빠른 복구는 이 시간을 줄여서 장애가 느린 응답으로 드러나지 않게 합니다.

rsync보다 얼마나 빠른가요?

순수 전송 처리량 기준으로 약 1015배입니다: 단일 스레드 rsync 스트림은 대략 초당 100200MB인 반면, 저희의 병렬화된 전송은 프라이빗 네트워크에서 초당 2~3GB입니다. 실제로 이는 몇 시간 걸리던 플릿 재구축을, 13개 노드로 구성된 Base Mainnet 플릿에서 실패 0건으로 데이터 전송이 약 35분 만에 끝나는 작업으로 바꾸었습니다.

이런 방식으로 설계된 인프라 위에서 구축하고 싶으신가요? alchemy.com/docs에서 문서를 확인해 보세요.