Validação arquitetural

Continuando o papo sobre arquitetura, hoje o foco é sobre a sua validação. A ideia é responder se a proposta arquitetural feita irá honrar todos os requisitos, especialmente os não funcionais.

Como eu posso saber se o site que eu planeje suportaria dez mil usuários simultâneos? Ou quantas conexões eu tenho que colocar no meu pool para dar conta de atender aos meus clientes, na minha aplicação multi-tenant? Esse tipo de pergunta é melhor respondida se você colocar a prova o sistema.

O ideal é fazer uma carga e observar, colhendo alguns indicadores. Ora, como qualquer bom trabalho, o primeiro passo é planejar: o que precisa ser medido / testado? Quais serial bons valores obtidos? Para esta última pergunta, vale buscar referências de mercado, sua base histórica (você tem uma, não?), informações com parceiros e quaisquer outras fontes que puder levantar. Então, é preciso se munir de instrumentos para colher indicadores. Busque ferramentas que possam medir uso de memória, processador, disco, rede, além de dados específicos da sua plataforma tecnológica, como frequência de uso do garbage collector, uso de memória heap, tamanho de pilha e assim por diante. Você também vai precisar simular a carga com alguma(s) ferramenta(s). Uma bem comum é o JMeter, mas opções não faltam. Se a aplicação for web, distribuir a origem da carga é uma estratégia interessante, usando vários computadores, de diferentes regiões, para fazer acesso simultâneo. Há, inclusive, empresas que oferecem esse serviço.

Enquanto a aplicação é testada, você precisa observar os indicadores que estavam em seu planejamento, e ver como o sistema se comporta, sempre alinhado com o nível de serviço acordado durante a fase de requisitos. É preciso exercitar os componentes da aplicação, para tentar descobrir qual é o elo mais fraco. Se a aplicação se mostrou lenta porque a demanda por conteúdo estático rouba recursos importantes, que tal pensar num cache, para desafogar o servidor? Ou usar CDN?
Sua demanda é imprevisível e pode aumentar ou diminuir com frequência - tem alguma sazonalidade? Hummm. Que tal pensar em colocar sua aplicação na nuvem e aproveitar os recursos de elasticidade característicos dela? Se você quer que sua aplicação escale de forma horizontal, alocando mais servidores (ou desalocando), é melhor você se preocupar em fazer uma aplicação stateless. Você usa muita variável de sessão? Bem, que tal externalizar o armazenamento de sessão em um lugar acessível entre os servidores de aplicação? A Microsoft tem opções no Azure para colocar os dados em um SQL Server ou usar um serviço de cache compartilhado.

Não se esqueça de planejar como você vai monitar a aplicação no dia a dia. Eu tenho alguma experiência com o New Relic e gosto muito. Mas há muitas outras opções, para todos os gostos e bolsos. Veja qual se adapta bem à sua necessidade. A que eu escolhi me provê informações bem organizadas e me avisa se algum limiar do sistema for ultrapassado, para que eu possa intervir. Isso também ajuda a entender como é o crescimento da minha aplicação. Eu posso descobrir quanto, em média, cada cliente novo consome de recurso no meu servidor e quando eu vou ter que fazer um upgrade da minha infra. Também sei quanto cresce o meu disco e qual o consumo da minha rede.

Outra coisa importante: inclua (muitos) testes de segurança para sua aplicação. Descubra suas fraquezas. Analise qual o risco você está correndo. Nenhum sistema é 100% seguro, mas é bom saber onde estão suas vulnerabilidades e qual a chance (e o impacto) de um ataque. Hoje há literatura extensa sobre os pen-tests e várias ferramentas para auxiliar tanto na segurança quanto na avaliação de risco.

Provocações finais

Como você sabe que está pronto para ir para produção? Como você testa a sua proposta de arquitetura? Qual sua segurança que sua aplicação atende aos requisitos? Sua aplicação é fácil de escalar? Você se preveniu de SQL Injection e acredita que seu sistema é impossível de invadir. Será mesmo que é? O que você colocou na sua aplicação que impediria um ataque DDoS? Quão atual é o seu algoritmo de criptografia? E por último, mas não menos importante: É fácil repetir seus testes, se precisar? Ou não tem nada automatizado e vai custar uma fortuna repeti-los no futuro, quando o sistema evoluir?

Comentários

Postagens mais visitadas deste blog

Documento de arquitetura

Requisitos conflitantes e dilemas no projeto de software

Levantamento de requisitos