Plataformas · Software · Proveedores · Mercados
Devin Hartcastle
En la primera semana, un entorno cloud puede estar aprovisionado, configurado y ejecutando un feed de prueba mientras un pedido de colocación sigue esperando un espacio en el rack, una asignación de energía o un cross-connect. En la sexta semana, el servicio cloud puede estar activo, pero todavía hay que demostrar su ruta hasta un mercado, su rendimiento bajo carga y su proceso de recuperación. Una instalación de colocación puede haber tardado más en arrancar, pero ahora ofrecer una ruta de red directa y probada.
Este calendario no es universal. Sirve para recordar que la rapidez de despliegue y la preparación para producción son medidas diferentes.
Para brokers y prop firms, la elección no consiste simplemente en contraponer la flexibilidad del cloud a la velocidad de la colocación. Se trata de decidir dónde se ejecuta cada parte del sistema de trading, qué latencia importa y quién se responsabiliza de cada dominio de fallo.
La primera y la sexta semana plantean problemas distintos
El cloud suele ganar la carrera de la configuración inicial. Los equipos pueden crear recursos de computación, almacenamiento y red sin esperar a la entrega de hardware ni a una ventana de instalación en el centro de datos.
La infraestructura como código permite crear entornos de prueba reproducibles, y la capacidad puede ajustarse sin pedir otro servidor. Esto resulta útil para desarrollo, análisis, servicios de back office y cargas de trabajo con demanda variable.
La preparación para producción implica otras dependencias. El acceso a un mercado o proveedor de liquidez puede requerir aprobación, conectividad privada, revisiones de firewall, configuración de sesiones y pruebas con las contrapartes.
Estas tareas llevan tiempo en cualquiera de los dos modelos. En la colocación, hay que sumar la adquisición de hardware, el espacio en el rack, la energía, el cableado y la coordinación de remote hands. Los plazos habituales para una nueva instalación de colocación van de cuatro a doce semanas, pero un cross-connect o la aprobación de un mercado pueden alargarlos.
El cloud cambia el trabajo, no lo elimina. Los equipos todavía deben validar la ubicación de las instancias, el comportamiento de la CPU, las rutas de red, la sincronización horaria y la recuperación. Que una máquina virtual arranque en minutos no demuestra que una sesión de trading vaya a cumplir su objetivo de latencia con carga máxima. Al calcular el plazo de lanzamiento, registre los plazos de las dependencias junto con el aprovisionamiento de recursos de computación.
Compare la ruta, no la etiqueta
Las cifras de latencia solo son útiles si están claros sus puntos de referencia. El viaje de ida y vuelta de la red entre dos hosts no es lo mismo que el tiempo desde que llegan los datos de mercado hasta que la estrategia toma una decisión, o desde el envío de una orden hasta su confirmación. Esa medida de extremo a extremo también incluye la aplicación, el kernel o la pila de red en espacio de usuario, los controles de riesgo, los gateways y el procesamiento propio del mercado.
Los rangos habituales para la planificación varían según la ubicación, el hardware, el operador y el método de medición. Una ruta de colocación dentro de la misma sala puede medirse en decenas de microsegundos. Las rutas entre hosts cloud suelen medirse en décimas de milisegundo o más, con variaciones adicionales entre zonas o conexiones externas.
Son rangos generales del mercado, no garantías de servicio. Mida la ruta que utilizará la carga de trabajo en producción.
Registre la latencia p50, p99 y p99.9, no solo el promedio. Una mediana baja puede ocultar colas durante picos de actividad, efectos de vecinos ruidosos, retransmisiones o cambios de ruta.
Cuando sea posible, utilice marcas de tiempo de hardware y compruebe la sincronización de los relojes, por ejemplo mediante PTP, antes de comparar marcas de tiempo entre sistemas. Mida con tasas de mensajes realistas e incluya pruebas de recuperación, no solo pruebas de rendimiento en reposo.
La proximidad a un mercado no es una ventaja universal. Una empresa que ejecuta una estrategia basada en reaccionar al feed de un mercado puede valorar una ruta corta y estable.
El portal de clientes de un broker, su pila de informes o su servicio de análisis de riesgos pueden obtener poco beneficio de pagar por la misma proximidad física. La cobertura de infraestructura de trading de Trading Technology ofrece más contexto sobre los sistemas que rodean estas decisiones.
Los costes y la capacidad tienen perfiles distintos
Las cifras siguientes son rangos habituales para la planificación del mercado, no presupuestos ni resultados auditados de ningún proveedor. Suponen una infraestructura de producción modesta y excluyen el trabajo de ingeniería, las licencias de software de trading y las tarifas de los mercados. Los precios locales de la energía, los requisitos de redundancia y la capacidad reservada pueden alterar sustancialmente los costes.
| Enfoque | Referencia de latencia habitual | Plazo habitual hasta producción | Coste recurrente habitual de infraestructura |
|---|---|---|---|
| Colocación, misma instalación | 5-100 microsegundos entre hosts, según la ruta y el equipo | 4-12 semanas | $3,000-$20,000 al mes por rack, energía y conectividad |
| Cloud, dentro de una región | 0.1-1 milisegundo entre hosts con una ubicación controlada | De varios días a 2 semanas | $2,000-$25,000 al mes por una infraestructura pequeña de computación y red para producción |
| Híbrido, de cloud a colocación mediante conectividad privada | 0.2-2 milisegundos de ida y vuelta en una ruta metropolitana | 3-10 semanas, según la entrega del circuito | $1,000-$10,000 al mes por conectividad privada, más ambos entornos |
Los costes de colocación son menos flexibles. El hardware es una inversión de capital, los compromisos de rack y energía se mantienen y la capacidad de reserva permanece inactiva hasta que se necesita. A cambio, se obtiene control sobre la selección de servidores, las NIC, la configuración de BIOS, la refrigeración y el diseño de la red física. Los costes del cloud varían según el tamaño de las instancias, la transferencia de datos, el almacenamiento, el soporte y las opciones de reserva. Escalar es más rápido, pero una prueba sin límites o un alto volumen de tráfico saliente pueden generar una factura más difícil de prever.
La resiliencia también tiene un coste. Un segundo sitio, operadores diversos, equipos de reserva y un estado replicado aumentan los costes en cualquiera de los dos modelos.
Las zonas de disponibilidad cloud pueden aislar algunos fallos, pero no protegen automáticamente a una empresa de errores de aplicación, configuraciones incorrectas o dependencias compartidas entre zonas. Identifique los dominios de fallo reales antes de considerar un segundo entorno como un plan de recuperación ante desastres.
Elija según la carga de trabajo, no por eslóganes
La colocación encaja mejor cuando la carga de trabajo tiene requisitos de latencia estrictos y medibles, tasas de mensajes altas y sostenidas, hardware de red especializado o necesita una conexión física a un mercado. También es adecuada para equipos capaces de operar hardware y mantener planes de capacidad. La justificación pierde fuerza si el mercado no está cerca, la estrategia tolera más demora o el coste de la infraestructura supera el valor de un rendimiento predecible.
- Considere la colocación para la captura de datos de mercado, los gateways de órdenes sensibles a la latencia y los servicios que dependen de conexiones directas con mercados o proveedores de liquidez.
- Considere el cloud para desarrollo, CI, análisis, servicios para clientes y cargas de trabajo con demanda variable o cambios frecuentes de entorno.
- Compruebe el límite cuando el tráfico pasa de un entorno a otro. Un enlace lento o mal gestionado puede anular la ventaja de ubicar un componente cerca del mercado.
El cloud puede dar soporte a sistemas sensibles a la latencia, especialmente con familias de instancias seleccionadas con cuidado, capacidad dedicada, controles de ubicación y conectividad privada. Pero estos controles requieren pruebas y tienen un coste. Fijar los procesos a núcleos, aislar núcleos de CPU, evitar rutas sobresuscritas y vigilar la pérdida de paquetes importa más que una afirmación genérica sobre el rendimiento del cloud. A la inversa, la colocación no garantiza velocidad si la aplicación es ineficiente o la red está congestionada.
Los equipos que comparan proveedores y componentes de plataforma también pueden usar los informes de operaciones de plataforma de Trading Technology como una fuente más. Las preguntas operativas siguen siendo específicas de cada empresa: ¿qué equipo aplica parches a los hosts, gestiona los certificados, renueva los secretos, supervisa los circuitos y se responsabiliza de un incidente a las 03:00?
Diseñe una ruta híbrida que pueda operar
Muchas empresas utilizan ambos modelos. Un diseño habitual mantiene en colocación los gateways conectados a los mercados y el procesamiento sensible a la latencia, mientras utiliza el cloud para las canalizaciones de compilación, la investigación, los informes, los servicios para clientes o los entornos secundarios.
La separación solo es útil si cada servicio tiene un responsable claro y se entiende el tráfico entre los sitios. Evite distribuir una ruta de órdenes entre entornos, salvo que el salto de red adicional y la gestión de fallos sean deliberados.
Antes de comprometerse, pruebe una ruta representativa con hardware y tráfico similares a los de producción. Registre las distribuciones de latencia y la pérdida de paquetes durante varios días, incluidos los periodos de mayor actividad. Simule un fallo de circuito, retire un host, reinicie un gateway y compruebe que las sesiones, la recuperación de secuencias y los controles de riesgo se comportan como se espera. Compare el resultado con un objetivo de servicio documentado, no con la mejor cifra posible de un proveedor.
- Dibuje las rutas de órdenes y de datos de mercado, incluidos DNS, la autenticación, los controles de riesgo y los enlaces externos.
- Establezca objetivos para la latencia p99 y p99.9, la pérdida de paquetes, el tiempo de recuperación y el margen de capacidad.
- Calcule el coste de toda la infraestructura: conectividad, energía, soporte, transferencia de datos, equipos de reserva y cobertura de guardia.
- Realice pruebas de conmutación por error y confirme quién puede actuar, qué estado se conserva y cómo se restablece el servicio normal.
Revise la ubicación cuando cambien los volúmenes, los mercados o las estrategias. El error que muchos lectores seguirán cometiendo es elegir basándose en la latencia destacada o el precio mensual antes de medir su propia ruta de extremo a extremo y sus modos de fallo.
Preguntas frecuentes
¿La colocación siempre es más rápida que el cloud para el trading?
No. La colocación puede ofrecer una ruta más corta y controlada hasta un mercado cercano, pero el procesamiento de la aplicación y el diseño de red siguen determinando el rendimiento de extremo a extremo. Mida la ruta en producción con p99 y p99.9 bajo una carga realista.
¿Cuánto suele tardar la colocación de infraestructura de trading?
Una nueva instalación de colocación suele tardar de cuatro a doce semanas, según la disponibilidad de racks, el hardware, los cross-connects y las aprobaciones de los mercados. Los recursos cloud pueden aprovisionarse en días, aunque la conectividad y la validación para producción pueden llevar mucho más tiempo.
¿Qué cargas de trabajo de trading son adecuadas para el cloud?
El cloud suele ser adecuado para desarrollo, análisis, informes, servicios para clientes y cargas de trabajo con necesidades de capacidad variables. También puede ejecutar componentes sensibles a la latencia, pero las empresas deben probar la ubicación, el comportamiento de la red, la latencia de cola y la recuperación antes de comprometer la ruta de órdenes.
