TradeTech Brazil 2011 - O Desafio Da Latencia

1,213 views

Published on

Apresentação realizada no TradeTech Brazil 2011

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,213
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
15
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

TradeTech Brazil 2011 - O Desafio Da Latencia

  1. 1. O Desafio Da Latência Alcance Baixa Latência No Electronic Trading Brasileiro Para Obter Vantagens Competitivas<br />Dr. Christian J. Zimmer- Head of Quantitative Portfolio Management and ResearchItaú Asset Management<br />José Ricardo Maia Moraes - Diretor de Desenvolvimento de NegóciosMultirede Informática S.A.<br />
  2. 2. Agenda<br /><ul><li>Overview
  3. 3. Componentes de latência
  4. 4. Padrões brasileiros x internacionais de latência
  5. 5. Software, rede, interface e hardware: o que será preciso para ser suficientemente rápido?
  6. 6. Por que ser rápido: justificando à sua empresa os investimentos em tecnologia para diminuir a latência
  7. 7. Latência & DMA: como medir e assegurar-se de que a latência será mantida baixa?
  8. 8. Discussão sobre cenários</li></li></ul><li>Percepção de latência<br /><ul><li>Olho humano: 300 milissegundos
  9. 9. Tempo aproximado da BM&FBOVESPA: 15 milissegundos
  10. 10. Meta para os próximos 18 meses: 400 microssegundos
  11. 11. Percepção da dor: 100 milissegundos</li></ul>“Ao ser ferido por faca, você levará 100 milissegundos para gritar. Nesse mesmo período um sistema de negociação algorítmica terá processado cerca de 250 ofertas de compra ou venda”<br />Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  12. 12. Overview - Brasil<br />Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  13. 13. Brasil x usa<br />Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  14. 14. Conectividade bm&fbovespa<br />Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  15. 15. Volume - brasil<br />Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  16. 16. Volume - brasil<br />Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  17. 17. Evolução de latência - usa<br />
  18. 18. Evolução volume - usa<br />
  19. 19. LSE Environment<br />www.londonstockexchange.com/hosting<br />
  20. 20. LSE Environment<br />www.londonstockexchange.com/hosting<br />
  21. 21. LSE hosting service<br />www.londonstockexchange.com/hosting<br />
  22. 22. LSE Environment<br />www.londonstockexchange.com/hosting<br />
  23. 23. cme<br />CME CLIENT MANAGED ROUTER GUIDANCE<br />
  24. 24. cme<br />CME CLIENT MANAGED ROUTER GUIDANCE<br />
  25. 25. Nasdaq omx<br />Thomas Fay, VP Engineering NASDAQ OMX - April 4, 2011<br />
  26. 26. Nasdaq omx<br />Thomas Fay, VP Engineering NASDAQ OMX - April 4, 2011<br />
  27. 27. Volumes - nyse<br />
  28. 28. ciclo<br />Electronic<br />Trading<br />Criamais<br />Criando mais<br />Inabilidadehumana<br />Algo Trading<br />Negócios<br />e<br />Market Data<br />Rápidarecepção, tradução,<br />e distribuição domarket data<br />Requerendo<br />Resulta<br />Source: TowerGroup 2007<br />
  29. 29. Ordem de grandeza<br />MaisLatência<br />7<br />AplicaçãoApresentaçãoSessão<br />Dado<br />6<br />5<br />Janelamento TCPControle de FluxoRetransmissão<br />Segmentos<br />4<br />Procura de endereçosEncaminhamentoRoteamento<br />Pacotes<br />Camada OSI<br />Unidade<br />3<br />Store-ForwardCodificaçãoSwitching<br />Frames<br />2<br />Framing<br />Bits<br />1<br />MenosLatência<br />
  30. 30. Componentes da latência<br /><ul><li>Propagação - emfunção da distância e velocidade da luz (limitada pelas leis da física)
  31. 31. Serialização – emfunção do tamanho do pacote e velocidade da conexão
  32. 32. Enfileiramento – em função do tráfego, velocidade e enfileiramento</li></li></ul><li>Latência fim a fim<br />LatênciaFim a Fim<br />Segundos<br />Milisegundos<br />Microsegundos<br />NANOSEGUNDOS<br />Aplicação<br />Servidores/OS<br />Segurança<br />Rede (LAN)<br />Rede (MAN/WAN)<br />Muitasvariáveisenvolvidas - a chave é endereçar o processofim a fim<br />
  33. 33. Endereçando variáveis<br />SERVER<br />SERVER<br />NIC<br />NIC<br />CABLING<br />SWITCHING<br />
  34. 34. Servidores<br /><ul><li>VISÃO GERAL
  35. 35. Arquitetura de computação paralela da NVIDIA que possibilita aumentos significativos na performance de computação pelo aproveitamento da potência da GPU (unidade de processamento gráfico).
  36. 36. Com milhões de GPUs habilitadas para CUDA vendidas até o momento, desenvolvedores de software, cientistas e pesquisadores continuam achando os mais diversos usos para a essa tecnologia</li></li></ul><li>Servidores - fpga<br />FPGA (Field Programmable Gate Arrays) <br />Usar o poder de chips programáveis FPGA para entregar poder de computação dez vezes maior do que a utilização de CPUs convencionais<br />CPU<br />FPGA<br />Maisflexível<br />Maisrápido<br />Investimento e despesasuperiores<br />Investimento e despesainferiores<br />Menordespesa de desenvolvimento<br />Maiordespesa de desenvolvimento<br />
  37. 37. Servidores - alternativas<br /><ul><li>RDMA
  38. 38. iWARP
  39. 39. Infiniband</li></li></ul><li>1G x 10G<br />
  40. 40. SFP+ to SFP+<br />TransceiverLatency (link)<br />Power(each side)<br />Cable<br />Distance<br />Technology<br />SFP+ Cu<br />SFP+ CUCopper<br />Twinax<br />~0.25ms<br />~0.1W<br />10m<br />MM OM2MM OM3<br />10m100m<br />SFP+ USRultra short reach<br />~0.1ms<br />1W<br />MM 62.5mmMM 50mm<br />82m300m<br />SFP+ SRshort reach<br />~0.1ms<br />1W<br />Cat6Cat6a/7Cat6a/7<br />2.5ms2.5ms1.5ms<br />~8W~8W~4W<br />55m100m30m<br />10GBASE-T<br />cabling<br />
  41. 41. storage<br />150 IOPS HDD  15,000 IOPS SSD<br />
  42. 42. switching<br /><ul><li>NonBlocking (No oversubscription)
  43. 43. Ultra LowLatency (atualmente em 500ns)</li></ul>AggregationLayer<br />24 x 10G<br />Access Layer<br />24 x 10G<br />
  44. 44. arquitetura<br />Arquiteturas virtualizadas transformando diversas unidades físicas em uma única unidade lógica<br />VIRTUAL<br />FÍSICO<br />ARQUITETURA TOTALMENTE REDUDANTE<br />(FÍSICA E LÓGICA) LIVRE DE LOOPINGS<br />
  45. 45. arquitetura<br />Arquitetura em camada 3 a partir do acesso de desktops e servidores não possuem tempo de convergência<br />VIRTUAL<br />ROTEAMENTO SIMPLIFICADO<br />
  46. 46. arquitetura<br />Conexão de servidores em alta disponibilidade<br />FÍSICO<br />VIRTUAL<br />LÓGICO<br />
  47. 47. arquitetura<br />Canais de comunicação dedicados<br />Acesso<br />
  48. 48. A importância da localização<br />Quanto mais próximos da Bolsa, menor será a latência<br />LATÊNCIA-5µs/Km<br />
  49. 49. Conexões internacionais<br />SP – NY<br />Típico 104-110ms<br />Fonte: GlobeNet<br />
  50. 50. Conexões internacionais<br />110<br />Fonte: GlobeNet<br />
  51. 51. Problemas reais<br />AMBIENTE 2<br />AMBIENTE 6<br />AMBIENTE 3<br />AMBIENTE 4<br />AMBIENTE 5<br />AMBIENTE 1<br />Componentes das aplicações são distribuídos pelo ambiente sem observar o fluxo entre eles <br />AMBIENTE 7<br />AMBIENTE 8<br />DESTINO<br />WAN<br />Pacotes atravessam elementos de rede 32 vezes<br />
  52. 52. aplicações<br /><ul><li>Linguagens: C++, Java, C#
  53. 53. Linguagens funcionais: F#, Scala, Erlang
  54. 54. Sistemas operacionais: Linux, CentOS
  55. 55. Banco de dados: KDB+, Berkeley, DB, RED
  56. 56. Modelagem: R, Mathematica, Matlab
  57. 57. Script languages: Python, Rubyonrails, LUA
  58. 58. Protocolos: FIX/FAST, TCP/IP, UDP, proprietários
  59. 59. Middleware: QuickFIX, AMQP, TIBCO </li></ul>Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  60. 60. aplicações<br />Arquitetura que possa escalar verticalmente e horizontalmente <br /><ul><li>Uso de memória – além de permitir escalabilidade vertical, dá alto desempenho
  61. 61. Uso de threads, múltiplas instâncias de serviço – escala verticalmente (máquinas multiprocessadas ou com múltiplos cores). Atenção para afinidades de processamento
  62. 62. Processos de distribuição de carga (Balanceamento de carga) permitem a implementação da escalabilidade horizontal
  63. 63. Atenção com banco de dados na arquitetura distribuída.</li></ul>Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  64. 64. aplicações<br />Comunicação entre processos<br /><ul><li>Memória compartilhada – bom desempenho, mas limita escalabilidade horizontal
  65. 65. Webservices (SOA) – excelente arquitetura, mas com performance limitada – ideal para produtividade em sistemas específicos que não requeiram alto desempenho
  66. 66. Nada mais rápido que comunicação TCP/IP (sockets) ou Multicast para difusão
  67. 67. Para comunicação TCP/IP considerar middleware como MS-MQ, WebSphere MQ. Idealmente um middleware de alto desempenho como TIBCO ou IBM WebSphere MQ LowLatencyMessaging
  68. 68. Comunicação pura TCP/IP por socket, com protocolo binário, é o que apresenta melhor desempenho, mas há que se considerar (i) o padrão da mensageria e (ii) o protocolo de sessão
  69. 69. Utilização de padrões, como o FIX, para produtividade. Para aplicações que necessitam alto desempenho, evitar o XML
  70. 70. Considerar FIX FAST para performance na difusão</li></ul>Fonte: Marcio Castro, CTO BM&FBOVESPA, 4/3/2011<br />
  71. 71. Protocolos - tcp<br />O retorno ao máximo pode levar bastante tempo!<br />TCP<br />Perda de pacotes<br />Perda de pacotes<br />Perda de pacotes<br />Perda de pacotes<br />cwnd<br />Tempo (RTT)<br />Slow start<br />Congestion avoidance<br />
  72. 72. Porque monitorar no µs?<br />Um microburst de 50 µS no Data Center podeintroduzirpicos de latênciamaioresque 50 ms mesmoque a utilizaçãosejamenorque 2%<br />Visão legada<br />Velocidade do Link<br />Visão de 1 segundo<br />Visão de 5 minutos<br />Rede ok?<br />Data Center<br />Aplicação<br />Impactada<br />Visão de 5 milissegundos <br />Velocidade do Link<br />NecessárioAjuste<br />Data Center<br />Aplicação<br />Impactada<br />CongestionamentoDinâmico – Perda de pacotes e delay intermitentes<br />
  73. 73. microburst<br /><ul><li>Microbursts são os picos de tráfego de menos de 1 segundo
  74. 74. Microbursts podem perturbar seriamente o fluxo de streaming de aplicações críticas como IP Multicast, e porque eles acontecem em um curto espaço de tempo, são muitas vezes difíceis de isolar</li></li></ul><li>microburst<br />Granularidade de sub-segundo<br />Microburst Event<br />
  75. 75. Monitoração<br />A necessidade por informações precisas de monitoração exige que sejam instalados sensores em todos os segmentos de rede por onde trafegam as aplicações<br />VLAN<br />VLAN<br />VLAN<br />WAN<br />PROBES 1G/10G<br />APLICAÇÃO<br />MONITORAÇÃO<br />
  76. 76. Monitoração sem adição de latência<br />Situação 1 : Dispositivo copia o pacote para uma outra porta<br />Pontos de Atenção:<br /><ul><li>Introduz latência
  77. 77. Limitações no hardware fazem com que a solução não escale</li></ul>MONITORAÇÃO<br />Situação 2: Monitoração fica em linha<br />Pontos de Atenção:<br /><ul><li>Introduz latência
  78. 78. Limitações fazem com que a solução não escale
  79. 79. Indisponibilidade da monitoração também indisponibiliza conectividade</li></ul>MONITORAÇÃO<br />Situação 3: Dispositivo (TAP) coleta e envia os dados para a monitoração<br />Pontos de Atenção:<br /><ul><li>Não Introduz latência
  80. 80. Em caso de falha não há indisponibilidade de conectividade
  81. 81. Opção de cobre e óptico</li></ul>TAP<br />MONITORAÇÃO<br />
  82. 82. Monitoração<br />Trader FIX Gateway Smart Order Router<br />Buy NTCT !<br />Exchange 1<br />Exchange 2<br />Exchange 3<br />xxx.xxx.xxx.0/24<br />xxx.xxx.xxx.0/24<br />xxx.xxx.xxx.0/24<br />FIX Protocol<br />Different application protocols<br />10.25.12.0/24<br />FIX Protocol<br />192.168.1.0/24<br />29West / LBM Protocol<br />Total Latency<br />22.6 msec<br />Latency Breakout<br />3.8 msec<br />0.1 msec<br />1.2 msec<br />12.3 msec<br />0.2 msec<br />
  83. 83. Onde focar esforços?<br />OU<br />AQUI?<br />AQUI?<br />
  84. 84. Quanto custa cada microssegundo?<br /><ul><li>Depende dos objetivos e estratégias
  85. 85. Faz mais sentido atacar o problema maior primeiro (aplicação), contudo pode ser muito mais caro e demorado
  86. 86. Microssegundos reduzidos com arquitetura e dispositivos de rede podem ser mais baratos e rápido de implementar
  87. 87. Não há uma receita, cada caso é um caso e merece uma análise cuidadosa</li></li></ul><li>No freelunch<br /><ul><li>Eletronificação do mercado é baseado em tecnologia de ponta
  88. 88. Altos volumes e redução de latência exigem soluções cada vez mais sofisticadas
  89. 89. Gerenciamento e monitoração não é uma opção – você só controla o que você conhece!
  90. 90. Nos próximos anos haverá uma forte onda de investimentos no mercado (Bolsa, participantes, vendors, software houses, etc.)</li></ul>DESAFIO<br />Alinhar as demandas de negócios com os investimentos em tecnologia<br />
  91. 91. Sucesso = Σ de variáveis<br />
  92. 92. Perguntas?<br />obrigado<br />

×