Subiendo 2 millones de archivos a la nube

En el contexto de la migracion de un sistema PHP desde un entorno local a servidores en AWS, sin embargo debemos subir mas de 220 Gb de informacion en archivos 100K

Para poder subir archivos a servidores en la nube suelo usar comandos como scp o rsync, los cuales realizan la transferencia de los archivos en una conexion segura. Esta solucion funciona relativamente bien cuando se sube hasta 1000 archivos, sin embargo mas alla de eso se puede empezar algunos problemas.

Velocidad de Transferencia, cuando se realiza la transferencia de un archivo, la velocidad de transferencia empieza a la menor velocidad posible y va aumentando la velocidad conforme dura la transferencia. Eso quiere decir, que se necesita un tiempo minimo para alcanzar la velocidad maxima posible. Un archivo muy pequeño ( 100K ) no permite alcanzar la velocidad maxima de transferencia.

Costo Administrativo, de todo el tiempo que dura realizar la transferencia de un archivo. Una pequeña parte se gasta en coordinaciones entre servidor y cliente, este tiempo no es afectado por el tamaño del archivo. Es decir gasto 5 milisegundos ya sea vaya a subir un archivo de 100K o suba un archivo de 100M. En archivos muy pequeños este tiempo administrativo se transforma en una parte muy importante del tiempo total de transferencia.

Con estos dos problemas, subir 2 millones de archivos de 100K me generaba un tiempo estimado de 1 semana en condiciones de red ideales.

En este escenario recorde mi primer proyecto que desarrolle en la universidad en el año 1999. ( El siglo pasado o el milenio pasado ... como prefieran ) que era cortar un archivo grande en pequeños pedazos para guardarlos en disquettes 3 1/4 y llevarlos de las cabinas de internet a la casa.

Debia pasar de 2millones de archivos a apenas 220 archivos de 1G cada uno. Con 1G de tamaño por archivo la velocidad de transferencia seria mucho mayor, y el Costo Administrativo de la Transferencia seria despreciable.

Para lograrlo debia convertir los 2 millones de archivos a uno solo

tar -cf archivos.tar archivos/

Con este comando creaba un archivo unico con el contenido de la carpeta archivos. No realize ninguna compresion ya que el proceso de comprimir podria ser muy demandante en tiempo y CPU para 220 Gb. Ademas que al no ser archivos de texto esperaba que el porcentaje de ahorro no sea mayor al 15%.

Con mi nuevo archivo de 220G, la transferencia hubiera tomando ya no 2 semanas, sino tan solo 5 dias. Sin embargo al ser un archivo unico, se corria el riesgo de corrupcion del archivo o corte de la transferencia y habria q volver a subir todo el archivo ... siendo esto un riesgo inaceptable.

Para reducir este riesgo, opte por dividir el archivo en 220 partes de 1G cada una. una transferencia de 1G me tomaba unos 10min aprox. Si alguna fallaba, solo debia repetir esa parte.

split --bytes=1G archivo.tar partes/

Con este comando, indicaba a mi Ubuntu que cortara el archivo.tar en tantas partes de 1G como fuera necesario y lo colocara en la carpeta partes.

El proceso de corte es un proceso que demora bastante ... ya vamos 2 horas y contando. Generar cada parte toma un aproximado de 2 minutos, asi que seran unas 8 horas casi :D

Por mientras se van generando, se puede ir subiendo los archivos por rsync o scp.

Una vez los archivos estan en el servidor debemos proceder a juntarlos

cat * > archivos.tar

Este comando reconstruye el archivo tar original de 220G uniendo todas las partes.

tar -xf archivos.tar archivos/

Este comando descomprime el archivo tar a todos los 2 millones de archivos y lo coloca en la carpeta archivos/

En total reducimos el tiempo de transferencia de 2 semanas a tan solo 4h de creacion del TAR + 8h de creacion de las partes + 40h de transferencia + 8h de union de las partes + 4h de descompresion del TAR = 64h un total de 3 dias.