Colocation frente a nube: los controles de riesgo que importan

A las 17:42 del viernes, un responsable de operaciones consulta un panel después de una semana difícil. Las confirmaciones de órdenes se ralentizaron durante un repunte del mercado, una conmutación por error en la nube dejó rezagado a un consumidor de datos y la revisión del incidente no puede determinar qué configuración estaba activa. La primera pregunta es si la empresa necesita colocation o nube. La pregunta más útil es qué riesgos puede medir, contener y explicar el diseño.

La latencia es una propiedad de la ruta

La colocation sitúa los equipos en una instalación bursátil o cerca de ella, por lo general con una conexión cruzada a la red de un mercado. Elimina algunos saltos de la red pública y permite a los equipos controlar los servidores, las tarjetas de red, la configuración del kernel y las rutas de los paquetes. No hace que todas las órdenes sean rápidas. Las colas de las pasarelas, los bloqueos de las aplicaciones, el tratamiento de los datos, la calidad del reloj y la limitación de tráfico del mercado pueden determinar el resultado.

La infraestructura en la nube sustituye parte del control físico por recursos de cómputo, redes y zonas de disponibilidad gestionados por el proveedor. Una carga de trabajo en la misma área metropolitana que un mercado puede seguir pasando por una conexión privada, un punto de presencia del proveedor, conmutadores virtuales y componentes de red compartidos. Las regiones y los tipos de instancia varían. El compromiso de disponibilidad de un servicio en la nube no garantiza un tiempo concreto de ida y vuelta de las órdenes.

Las cifras siguientes son rangos habituales para la planificación del mercado, no compromisos de servicio. Describen únicamente la latencia de red, no el procesamiento de aplicaciones ni la casación en el mercado.

Los resultados reales dependen del mercado, la ruta, el proveedor, la carga de trabajo y el método de medición. Compare condiciones equivalentes: use los mismos puntos de conexión, tamaños de paquetes, carga y fuente de reloj, y después analice la mediana, p99 y los peores intervalos observados.

Estos rangos sirven para evaluar arquitecturas, no para aprobar una estrategia. Un límite de riesgo basado en la latencia media puede ocultar una cola p99 que provoque cotizaciones obsoletas o rechazos. Instrumente toda la ruta de las órdenes, incluidas las marcas de tiempo de las aplicaciones y las respuestas del mercado. Si la empresa necesita un método de comparación fiable, la cobertura de infraestructura de Trading Technology puede ayudar a plantear las preguntas sobre proveedores y plataformas, pero las pruebas de aceptación deben utilizar la carga de trabajo propia de la empresa.

El riesgo cambia con los límites de control

Con la colocation, la empresa es responsable de una mayor parte de la infraestructura física y técnica. Esto incluye el ciclo de vida del hardware, el firmware, las actualizaciones del sistema operativo, el acceso a los racks, los registros de cableado, la planificación de capacidad y las piezas de repuesto. El operador de la instalación controla el acceso al edificio, la energía y la refrigeración; el mercado o el proveedor de conectividad controla otras partes de la ruta. Una ruta de cable corta no elimina esas dependencias. Hace que el límite sea más concreto.

En la nube, el proveedor opera las instalaciones físicas y buena parte de la red subyacente. La empresa sigue siendo responsable de sus políticas de identidad, la configuración de las cargas de trabajo, el tratamiento de datos, la seguridad de las aplicaciones, el diseño de recuperación y la supervisión. Las responsabilidades varían según el servicio. Una base de datos gestionada, una máquina virtual y una plataforma de contenedores no ofrecen los mismos controles ni la misma evidencia. Considerar que el informe de aseguramiento del proveedor demuestra que una carga de trabajo de trading está controlada deja lagunas en la configuración y los procedimientos operativos de la propia empresa.

En las empresas reguladas, las evaluaciones de externalización y resiliencia deben reflejar la cadena de servicios real, no solo el nombre del proveedor principal. Los requisitos varían según la jurisdicción y el negocio, pero la evidencia suele tener que cubrir la criticidad del servicio, el acceso, la ubicación de los datos, la notificación de incidentes, la subcontratación, los derechos de auditoría y un plan de salida. Mantenga un registro del servicio, el responsable, los tipos de datos, los objetivos de recuperación y las dependencias materiales. Compruebe que esos registros coincidan con lo que se ejecuta en producción.

Para cualquiera de los dos modelos, especifique estos controles:

• Acceso: registre el acceso privilegiado, las aprobaciones, la actividad de las sesiones y los cambios de emergencia. Concilie los registros de acceso físico con las identidades lógicas cuando la implementación lo permita.
• Cambios: controle las versiones de la configuración de red, firewall y hosts. Vincule los cambios en producción con las aprobaciones y conserve una forma de identificar la versión activa durante un incidente.
• Datos: clasifique los datos de mercado, de clientes y de órdenes; establezca reglas de conservación y eliminación; y verifique dónde se guardan las copias de seguridad y las copias de diagnóstico.
• Evidencia: conserve registros con hora sincronizada de enrutamiento de órdenes, datos de mercado, implementaciones y conmutaciones por error. Establezca periodos de conservación que satisfagan las necesidades legales, regulatorias y de investigación interna.

La colocation puede reducir la dependencia de las redes virtuales y, a la vez, aumentar la dependencia del personal de las instalaciones, los proveedores de hardware y los procedimientos físicos. La nube puede estandarizar las implementaciones y ofrecer servicios gestionados, al tiempo que aumenta la dependencia de los planos de control del proveedor, los servicios de identidad y la conectividad regional. Ninguno de los dos modelos es intrínsecamente más fácil de auditar. La prueba útil es si la empresa puede demostrar quién cambió qué, cuándo lo cambió y qué servicio se vio afectado.

Pruebe el fallo y después recopile la evidencia

Las afirmaciones de resiliencia deben probarse frente a los modos de fallo que importan para el trading, no con una lista genérica de comprobación de infraestructura. Una réplica en espera activa que restaura una capa web puede ser irrelevante si un normalizador de datos de mercado no puede recuperar el estado de secuencia. Un segundo rack no es independiente si comparte la misma alimentación eléctrica o ruta de red. Una segunda zona de nube no constituye un plan de recuperación si ambas implementaciones dependen de un proveedor de identidad o una operación del plano de control comunes.

Utilice un proceso repetible antes de asignar una carga de trabajo crítica a cualquiera de los dos modelos:

1. Mapee el servicio: dibuje las rutas de las órdenes y los datos de mercado, incluidas las pasarelas, la conectividad, DNS, las fuentes de hora, la identidad, el almacenamiento y las consolas operativas. Indique qué partes operan la empresa, el mercado y cada proveedor.
2. Fije objetivos medibles: defina la latencia aceptable de la ruta de las órdenes y el comportamiento de cola, el tiempo de recuperación, el punto de recuperación, la pérdida de mensajes y el intervalo máximo de datos obsoletos. Establezca objetivos separados para la operación normal y el modo degradado.
3. Mida con una carga realista: reproduzca picos de actividad del mercado y máximos de órdenes, incluidos los reintentos de conexión y las repeticiones. Registre la latencia p50, p99 y p99.9 cuando el volumen permita medir la cola de forma significativa, además de las pérdidas, los rechazos y la profundidad de las colas.
4. Simule fallos: elimine una ruta de red, reinicie un host, revoque una credencial o desactive una zona. Pruebe la recuperación planificada y la no planificada, y compruebe si hay órdenes duplicadas, huecos de secuencia, split brain y sesiones obsoletas.
5. Conserve las pruebas: guarde los planes de prueba, las marcas de tiempo, la telemetría, las aprobaciones, las excepciones y los responsables de las medidas correctivas. Repita las pruebas después de cambios materiales en el enrutamiento, los servicios del proveedor, las aplicaciones de trading o los procedimientos de recuperación.

Las cifras de recuperación deben tratarse como objetivos de diseño, no como propiedades universales de ninguno de los dos modelos. Los rangos habituales de planificación del mercado para una conmutación en caliente bien preparada pueden ir de decenas de segundos a varios minutos; una reconstrucción en frío puede tardar decenas de minutos o más.

La sustitución de hardware, los permisos del mercado, la configuración de rutas y la repetición de datos pueden prolongar la interrupción. Mida la restauración completa del servicio, incluidos los primeros datos de mercado válidos y la primera orden aceptada de forma segura.

La automatización en la nube puede acortar el tiempo de implementación, pero también puede reproducir rápidamente una configuración incorrecta en varias regiones. La colocation puede ofrecer rutas estables y estrictamente controladas, pero el trabajo manual con el hardware y el acceso a las instalaciones pueden ralentizar la recuperación. En ambos casos, los procedimientos operativos deben incluir puntos de decisión para detener los reintentos automáticos, vaciar las colas y confirmar el estado del trading antes de reabrir el flujo de órdenes.

Elija según la carga de trabajo y demuestre que puede salir

Las pasarelas sensibles a la latencia y las estrategias con requisitos estrictos de proximidad a los mercados pueden justificar la colocation. Las cargas de trabajo con demanda variable, grandes necesidades de cómputo para investigación o preferencia por servicios gestionados pueden encajar en la nube, siempre que sus dependencias de red y servicios cumplan los objetivos establecidos.

Muchas empresas utilizan ambos modelos. Un diseño híbrido puede separar la ejecución de la analítica, pero crea puntos de unión operativos: controles duplicados, telemetría diferente, divergencias de configuración y una cronología de incidentes más compleja.

No dimensione el diseño para una sesión media. Modele los periodos de mayor actividad del mercado, el tráfico de recuperación y las implementaciones simultáneas.

En la nube, pruebe las cuotas, la disponibilidad de instancias y el rendimiento de red a la escala necesaria, en vez de suponer que la capacidad puede crearse al instante. En la colocation, tenga en cuenta la potencia del rack, la capacidad de los puertos, el hardware de repuesto y los plazos de las conexiones cruzadas. Mantenga un margen de capacidad basado en los picos de carga medidos y en un crecimiento plausible, y después pruebe qué ocurre cuando se agota ese margen.

La planificación de salida forma parte de la resiliencia y del riesgo de terceros. Una salida de la nube puede requerir la exportación de datos, servicios de sustitución, cambios de identidad y una transición controlada de rutas. Una salida de la colocation puede implicar retirar equipos, obtener acceso a nuevas instalaciones, solicitar conectividad y probar los mercados. En ambos casos, identifique las dependencias que no se pueden trasladar rápidamente, establezca una secuencia realista y conserve la configuración en un formato portátil y revisable. Pruebe al menos las partes críticas del plan, como restaurar los datos de mercado y demostrar los controles de órdenes en la ruta alternativa.

Los equipos de operaciones que comparan proveedores deberían pedir la definición exacta del límite de medición que respalda las afirmaciones sobre latencia, evidencia de recuperación específica de cada servicio, condiciones de notificación de incidentes, visibilidad de los subcontratistas y acceso a los registros. También deberían preguntar qué ocurre durante una interrupción del plano de control del proveedor, una desconexión del mercado y la filtración de credenciales de la empresa.

Las respuestas deben tener responsables y fechas de prueba, no limitarse al lenguaje contractual. En Trading Technology hay más información sobre opciones de plataformas y proveedores, pero la evaluación de riesgos sigue dependiendo de la arquitectura y las obligaciones específicas de cada empresa.

El error que probablemente seguirán cometiendo muchos lectores es tratar la colocation o la nube como si fueran el control, en lugar de demostrar cómo funciona la ruta completa del servicio y cómo responde ante fallos.

#infraestructura de trading #infraestructura de datos de mercado #latencia del sistema de trading #coubicación en bolsas #recuperación ante desastres #gestión de riesgos en la nube #resiliencia operativa #compliance en la nube