Plataformas · Software · Proveedores · Mercados
Devin Hartcastle
La colocation no es automáticamente más rápida que el cloud.
La colocation consiste en instalar los servidores propios de una empresa en un centro de datos, a menudo en una instalación utilizada por un mercado o por sus proveedores de conectividad. El cloud consiste en alquilar capacidad de cómputo, almacenamiento y redes a un proveedor. Ambos pueden alojar sistemas de gestión de datos de mercado, gateways de órdenes, controles de riesgo y servicios internos. La distinción útil no es entre físico y virtual. Es cuánto control tiene un equipo sobre la ruta, el hardware y el dominio de fallos, y cuánto paga por mantener ese control.
Un broker que envía órdenes a un centro de negociación desde un rack junto al motor de casación tiene un trabajo distinto al de una prop firm que ejecuta lotes de investigación o al de un portal de clientes de un broker. Una misma plataforma puede utilizar ambos modelos. La decisión adecuada empieza por el presupuesto de latencia, el patrón de tráfico y los requisitos de recuperación del servicio, no por una regla general según la cual todas las cargas de trading deben estar en un rack.
Qué ofrecen realmente los dos modelos
En una instalación de colocation, el operador alquila espacio, suministro eléctrico y refrigeración. La empresa proporciona o alquila los servidores y los conecta a las redes mediante cross-connects, switches gestionados o un operador de telecomunicaciones.
Si la instalación aloja un punto de acceso de un mercado, puede haber una ruta física corta. Eso no significa que una empresa esté conectada directamente al motor de casación: el acceso al mercado, la certificación, el diseño de red y el punto exacto de interconexión son importantes.
En el cloud, el proveedor opera la infraestructura física y ofrece máquinas virtuales, instancias bare metal, bases de datos gestionadas y servicios de red. Los equipos pueden aprovisionar capacidad en minutos y automatizar su sustitución.
Por lo general, tienen menos control sobre el host subyacente, el cableado y la ruta física. Una conexión privada puede evitar internet público en parte del recorrido, pero no hace que toda la ruta sea determinista ni garantiza una cifra de latencia.
La etiqueta del despliegue también oculta diferencias importantes dentro de cada modelo. Una ruta de cloud bien diseñada puede superar a una configuración de colocation sobrecargada o con un enrutamiento deficiente.
Un servidor dedicado en la instalación de un proveedor de cloud no equivale a un cross-connect con un mercado. Compare los puntos de conexión y las condiciones reales del tráfico. La cobertura de infraestructura de Trading Technology puede ayudar a los equipos a tener presentes esas diferencias entre proveedores y plataformas.
Mida la ruta, no la descripción comercial
Las cifras de latencia solo tienen sentido si se indican los puntos de conexión y el método. Mida desde el evento de la aplicación que importa, como la recepción de un paquete de datos de mercado o el envío de una orden, hasta el evento correspondiente en el otro extremo. Registre el tiempo de ida y vuelta cuando sea pertinente, pero no confunda un ping a un router cercano con el rendimiento entre el envío de la orden y su acuse de recibo. La aplicación puede añadir demoras por análisis sintáctico, controles de riesgo, colas, cifrado y planificación.
Las cifras que aparecen a continuación son rangos habituales del mercado, no garantías. Describen rutas distintas, por lo que sirven para fijar expectativas, no para clasificar proveedores sin una prueba comparable.
| Configuración y ruta medida | Latencia de ida y vuelta habitual | Fuentes comunes de variación | Qué excluye la cifra |
|---|---|---|---|
| Colocation, del host al gateway del mercado en la misma instalación | 50 to 500 microsegundos | Saltos entre switches, configuración de la NIC, ruta del cross-connect y punto de interconexión con el mercado | Procesamiento de la aplicación y gestión del acuse del mercado |
| Cloud, de host a host dentro de una zona de disponibilidad | 100 to 500 microsegundos | Virtualización, contención en el host, políticas de red y tamaño de los paquetes | Cualquier ruta fuera de la red del cloud |
| Cloud, conexión privada a un gateway del mercado en la misma área metropolitana | 0.5 to 5 milisegundos | Puntos de interconexión de los proveedores, ruta del operador y ubicación del gateway | Procesamiento de datos de mercado o controles de riesgo de órdenes |
| Cloud, red pública hasta un punto de conexión del mercado en la misma área metropolitana | 1 to 10 milisegundos | Enrutamiento de internet, congestión y cambios de ruta | Procesamiento de la aplicación y del mercado |
El comportamiento de cola importa más que un buen promedio. Recopile la latencia mediana, de percentil 99th y 99.9th, la pérdida de paquetes y el jitter durante la ventana de trading real. Separe los datos de mercado entrantes de las órdenes salientes. Registre marcas de tiempo en la NIC o con un reloj de hardware adecuado cuando la precisión lo justifique, y verifique la sincronización del reloj. Los promedios pueden ocultar ráfagas breves que llenan las colas, activan controles de precios obsoletos o provocan tiempos de espera de órdenes.
Mida la ruta completa de la orden bajo carga, incluida la parte más lenta que usted controla.
Control, resiliencia y trabajo operativo
La colocation ofrece un control más estricto sobre los modelos de servidor, las NIC, la configuración del kernel y la topología de red. Esto puede ser importante para un rendimiento determinista y las marcas de tiempo de hardware.
También deja a la empresa a cargo de la planificación de capacidad, el firmware, las piezas de repuesto, la asistencia técnica remota, el acceso físico y la renovación del ciclo de vida. Un fallo en una fuente de alimentación o un switch sigue siendo un incidente operativo, aunque el mercado esté al lado.
El cloud facilita crear instancias adicionales, aislar entornos y automatizar reconstrucciones. Puede simplificar la recuperación ante desastres cuando hay capacidad disponible en otra zona o región.
Pero un grupo de escalado automático no hace resiliente por sí solo una ruta de órdenes. Dependencias compartidas como la identidad, el DNS, los secretos, los feeds de datos de mercado y un único circuito privado pueden seguir siendo puntos comunes de fallo. La replicación entre zonas y el tráfico duplicado también pueden aumentar los cargos de red.
Deje por escrito qué fallos puede tolerar cada diseño. Incluya como mínimo:
- Pérdida de un servidor, rack, switch o suministro eléctrico.
- Pérdida de un operador, circuito privado, zona o región del cloud.
- Interrupciones de datos de mercado, datos obsoletos y mensajes duplicados o fuera de orden.
- Fallo del servicio de riesgo, incluido si el gateway bloquea las operaciones o dispone de una alternativa controlada.
- Objetivo de tiempo de recuperación y objetivo de punto de recuperación para cada servicio, no solo para la plataforma en su conjunto.
Pruebe la conmutación por error con tráfico realista y una autoridad clara para cambiar de ruta. Los gateways de órdenes activos-activos necesitan controles de secuenciación y de órdenes duplicadas; los sistemas activo-pasivo necesitan un método probado para determinar qué lado controla una sesión.
Una segunda ubicación que nunca ha procesado una carga similar a la real no es un plan de recuperación. Los equipos que siguen los cambios de plataformas y proveedores a través de Trading Technology deben validar igualmente el contrato, la topología y los límites del servicio con cada proveedor.
Compare el coste total y la adecuación a cada carga
Las facturas de colocation suelen incluir espacio en rack, potencia contratada, cross-connects, ancho de banda, hardware y soporte. Las del cloud incluyen capacidad de cómputo, almacenamiento, transferencia de datos, conectividad privada y herramientas operativas. Los precios varían según el mercado, la instalación y el compromiso, pero una instalación pequeña de colocation puede costar unos pocos miles de libras al mes, antes de incluir hardware y costes de red.
Las cargas de cloud pueden costar desde cientos hasta decenas de miles de libras al mes a medida que aumentan el tamaño de las instancias, la redundancia y los datos salientes. Considere estas cifras rangos habituales del mercado y calcule el precio del diseño concreto.
Compare un año completo de servicio, incluidos los costes de despliegue y personal. Una instancia de cloud que parece barata por hora puede salir cara si funciona de forma continua en zonas redundantes y mueve grandes volúmenes de datos de mercado. La colocation puede ofrecer menor latencia de red, pero requerir plazos de adquisición más largos, renovaciones de hardware y soporte in situ. Incluya el coste de una segunda ubicación, entornos de prueba, supervisión y el tiempo que los ingenieros dedican a operar cada modelo.
Un ejercicio práctico para decidir la ubicación sigue este orden:
- Enumere cada servicio y su presupuesto de latencia, volumen de datos, tasa de ráfagas y objetivo de recuperación.
- Dibuje la ruta completa de los paquetes, desde el feed o la conexión del cliente hasta los componentes de riesgo y gateway y, finalmente, el mercado.
- Mida la ruta actual bajo carga máxima y registre la latencia por percentiles, la pérdida y el jitter en puntos acordados.
- Calcule el precio de dos diseños viables para 12 meses, incluidos circuitos, cross-connects, tráfico de salida, hardware, soporte y personal.
- Realice una prueba de fallos y una prueba de tráfico representativo antes de trasladar una ruta de órdenes de producción.
La normalización de datos de mercado, los informes de back office, los entornos de prueba y los trabajos de investigación suelen ser adecuados para el cloud porque pueden escalar o tolerar una latencia variable. Los gateways orientados al mercado y las estrategias sensibles a la latencia pueden favorecer la colocation cuando la ruta y las condiciones de acceso permiten cumplir el presupuesto requerido. Es un punto de partida, no una regla: un servicio con requisitos estrictos de recuperación puede necesitar una segunda ubicación, independientemente de dónde esté su despliegue principal.
Tome la decisión con pruebas a nivel de servicio
Evalúe la decisión a nivel de servicio. Una empresa puede instalar sus gateways de mercado en colocation, ejecutar los cálculos de riesgo cerca de esos gateways y utilizar el cloud para servicios a clientes, análisis y capacidad de recuperación.
Otra puede tener una región de cloud lo bastante cerca de las rutas a sus mercados y una carga que no justifique operar hardware físico. La arquitectura debe responder a requisitos medidos y modos de fallo probados.
Antes de comprometerse, asegúrese de que el diseño responda a estas preguntas:
- ¿Dónde están los puntos de medición y abarcan la aplicación y el punto de interconexión con el mercado?
- ¿Qué ocurre con la latencia del percentil 99th cuando el sistema alcanza las tasas máximas de mensajes?
- ¿Qué servicios de red, suministro eléctrico, identidad y datos comparten las rutas principal y de recuperación?
- ¿Puede el personal de operaciones identificar una ruta defectuosa y cambiarla de forma segura sin generar órdenes duplicadas?
- ¿Incluye el modelo de costes la segunda ubicación, la transferencia de datos, la renovación del hardware y el trabajo de guardia?
No acepte una cifra destacada de latencia sin conocer sus puntos de conexión, percentil, carga de tráfico y ventana de prueba. Unos pocos microsegundos pueden importar para una estrategia concreta, mientras que un milisegundo puede ser irrelevante para un flujo de trabajo más lento. Defina el objetivo, mídalo en producción y vuelva a evaluarlo cuando cambien las rutas, los volúmenes o el acceso al mercado. Compruebe la cifra del percentil 99th entre la orden y su acuse de recibo en la ruta más concurrida, e investigue si supera 5 ms.
Preguntas frecuentes
¿La colocation siempre es más rápida que el cloud para el trading?
No. La colocation puede ofrecer una ruta más corta y controlable hasta un mercado, pero el rendimiento real depende del punto de interconexión, el diseño de red, el hardware y la aplicación. Compare los mismos puntos de conexión bajo una carga representativa, incluida la latencia de cola.
¿Puede un broker ejecutar infraestructura de trading en el cloud?
Sí. El cloud puede ser adecuado para servicios que necesitan un aprovisionamiento rápido, capacidad flexible o recuperación geográfica. Las rutas de órdenes orientadas al mercado siguen necesitando mediciones de latencia, conectividad adecuada y controles probados para las dependencias compartidas y la conmutación por error.
¿Qué latencia debe medir un equipo de trading?
Mida la ruta que corresponda a los requisitos del servicio, como el tiempo desde la llegada de los datos de mercado hasta su procesamiento por la aplicación, o desde el envío de una orden hasta su acuse de recibo. Registre la mediana y los percentiles de cola, la pérdida de paquetes y el jitter durante el tráfico máximo, y documente los puntos de conexión.
¿El cloud es más barato que la colocation para un broker?
Depende de la utilización, la redundancia, el tráfico de red, el hardware y el personal. Compare un diseño para un año completo que incluya circuitos, transferencia de datos, soporte, capacidad de recuperación y trabajo de guardia, en lugar de comparar únicamente los precios de las instancias con el alquiler del rack.
