Colocation vs. cloud: os controles de risco que importam

Às 17:42 de sexta-feira, um responsável por operações analisa um painel após uma semana ruim. As confirmações de ordens ficaram mais lentas durante um pico de atividade no mercado, um failover na cloud deixou um consumidor de feed para trás e a revisão do incidente não consegue determinar qual configuração estava ativa. A primeira pergunta é se a empresa precisa de colocation ou cloud. A pergunta mais útil é quais riscos o design consegue medir, conter e explicar.

Latência é uma propriedade do caminho

Colocation coloca equipamentos dentro ou perto de uma instalação de bolsa, geralmente com uma conexão cruzada à rede de uma venue. Isso elimina alguns saltos da rede pública e dá às equipes controle sobre servidores, placas de rede, configurações do kernel e caminhos dos pacotes. Isso não torna todas as ordens rápidas. Filas de gateway, bloqueios de aplicação, tratamento de feeds, qualidade do relógio e limitação de tráfego do lado da venue podem determinar o resultado.

A infraestrutura de cloud substitui parte do controle físico por computação, redes e zonas de disponibilidade gerenciadas pelo provedor. Uma carga de trabalho na mesma região metropolitana de uma venue ainda pode passar por uma conexão privada, uma borda do provedor, switches virtuais e componentes de rede compartilhados. Regiões e tipos de instância variam. O compromisso de disponibilidade de um serviço de cloud não é uma promessa de um tempo específico de ida e volta de uma ordem.

Os números abaixo são faixas típicas de planejamento de mercado, não compromissos de serviço. Eles descrevem apenas a latência de rede, não o processamento da aplicação ou o matching da bolsa.

Os resultados reais dependem da venue, da rota, do provedor, da carga de trabalho e do método de medição. Compare condições equivalentes: use os mesmos endpoints, tamanhos de pacote, carga e fonte de relógio, depois analise a mediana, o p99 e os maiores intervalos observados.

Essas faixas são úteis para uma avaliação inicial de arquiteturas, não para aprovar uma estratégia. Um limite de risco baseado na latência média pode ocultar uma cauda no p99 que causa cotações desatualizadas ou rejeições. Instrumente todo o caminho da ordem, incluindo os registros de data e hora da aplicação e as respostas da venue. Se a empresa precisa de um método confiável de comparação, a cobertura de infraestrutura da Trading Technology pode ajudar a estruturar as questões sobre fornecedores e plataformas, mas os testes de aceitação ainda precisam usar a carga de trabalho da própria empresa.

O risco muda com o limite de controle

Com colocation, a empresa é responsável por uma parcela maior da infraestrutura física e técnica. Isso inclui ciclo de vida do hardware, firmware, aplicação de patches no sistema operacional, acesso aos racks, registros de cabeamento, planejamento de capacidade e peças de reposição. O operador da instalação controla o acesso ao prédio, a energia e a refrigeração; a bolsa ou o provedor de conectividade controla outras partes da rota. Um caminho curto de cabos não elimina essas dependências. Ele torna o limite mais específico.

Na cloud, o provedor opera as instalações físicas e grande parte da rede subjacente. A empresa continua responsável por suas políticas de identidade, configuração das cargas de trabalho, tratamento de dados, segurança das aplicações, design de recuperação e monitoramento. A responsabilidade varia conforme o serviço. Um banco de dados gerenciado, uma máquina virtual e uma plataforma de contêineres não oferecem os mesmos controles nem as mesmas evidências. Tratar o relatório de asseguração do provedor como prova de que uma carga de trading está sob controle deixa lacunas na configuração e nos procedimentos operacionais da própria empresa.

Para empresas reguladas, as avaliações de terceirização e resiliência devem registrar a cadeia de serviço real, não apenas o nome do provedor principal. Os requisitos variam conforme a jurisdição e o negócio, mas as evidências geralmente precisam abranger criticidade do serviço, acesso, localização dos dados, notificação de incidentes, subcontratação, direitos de auditoria e um plano de saída. Mantenha um registro do serviço, do responsável, dos tipos de dados, dos objetivos de recuperação e das dependências relevantes. Verifique se esses registros correspondem ao que está em produção.

Para qualquer um dos modelos, deixe explícitos estes controles:

• Acesso: registre acessos privilegiados, aprovações, atividade de sessão e mudanças emergenciais. Reconcilie os registros de acesso físico com as identidades lógicas, quando a implantação permitir.
• Mudanças: versione as configurações de rede, firewall e host. Vincule as mudanças em produção às aprovações e mantenha uma forma de identificar a versão ativa durante um incidente.
• Dados: classifique dados de mercado, de clientes e de ordens; defina regras de retenção e exclusão; e verifique onde ficam os backups e as cópias de diagnóstico.
• Evidências: mantenha logs sincronizados no tempo para roteamento de ordens, dados de mercado, implantações e failovers. Defina períodos de retenção que atendam às necessidades legais, regulatórias e de investigações internas.

Colocation pode reduzir a dependência de redes virtuais e, ao mesmo tempo, aumentar a dependência de funcionários da instalação, fornecedores de hardware e procedimentos físicos. Cloud pode padronizar implantações e oferecer serviços gerenciados, mas aumenta a dependência dos planos de controle do provedor, dos serviços de identidade e da conectividade regional. Nenhum dos modelos é inerentemente mais fácil de auditar. O teste útil é saber se a empresa consegue demonstrar quem mudou o quê, quando mudou e qual serviço foi afetado.

Teste a falha e depois reúna as evidências

As alegações de resiliência precisam ser testadas com base nos modos de falha que importam para o trading, não em uma lista genérica de infraestrutura. Um ambiente de espera aquecido que restaura uma camada web pode ser irrelevante se um normalizador de dados de mercado não consegue recuperar o estado da sequência. Um segundo rack não é independente se compartilha a mesma alimentação de energia ou rota de rede. Uma segunda zona de cloud não é um plano de recuperação se ambas as implantações dependem de um único provedor de identidade ou de uma única operação do plano de controle.

Use um processo repetível antes de comprometer uma carga de trabalho crítica com qualquer um dos modelos:

1. Mapeie o serviço: desenhe os caminhos das ordens e dos dados de mercado, incluindo gateways, conectividade, DNS, fontes de horário, identidade, armazenamento e consoles operacionais. Marque as partes operadas pela empresa, pela venue e por cada fornecedor.
2. Defina objetivos mensuráveis: estabeleça latência aceitável no caminho da ordem e comportamento da cauda, tempo de recuperação, ponto de recuperação, perda de mensagens e intervalo máximo de dados desatualizados. Defina metas separadas para a operação normal e o modo degradado.
3. Meça sob carga realista: reproduza picos de atividade do mercado e de ordens, incluindo reconexões e novas tentativas. Registre a latência p50, p99 e p99.9 quando o volume permitir uma medição significativa da cauda, além de descartes, rejeições e profundidade das filas.
4. Injete falhas: remova um caminho de rede, reinicie um host, revogue uma credencial ou desative uma zona. Teste a recuperação planejada e a não planejada, e verifique se há ordens duplicadas, lacunas de sequência, split brain e sessões desatualizadas.
5. Preserve as evidências: mantenha planos de teste, registros de data e hora, telemetria, aprovações, exceções e responsáveis pelas correções. Repita os testes após mudanças relevantes no roteamento, nos serviços do provedor, nas aplicações de trading ou nos procedimentos de recuperação.

Os números de recuperação devem ser tratados como metas de design, não como propriedades universais de qualquer um dos modelos. Faixas típicas de planejamento de mercado para um failover aquecido bem preparado podem variar de dezenas de segundos a vários minutos; uma reconstrução a frio pode levar dezenas de minutos ou mais.

A substituição de hardware, as permissões da venue, a configuração de rotas e a reprodução de dados podem prolongar a interrupção. Meça a restauração completa do serviço, incluindo os primeiros dados de mercado válidos e a primeira ordem aceita com segurança.

A automação na cloud pode reduzir o tempo de implantação, mas também pode reproduzir rapidamente uma configuração incorreta em várias regiões. Colocation pode oferecer caminhos estáveis e rigorosamente controlados, mas o trabalho manual com hardware e o acesso à instalação podem atrasar a recuperação. Nos dois casos, os procedimentos operacionais precisam prever pontos de decisão para interromper novas tentativas automatizadas, esvaziar filas e confirmar o estado do trading antes de reabrir o fluxo de ordens.

Escolha pela carga de trabalho e comprove a saída

Gateways sensíveis à latência e estratégias com requisitos rigorosos de proximidade à venue podem justificar colocation. Cargas de trabalho com demanda variável, grande necessidade de computação para research ou preferência por serviços gerenciados podem se adequar à cloud, desde que as dependências de rede e de serviço atendam aos objetivos estabelecidos.

Muitas empresas usam os dois modelos. Um design híbrido pode separar execução de analytics, mas cria pontos de atrito operacionais: controles duplicados, telemetria diferente, divergências de configuração e uma linha do tempo de incidentes mais complicada.

Não dimensione o design para uma sessão média. Modele os períodos mais movimentados do mercado, o tráfego de recuperação e as implantações simultâneas.

Na cloud, teste cotas, disponibilidade de instâncias e vazão de rede na escala necessária, em vez de presumir que a capacidade pode ser criada instantaneamente. Em colocation, considere a energia disponível no rack, a capacidade das portas, o hardware de reserva e os prazos das conexões cruzadas. Mantenha uma margem de capacidade baseada na carga de pico medida e em um crescimento plausível, e depois teste o que acontece quando essa margem se esgota.

O planejamento de saída faz parte da resiliência e do risco de terceiros. Uma saída da cloud pode exigir exportação de dados, serviços substitutos, mudanças de identidade e uma transferência controlada de rota. Uma saída de colocation pode envolver retirada de equipamentos, novo acesso à instalação, pedidos de conectividade e testes com a venue. Em ambos os casos, identifique dependências que não podem ser transferidas rapidamente, defina uma sequência realista e mantenha a configuração em um formato portátil e passível de revisão. Teste pelo menos as partes críticas do plano, como restaurar os dados de mercado e comprovar os controles de ordens no caminho alternativo.

As equipes de operações que comparam fornecedores devem pedir o limite exato de medição por trás das alegações de latência, evidências de recuperação específicas para cada serviço, termos de notificação de incidentes, visibilidade dos subcontratados e acesso aos logs. Também devem perguntar o que acontece durante uma interrupção do plano de controle do provedor, uma desconexão do lado da venue e o comprometimento de uma credencial da empresa.

As respostas precisam ter responsáveis e datas de teste, não apenas constar no contrato. Há mais cobertura sobre opções de plataformas e provedores na Trading Technology, mas a avaliação de risco continua específica para a arquitetura e as obrigações da empresa.

O erro que a maioria dos leitores ainda cometerá é tratar colocation ou cloud como o controle, em vez de comprovar o caminho completo do serviço e seu comportamento diante de falhas.

#infraestrutura de trading #infraestrutura de dados de mercado #latência de sistemas de trading #colocation em bolsa #recuperação de desastres #gestão de risco na nuvem #resiliência operacional #compliance na nuvem