---
title: "노드 플릿을 15배 빠르게 재구축하는 방법"
description: "안정성 관련 작업은 대부분 겉으로 드러나지 않습니다. Alchemy가 병렬 전송과 프라이빗 네트워킹을 통해 노드 상태 복구를 재구축하여 하드웨어 장애 시에도 지연 시간을 일정하게 유지한 방법을 소개합니다."
---

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

<ImageBlock
  src="https://media.alchemy.com/blog/how-we-rebuild-node-fleets-15x-faster-hero.png"
  alt="노드 복구, 15배 더 빠르게"
  width={1024}
  height={480}
  priority
/>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### 오케스트레이션: Ansible과 AWX

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

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

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

저희 도구는 10~15배 빠릅니다. 단일 스레드 `rsync`는 노드 상태를 초당 100~200MB로 이동시킵니다. 저희의 병렬화된 전송은 초당 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](https://research.google/pubs/the-tail-at-scale/)을 참고하십시오.) 빠른 복구는 이 시간을 줄여줍니다. 플릿은 성능 저하가 여러분 쪽에서 느린 응답으로 체감되기 전에 치유됩니다.

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

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

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

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

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

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

## 자주 묻는 질문

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

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

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

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

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

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

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

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

**rsync보다 얼마나 빠른가요?**

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

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