Fundamentos de la computación en la nube
Servicios de almacenamiento
Almacenamiento de objetos, de bloques y de archivos: cómo cada uno organiza los datos de forma distinta, qué cargas encaja realmente cada uno, y el error clásico de examen de tratarlos como intercambiables.
- Distinguir el almacenamiento de objetos, de bloques y de archivos según cómo organiza y otorga acceso a los datos
- Emparejar un tipo de almacenamiento con una carga de trabajo según su patrón de acceso
- Explicar por qué durabilidad y disponibilidad son 2 garantías separadas, no una sola
- Identificar los productos de almacenamiento de objetos, de bloques y de archivos que ofrecen AWS, Azure y Google Cloud
La misma palabra, 3 trabajos muy distintos
"Almacenamiento" suena como una sola cosa hasta que en verdad lo necesitas. Una app para compartir fotos guardando 50 millones de imágenes de usuarios, una base de datos escribiendo miles de actualizaciones pequeñas por segundo, y 5 servidores web que necesitan leer la misma carpeta de configuración compartida son 3 problemas completamente distintos, y ningún diseño de almacenamiento único resuelve bien los 3. Los proveedores de nube ofrecen 3 tipos de almacenamiento distintos justo por esta razón: objetos, bloques y archivos. Distinguirlos por lo que están construidos para hacer, no solo por su nombre, es la habilidad real que enseña esta lección.
Almacenamiento de objetos: buckets llenos de archivos etiquetados
Empieza con la app para compartir fotos. Cada imagen se sube una vez, se lee muchas veces y nunca se edita en su lugar, reemplazas una foto, no modificas 4KB de ella. Amazon S3, el modelo del almacenamiento de objetos, organiza los datos justo alrededor de ese patrón: un bucket es un contenedor, y cada archivo dentro de él es un objeto, direccionado por una clave única en vez de una ruta de carpeta. No hay una jerarquía de carpetas real por debajo, solo un espacio de nombres plano donde la clave "photos/vacation/beach.jpg" parece una ruta pero en realidad es solo una cadena de texto.
El almacenamiento de objetos cambia la edición en el lugar por escala masiva, costo bajo y durabilidad fuerte, S3 está diseñado para una durabilidad del 99.999999999% (11 nueves), lograda al guardar los datos de forma redundante en varias zonas de disponibilidad. Esa combinación es la razón de que el almacenamiento de objetos sea la elección por defecto para data lakes, respaldos, activos de sitios web estáticos y archivos de medios: cargas definidas por un patrón de escribir una vez y leer con frecuencia, no por ediciones pequeñas constantes.
Almacenamiento de bloques: fragmentos numerados para una sola máquina
Ahora piensa en una base de datos relacional escribiendo y reescribiendo filas constantemente. Esa carga necesita baja latencia y la capacidad de cambiar pequeños fragmentos de datos en su lugar, justo lo que no ofrece el almacenamiento de objetos. El almacenamiento de bloques, modelado según Amazon EBS, divide un volumen en fragmentos de tamaño fijo, direccionados por número, y conecta ese volumen a una sola instancia, de la misma forma en que un disco duro se conecta a una sola computadora. El sistema operativo que corre en esa instancia puede formatear el volumen, montarlo y tratarlo como disco local, porque, funcionalmente, eso es lo que es.
El almacenamiento de bloques es zonal: un volumen de EBS vive en 1 zona de disponibilidad específica y solo puede conectarse a instancias de esa misma zona, por eso una base de datos sobre un solo volumen de EBS todavía necesita su propia estrategia de replicación o respaldo para sobrevivir a la falla de una zona. A cambio de esa restricción, el almacenamiento de bloques entrega el rendimiento de baja latencia y alto IOPS que en verdad necesita una base de datos en ejecución, o el disco de arranque de una máquina virtual.
Almacenamiento de archivos: un árbol de carpetas, varias máquinas a la vez
El tercer escenario, 5 servidores web compartiendo el mismo directorio de configuración, necesita algo que ninguno de los otros 2 ofrece directamente: acceso simultáneo desde varias máquinas a la misma estructura jerárquica de carpetas. El almacenamiento de archivos, modelado según Amazon EFS, resuelve esto usando un protocolo de sistema de archivos de red (NFS), así cada servidor monta el mismo sistema de archivos y ve las mismas carpetas y archivos, con los cambios de uno visibles para los demás de inmediato. A diferencia de un volumen de EBS de una sola conexión, un sistema de archivos como EFS escala automáticamente conforme se agregan datos y puede ser montado por muchas instancias EC2, contenedores e incluso servidores on-premises a la vez.
El límite, lado a lado
| Propiedad | Objetos | Bloques | Archivos |
|---|---|---|---|
| Datos organizados como | Espacio de nombres plano de objetos direccionados por clave | Bloques numerados de tamaño fijo | Carpetas y archivos jerárquicos |
| Se conecta a | Accedido por red desde cualquier cliente autorizado | Una instancia a la vez (típicamente) | Muchas instancias a la vez |
| Mejor patrón de acceso | Escribir una vez, leer con frecuencia, sin ediciones en el lugar | Lecturas y escrituras pequeñas y frecuentes, baja latencia | Lecturas y escrituras compartidas entre máquinas |
| Uso típico | Respaldos, medios, data lakes, activos estáticos | Bases de datos, volúmenes de arranque, cargas transaccionales | Contenido compartido, directorios home, configuración compartida en una flota |
| Producto de AWS | S3 | EBS | EFS |
| Producto de Azure | Blob Storage | Managed Disks | Azure Files |
| Producto de Google Cloud | Cloud Storage | Persistent Disk | Filestore |
Ejemplo trabajado: 1 sitio de e-commerce, 3 decisiones de almacenamiento
Una plataforma de e-commerce necesita guardar 3 tipos de datos distintos, y la respuesta correcta es diferente cada vez. Las fotos de producto, millones de ellas, subidas una vez y servidas constantemente a los compradores: almacenamiento de objetos, porque nada en una foto de producto necesita edición en el lugar, y el volumen favorece la escala y el costo del almacenamiento de objetos. La base de datos transaccional que rastrea pedidos e inventario: almacenamiento de bloques, porque cada compra escribe y reescribe filas y necesita la baja latencia que solo entrega un volumen conectado directamente. Un directorio compartido de archivos de caché de sesión que 6 servidores web idénticos detrás de un balanceador de carga necesitan leer y escribir juntos: almacenamiento de archivos, porque es el único de los 3 construido para acceso simultáneo multi-instancia al mismo árbol de carpetas.
Intercambia cualquier par de esas elecciones y el sistema o se rompe por completo, una base de datos no correrá de forma aceptable sobre almacenamiento de objetos, o funciona pero desperdicia dinero y rendimiento en un desajuste que no tenía por qué cometer.
El error de concepto: más barato no significa intercambiable
Es tentador mirar el precio bajo por gigabyte del almacenamiento de objetos y asumir que es simplemente la "opción económica" que puedes usar en cualquier lugar. No lo es. El almacenamiento de objetos es barato justo porque renuncia al acceso aleatorio en el lugar y de baja latencia del que depende una base de datos en ejecución o un volumen de arranque. Mover los archivos de datos de una base de datos a almacenamiento de objetos no ahorra dinero en un sistema que funciona, produce un sistema que no funciona, porque el tipo de almacenamiento y el patrón de acceso tienen que coincidir. El precio es una consecuencia de la compensación, no un sustituto de entenderla.
Dónde te deja esto
3 preguntas ordenan casi cualquier decisión de almacenamiento: ¿los datos se editan en el lugar o solo se escriben una vez y se leen?, ¿necesitan ser compartidos por varias máquinas a la vez?, ¿necesitan arrancar o correr un sistema operativo directamente? El almacenamiento de objetos responde "escrito una vez, leído con frecuencia, sin necesidad de compartir". El almacenamiento de bloques responde "conectado a una sola máquina, editado constantemente, necesita velocidad". El almacenamiento de archivos responde "carpeta compartida, varias máquinas". La siguiente lección pasa del almacenamiento en bruto a la capa con la que en verdad habla la mayoría de las aplicaciones directamente: las bases de datos.