DEV Community: Eduardo Santana

Caixa de ferramentas da Arquitetura de Software [Parte-2]

Eduardo Santana — Thu, 11 Apr 2024 14:33:39 +0000

Continuando o texto que escrevi semana passada sobre o livro "Caixa de Ferramentas da Arquitetura de Software" hoje vou escrever sobre a terceira parte do livro que é focado na confiabilidade da aplicação.

Se você não leu o primeiro post, você pode encontra-lo aqui:
https://dev.to/ezambomsantana/caixa-de-ferramentas-da-arquitetura-de-software-parte-1-2i7a

No post de hoje vou falar sobre a confiabilidade em uma aplicação, que é talvez um dos requisitos não funcionais mais importantes na Engenharia de Software, já que ele indica que a aplicação executa corretamente os requisitos funcionais para que ela foi projetado de forma confiável.

Mas o que isso quer dizer? Primeiro que os requisitos estão implementados corretamente, se o usuário fizer uma operação ela vai executar exatamente o que ele esperava.

Segundo, que a aplicação estará sempre disponível, você já deve ter visto um sistema indisponível, e sabe o quanto isso é frustrante.

Por último, sabendo que por melhor que a aplicação seja, ela pode falhar, e se falhar, será possível recupera-la sem efeitos colaterais.

Para garantir a confiabilidade da aplicação temos que pensar em todas as fases do software, iniciando do projeto e indo até a execução da aplicação. No processo de desenvolvimento temos que garantir que a aplicação cumpra os seus requisitos e que eles foram bem testados.

No código, é necessário garantir que ele trate exceções e que a aplicação continue a funcionar mesmo em situações adversas, como um alto número de requisições por exemplo. Na infraestrutura precisamos garantir que a aplicação se recupere de possíveis falhas e também que a troca de versões não cause grandes momentos de indisponibilidade da aplicação.

Vamos discutir um pouco mais a fundo como podemos aumentar a confiabilidade das aplicações em cada um dos estágios de uma aplicação.

Confiabilidade no Desenvolvimento

Para aumentar a confiabilidade da aplicação devemos começar a trabalhar ainda no processo de desenvolvimento, existem várias práticas nesse processo que ajudam a aumentar bastante a confiabilidade.

Um exemplo é a revisão de código, essa prática ajuda muito em evitar problemas como mal entendimento das regras de negócio ou exceções que um desenvolvedor não pensou. O velho ditado que duas cabeças pensam melhor que um vale bastante na programação (como em praticamente qualquer outra coisa).

Além da revisão outra prática que ajuda bastante é o desenvolvimento de testes automatizados. No mundo ideal, teríamos tempo para testar a aplicação inteira novamente a cada subida pra produção, mas sabemos que não é isso que acontece, pois isso levaria muito tempo.

Assim, a única forma de ter segurança que uma mudança no código não teve efeitos inesperados é ter uma grande cobertura de testes automatizados.

Existem várias ferramentas que podem ser usadas nessa fase do desenvolvimento de software. Algumas comuns são um bom sistema de controle de versão, como o Git, frameworks de teste como o JUnit e Mockito para Java e ferramentas que fazem análise de código e de cobertura de testes como o Sonar.

Confiabilidade no Código

Pensando no código, existem várias implementações para aumentar a confiabilidade no código, uma indispensável é o tratamento de exceções, para garantir que erros inesperados não estourem na cara dos usuários. Por isso tratar exceções, e se possível se recuperar delas é essencial.

Outra implementação importante em qualquer aplicação que tenha uma alta carga de trabalho é o rate limit (ou limitação de carga). Essa implementação evita um sobrecarga no servidor, e também pode ajudar a mitigar ataques do tipo DDoS, e caso um usuário passe do seu limite de requisições, o servidor pode retornar um erro 429 (Too Many Requests).

Definir timeouts para chamadas a recursos externos também é uma prática importante. As vezes é melhor falhar logo do que ficar esperando por um tempo indeterminado ou muito grande. Lembrando que na maioria dos servidores, se uma thread está parada esperando uma resposta, ela não consegue atender outras requisições, desperdiçando recursos.

Também relacionado a recursos externos, também vale a pena mencionar os Circuit Breakers que verifica se o recurso que a aplicação está acessando está enfrentando problemas (demora na respostas ou muitos erros) e caso sim pode interromper momentaneamente as chamadas para esse recurso.

Confiabilidade na Infraestrutura

Pensando na infraestrutura, o passo mais obvio para garantir a confiabilidade é ter mais de uma instância rodando a aplicação. Isso pode ser feito usando um balanceador de carga (Load Balancer - LB) que vai distribuir as requisições entre duas ou mais instâncias de uma aplicação, ou em uma ferramenta de gerenciamento de conteineres, como o Kubernetes.

Esse ideia de instâncias pode existir em vários níveis. Por exemplo, podem existir duas instâncias em um mesmo servidor, isso já é melhor do que nada, mas ainda pode ser insuficiente, pois se o servidor cair, as duas instâncias ficarão fora do ar. Em um provedor de cloud, é possível ter duas ou mais instâncias em diferentes áreas geográficas, o que diminui bastante a probabilidade de falhas totais.

Obviamente que para isso a aplicação deve estar preparada. Um exemplo é que para permitir a execução de mais de uma instância, a aplicação não deve ter nada local, por exemplo, um token de autenticação não pode ser mantido diretamente na aplicação, senão um token só valerão naquela instância, para isso pode ser usado um cache distribuído como o Redis.

Outro ponto bastante importante na infraestrutura é garantir a recuperabilidade da aplicação, isto é, a capacidade da aplicação se recuperar de problemas (já que problemas são inevitaveis). Um exemplo disso é se um servidor (ou VM) reiniciar automaticamente, a aplicação voltará a funcionar automaticamente ou precisará de uma intervenção humana?

Outro exemplo de recuperabilidade são os backups, eles são essenciais para o caso de perda de dados seja possível recuperar a aplicação para um ponto não tão distante do atual. Uma dica sobre backups, nunca os guarde na mesma máquina onde a aplicação está sendo executada.

Por fim, um último requisito indispensável para a confiabilidade da aplicação é o seu monitoramento. Isso importante tanto para a aplicação quanto para a infraestrutura. Existem várias ferramentas que podem ser usadas para isso como o Prometheus, Grafana e o Dotadog.

Se tiver interesse no livro, você pode encontrar diretamente no site da Casa do Código:

https://www.casadocodigo.com.br/products/livro-caixa-de-ferramentas-da-arquitetura-de-software

ou na Amazon:

https://www.amazon.com.br/Caixa-ferramentas-Arquitetura-Software-aplica%C3%A7%C3%B5es-ebook/dp/B0CYJV5P11/ref=rvi_d_sccl_1/147-7357894-3056112

Caixa de ferramentas da Arquitetura de Software [Parte-1]

Eduardo Santana — Mon, 25 Mar 2024 15:54:55 +0000

Vou escrever uma série de publicações para descrever um pouco mais profundamente o conteúdo do meu livro "Caixa de ferramentas da Arquitetura de Software: Como tornar suas aplicações mais escaláveis, confiáveis e seguras" publicado pela Casa do Código no dia 19/03/2024.

Neste texto vou dar uma visão geral das duas primeiras partes do livro. O livro é dividido em 5 partes, a primeira parte é uma introdução a arquitetura de software, nela descrevo algumas visões sobre o que é arquitetura de software e mostro algumas das organizações mais comuns que são usadas para o desenvolvimento de software.

Depois, na segunda, terceira e quarta parte entro em cada um dos requisitos destacados no subtítulo do livro, que são Escalabilidade, Confiabilidade e Segurança. Esse requisitos são fortemente influenciados pela arquitetura de uma aplicação, e existem diversas ferramentas que podem ser utilizadas para atingir os objetivos da aplicação.

Na segunda parte eu foco em três requisitos importantes:

Desempenho: Relacionado principalmente ao tempo de resposta da aplicação. Normalmente, esse tempo deve ser o menor possível, mas no mínimo ele deve atender as expectativas do usuário. Por exemplo, uma rota REST síncrona deve responder em alguns poucos segundos, se o tempo for muito maior que isso, será necessário pensar em alternativas para implementar essa rota, como por exemplo implementar uma rota assíncrona, que irá avisar o usuário quando o processamento está completo.
Escalabilidade: Uma aplicação pode funcionar bem com poucos usuário, mas e se a carga aumentar, ela continua funcionando bem? Se sim, a aplicação é escalável, isso tem bastante relação com desempenho, normalmente algoritmos e aplicações eficientes são escaláveis, mas existem técnicas que podem aumentar a escalabilidade até de aplicações que podem ter desempenhos não tão bons, como cache e balanceamento de carga.
Elasticidade: Muitas vezes é necessário usar uma grande infraestrutura para garantir a escalabilidade de uma aplicação. Porém, se a carga da aplicação varia muito, manter toda essa infraestrutura ligada o tempo todo pode desperdiçar muitos recursos. Imagine uma aplicação de entrega de comida, ela tem picos muito bem definidos nos horários do almoço e jantar, nessa hora a infraestrutura tem que estar toda funcionando, mas durante a madrugada, é possível atender toda a demanda com muito menos recursos. Isso pode diminuir drasticamente o custo para a execução da sua aplicação.

Esses três requisitos são extremamente importantes para manter a satisfação dos usuários da aplicação, mas sem que os custos explodam. Por exemplo, pode ser fácil garantir desempenho e a escalabilidade de uma aplicação, basta executa-la em uma máquina com uma quantidade grade de recursos (memória, cpu, disco, rede, ...) ou em um cluster com uma grande quantidade de VMs.

Porém, o custo disso pode ser muito alto. Por isso é extremamente importante conhecer técnicas que podem aumentar a capacidade de uma aplicação antes de simplesmente aumentar a quantidade de recursos utilizados para executar a aplicação.

No próximo post vou falar mais sobre a terceira parte do livro que foca na confiabilidade das aplicações. Até lá!

Testing a Spring application with MongoDB aggregations

Eduardo Santana — Sun, 07 Jan 2024 20:20:47 +0000

Currently, I am working on an application that involves various MongoDB aggregations to calculate sums, averages, among many other things.

I am using MongoDB's standard classes to implement these aggregations, rather than Spring Data, mainly to leverage MongoDB Compass's functionality to generate aggregation code that can be directly executed within the tool. The figure below illustrates how this can be done:

The challenge now is how to test these aggregations. It would be possible to mock all the MongoDB classes and test the Java code. However, these tests may not be very useful since the complexity lies mainly in the aggregations, not in the code itself.

To address this, I remembered that some time ago, I used an embedded Postgres in a Spring application and decided to verify if it was possible to do the same with MongoDB. I found the de.flapdoodle.embed.mongo.spring30x library, which made this task possible. In this article, I will show a simple example of how to implement testing for a MongoDB aggregation using an embedded database instance.

The complete application code is available on GitHub:

GitHub Repository

I developed a very simple application that has three routes: one for creating users, another for listing users, and a third one that performs an aggregation on users, grouping them by city and calculating the average salary and age of the users.

The challenge is testing the method that performs the aggregation; it utilizes MongoDB access classes such as AggregateIterable and MongoDatabase. The code snippet below illustrates the implementation of this code:

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;

    private final MongoClient mongoClient;

    // other methods to save and list users

    public List<CityAggregationDTO> getAvg() {
        var database = mongoClient.getDatabase("test");
        var collection = database.getCollection("user");
        var result = collection.aggregate(Arrays.asList(new Document("$group",
                new Document("_id", "$city")
                        .append("avgAge",
                                new Document("$avg", "$age"))
                        .append("avgSalary",
                                new Document("$avg", "$salary")))));

        List<CityAggregationDTO> response = new ArrayList<>();
        for (Document doc : result) {
            var cityAggregationDTO = new CityAggregationDTO();
            cityAggregationDTO.setCity(doc.getString("_id"));
            cityAggregationDTO.setAvgSalary(doc.getDouble("avgSalary"));
            cityAggregationDTO.setAvgAge(doc.getDouble("avgAge"));
            response.add(cityAggregationDTO);
        }
        return response;
    }

}

The above code performs the aggregation by grouping users based on the city they live in and then calculating the average salary and age per city. This aggregation returns a list of results, with each object representing a different city.

Let's test this code now. To do that, the first step is to add the 'de.flapdoodle.embed.mongo.spring30x' library to the pom.xml file.

<dependency>
    <groupId>de.flapdoodle.embed</groupId>
    <artifactId>de.flapdoodle.embed.mongo.spring30x</artifactId>
    <version>4.6.1</version>
    <scope>test</scope>
</dependency>

We need to add an entry to the application.properties file for testing (remember to create this file in src/test/resources/application.properties). This property indicates which version of MongoDB will be used for testing. In this case, I am using version 6.0.1.

de.flapdoodle.mongodb.embedded.version=6.0.1

Now we can create our test. To do that, let's create the UserServiceTests class. The following code shows the declaration of this class:

@AutoConfigureDataMongo
@SpringBootTest
public class UserServiceTests {


    @Autowired
    private UserService userService;

    @Autowired
    private MongoClient mongoClient;

}

To run the tests, we need to add some data to the embedded database. We can use the @BeforeEach annotation with a method that will be executed before the tests. This method adds some users to MongoDB. Note that I am also clearing the user collection before inserting the data. This is optional and depends on what you want to achieve with your tests:

@BeforeEach
void setup() {
    MongoDatabase database = mongoClient.getDatabase("test");
    MongoCollection<Document> collection = database.getCollection("user");

    collection.deleteMany(new Document());

    List<Document> documents = new ArrayList<>();
    for (int i = 0; i < 5; i++) {

        Document document = new Document();
        document.put("name", "Eduardo");
        document.put("city", "SP");
        document.put("age", 20);
        document.put("salary", 1000 * (i + 1));

        documents.add(document);
    }

    collection.insertMany(documents);

}

Finally, we can create and run the tests. This part is straightforward since we are not mocking any classes, and the data has already been inserted into the database in the previous method. So, basically, we just need to call the method we want to test and then verify if the aggregation data came as expected:

@Test
void test_aggregateUsersSuccessfully() {
    List<CityAggregationDTO> page = userService
            .getAvg();

    Assertions.assertEquals("SP", page.get(0).getCity());
    Assertions.assertEquals(20, page.get(0).getAvgAge());
    Assertions.assertEquals(3000, page.get(0).getAvgSalary());
}