Eu votei, tu votaste… é hora de seguir com a vida com a parte 2 do meu post recente sobre o front-end de consulta de assembleias de voto da CNE na cloud AWS (Amazon Web Services).
O objectivo deste post é uma análise breve de um ponto de vista mais técnico da arquitectura desta aplicação web.
Irei tocar na alta disponibilidade, latência para os utilizadores e “adivinhar” onde está a base de dados.
Nota: Este post foi escrito, e os dados recolhidos antes das eleições em 21 de Setembro de 2017. Quando estiver a ler, é possível que o site e formulário mencionados não estejam mais disponíveis.
Esse tal de ELB é quié?
Vou começar por esclarecer os leitores sobre o que é o serviço ELB (Elastic Load Balancing) da AWS.
De forma simples, um Load Balancer é um dispositivo/serviço que encaminha o tráfego destinado a um ou mais grupos de servidores de acordo com um conjunto de parâmetros definidos como por exemplo a “carga” dos mesmos ou a distribuição equitativa de sessões entre eles. No caso da carga do servidor, ela pode ser medida de várias formas como a utilização de CPU, latência, quantidade de tráfego, número de sessões, etc.
Os Load Balancers são utilizados para:
- Facilmente escalar serviços adicionando novos servidores quando necessários sem grande impacto para os servidores existentes
- Alta disponibilidade identificando servidores em estado degradado e retirando-os de serviço sem alteração do ponto de contacto dos clientes
O Elastic Load Balancer é o nome que se dá ao serviço AWS que distribui os pedidos e tráfego definido entre várias instâncias EC2 (é o nome bonito que AWS dá às máquinas virtuais). O Load Balancer é elástico (Elastic) porque escala dinamicamente de acordo com a demanda a ele submetida.
Alta disponibilidade?
A cloud nos oferece maior confiança e segurança. Sem dúvidas. Mas de que nos serve toda esta disponibilidade se não conseguirmos chegar aos servidores?
É o que pode acontecer se considerarmos que “a porta de entrada” para esta consulta é o site da CNE (www.cne.ao) e o servidor DNS do domínio que, como vimos no post anterior, está em Angola, num Data Center que, de acordo com os nossos padrões, oferece disponibilidade mais baixa.
Quando se fala de isolamento de serviços de alta disponibilidade há também a considerar a possibilidade de degradação ou corte da ligação internacional, tal como sucedeu recentemente com o cabo submarino SAT-3. Dependendo do provedor que usa, com certeza sentiu alguma dificuldade, mas será que notou o mesmo ao aceder aos serviços de Internet Banking? Provavelmente não pois estes estão geralmente alojados em Angola e ligados ao(s) IXP (Internet Exchange Point).
Com falhas de ligações à internet, caso acontecesse, perderíamos a capacidade de consultar as assembleias de voto ao passo que tudo cá continuaria acessível.
Latência
Latência é um elemento crucial para a percepção de “rapidez” nos serviços web. Um dos factores mais consideráveis para nós é a distância da grande maioria dos serviços por motivos físicos: a luz (em fibra óptica) tem uma velocidade finita e leva tempo para percorrer distâncias. Quanto maior a distância, maior o tempo de “viagem”.
Ter os servidores mais longe da maioria dos utilizadores, implica tempos de resposta mais longos, embora para este serviços em específico a diferença não tenha relevante.
Onde está a base de dados?
Esta é uma pergunta difícil de responder. Mas podemos tentar “adivinhar” tendo em conta a informação acima e conhecimento da arquitectura típica deste tipo de aplicações.
Como? Analisando os tempos de resposta.
Para esta análise, vamos supor o caso mais simples de uma arquitectura de aplicação de 2 camadas (2 tier architecture) em que a base de dados é separada da camada web ou presentation.
Hipótese 1: A base de dados está em Angola
Com base na informação acima, já sabemos que os pedidos são feitos para um ELB na AWS que encaminha para uma ou mais VMs também na AWS. Pela informação publicada, não há nenhuma região AWS em Angola, sequer em África, pelo que estas VMs devem estar também na Europa, na mesma região que o ELB.
Supondo uma arquitectura de aplicação típica de 2 camadas (2 tier) com a base de dados em Angola, teríamos o seguinte:
No desenho acima, consideramos o ping médio de 150ms (ida e volta) de Luanda a Europa. Este tempo poderá variar para si de acordo com a hora do dia (congestionamento) e a tecnologia de acesso (fibra vs. satélite vs. WiMAX vs. LTE, etc…)
Hipótese 2: A base de dados está na Europa
Vamos fazer a mesma análise supondo a mesma arquitectura de 2 camadas com a base de dados em servidor separado mas na mesma região, ou até alojada no mesmo servidor virtual.
Nesta análise temos a mesma latência Angola-Europa mas estimamos 10ms entre Web e a base de dados. 170ms no total.
Veredicto
Antes do veredicto vamos dar uma olhada rápida aos tempos estimados até ao destino. Para o teste, usei o serviço da ZAP Fibra sempre depois da meia-noite (para minimizar congestionamento).
O trace não chega ao destino mas perceber facilmente que 52.93.7.139 já está dentro da rede da Amazon e bem pertinho do destino. 180ms em média até à AWS.
Para estimar o tepmo desde uma consulta até se obter uma resposta nada melhor que o nosso querido Wireshark onde análise de HTTP nos dá o tempo desde o pedido (HTTP GET) até a entrega completa da resposta. Esta valor pode ser visto clicando sobre o pacote de resposta HTTP, expandindo a camada Hypertext Transfer Protocol e vendo o valor de Time Since Request.
Para um pedido bem sucedido:
Para um pedido sem sucesso (números inventados)
Onde está a base de dados? Não sei. Mas em Angola não está!
O que faria eu?
Sem dúvidas mandava tudo para cloud. Pelo menos até os nossos provedores serem mais ágeis e conseguirem ter propostas e descrições de produtos VPS em menos de 1 mês!!
Nota adicional
Foi interessante notar que os restantes elementos da página da CNE, todos estáticos carregavam em ~15ms! De tudo que martelei, a única explicação lógica que encontrei é que a ZAP usa alguma forma de Caching transparente.