Plataformas · Software · Provedores · Mercados
Devin Hartcastle
Colocation não é automaticamente mais rápida que cloud.
Colocation significa instalar os servidores próprios de uma empresa em um data center, muitas vezes em uma instalação usada por uma bolsa ou por seus provedores de conectividade. Cloud significa alugar capacidade computacional, armazenamento e rede de um provedor. Ambos podem hospedar processadores de dados de mercado, gateways de ordens, verificações de risco e serviços internos. A distinção útil não é entre físico e virtual. É quanto controle o time tem sobre a rota, o hardware e o domínio de falha, e quanto paga para manter esse controle.
Um broker que envia ordens a um venue a partir de um rack próximo ao matching engine tem uma necessidade diferente da de uma prop firm que executa lotes de research ou de um portal de clientes de um broker. Uma única plataforma pode usar os dois modelos. A decisão certa começa pelo orçamento de latência, pelo padrão de tráfego e pelos requisitos de recuperação do serviço, não por uma regra geral de que toda operação de trading deve ficar em um cage.
O que os dois modelos oferecem de fato
Em uma instalação de colocation, o operador aluga espaço, energia e refrigeração. A empresa fornece ou aluga servidores e os conecta às redes usando cross-connects, switches gerenciados ou uma operadora.
Se a instalação hospeda um ponto de acesso de um venue, pode haver uma rota física curta. Isso não significa que a empresa esteja conectada diretamente ao matching engine: o acesso ao venue, a certificação, o projeto de rede e o ponto exato de interconexão são importantes.
Na cloud, o provedor opera a infraestrutura física e oferece máquinas virtuais, instâncias bare-metal, bancos de dados gerenciados e serviços de rede. Os times podem provisionar capacidade em minutos e automatizar a substituição.
Em geral, eles têm menos controle sobre o host, o cabeamento e a rota física subjacentes. Uma conexão privada pode evitar a internet pública em parte do trajeto, mas não torna toda a rota determinística nem garante um valor de latência.
O rótulo de implantação também oculta diferenças importantes dentro de cada modelo. Uma rota de cloud bem projetada pode superar uma configuração de colocation sobrecarregada ou com roteamento ruim.
Um servidor dedicado na instalação de um provedor de cloud não equivale a um cross-connect com uma bolsa. Compare os endpoints e as condições de tráfego reais. A cobertura de infraestrutura da Trading Technology pode ajudar os times a levar em conta essas diferenças entre provedores e plataformas.
Meça a rota, não a descrição comercial
Os números de latência só fazem sentido quando os endpoints e o método são informados. Meça desde o evento relevante na aplicação, como o recebimento de um pacote de dados de mercado ou o envio de uma ordem, até o evento correspondente na outra ponta. Registre o tempo de ida e volta quando for relevante, mas não confunda um ping para um roteador próximo com o desempenho entre o envio da ordem e a confirmação. A aplicação pode acrescentar atrasos de análise, verificações de risco, enfileiramento, criptografia e escalonamento.
Os números abaixo são faixas típicas de mercado, não garantias. Eles descrevem rotas diferentes e servem para estabelecer expectativas, não para classificar provedores sem um teste comparável.
| Configuração e rota medida | Latência típica de ida e volta | Fontes comuns de variação | O que o número não inclui |
|---|---|---|---|
| Colocation, host até o gateway do venue na mesma instalação | 50 to 500 microseconds | Saltos entre switches, configurações da NIC, rota do cross-connect e ponto de interconexão com o venue | Processamento da aplicação e tratamento da confirmação pelo venue |
| Cloud, de host a host em uma zona de disponibilidade | 100 to 500 microseconds | Virtualização, disputa por recursos no host, políticas de rede e tamanho dos pacotes | Qualquer rota fora da rede da cloud |
| Cloud, conexão privada com um gateway de venue na mesma região metropolitana | 0.5 to 5 milliseconds | Pontos de interconexão do provedor, rota da operadora e localização do gateway | Processamento de dados de mercado ou verificações de risco de ordens |
| Cloud, rede pública até um endpoint de venue na mesma região metropolitana | 1 to 10 milliseconds | Roteamento pela internet, congestionamento e mudanças na rota | Processamento da aplicação e do venue |
O comportamento nos percentis mais altos importa mais do que uma boa média. Colete a latência mediana e dos percentis 99th e 99.9th, a perda de pacotes e o jitter durante o horário real de trading. Separe os dados de mercado de entrada das ordens de saída. Registre os timestamps na NIC ou com um relógio de hardware adequado quando a precisão justificar, e verifique a sincronização dos relógios. As médias podem ocultar picos breves que enchem filas, acionam controles de preço defasado ou causam timeout de ordens.
Meça a rota completa da ordem sob carga, incluindo a parte mais lenta que você controla.
Controle, resiliência e trabalho operacional
Colocation oferece maior controle sobre modelos de servidor, NICs, configurações do kernel e topologia de rede. Isso pode ser importante para o desempenho determinístico e o registro de timestamps por hardware.
Ela também deixa a empresa responsável pelo planejamento de capacidade, firmware, peças de reposição, suporte presencial, acesso físico e substituição ao longo do ciclo de vida. Uma fonte de alimentação ou um switch com defeito ainda representa um evento operacional, mesmo que o venue fique ao lado.
Cloud facilita a criação de instâncias adicionais, o isolamento de ambientes e a automação de reconstruções. Pode simplificar a recuperação de desastres quando há capacidade disponível em outra zona ou região.
Mas um grupo de autoescalonamento não torna automaticamente resiliente uma rota de ordens. Dependências compartilhadas, como identidade, DNS, segredos, feeds de dados de mercado e um único circuito privado, podem continuar sendo pontos comuns de falha. A replicação entre zonas e o tráfego duplicado também podem aumentar os custos de rede.
Documente as falhas que cada projeto consegue tolerar. Inclua pelo menos:
- Perda de um servidor, rack, switch ou alimentação elétrica.
- Perda de uma operadora, circuito privado, zona ou região de cloud.
- Lacunas nos dados de mercado, dados defasados e mensagens duplicadas ou fora de ordem.
- Falha do serviço de risco, incluindo se o gateway interrompe as operações ou dispõe de uma alternativa controlada.
- Objetivo de tempo de recuperação e objetivo de ponto de recuperação para cada serviço, não apenas para a plataforma como um todo.
Teste a comutação para contingência com tráfego realista e uma autoridade claramente definida para mudar as rotas. Gateways de ordens ativo-ativo precisam de controles de sequenciamento e de ordens duplicadas; sistemas ativo-passivo precisam de um método testado para determinar qual lado controla uma sessão.
Um segundo site que nunca processou carga semelhante à de produção não é um plano de recuperação. Os times que acompanham mudanças de plataformas e provedores pela Trading Technology ainda devem validar o contrato, a topologia e os limites do serviço com cada fornecedor.
Compare o custo total e a adequação à operação
As faturas de colocation geralmente incluem espaço em rack, energia contratada, cross-connects, largura de banda, hardware e suporte. As faturas de cloud incluem capacidade computacional, armazenamento, transferência de dados, conectividade privada e ferramentas operacionais. Os preços variam conforme o mercado, a instalação e o compromisso, mas uma pequena estrutura de colocation pode custar alguns milhares de libras por mês, antes dos custos de hardware e rede.
Os custos de operações em cloud podem variar de centenas a dezenas de milhares de libras por mês, à medida que aumentam o tamanho das instâncias, a redundância e os dados de saída. Trate esses valores como faixas típicas de mercado e calcule o preço do projeto específico.
Compare um ano inteiro de serviço, incluindo os custos de implantação e de pessoal. Uma instância de cloud que parece barata por hora pode ficar cara quando funciona continuamente em zonas redundantes e transfere grandes volumes de dados de mercado. Colocation pode ter menor latência de rede, mas exigir prazos maiores de aquisição, atualizações de hardware e suporte presencial. Inclua o custo de um segundo site, ambientes de teste, monitoramento e o tempo que os engenheiros gastam operando cada modelo.
Um exercício prático de alocação segue esta ordem:
- Liste cada serviço e seu orçamento de latência, volume de dados, taxa de pico e objetivo de recuperação.
- Desenhe a rota completa dos pacotes, da conexão do feed ou do cliente, passando pelos componentes de risco e gateway, até o venue.
- Meça a rota atual sob carga de pico, registrando latência por percentil, perda e jitter em pontos acordados.
- Calcule o custo de dois projetos viáveis ao longo de 12 meses, incluindo circuitos, cross-connects, tráfego de saída, hardware, suporte e equipe.
- Faça um teste de falha e um teste com tráfego representativo antes de migrar uma rota de ordens de produção.
A normalização de dados de mercado, os relatórios de back office, os ambientes de teste e os trabalhos de research costumam se adequar à cloud, porque podem escalar ou tolerar latência variável. Gateways voltados a venues e estratégias sensíveis à latência podem favorecer colocation quando a rota e as condições de acesso atendem ao orçamento necessário. Esse é um ponto de partida, não uma regra: um serviço com requisitos rígidos de recuperação pode precisar de uma segunda localização, independentemente da implantação principal.
Tome a decisão com evidências sobre os serviços
Tome a decisão no nível do serviço. Uma empresa pode colocar seus gateways de venue em colocation, executar cálculos de risco perto desses gateways e usar cloud para serviços ao cliente, análise e capacidade de recuperação.
Outra pode ter uma região de cloud suficientemente próxima das rotas até o venue e uma operação que não justifique manter hardware físico. A arquitetura deve seguir os requisitos medidos e os modos de falha testados.
Antes de se comprometer, verifique se o projeto responde a estas perguntas:
- Onde ficam os endpoints de medição e eles incluem a aplicação e o ponto de interconexão com o venue?
- O que acontece com a latência do percentil 99th quando o sistema atinge as taxas máximas de mensagens?
- Quais serviços de rede, energia, identidade e dados são compartilhados entre as rotas principal e de recuperação?
- A equipe de operações consegue identificar uma rota problemática e mudar com segurança sem criar ordens duplicadas?
- O modelo de custos inclui o segundo site, a transferência de dados, a atualização de hardware e o trabalho de plantão?
Não aceite um número de latência em destaque sem conhecer seu endpoint, percentil, carga de tráfego e janela de teste. Alguns microssegundos podem importar para uma estratégia específica, enquanto um milissegundo pode ser irrelevante para um fluxo de trabalho mais lento. Defina a meta, meça-a em produção e reavalie-a quando as rotas, os volumes ou o acesso ao venue mudarem. Verifique o número do percentil 99th entre o envio e a confirmação de ordens na sua rota mais movimentada e investigue se estiver acima de 5 ms.
Perguntas frequentes
Colocation é sempre mais rápida que cloud para trading?
Não. Colocation pode oferecer uma rota mais curta e controlável até um venue, mas o desempenho real depende do ponto de interconexão, do projeto de rede, do hardware e da aplicação. Compare os mesmos endpoints sob carga representativa, incluindo a latência nos percentis mais altos.
Um broker pode operar infraestrutura de trading na cloud?
Sim. Cloud pode ser adequada a serviços que precisam de provisionamento rápido, capacidade flexível ou recuperação geográfica. Rotas de ordens voltadas a venues ainda precisam de latência medida, conectividade adequada e controles testados para dependências compartilhadas e comutação para contingência.
Que latência um time de trading deve medir?
Meça a rota correspondente ao requisito do serviço, como o intervalo entre a chegada dos dados de mercado e o processamento pela aplicação ou entre o envio da ordem e sua confirmação. Registre a mediana, os percentis mais altos, a perda de pacotes e o jitter durante o pico de tráfego, e documente os endpoints.
Cloud é mais barata que colocation para um broker?
Depende da utilização, da redundância, do tráfego de rede, do hardware e da equipe. Compare um projeto para o ano inteiro que inclua circuitos, transferência de dados, suporte, capacidade de recuperação e trabalho de plantão, em vez de comparar preços de instâncias apenas com o aluguel de racks.
