Mejores prácticas para desplegar Qdrant en Microsoft Azure

Problema

Se necesita ejecutar un motor de búsqueda vectorial (Qdrant) en Azure para alimentar un RAG que crecerá a decenas de millones de vectores y que recibirá inserciones/actualizaciones continuas desde SQL Server. La pregunta central es: ¿qué servicio de Azure usar, cómo dimensionar la máquina, qué familia de VM se adapta a cargas intensivas de memoria, cómo monitorizar el clúster y cómo prever el gasto mensual?

Este escenario se repite en muchos proyectos de IA generativa, donde la base de datos vectorial pasa de pruebas de concepto a producción y la infraestructura debe escalar sin interrupciones.

Causa

Los problemas suelen aparecer por tres motivos recurrentes:

1. Elección inadecuada del servicio – desplegar Qdrant en una VM genérica o en un clúster de AKS sin considerar la carga de I/O y la latencia de red genera cuellos de botella cuando el número de vectores supera los pocos millones.
2. Sub‑dimensionamiento de recursos – la memoria RAM y el IOPS de los discos SSD son críticos para mantener el índice en RAM y evitar lecturas de disco excesivas. Un cálculo basado solo en CPU puede dejar la instancia sin espacio para los segmentos de datos.
3. Falta de observabilidad – sin métricas de latencia, uso de heap y consumo de disco, los incidentes aparecen como “latencia alta” sin pista de la causa, lo que dificulta la corrección rápida y la planificación de capacidad.

Solución

1. Selección del tipo de servicio

Para la mayoría de los despliegues productivos de Qdrant, AKS resulta la opción más robusta. Permite definir un node pool con máquinas optimizadas para memoria y SSD, y añadir un deployment con replicación y readiness probes.

2. Dimensionamiento de recursos

1. Memoria – Qdrant mantiene los índices en RAM. Como regla práctica, reserva al menos 2 GB de RAM por cada 1 M de vectores (para vectores de 1536 dimensiones, típicos de embeddings). Para 30 M vectores, apunta a ~60 GB de RAM.
2. CPU – Las operaciones de inserción y búsqueda son paralelizables. Un vCPU por 5 M de vectores suele ser suficiente, pero mantén un margen del 30 % para picos de carga.
3. Almacenamiento – Usa discos Premium SSD v2 (IOPS ≥ 5 000, throughput ≥ 200 MiB/s) y provisiona al menos 2× el tamaño estimado de los vectores (por redundancia de snapshots).
4. Red – En AKS, coloca los pods en una subnet con Accelerated Networking y habilita private endpoints para evitar latencia externa.

Elección de familia de VM

En producción he visto que Esv4 (por ejemplo, Standard_E8s_v4) ofrece un equilibrio cómodo: 8 vCPU, 64 GiB RAM, 2 × P10 Premium SSD.

3. Configuración de AKS

# Crear un cluster AKS con un node pool de tipo Esv4
az group create -n rg-qdrant -l eastus2
az aks create \
  -g rg-qdrant \
  -n aks-qdrant \
  --node-vm-size Standard_E8s_v4 \
  --node-count 3 \
  --enable-addons monitoring \
  --network-plugin azure \
  --vnet-subnet-id /subscriptions/<sub>/resourceGroups/rg-qdrant/providers/Microsoft.Network/virtualNetworks/vnet-qdrant/subnets/aks-subnet \
  --attach-acr <acr-name>

1. Persistencia – Crea un storage class basado en Premium SSD v2 y monta un PersistentVolume para los snapshots de Qdrant.
2. Health checks – Define livenessProbe y readinessProbe que consulten /health del API.
3. Auto‑escalado – Configura Cluster Autoscaler y Horizontal Pod Autoscaler (HPA) con métricas de CPU y de uso de memoria del contenedor.

4. Observabilidad

1. Azure Monitor – Habilita el container insights al crear el cluster (--enable-addons monitoring). Recopila métricas de CPU, memoria, IOPS y latencia de red.
2. Prometheus + Grafana – Qdrant expone un endpoint /metrics. Añade un scrape config en Prometheus y un dashboard de Grafana con paneles de:
   • qdrant_collection_points_count (tamaño del índice)
   • qdrant_search_latency_seconds
   • process_resident_memory_bytes
3. Alertas – Configura alertas en Azure Monitor o en Prometheus Alertmanager para: uso de RAM > 80 %, latencia de búsqueda > 200 ms, IOPS > 90 % de la cuota.

5. Estimación de costos

1. VMs – Calcula el precio por hora de la familia elegida (Esv4 ≈ $0.40/h en East US 2). Multiplica por número de nodos y horas al mes.
2. Discos – Premium SSD v2 tiene costo por GB‑mes (≈ $0.12/GB). Multiplica por el espacio provisionado.
3. Red – Salida de datos a internet se cobra por GB; si todo el tráfico es interno a la VNet, el costo es casi nulo.
4. AKS – El control plane es gratuito; solo pagas por los nodos.
5. Monitor – Azure Monitor tiene un nivel gratuito; el consumo extra se mide en métricas y logs (≈ $2.30/1 M métricas).

Una hoja de cálculo sencilla con los parámetros anteriores permite obtener una estimación mensual con ±10 % de precisión.

Cuándo aplicar esta solución

• Escala esperada > 10 M vectores o crecimiento rápido.
• Requerimientos de alta disponibilidad (mínimo 2 réplicas).
• Necesidad de observabilidad centralizada (integración con Azure Monitor o Prometheus).
• Presupuesto suficiente para VMs de alta memoria (Esv4/Es5).

No es adecuada cuando:

• El proyecto está en fase de prototipo con < 5 M vectores y no justifica la complejidad de AKS.
• El equipo no tiene experiencia con Kubernetes y el tiempo de puesta en marcha es crítico; una VM única puede ser más rápida.

Verificación

1. Carga de datos – Inserta un lote de 1 M vectores y verifica que qdrant_collection_points_count aumenta en tiempo real.
2. Latencia de búsqueda – Ejecuta 100 consultas de similitud y confirma que la métrica qdrant_search_latency_seconds se mantiene bajo el umbral definido (p.ej., 150 ms).
3. Uso de recursos – Observa process_resident_memory_bytes; debe estar por debajo del 80 % de la RAM asignada.
4. Resiliencia – Detén un nodo del pool; AKS debe re‑programar los pods y el endpoint debe seguir respondiendo sin errores 5xx.

Notas adicionales

• Snapshots automáticos – Programa snapshots diarios a un Blob Storage mediante la CLI de Qdrant (qdrant snapshot create).
• Sincronización con SQL Server – Usa Change Data Capture (CDC) en SQL Server y un Azure Function que publique cambios a una cola (Service Bus) consumida por un worker que actualice Qdrant.
• Tuning de índices – Ajusta hnsw_m y hnsw_ef_construct al crear la colección; valores más altos reducen latencia a costa de mayor RAM.
• Costos ocultos – Los snapshots en Blob pueden generar costos de almacenamiento y salida; configura una política de retención de 30 días para evitar sorpresas.

Con estos lineamientos puedes pasar de una prueba de concepto a una arquitectura de producción robusta, predecible en costos y fácil de monitorizar.