--- title: "Cómo reconstruimos flotas de nodos 15 veces más rápido" description: "La mayor parte del trabajo de confiabilidad es invisible. Así es como Alchemy reconstruyó la recuperación del estado de los nodos con transferencia paralela y redes privadas para mantener una latencia constante cuando falla el hardware." --- # Cómo reconstruimos flotas de nodos 15 veces más rápido Gran parte de nuestro trabajo de confiabilidad es invisible por diseño. Envías una solicitud RPC, recibes una respuesta en unos pocos milisegundos y nunca piensas en la máquina que la sirvió. Así es exactamente como debe sentirse. Pero detrás de esa única solicitud hay una flota de nodos blockchain que tiene que mantenerse saludable las 24 horas, en muchas chains, en múltiples regiones, sin pausa. Mantener esa flota saludable a escala resulta ser un problema de movimiento de datos, y uno mucho más grande de lo que la mayoría espera. Este artículo trata sobre una inversión específica que hicimos para resolverlo: un sistema de transferencia de datos paralelizado y de alto ancho de banda que construimos internamente, junto con una red privada dedicada entre nuestras máquinas. Juntos, nos permiten reconstruir el almacenamiento de un nodo en una fracción del tiempo que solía tomar. Esto es, ante todo, una inversión en confiabilidad, y la confiabilidad es lo que mantiene la latencia baja y _consistente_ cuando el hardware falla. Es una pieza deliberada de las garantías de disponibilidad sobre las que nuestros clientes construyen con nuestra infraestructura de nodos, no toda la historia de cómo defendemos la latencia. La versión honesta de esta afirmación, por adelantado: esto no hace que una llamada RPC individual sea más rápida en un día normal, porque no está en tu ruta de solicitud. Lo que hace es que la recuperación sea rápida y confiable exactamente cuando una máquina falla, el momento en que tu latencia corre más riesgo. Así que sí, respalda la baja latencia, en los casos límite donde realmente importa. ## ¿Qué estamos recuperando exactamente? Vale la pena responder esto directamente, porque "recuperación" puede significar varias cosas. Se trata de restaurar el **estado del nodo** (el conjunto de datos de blockchain en disco que un nodo necesita para responder solicitudes) en hardware saludable. No se trata de recuperar una solicitud individual fallida, datos en tránsito, ni el hardware físico en sí. Recurrimos a esto en tres situaciones: - **Un nodo falla o se degrada.** El hardware o su disco no está saludable, así que levantamos un reemplazo y necesitamos cargar el estado completo de la chain en él rápidamente. - **Agregamos capacidad.** El tráfico de una chain crece y necesitamos más nodos saludables sirviéndolo, cada uno necesitando el conjunto de datos completo antes de poder recibir tráfico. - **Levantamos una nueva chain o región.** Los nodos nuevos empiezan vacíos y necesitan terabytes de estado antes de ser útiles. En los tres casos, el cuello de botella es el mismo: llevar un conjunto de datos grande y en constante crecimiento a hardware nuevo, rápido y de forma confiable. ## ¿Por qué reconstruir un nodo blockchain es un problema de movimiento de datos? Un full node o archive node de blockchain no es algo pequeño. Dependiendo de la chain, su estado en disco va desde cientos de gigabytes hasta el rango de múltiples terabytes, y crece todos los días. Cada vez que nos encontramos con una de las situaciones anteriores, tenemos que llevar ese estado a hardware nuevo, rápido. Hay dos formas lentas de hacerlo. Puedes sincronizar desde la red, dejando que el nodo reproduzca el historial desde sus pares, lo cual puede tomar días para una chain grande. O puedes copiar el estado desde un nodo saludable que ya operas. Copiar es dramáticamente más rápido que sincronizar desde cero, así que ese es el camino que optimizamos. El problema: copiar terabytes sigue siendo lento si lo haces un nodo a la vez, sobre una ruta de red compartida, con una herramienta que nunca fue construida para esta escala. ## ¿Qué es rsync, y por qué lo superamos? No empezamos construyendo algo nuevo. Durante años usamos `rsync`, la herramienta estándar de Unix para copiar y sincronizar archivos entre máquinas. **Qué es.** `rsync` copia archivos de una máquina a otra y es inteligente con las ejecuciones repetidas: usa un algoritmo de delta con checksum continuo para transferir solo las partes de un archivo que cambiaron, en lugar de volver a copiar todo. Está probado en batalla, es ubicuo, y su enfoque de transferencia por delta hace que las copias incrementales sean económicas. Para sincronizar un conjunto de datos entre dos máquinas, es difícil de superar. **Dónde dejó de funcionarnos.** `rsync` fue diseñado para sincronizar archivos entre dos hosts, no para mover terabytes a hardware nuevo bajo presión de tiempo. A nuestra escala, chocó con un límite duro: el throughput. Un solo stream de `rsync` es en gran medida secuencial y no se acerca a saturar el hardware rápido de red y almacenamiento que operamos, por lo que gran parte del ancho de banda disponible queda ocioso. A escala de flota, esa capacidad desperdiciada se acumula en horas de tiempo de reconstrucción por nodo y en fricción operativa real. `rsync` no estaba mal. Simplemente superamos lo que fue construido para hacer. Así que construimos una herramienta de transferencia diseñada desde el inicio para un solo trabajo: mover conjuntos de datos enormes a nodos nuevos tan rápido como el hardware lo permita. ## Cómo lo hacemos: una red privada dedicada más una herramienta de transferencia paralela Atacamos el problema en dos frentes a la vez: el camino y el vehículo. ### El camino: una red privada dedicada Movimos la transferencia masiva de datos de nodos a una red privada dedicada entre nuestras máquinas, separada de la ruta que sirve el tráfico de producción. Dos cosas cambian en el momento en que la copia corre sobre esa red privada. Primero, la transferencia masiva ya no compite con el tráfico de solicitudes de producción, así que una reconstrucción grande nunca pone en riesgo la latencia de cara al cliente. Segundo, entrega un ancho de banda alto y predecible entre nodos: la capacidad bruta que la herramienta de transferencia está construida para usar, hasta decenas de gigabits por segundo. ### El vehículo: una herramienta de transferencia paralela construida a medida Nuestra herramienta interna hace un solo trabajo: empujar un directorio completo de estado de nodo desde una máquina de origen saludable a una máquina de destino tan rápido como sea posible. El diseño está construido alrededor de saturar un enlace de alto ancho de banda que una sola copia secuencial dejaría mayormente ocioso. Tres ideas hacen el trabajo: - **Muchas conexiones paralelas.** En lugar de un solo stream, la transferencia corre a través de muchas conexiones TCP concurrentes a la vez, de modo que pueda llenar realmente el ancho de banda de la red privada. - **Dividir archivos muy grandes.** Un solo archivo de estado de múltiples terabytes sería un cuello de botella para una conexión, así que los archivos por encima de un umbral de tamaño configurable se dividen en fragmentos por desplazamiento de bytes, y cada fragmento se envía por su propia conexión en paralelo. El destino escribe cada fragmento directamente en el desplazamiento correcto dentro del archivo. - **Agrupar archivos pequeños y empezar por los más grandes.** Muchos archivos pequeños se agrupan para amortizar la sobrecarga por transferencia, y los archivos más grandes comienzan primero para que las transferencias más largas estén en curso de inmediato. ### La orquestación: Ansible y AWX Una herramienta de transferencia rápida solo es útil si puedes operarla de forma confiable en muchas máquinas sin que una persona escriba comandos. Orquestamos las reconstrucciones con Ansible, que ejecuta tareas definidas en muchos servidores, administradas a través de AWX, su plano de control de trabajos y programación. El resultado es que una reconstrucción se convierte en un trabajo repetible y auditable: seleccionas el objetivo, inicias el flujo de trabajo, y dejas que el sistema lleve el estado a través de la red privada en paralelo, con resultados consistentes cada vez. ## ¿Qué tan más rápida es nuestra solución que rsync? Nuestra herramienta es 10-15 veces más rápida. `rsync` de un solo hilo mueve el estado del nodo a 100-200 MB/s. Nuestra transferencia paralelizada sostiene 2-3 GB/s. Esa velocidad se nota donde importa, en una reconstrucción real. En una ejecución de producción reconstruimos una flota de Base Mainnet de 13 nodos (un origen, doce destinos) con la transferencia de datos real completándose en aproximadamente **35 minutos**, y el flujo de trabajo completo, incluyendo la configuración y el desmontaje de la red privada, terminando en aproximadamente **1 hora 27 minutos**, con **cero fallas y cero nodos inalcanzables**. El antiguo enfoque nodo por nodo convertía el mismo tipo de reconstrucción en un calvario de varias horas. ## Qué desbloquea esto para ti con Alchemy Esta es una capacidad de capa base, así que su beneficio alcanza a cualquier producto que corra sobre nuestra flota de nodos. El mecanismo es siempre el mismo (una falla de hardware sana antes de que pueda concentrar carga y elevar la latencia de cola), pero esto es lo que significa para ti, producto por producto. - **Node & RPC APIs (la RPC API de Alchemy):** tus tiempos de respuesta p95/p99 se mantienen estables durante una falla de nodo, porque un nodo degradado se reemplaza antes de que los sobrevivientes se sobrecarguen. Menos picos de solicitudes lentas para tus usuarios. - **APIs de datos e indexación (Transfers, Balances, Token, Webhooks):** menos huecos y menos retraso en los datos que consumes cuando se reconstruye un nodo de respaldo, porque la recuperación es una ventana corta en lugar de horas. Datos más confiables, más pronto. - **Rollups y servicios de chain:** restauración de capacidad más rápida para tu chain dedicada o específica de la aplicación, de modo que una sola falla de hardware no se convierta en una ventana degradada prolongada para tu app. Estas son ganancias reales de _consistencia_: mantenemos tu experiencia rápida haciendo que los momentos difíciles sean cortos y poco frecuentes. ## Por qué esto importa para las personas que nunca lo ven Aquí está la conexión de vuelta con tu aplicación. Cuando un nodo se degrada o falla, su tráfico tiene que trasladarse a los nodos saludables restantes. Si reconstruir un reemplazo es lento, esa presión permanece sobre los sobrevivientes por más tiempo, y la carga concentrada es precisamente lo que eleva la _latencia de cola_: los tiempos de respuesta p95 y p99 que se manifiestan como tus solicitudes más lentas. (El tratamiento clásico de este efecto es el de Dean y Barroso, [The Tail at Scale](https://research.google/pubs/the-tail-at-scale/).) Una recuperación rápida reduce esa ventana. La flota sana antes de que la degradación llegue a sentirse alguna vez como una respuesta lenta de tu lado. Esto es lo que queremos decir cuando afirmamos que planificamos para la falla. No asumimos que las máquinas se mantendrán activas. Asumimos que fallarán, e invertimos para que la falla se mantenga pequeña y la recuperación se mantenga rápida. Este sistema de transferencia y la red privada detrás de él son una de esas inversiones: infraestructura cuyo trabajo completo es asegurar que un problema de hardware en nuestro centro de datos nunca se convierta en un problema de latencia en tu app. Probablemente nunca notarás nada de esto. Ese es el punto. ## El panorama más amplio: rápido, y rápido bajo presión Es fácil publicar un buen número de latencia en un día saludable. La afirmación más difícil, la que realmente importa en producción, es mantenerse rápido cuando las cosas se rompen. La baja latencia no es solo una propiedad de estado estable. Es una propiedad de cómo se comporta un sistema _durante_ una falla, y qué tan rápido se recupera. Es también por lo que, en primer lugar, operamos infraestructura de nodos heterogénea y redundante. Esta es una parte de cómo defendemos eso: una inversión deliberada en la ruta de recuperación, para que los tiempos de respuesta en los que confías se mantengan no solo cuando todo está en verde, sino cuando una máquina se cae a las 3 a.m. y tiene que ser reconstruida antes de que alguien lo note. Ese es el estándar con el que nos medimos. Es por eso que el trabajo de rendimiento en Alchemy llega hasta el nivel de qué tan rápido podemos mover un terabyte entre dos máquinas. ## Preguntas frecuentes **¿Esto hace que mis solicitudes RPC sean más rápidas?** En un día normal, no. No está en tu ruta de solicitud. Pero protege tu latencia en el momento que más importa: cuando el hardware falla. Al reconstruir un nodo saludable rápido, evita que la carga concentrada eleve tus p95/p99, de modo que tus solicitudes más lentas se mantengan rápidas bajo presión. **¿Qué exactamente recupera?** El estado del nodo: el conjunto de datos de blockchain en disco que un nodo necesita para servir solicitudes. Lo usamos para reemplazar un nodo fallido, agregar capacidad, o levantar un nuevo nodo o región. No recupera solicitudes individuales ni hardware físico. **¿Por qué no usar simplemente rsync?** `rsync` es excelente para sincronizar archivos entre dos máquinas, y lo usamos durante años. Pero un solo stream de `rsync` es en gran medida secuencial, así que a escala de flota no satura nuestro hardware de red y almacenamiento, sumando hasta horas de tiempo de reconstrucción por nodo. Nuestra herramienta ejecuta la transferencia a través de muchas conexiones paralelas y divide archivos muy grandes entre ellas para usar el ancho de banda completo de una red privada dedicada. **¿Cómo mejora la latencia una recuperación de nodo más rápida?** Cuando un nodo falla, su carga se traslada a los nodos saludables restantes. Cuanto más tiempo tome una reconstrucción, más tiempo esa carga concentrada eleva la latencia de cola: los tiempos de respuesta p95 y p99 que los usuarios sienten como sus solicitudes más lentas. Una recuperación más rápida reduce esa ventana para que las fallas no se manifiesten como respuestas lentas. **¿Qué tan más rápida es que rsync?** Alrededor de 10-15 veces en throughput de transferencia bruto: aproximadamente 100-200 MB/s para un stream de `rsync` de un solo hilo frente a 2-3 GB/s para nuestra transferencia paralelizada sobre la red privada. En la práctica, eso convirtió una reconstrucción de flota de varias horas en una donde la transferencia de datos terminó en aproximadamente 35 minutos, en una flota de Base Mainnet de 13 nodos con cero fallas. _¿Quieres construir sobre infraestructura diseñada de esta manera? Explora la documentación en_ [alchemy.com/docs](https://www.alchemy.com/docs).