Forem: Rafael

Minha jornada de otimização de uma aplicação django

Rafael — Wed, 13 Mar 2024 20:19:00 +0000

Rinha de backend é um desafio de programação com o objetivo de gerar e compartilhar conhecimento. O texto descreve minha experiência ao participar do desafio mas acredito que é útil para todos que querem entender um pouco mais de django, gunicorn e gevent.

Para a rinha de backend segunda edição eu fiz uma submissão usando django com o objetivo de aprimorar meus conhecimentos em python e no framework. O desafio consiste em resolver o problema clássico de concorrência de transações bancárias ao mesmo tempo que deve suportar um teste de carga. O código resultante da minha submissão pode ser visto aqui.

Além do django, eu escolhi usar:

Django rest framework
Gunicorn como web server
PostrgreSQL como banco de dados

A minha primeira meta era conseguir executar os testes de carga na API sem restrições de recursos, podendo usar todos os recursos disponíveis do meu computador. Após isso, para poder submeter minha solução do desafio era necessário aplicar limites de CPU (1.5) e memória (550MB). Ou seja, a soma dos recursos do load balancer, banco de dados e duas instâncias da API devem estar dentro do limite especificado. E, se possível, manter os tempos de requisições baixos durante todo o teste.

Importante falar que a maioria das otimizações foram feitas especialmente para a rinha e não necessariamente sejam necessárias ou até mesmo recomendadas em aplicação reais. Mas ao mesmo tempo me sinto muito mais confortável em colocar aplicações django em produção com o conhecimento que adquiri durante essa jornada.

Gevent

Gevent é uma biblioteca de corotinas do python que facilita a execução de código bloqueante de maneira assíncrona. Um exemplo do impacto do uso gevent pode ser visto nesse artigo. Como tenho mais experiência com C# faço o paralelo com o async/await apesar de terem implementações distintas.

O gunicorn apresenta tipos distintos de workers e a documentação recomenda:

Some examples of behavior requiring asynchronous workers:
Applications making long blocking calls (Ie, external web services)

Como a API é basicamente IO bound foi escolhido o gevent como worker type.

Micro-otimizacoes

Uma vez que um dos objetivos era ter uma API otimizada busquei e encontrei os seguintes tópicos para melhorar a performance do meu código:

values(): retorna um Queryset que retorna um dicionário ao invés de uma instância do modelo
update_fields: argumento do método save que especifica qual campo deve ser atualizado simplificando o comando SQL gerado
Remoção dos middlewares desnecessários (para o desafio)

Eu não medi o impacto mas mantive as mudanças. Considerando as documentações e blogs é esperado algum ganho de performance.

Algumas coisas que tentei mas abandonei:

Pgbouncer - resolvia o problema do limite de conexões no postgres. Mas a API “saudável” manteve o número de conexões baixo o suficiente.
Pypy ao invés de cpython - os resultados não foram bons, aumentou o consumo de recursos entregando uma performance pior. No entanto, é importante dizer que não me aprofundei no assunto e não dediquei nenhum tempo para fazer qualquer tunning.
Usar diretamente o psycopg3 e o seu connection pool. Obtive ótimos resultados dessa maneira e serviu para mostrar que o setup django + gunicorn + gevent funciona bem e é capaz de processar as requisições com a limitação de recursos da rinha. Mas ainda queria ter uma submissão com o ORM.

Conexões persistentes (CONN_MAX_AGE)

Django não possui uma connection pool própria para conexão com banco de dados. Uma possibilidade é o uso da propriedade CONN_MAX_AGE que determina o tempo de vida que uma conexão pode ter. Quando 0 (valor padrão) cada conexão será finalizada no fim da execução da requisição. Valores maiores que 0 indicam o tempo que uma conexão pode existir até ser finalizada, permitindo que outras requisições reusem a conexão. Percebi na prática que usar qualquer valor diferente de 0 não funciona bem com o worker do tipo gevent do gunicorn. Como descrito aqui, as conexões não são reutilizadas nesse cenário.

Com CONN_MAX_AGE!=0 e worker_type=gevent não há reutilizações das conexões persistentes. O número de conexões total cresce mesmo com quase todas conexões ociosas. Na medida que se aumenta a quantidade de requisições por segundo o número de conexões também cresce

Usar esse valor com 0 mantém o número de sessões no postgres baixo, sem necessidade de se reutilizar as conexões para esse fim.

Com CONN_MAX_AGE=0 e worker_type=gevent o número de conexões se manteve estável. Cada requisição abre e fecha uma nova conexão com o banco

Worker connections

O valor padrão de worker connections é 1000 então começar os testes com o valor 50 e ir aumentando me pareceu razoável. No entanto, enquanto usava esse valor “alto”, durante o teste o número de sessões no postgres começava estável até chegar um momento de pico e a partir daí aplicação já não era capaz de responder as requisições do teste de carga.

Com um valor maior de GUNICORN_WORKER_CONNECTIONS e GUNICORN_WORKER_TYPE=gevent, em um determinado ponto da execução dos testes de carga o número de conexões com banco de dados explodia, causando erros na API

Acidentalmente fiz um teste sem gevent e para minha surpresa os testes foram concluídos sem erros. Lendo esse artigo entendi o motivo. O número alto de worker connections e gevent significa que mais greenlets (pseudo threads) eram agendados além da capacidade de processamento. Uma requisição era iniciada e, por conta de uma operação bloqueante como um query no banco, a execução era pausada e ia para fila de itens a serem processados. Como já existiam várias requisições na frente, essa greenlet sofria starvation e esse processo causa um pico de número de sessões abertas ao aplicar uma carga suficiente. Ajustando esse valor para um número menor (no meu caso 5) já é possível perceber que há uma melhora considerável nos resultados dos testes.

Com worker_connections=5 as conexões do banco se mativeram baixas durante todo o teste.

Parte do relatório de execução dos testes de carga do Gatling. O resultado apresenta boa performance mas ainda não foi aplicado os limites de recursos

Profiling

Apesar de muito contente com a execução da API ainda estava cético pois as métricas coletadas durante os testes mostravam que a API não iria se comportar bem com os limites impostos do desafio, principalmente para CPU.

Resultado do comando docker stats. Valores de CPU das APIs superam (e muito) os limites do desafio

Quando limitado, os resultado dos testes de carga apresentavam alta taxa de erro pois a API não processava as requisições em tempo hábil para responder a carga enviada. Para tentar entender o motivo usei uma ferramenta muito interessante para profiling que me ganhou pela facilidade de uso. Com um simples comando py-spy consegui gerar o flamegraph da minha API durante a carga e visualizar os métodos que mais consomem tempo de CPU.

py-spy record --gil --subprocesses -o profile.svg -- gunicorn -w 2 rinha.wsgi -b 0:9999

Flamegraph de um worker gerado pelo py-spy durante a execução dos testes de carga

Flamegraph com foco na abertura da transação com o banco de dados

O arquivo gerado é um SVG navegável e pode ser baixado aqui.

De volta com CONN_MAX_AGE

Já no último dia da rinha, a poucas horas do fim, enquanto observava o gráfico percebi que muito tempo de CPU era gasto na criação da conexão com o banco de dados. Assim eu especulei que se houvesse um pool de conexões ou, pelo menos evitar que elas fossem abertas a cada requisição, haveria redução do consumo de CPU. Isso trouxe a ideia de setar novamente um valor de CONN_MAX_AGE para manter as conexões abertas e que fossem reutilizadas. Mas para isso seria necessário alterar o worker type para sync. A expectativa é que o menor consumo de recursos possibilitaria a execução da API sob carga com as limitações impostas. E felizmente foi isso que aconteceu.

Parte do relatório de execução dos testes de carga do Gatling. O resultado apresenta boa performance mesmo com os limites de recursos aplicados

E isso é o fim da minha versão de django + orm para a rinha!

Conclusão

Então o gevent é ruim e é melhor usar sync mesmo? Não é bem assim. O que eu posso afirmar é que em um cenário de baixíssima latência, requisições externas rápidas, carga alta e recursos limitados é melhor abrir mão do “async” para ter a reutilização de conexões. O overhead de abrir uma conexão por requisição foi o fator determinante para a API não passar nos testes de carga do desafio. Acredito que usando alguma biblioteca que implemente um pool de conexões no django seria possível usar o gevent para esse caso.

Além disso, os maiores ensinamentos foram:

Conexões persistentes e gevent worker não funcionam juntos. É necessário escolher um ou outro;
Usando gunicorn, se for alterar o worker type de sync para gevent faça testes para escolher o valor de worker connections. Um valor muito acima do ideal prejudica bastante a performance;
Não dá para resolver o problema sem saber qual é o problema. Em outras palavras, use ferramentas para medir e permitir fazer uma análise efetiva. Eu não teria feito muito sem docker stats, pgadmin e py-spy. E se eu tivesse gasto mais tempo em instrumentação poderia ter ido mais longe e gasto menos tempo em tentativa e erro.

Referências

Understand Async Workers by Practice with Django, Gunicorn, and Gevent - https://www.willianantunes.com/blog/2023/07/understand-async-workers-by-practice-with-django-gunicorn-and-gevent/
Web API performance: profiling Django REST framework - https://medium.com/@yashnarsamiyev2/web-api-performance-profiling-django-rest-framework-72886c5cd614
What the heck is gevent? (Part 1 of 4) - https://eng.lyft.com/what-the-heck-is-gevent-4e87db98a8
Django ORM Under the Hood - Iterables - https://www.hacksoft.io/blog/django-orm-under-the-hood-iterables

Diagnósticos usando dotnet-monitor + prometheus + grafana

Rafael — Wed, 03 Jan 2024 21:30:00 +0000

No meu último post escrevi sobre o problema de Threadpool Starvation e o uso de dotnet-counters para obter as métricas de performance de uma aplicação dotnet. Neste artigo, será usado o dotnet-monitor como ferramenta para obter diversas informações de diagnóstico de aplicações dotnet. O foco será em métricas de performance da aplicação e para facilitar a visualização será utilizado o conjunto prometheus e grafana.

Para o artigo foi criado um laboratório usando docker compose e o código pode ser encontrado no github.

dotnet-monitor

dotnet-monitor é uma ferramenta de monitoramento em ambiente produtivo capaz de coletar artefatos como dumps, traces, logs e métricas. A ferramenta expõe uma API que disponibiliza extração de informações de diagnóstico sob demanda.

O runtime do dotnet expõe um endpoint de serviço para comunicação entre processos chamado de porta de diagnóstico. A tecnologia usada depende da plataforma. No Linux são utilizados sockets de domínio Unix como transporte. É dessa maneira que o dotnet-monitor se comunica com as aplicações dotnet. No laboratório, a aplicação e o monitor são executados em diferentes containers e dessa forma é preciso que o monitor compartilhe um volume com a aplicação.

# docker-compose.yml
  app:
    ...
    environment:
      DOTNET_DiagnosticPorts: /app/diag/dotnet-monitor.sock
    volumes:
      - "./:/app/"
  monitor:
    image: mcr.microsoft.com/dotnet/monitor:6
    environment:
      DOTNETMONITOR_Storage__DefaultSharedPath: /diag
      DOTNETMONITOR_DiagnosticPort__ConnectionMode: listen
      DOTNETMONITOR_DiagnosticPort__EndpointName: /diag/dotnet-monitor.sock
    volumes:
      - "./diag:/diag"
    ...

É possível executar a aplicação e o monitor com o comando:

docker compose up app

O endpoint de metrics exporta os valores no formato compatível do Prometheus e pode ser acessado no endereço http://localhost:52325/metrics.

Prometheus

Prometheus é uma ferramenta de monitoramento open source capaz de coletar e armazenar métricas como series de dados temporais.

Para o laboratório é usada a seguinte configuração:

# prometheus/prometheus.yml
scrape_configs:
  ...
  - job_name: "monitor"
    scrape_interval: 5s
    metrics_path: "/metrics"
    static_configs:
      - targets: ["monitor:52323"]

Dessa forma, ao inicializar o container usando o docker compose o prometheus irá se conectar ao dotnet-monitor para coleta das métricas.

É possível navegar e visualizar as métricas na interface do Prometheus mas vamos usá-lo como fonte de dados para uma outra ferramenta focada em visualização.

Grafana

Grafana é uma ferramenta open source de visualização e monitoramento que permite a criação de dashboards. É possível usar várias tecnologias como fonte de dados, incluindo Prometheus.

Outro ponto interessante do grafana é a disponibilização de inúmeros dashboards pela comunidade que podem ser usados como base para monitoramento de sistemas e aplicações. Para o laboratório vamos usar o dotnet-monitor dashboard.

A configuração do grafana para o laboratório poderia ser feita manualmente via GUI mas para facilitar a reprodução usaremos arquivos de provisionamento para automatizar o setup.

A configuração do Prometheus como fonte de dados é feita pelo arquivo:

# grafana/provisioning/datasources/default.yaml
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    # Access mode - proxy (server in the UI) or direct (browser in the UI).
    url: http://prometheus:9090
    jsonData:
      httpMethod: POST
      manageAlerts: true
      prometheusType: Prometheus
      prometheusVersion: 2.44.0
      cacheLevel: "High"
      disableRecordingRules: false
      incrementalQueryOverlapWindow: 10m

E a configuração para permitir o provisionamento de dashboards é feita no arquivo:

# grafana/provisioning/dashboards/default.yaml
providers:
  - name: "default"
    folder: ""
    type: file
    options:
      path: /var/lib/grafana/dashboards

Cada dashboard deve ter sua definição em JSON disponibilizado no caminho definido no arquivo anterior.

O arquivo docker-compose mapeia os volumes para os diretórios padrão de configurações esperada pelo grafana.

# docker-compose.yml
  grafana:
    image: grafana/grafana-oss
    ports:
      - "3000:3000"
    volumes:
      # https://grafana.com/docs/grafana/latest/administration/provisioning/
      - "./grafana/provisioning/:/etc/grafana/provisioning/"
      - "./grafana/dashboards/:/var/lib/grafana/dashboards/"

O próximo comando executa o grafana e o prometheus:

docker compose up grafana

O grafana pode ser acessado no endereço http://localhost:3000 (use admin/admin para login).

Testes de carga

Por último, podemos executar os testes de carga usando hey.

O comando docker compose up send-load-async dispara uma série de requisições em um endpoint que utiliza o async/await do dotnet para reaproveitamento das threads e otimização de aplicações IO bound. Os gráficos abaixo mostram a quantidade se requisições processadas durante a execução do teste bem como as métricas relacionadas ao uso de threads pela aplicação.

Por sua vez, o comando docker compose up send-load-sync realiza requisições em um endpoint que utiliza não utiliza o async/await e portanto realiza o bloqueio de threads em operações de IO. Os gráficos abaixo mostram o resultado do teste.

Conclusão

Os testes realizados mostram o potencial do dotnet-monitor para monitoramento de aplicações em ambientes produtivos. Os testes foram feitos usando o docker compose e a configuração para execução em kubernetes é similar, sendo que o monitor seria publicado como um sidecar da aplicação.

Tão importante quanto a extração das métricas é a possibilidade de visualizar e correlacionar esses dados para permitir o diagnóstico de problemas de performance. O par prometheus e grafana foram usados para esse meio por serem ferramentas conhecidas do mercado e facilitarem a reprodução em ambiente local para um laboratório.

Threadpool no aspnet e problemas de performance

Rafael — Mon, 04 Sep 2023 09:22:38 +0000

Quando uma requisição passa maior parte do seu tempo aguardando o resultado de operações de entrada e saída, como banco de dados ou requisições para outras APIs, ela é considerada I/O bound.

Considere o seguinte trecho de código C#, que executa uma consulta ao banco de dados.

_context.Customers.FirstOrDefault(x => x.Id = id)

O que acontece nesse cenário é que a thread sendo executada é bloqueada ao executar a chamada remota e só será desbloqueada quando o resultado da requisição estiver disponível. Logo, outras requisições dessa API precisam ser executadas em outras threads. Se não houverem threads disponíveis no momento as outras requisições devem esperar.

Para melhorar a performance de aplicações desse tipo o dotnet disponibiliza o tipo Task que representa uma operação normalmente executada de forma assíncrona.

O cenário anterior foi modificado para usar programação assíncrona.

await _context.Customers.FirstOrDefaultAsync(x => x.Id = id)

Quando usamos o async/await a thread corrente não é bloqueada como no cenário anterior. As threads são reaproveitadas ao invés de bloqueadas, o que permite que mais requisições possam ser processadas de forma concorrente. Quando usamos Task e o async/await por baixo dos panos uma callback é registrada e executada quando o resultado da operação de IO é retornada.

Threadpool starvation

A criação e destruição de threads é um processo caro ao sistema operacional. Por esse motivo o dotnet disponibiliza o threadpool, que é um conjunto de threads que foram criadas e são disponibilizadas para uso. Quando necessário novas threads podem ser criadas pelo threadpool do dotnet mas numa taxa limitada (um ou duas por segundo).

O cenário em que a quantidade de tarefas aguardando a liberação de threads aumenta em uma taxa maior que a de criação de novas threads é chamado de threadpool starvation. As requisições são enfileiradas aguardando a sua vez para serem processadas impactando a performance da aplicação.

Os sintomas de aplicação nesse estado é o aumento do número de threads enquanto ainda há capacidade de CPU disponível.
Uma maneira para diagnosticar APIs no estado de threadpool starvation é observar as seguintes métricas:

threadpool-queue-length: O número de itens de trabalho que estão enfileirados, no momento, para serem processados no ThreadPool
threadpool-thread-count: O número de threads do pool de threads que existem no momento no ThreadPool, com base em ThreadPool.ThreadCount
threadpool-completed-items-count: O número de itens de trabalho processados no ThreadPool

O saudável seria o número de threads constante, a fila se mantendo zerada e o número de itens processados alto.

Exemplo

Como laboratório para analisar as métricas de performance em um cenário saudável e em threadpool starvation serão usadas duas ferramentas:

dotnet-counters: uma ferramenta para análise de performance e saúde de aplicações dotnet. Permite observar valores de contadores de performance.
hey: gerador de carga para aplicações web.

O código da aplicação de teste e todo o setup das ferramentas usando docker está disponível no github. A aplicação possui dois endpoints que executam chamadas no banco de dados em uma operação de duração de 500 milissegundos, para simular um cenário com maior latência. O endpoint sync utiliza a API síncrona e o async a API assíncrona:

[HttpGet("sync")]
public IActionResult GetSync()
{
    _context.Database.ExecuteSqlRaw("WAITFOR DELAY '00:00:00.500'");
    return Ok();
}

[HttpGet("async")]
public async Task<IActionResult> GetAsync()
{
    await _context.Database.ExecuteSqlRawAsync("WAITFOR DELAY '00:00:00.500'");
    return Ok();
}

Para iniciar aplicação e o monitoramento com o dotnet-counters devem ser executados os seguintes comandos:

docker compose up app
docker exec -it thread-pool-test-app dotnet-counters monitor -n dotnet

O teste de carga usando o endpoint sync:

docker compose up send-load-sync

O resultado simplificado do teste carga e um snapshot do dotnet-counters é aprensentado abaixo.

 Summary:
   Total:    27.2940 secs
   Slowest:  5.1772 secs
   Fastest:  0.5020 secs
   Average:  2.6085 secs
   Requests/sec:     36.6380

[System.Runtime]
    % Time in GC since last GC (%)                              0
    Allocation Rate (B / 1 sec)                         2,987,784
    CPU Usage (%)                                               0
    Exception Count (Count / 1 sec)                             0
    GC Committed Bytes (MB)                                     0
    GC Fragmentation (%)                                        0
    GC Heap Size (MB)                                         109
    Gen 0 GC Count (Count / 1 sec)                              0
    Gen 0 Size (B)                                              0
    Gen 1 GC Count (Count / 1 sec)                              0
    Gen 1 Size (B)                                              0
    Gen 2 GC Count (Count / 1 sec)                              0
    Gen 2 Size (B)                                              0
    IL Bytes Jitted (B)                                   797,595
    LOH Size (B)                                                0
    Monitor Lock Contention Count (Count / 1 sec)              11
    Number of Active Timers                                     3
    Number of Assemblies Loaded                               152
    Number of Methods Jitted                               10,503
    POH (Pinned Object Heap) Size (B)                           0
    ThreadPool Completed Work Item Count (Count / 1 sec)       55
    ThreadPool Queue Length                                    74
    ThreadPool Thread Count                                    36
    Time spent in JIT (ms / 1 sec)                              0.656
    Working Set (MB)                                          232

O teste de carga usando o endpoint async:

docker compose up send-load-async

Os resultados:

 Summary:
   Total:   5.5532 secs
   Slowest: 1.0283 secs
   Fastest: 0.5011 secs
   Average: 0.5272 secs
   Requests/sec:    180.0777

[System.Runtime]
    % Time in GC since last GC (%)                              0
    Allocation Rate (B / 1 sec)                         4,458,328
    CPU Usage (%)                                               0
    Exception Count (Count / 1 sec)                             0
    GC Committed Bytes (MB)                                     0
    GC Fragmentation (%)                                        0
    GC Heap Size (MB)                                         114
    Gen 0 GC Count (Count / 1 sec)                              0
    Gen 0 Size (B)                                              0
    Gen 1 GC Count (Count / 1 sec)                              0
    Gen 1 Size (B)                                              0
    Gen 2 GC Count (Count / 1 sec)                              0
    Gen 2 Size (B)                                              0
    IL Bytes Jitted (B)                                   825,928
    LOH Size (B)                                                0
    Monitor Lock Contention Count (Count / 1 sec)              10
    Number of Active Timers                                     3
    Number of Assemblies Loaded                               152
    Number of Methods Jitted                               10,947
    POH (Pinned Object Heap) Size (B)                           0
    ThreadPool Completed Work Item Count (Count / 1 sec)    1,384
    ThreadPool Queue Length                                     0
    ThreadPool Thread Count                                    30
    Time spent in JIT (ms / 1 sec)                              3.467
    Working Set (MB)                                          236

Comparando as duas versões é possível ver que a versão sync tem chamadas lentas causadas pelo tempo de espera da requisição para ser processada. Durante todo o teste o ThreadPool Queue Length se manteve alto.

A versão async tem uma média de chamadas próximo ao tempo de 500 milissegundos que é o esperado para cada requisição e o ThreadPool Queue Length se mantem próximo a 0 durante o teste. O ThreadPool Completed Work Item Counté bem maior comparado ao cenário sync.

Conclusão

A programação assíncrona, ao reutilizar threads ao invés de bloqueá-las, permite aumentar a quantidade de requisições capaz de serem processadas em aplicações com características IO bound. No dotnet isso é feito usando o async/await.

Em uma aplicação real pode não ser simples identificar operações blocantes que podem levar a problemas de performance em um cenário de grande quantidade de requisições. Para isso, pode ser usada a ferramenta dotnet-counters somado à um teste de carga para diagnosticar possíveis cenários de thread starvation.

Consistência de dados e padrão Outbox

Rafael — Sat, 13 May 2023 12:15:00 +0000

Um dos pontos mais importantes em todas aplicações que trabalha com escrita de dados é garantir a consistência dos dados.

Um exemplo básico é a criação de um pedido que possui itens. Considerando um banco relacional, os dados são armazenados em duas tabelas Orders e OrderItems. Imagine que a aplicação realize um INSERT no banco na tabela Orders e recebe um erro na tentativa de fazer o INSERT na tabela OrderItems. Dessa forma o sistema ficou inconsistente, o usuário tem um pedido sem itens e isso pode, inclusive, impedir que ele consiga repetir o pedido.

O desejado é que o pedido seja salvo completamente ou que seja nada salvo. Nos bancos relacionais a solução é o uso de transações.

BEGIN TRANSACTION
  INSERT INTO TABLE Orders...
  INSERT INTO TABLE OrderItems...
COMMIT

Caso o segundo INSERT não seja concluído deve ser realizado o rollback da transação mantendo o comportamento de "tudo ou nada".

O problema de escrita dupla (dual write)

Agora vamos ampliar nosso cenário, um microsserviço de Pedidos é responsável por manter os dados de pedidos e notificar os outros sistemas sobre pedidos feitos. Para se comunicar com os outros serviços será utilizado uma solução de mensageria.

Dessa forma, ao receber um novo pedido deve ser feita uma escrita na tabela Orders no banco de dados e enviar uma mensagem order.created para uma fila. Como manter a consistência entre o banco de dados e o sistema de mensageria? Se, após inserir um registro no banco de dados, o envio da mensagem para a fila não tiver sucesso as aplicações que esperam a mensagem ficam inconsistentes. Invertendo a lógica e enviando a mensagem antes de salvar no banco de dados produz um problema maior pois as aplicações seguintes podem receber mensagens de operações que nunca foram registradas na aplicação que é dona desse dado.

Manter a consistência dos dados em sistemas distribuídos é um grande desafio e diversas abordagens tem diferentes trade-offs. Comumente, é aceitável garantir que o sistema esteja consistente em algum ponto no futuro. Essa abordagem é chamada de Consistência Posterior (eventual consistency).

Outbox Pattern

A ideia do outbox pattern é usar o banco de dados para garantir que a mensagem será enviada. As mensagens que serão enviadas para o sistema de mensageria devem ser armazenadas em uma tabela junto do status de envio. Ao inserir um registro da tabela Orders também deve-se inserir a mensagem, tudo dentro de uma transação.

BEGIN TRANSACTION
  INSERT INTO Orders...
  INSERT INTO OutboxMessages(message, status)...
COMMIT

Essa tabela OutboxMessages deve ser verificada periodicamente em busca de mensagens com o status pendente para que sejam enviadas para a fila. Dessa forma tem-se a garantia que a mensagem será enviada ao menos uma vez. Por que ao menos uma vez? Porque o processo de envio da mensagem e a atualização do status de envio do registro do banco é uma escrita dupla e está sujeita a falhas. A operação de atualização do status como enviado pode falhar e portanto durante a próxima busca de mensagens pendentes essa mensagem seria enviada novamente.

Idempotência

Considerando o problema anterior é possível que uma mesma mensagem seja enviada repetidamente para a fila. Assim, é necessário que os sistemas que processam essas mensagens sejam idempotentes, ou seja, a execução de operações repetidas não podem afetar o resultado da primeira operação. Algumas operações são idempotentes por natureza, como atribuir um determinado valor para um campo de um registro de uma tabela. Se executada múltiplas vezes o resultado final é o mesmo de se executar apenas uma vez. Em outras situações não garantir a idempotência pode ser catastrófico. Expandindo nosso exemplo, considere uma aplicação que recebe mensagens de pedidos realizados e decrementa o estoque dos produtos vendidos. Se a mensagem do pedido for duplicada, o pedido abateria do estoque o dobro de produtos comprados.

Uma maneira de implementar idempotência para esses casos é utilizar novamente o banco de dados. A aplicação que consome as mensagens deve possuir uma tabela para armazenar o id das mensagens processadas. Ao executar a operação no banco de dados, no nosso exemplo um UPDATE na tabela Products, deve-se inserir o id da mensagem na tabela de mensagens processadas. As duas operações devem ser realizadas dentro de uma transação pois se a restrição de chave primária da tabela ProccessedMessages retornar erro (ou seja, a mensagem já foi processada) a atualização do produto deve ser desfeita.

BEGIN TRANSACTION
  UPDATE Produtcs...
  INSERT INTO ProccessedMessages(Id) ...
COMMIT

Implementação

Usando C# existem algumas opções de bibliotecas que implementam o padrão Outbox como CAP e Mass Transit. Para idempotência eu criei o Ziggurat que implementa a solução descrita nesse texto. É possível ver um exemplo de implementação de CAP com Ziggurat aqui.

No python existe a biblioteca django-outbox-pattern que implementa o padrão outbox e também garante idempotência nos consumidores.

Validação de entrada de dados e respostas de erro no ASP.NET

Rafael — Wed, 18 Aug 2021 20:51:12 +0000

Validação dos dados de entrada é parte essencial no desenvolvimento de software. O framework ASP.NET provê um conjunto de funcionalidades que auxiliam os desenvedores garantir que as APIs só processem dados que possuem valores que atendam as regras da aplicação. Nesse texto serão discutidas as formas de validação do ASP.NET e o formato das mensagens de erro retornadas. Serão tratados erros de tipos inválidos e a validação dos modelos usando a funcionalidade de DataAnnotations do ASP.NET. Além disso, será mostrado como customizar o formato de resposta. Os exemplos de código foram desenvolvidos usando a versão 5 do ASP.NET e estão disponíveis no github.

Erros de Model Binding

Model binding é a funcionalidade do ASP.NET que atua nas requisições HTTP convertendo os dados de entrada nas rotas em tipos .NET.

A etapa de Model Binding é executada durante o pipelines de filtros. Mais especificamente, essa etapa é executada antes dos filtros de ação que por sua vez são executados antes e depois da execução dos métodos dos controllers.

Considere o Controller de exemplo:



[Route("[controller]")]
public class ExampleController : ControllerBase
{
    [HttpGet]
    public ActionResult Get(int id)
    {
        if (id == 1)
            return Ok(new ExampleRequest{Name = "Example1"});

        return NotFound();
    }
}

Ao fazer uma requisição para essa rota o ASP.NET vai examinar a requisição para encontrar o campo id, que nesse caso é enviada como parâmetro. Em seguida, o valor encontrado será convertido para inteiro e o método Get será executado. Mas o que acontece se o valor passado for um texto? O dado não é convertido e é preenchido com o valor padrão, que para inteiro é 0. Caso fosse um objeto, o valor padrão seria null o que poderia causar um NullReferenceException se não fosse feita nenhuma verificação.

ModelState

A propriedade ModelState da classe ControllerBase contém o estado do modelo e a validação de associação de modelo. Quando não é possível a conversão da entrada de dados o ModelState é inválido. Logo, é possível verificar se os dados de entrada estão corretos em relação aos tipos esperados.



[Route("[controller]")]
public class ExampleController : ControllerBase
{
    [HttpGet]
    public ActionResult Get(int id)
    {
        if (!ModelState.IsValid)
            return BadRequest(ModelState);

        if (id == 1)
            return Ok(new ExampleRequest{Name = "Example1"});

        return NotFound();
    }
}

Dessa forma, se essa rota for chamada enviando o valor "texto" no campo id recebemos o seguinte erro:



{
    "id": [
        "The value 'texto' is not valid."
    ]
}

Isso previne que a aplicação processe requisições com dados inválidos. Mas se minha aplicação possui vários controllers eu preciso repetir essa verificação em todos?

[ApiController]

O atributo do ASP.NET ApiControllerAttribute pode ser aplicado à Controllers e traz algumas funcionalidades. Entre elas, ele faz a validação automática dos dados de entrada e retorna um erro 400 de maneira similar à verificação do ModelState. Alterando o Controller de exemplo:



[ApiController]
[Route("[controller]")]
public class ExampleController : ControllerBase
{
    [HttpGet]
    public ActionResult Get(int id)
    {
        if (id == 1)
            return Ok(new ExampleRequest{Name = "Example1"});

        return NotFound();
    }
}

E ao fazer a requisição com o valor inválido obtemos o mesmo erro quando usamos a verificação do ModelState. Isso ocorre porque o filtro ModelStateInvalidFilter é adicionado a todos os Controllers que são anotados com o ApiControllerAttribute.

Além da validação do ModelState, o ApiControllerAttribute traz outras informações de erro no seu resultado:



{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "traceId": "00-a89db4d9a02dfc479c4d50b401f60fb5-28ba31ad1392154c-00",
    "errors": {
        "id": [
            "The value 'texto' is not valid."
        ]
    }
}

Por padrão o atributo tem como resposta o formato acima contendo:

type: o link da RFC em que determina os tipos de resposta HTTP, especificamente para a sessão do erro 400;
status: o código do status de erro;
traceId: o traceId da requisição. Por padrão, o ASP.NET 5 utiliza o formato definido pela recomendação da W3C. Você pode encontrar mais informações sobre o traceId e o trace context aqui;
errors: uma lista de erros contendo o erro de validação do modelo.

É possível também decorar o assembly com o ApiControllerAttribute. Isso pode ser feito decorando a declaração do namespace que contém a classe Startup. Dessa forma, o comportamento do ApiControllerAttribute será aplicado a todos os controllers do assembly



[assembly: ApiController]
namespace WebApiSample
{
    public class Startup
    {
        ...
    }
}

Validação do modelo

A validação dos tipos de dados é importante mas normalmente queremos aplicar outras validações ao nossos dados de entrada. Por exemplo, podemos marcar campos como obrigatórios, tamanho mínimo ou máximo e regras mais complexas. É importante garantir que a nossa aplicação só vai processar dados válidos. Isso também evita que o código da aplicação tenha uma quantidade de ifs e elses que acabam poluindo o código. Vejam o exemplo abaixo:



[HttpPost]
public ActionResult Add(ExampleRequest example)
{
    return Ok();
}
...
public class ExampleRequest
{
    [Required]
    public string Name { get; set; }
}

O exemplo utiliza o atributo Required pressente no namespace System.ComponentModel.DataAnnotations.

Realizando uma requisição para a nova rota de POST com o body vazio obtemos o erro:



{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "One or more validation errors occurred.",
    "status": 400,
    "traceId": "00-421e7740cdb1394aba958b549d319bc2-ffc80b3fe2883349-00",
    "errors": {
        "Name": [
            "The Name field is required."
        ]
    }
}

Existem vários outros atributos (a lista completa pode ser vista aqui) e também é possível estender essa funcionalidade criando atributos customizados herdando a classe ValidationAttribute como apresentado no exemplo:



public class ExampleRequest
{
    [Required]
    public string Name { get; set; }
    [StringLength(1000)]
    public string Description { get; set; }
    [Range(1, 100)]
    public int SomeValue { get; set; }
    [EmailAddress]
    public string Email { get; set; }
    [IsEven]
    public int EvenNumber { get; set; }
}

public class IsEvenAttribute : ValidationAttribute
{
    public IsEvenAttribute() : base ("Value is not an even number")
    {
    }

    public override bool IsValid(object value)
    {
        var intValue = Convert.ToInt32(value);
        return intValue % 2 == 0;
    }
}

O mesmo efeito pode ser obtido utilizando o FluentValidation configurando a sua integração com o ASP.NET.

Customização da resposta de erro

Para alguns casos a resposta de erro padrão que o ApiControllerAttribute envia pode ser indequada para a aplicação. Por exemplo, os campos status e type são redundantes considerando que o código da resposta HTTP já é retornado na requisição. Além disso, caso a aplicação retorne outros tipos de erros 400 pode ser necessário incluir novos campos na resposta.

Para isso o ASP.NET possui uma funcionalidade que permite alterar o formato da resposta. Deve-se utilizar a classe ApiBehaviorOptions para alterar o comportamento de todos os Controllers anotados com o ApiControllerAttribute. Essa configuração deve ser feita no método ConfigureServices da classe Startup da aplicação. Deve ser chamado o método ConfigureApiBehaviorOptions preenchendo a propriedade InvalidModelStateResponseFactory com a customização da resposta.

Segue o exemplo abaixo:



services.AddControllers()
    .ConfigureApiBehaviorOptions(options =>
    {
        options.InvalidModelStateResponseFactory = context =>
        {
            var response = new
            {
                Error = new Dictionary<string, string[]>(),
                Type = "VALIDATION_ERRORS"
            };
            foreach (var (key, value) in context.ModelState)
                response.Error.Add(key, value.Errors.Select(e => e.ErrorMessage).ToArray());

            return new BadRequestObjectResult(response);
        };
    });

O código acima simplifica o retorno da API, trazendo apenas a lista de erros e um novo campo para indicar que o motivo do erro é de validação dos dados. Fazendo novamente a requisição problemática recebemos o erro:



{
    "error": {
        "Name": [
            "The Name field is required."
        ]
    },
    "type": "VALIDATION_ERRORS"
}

É importante notar que apenas erros de validação, ou seja, que o ModelState é ínválido, são afetados por essa customização.

Conclusão

O ASP.NET possui funcionalidades para ajudar os desenvolvedores criarem APIs mais robustas aplicando validação de dados de entrada. Além disso, existem ótimas bibliotecas como o Fluent Validation que permite mais liberdade para criação de validadores de modelos mais inteligentes. O uso do atributo ApiController do ASP.NET incrementa as APIs adicionando funcionalidades como a resposta 400 automática para erros de validação padrão. No entanto, se desejado, é possível customizar o resultado de forma simples usando o InvalidModelStateResponseFactory.

Obrigado por ter chegado até aqui e espero que tenha gostado. Dúvidas, sugestões ou encontrou algum erro? Por favor, deixe seu comentário.

Referências

SaveChanges e controle transacional no EF Core

Rafael — Mon, 01 Mar 2021 23:29:02 +0000

O método SaveChanges é responsável por salvar todas as alterações no banco de dados quando se está trabalhando com o Entity Framework Core. Ao executar esse método, por padrão, estamos executando as operações dentro de uma transação. A documentação diz:

Por padrão, se o provedor de banco de dados oferecer suporte a transações, todas as alterações em uma única chamada para SaveChanges serão aplicadas em uma transação. Se qualquer uma das alterações falhar, a transação é revertida e nenhuma das alterações será aplicada ao banco de dados.

Será tratado aqui o funcionamento do método SaveChanges analisando os logs do EF Core e as consultas geradas. O foco da análise será o controle da transação. A versão da biblioteca nos testes é a 5 e o banco de dados utilizado na análise é o SQL Server da Microsoft. Os resultados encontrados podem ser diferentes em outras versões e/ou utilizando outro bancos de dados. O código criado para os testes pode ser visto aqui.

Configurando o `DbContext`

O contexto do banco de dados deve ser configurado para obter as informações necessárias para o entendimento do EF Core.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(
            "Data Source=localhost,1433;Initial Catalog=Timesheet;User Id=sa;Password=Password1")
        .LogTo(message => Debug.WriteLine(message));
}

O método LogTo, usado na configuração, é a nova maneira de acessar os logs do EF Core. A funcionalidade Simple Logging foi apresentada na versão 5 do ORM e permite direcionar as entradas de log para o tipo de saída desejada. No exemplo, os dados são direcionados para janela de Debug do Visual Studio usando o método Debug.Writeline. Nas versões antigas é possível se obter os logs usando o método UseLoggerFactory.

Adicionando dados com o `SaveChanges`

Para verificar o funcionamento do SaveChanges foi escrito um teste simples adicionando dois objetos no banco de dados. No banco serão armazenadas duas linhas, uma em cada tabela.

var employee = new Employee
{
    Name = "John Doe",
    Entries = new List<TimeEntry>
    {
        new TimeEntry
        {
            Start = TimeSpan.FromHours(8),
            End = TimeSpan.FromHours(12)
        }
    }
};
context.Add(employee);

context.SaveChanges();

É possível ver no log gerado que os primeiros passos do EF Core na execução do método SaveChanges é a verificação das mudanças das entidades do contexto. Logo em seguida, a conexão com o banco é aberta.

dbug: CoreEventId.SaveChangesStarting[10004] (Microsoft.EntityFrameworkCore.Update) 
      SaveChanges starting for 'TestContext'.
dbug: CoreEventId.DetectChangesStarting[10800] (Microsoft.EntityFrameworkCore.ChangeTracking) 
      DetectChanges starting for 'TestContext'.
dbug: CoreEventId.DetectChangesCompleted[10801] (Microsoft.EntityFrameworkCore.ChangeTracking) 
      DetectChanges completed for 'TestContext'.
dbug: RelationalEventId.ConnectionOpening[20000] (Microsoft.EntityFrameworkCore.Database.Connection) 
      Opening connection to database 'Timesheet' on server 'localhost,1433'.
dbug: RelationalEventId.ConnectionOpened[20001] (Microsoft.EntityFrameworkCore.Database.Connection) 
      Opened connection to database 'Timesheet' on server 'localhost,1433'.

As entradas de log seguintes são relacionadas à transação. No primeiro momento, a transação é iniciada com o nível de isolamento não especificado. A próxima mensagem mostra que a transação foi inicializada com o nível ReadCommitted, que é o padrão do SQL Server.

dbug: RelationalEventId.TransactionStarting[20209] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Beginning transaction with isolation level 'Unspecified'.
dbug: RelationalEventId.TransactionStarted[20200] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Began transaction with isolation level 'ReadCommitted'.

Em seguida são executados dois comandos INSERT, um para cada entidade. Como o Id das entidades são gerados pelo banco de dados, pode-se ver que, para cada INSERT, também foi realizado um SELECT para que o EF Core obtenha o Id da entidade inserida. Alguns logs de criação dos comandos e detecção de alterações de chave estrangeira foram omitidos.

dbug: RelationalEventId.CommandExecuting[20100] (Microsoft.EntityFrameworkCore.Database.Command) 
      Executing DbCommand [Parameters=[@p0='John Doe' (Size = 4000)], CommandType='Text', CommandTimeout='30']
      SET NOCOUNT ON;
      INSERT INTO [Employees] ([Name])
      VALUES (@p0);
      SELECT [Id]
      FROM [Employees]
      WHERE @@ROWCOUNT = 1 AND [Id] = scope_identity();

dbug: RelationalEventId.CommandExecuting[20100] (Microsoft.EntityFrameworkCore.Database.Command) 
      Executing DbCommand [Parameters=[@p1='3' (Nullable = true), @p2='12:00:00', @p3='08:00:00'], CommandType='Text', CommandTimeout='30']
      SET NOCOUNT ON;
      INSERT INTO [TimeEntries] ([EmployeeId], [End], [Start])
      VALUES (@p1, @p2, @p3);
      SELECT [Id]
      FROM [TimeEntries]
      WHERE @@ROWCOUNT = 1 AND [Id] = scope_identity();

Por último, é feito o commit da transação.

dbug: RelationalEventId.TransactionCommitting[20210] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Committing transaction.
dbug: RelationalEventId.TransactionCommitted[20202] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Committed transaction.

Controlando a transação

Para a maioria dos casos, o uso do SaveChanges é o suficiente para garantir a consistência dos dados. Porém, quando necessário, é possível controlar as transações manualmente.

O segundo teste utiliza o mesmo exemplo do primeiro. Dessa vez o método SaveChanges está sendo executado dentro de uma transação iniciada com método BeginTransaction.

var employee = new Employee
{
      Name = "John Doe",
      Entries = new List<TimeEntry>
      {
            new TimeEntry
            {
                  Start = TimeSpan.FromHours(8),
                  End = TimeSpan.FromHours(12)
            }
      }
};
context.Add(employee);

using var transaction = context.Database.BeginTransaction();

context.SaveChanges();

transaction.Commit();

As primeiras entradas do log são de abertura da transação. Como o primeiro teste, a transação é iniciada com o nível de isolamento não especificado e criada com o nível ReadCommited.

dbug: RelationalEventId.TransactionStarting[20209] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Beginning transaction with isolation level 'Unspecified'.
dbug: RelationalEventId.TransactionStarted[20200] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Began transaction with isolation level 'ReadCommitted'.

Ao executar o método SaveChanges, o EF Core cria um savepoint da transação ao invés de abrir uma transação aninhada. Os logs de detecção de alterações nas entidades foram omitidos.

dbug: CoreEventId.SaveChangesStarting[10004] (Microsoft.EntityFrameworkCore.Update) 
      SaveChanges starting for 'TestContext'.

dbug: RelationalEventId.CreatingTransactionSavepoint[20212] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Creating transaction savepoint.
dbug: RelationalEventId.CreatedTransactionSavepoint[20213] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Created transaction savepoint.

Em seguida se realiza a execução dos comandos da mesma forma do primero teste.

dbug: RelationalEventId.CommandExecuting[20100] (Microsoft.EntityFrameworkCore.Database.Command) 
      Executing DbCommand [Parameters=[@p0='John Doe' (Size = 4000)], CommandType='Text', CommandTimeout='30']
      SET NOCOUNT ON;
      INSERT INTO [Employees] ([Name])
      VALUES (@p0);
      SELECT [Id]
      FROM [Employees]
      WHERE @@ROWCOUNT = 1 AND [Id] = scope_identity();

dbug: RelationalEventId.CommandExecuting[20100] (Microsoft.EntityFrameworkCore.Database.Command) 
      Executing DbCommand [Parameters=[@p1='5' (Nullable = true), @p2='12:00:00', @p3='08:00:00'], CommandType='Text', CommandTimeout='30']
      SET NOCOUNT ON;
      INSERT INTO [TimeEntries] ([EmployeeId], [End], [Start])
      VALUES (@p1, @p2, @p3);
      SELECT [Id]
      FROM [TimeEntries]
      WHERE @@ROWCOUNT = 1 AND [Id] = scope_identity();

Por fim, ao executar o método transaction.Commit(), as alterações são confirmadas.

dbug: RelationalEventId.TransactionCommitting[20210] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Committing transaction.
dbug: RelationalEventId.TransactionCommitted[20202] (Microsoft.EntityFrameworkCore.Database.Transaction) 
      Committed transaction.

Diferença entre transações aninhadas e savepoints no SQL Server

No SQL Server, o uso de transações aninhadas tem um comportamento que pode confundir os desenvolvedores. O ROLLBACK reverte todas as transações abertas da sessão. Não importa se existam transações aninhadas, o ROLLBACK vai desfazer todas as operações realizadas desde o primeiro BEGIN TRANSACTION.

Já o SAVE TRANSACTION coloca uma tag no ponto desejado da transação de forma a ser possível executar o ROLLBACK e reverter as mudanças até esse ponto. É possível criar vários savepoints em uma mesma transação. É importante lembrar que o SAVE TRANSACTION não abre uma nova transação.

Savepoints no EF Core

O EF Core também permite a criação manual de savepoints usando o método CreateSavepoint.

using var transaction = context.Database.BeginTransaction();

context.Add(new Employee { Name = "John Doe" });
context.SaveChanges();

transaction.CreateSavepoint("A");

context.Add(new Employee { Name = "Jane Doe" });
context.SaveChanges();

transaction.Commit();

Versões anteriores

A funcionalidade de savepoints foi incluída no EF Core 5. Nas versões 3.1 e 2.1 o EF Core, além de não permitir a criação de savepoints de forma manual, também não executa um SAVE TRANSACTION durante a execução do método SaveChanges. Ou seja, caso já exista uma transação aberta, como no segundo teste, o SaveChanges apenas executa os comandos de alteração da base de dados.

Conclusão

O método SaveChanges facilita a vida do desenvolvedor ao executar os comandos de alteração no banco de dados dentro de uma transação. Para os outros casos, em que se faz a abertura de uma transação manualmente, o SaveChanges apenas cria um savepoint dentro da transação.

Referências

Simple Logging - https://docs.microsoft.com/pt-br/ef/core/logging-events-diagnostics/simple-logging
Usando transações - https://docs.microsoft.com/pt-br/ef/core/saving/transactions
Guia de Controle de Versão de Linha e Bloqueio de Transações - https://docs.microsoft.com/pt-br/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver15
Nesting transactions and SAVE TRANSACTION command - https://dba-presents.com/index.php/databases/sql-server/43-nesting-transactions-and-save-transaction-command
SAVE TRANSACTION - https://docs.microsoft.com/pt-br/sql/t-sql/language-elements/save-transaction-transact-sql?view=sql-server-ver15
https://github.com/dotnet/efcore/blob/release/5.0/src/EFCore.Relational/Update/Internal/BatchExecutor.cs#L89
https://github.com/dotnet/efcore/blob/release/2.1/src/EFCore.Relational/Update/Internal/BatchExecutor.cs#L70

Forem: Rafael

Minha jornada de otimização de uma aplicação django

Gevent

Micro-otimizacoes

Conexões persistentes (CONN_MAX_AGE)

Worker connections

Profiling

De volta com CONN_MAX_AGE

Conclusão

Referências

Diagnósticos usando dotnet-monitor + prometheus + grafana

dotnet-monitor

Prometheus

Grafana

Testes de carga

Conclusão

Threadpool no aspnet e problemas de performance

Threadpool starvation

Exemplo

Conclusão

Consistência de dados e padrão Outbox

O problema de escrita dupla (dual write)

Outbox Pattern

Idempotência

Implementação

Validação de entrada de dados e respostas de erro no ASP.NET

Erros de Model Binding

ModelState

[ApiController]

Validação do modelo

Customização da resposta de erro

Conclusão

Referências

SaveChanges e controle transacional no EF Core

Configurando o DbContext

Adicionando dados com o SaveChanges

Controlando a transação

Diferença entre transações aninhadas e savepoints no SQL Server

Savepoints no EF Core

Versões anteriores

Conclusão

Referências

Configurando o `DbContext`

Adicionando dados com o `SaveChanges`