API Gateway: O que é e Principais Características – Desenvolvimento e Arquitetura de Software
Você sabe o que é um API Gateway, e quais principais características? Nesse artigo vamos ver exatamente isso, com um cenário de exemplo e com a análise de diversas características de um API Gateway e como elas podem contribuir para uma arquitetura mais segura, controlada e observável.
É muito comum que as empresas se conectem com seus parceiros e clientes através de APIs. Este tipo de comunicação deve ser tratado com muita atenção, pois é importante para quem está expondo seus serviços garantir questões como:
Com o boom da arquitetura de microsserviços, isso se tornou mais evidente uma vez que as empresas passaram a expor diversos serviços para seus parceiros. Aquele monolito com as regras de negócios centralizadas deu lugar a uma malha de serviços com responsabilidades específicas, tornando mais complexo o gerenciamento da aplicação.
O API Gateway é a ferramenta que ajuda a reduzir esta complexidade, fornecendo recursos que podem fazer parte da estratégia de software, assumindo responsabilidades e permitindo que a aplicação seja desenvolvida com foco maior na regra de negócio.
Em uma definição simples, um API Gateway é uma ferramenta de gerenciamento de APIs que fica entre o cliente e o servidor (backend) que intercepta todas as requisições e pode aplicar políticas na entrada (request) e na saída (response).
Vamos considerar um cenário de uma plataforma que fornece serviços de e-commerce e que possui 3 microsserviços: Carrinho, Catalogo e Pedidos. Esta plataforma é fornecida por assinatura e possui diversos clientes conectados a ela. Quando um arquiteto está projetando uma aplicação deste tipo, há várias preocupações como:
Como controlar o acesso as aplicações?
Como monitorar estas aplicações?
A Implementação de cache no catálogo para entrega rápida deve ser feito na aplicação?
Como garantir que os clientes acessem as 3 aplicações com a mesma autenticação?
Como vou identificar o problema se ocorrer uma falha?
Estas são algumas das preocupações, e se ignorarmos a existência de um API Gateway cada uma destas preocupações são triplicadas, considerando que estas responsabilidades devem ser atribuídas a cada uma das aplicações. Isso aumentaria a complexidade de desenvolvimento e, consequentemente, o custo do projeto.
Se o API Gateway fizer parte da estratégia da aplicação, algumas responsabilidades podem ser centralizadas diminuindo a necessidade de codificação e desta forma há redução de complexidade e custo de projeto.
Acesso por um único ponto
Se a plataforma de serviços de e-commerce tem 3 serviços é bem interessante que os clientes possam conectar suas aplicações a um único local, até porque no futuro outros serviços podem ser fornecidos.
Há diversas vantagens em um ponto de acesso único, tanto para o cliente quanto para quem mantém a plataforma.
O cliente não precisa se preocupar em configurar diversas conexões na aplicação e gerenciar diversas credenciais.
Já para quem mantém a plataforma, é possível:
Realizar roteamento entre os serviços
Aplicar políticas de segurança de forma global
Configurar throttling para não ter abusos
Configurar detecção de bots
Criar correlation id e repassar para as aplicações
Gerar logs de requisição
Com estes recursos, o arquiteto já pode pensar em reduzir a complexidade das aplicações, delegando estas responsabilidades ao API Gateway.
Roteamento entre os serviços
Quando a requisição chegar ao API Gateway, ela deverá ser redirecionada por ele a um serviço específico. Para fazer isso, uma política de rotas pode ser definida onde, por exemplo, a url https://api.ecommerce.com.br/carrinho/ direciona a aplicação para o serviço de carrinho, /pedidos para pedidos e /catalogo para catálogo. Assim, o cliente tem um ponto de acesso único e uma visão transparente da aplicação.
Este cenário pode ficar ainda mais interessante considerando que os serviços podem ser versionados, como por exemplo os caminhos /v1/carrinho ou /v2/carrinho que direcionam para versões específicas. Se considerar APIs de nível de maturidade 3, o versionamento pode ser feito diretamente pelo cabeçalho no próprio API Gateway.
Além de rotear para os serviços, as rotas podem ser reescritas. Se a aplicação foi construída com as rotas em português mas por uma estratégia da empresa, a exposição tem que ser feita em inglês, é possível criar rotas que mapeam para os endpoints internos. Por exemplo, uma requisição a /orders/approve poderia direcionar internamente para /pedidos/aprovar.
Como o API Gateway fica entre o cliente e o backend é interessante que ele seja responsável por cuidar da segurança das aplicações. A vantagem em fazer isso é que tanto a autenticação do usuário, quanto a autorização de acesso aos endpoints atuarão no tráfego ao backend, poupando recursos da aplicação.
A implementação de autenticação pode ser feita por usando mecanismos mais simples, como uma API Key, ou mecanismos mais complexos e mais seguros, como OAuth. No caso de OAuth, o API Gateway pode fazer o papel de provedor de identidade ou pode simplesmente validar se o token JWT é valido, confiando em um provedor externo. Tendo o token validado, o API Gateway pode determinar se a aplicação poderá ou não ter acesso a determinado recurso.
Levando em consideração o cenário da plataforma de ecommerce, é possível que uma aplicação tenha permissão para fazer uma requisição de leitura a um endpoint (GET) do serviço de Catálogo mas não para modificação, recebendo um retorno de proibido (403) caso tente realizá-la.
Apesar das linguagens de programação terem recursos que permitem fazer este tipo de autorização de forma simples, fazer este procedimento no API Gateway evita que a requisição seja processada pelo backend. Em caso de um ataque por excesso de tentativas, o backend fica protegido e não há sobrecarga do recurso.
Restrição por IP
Um recurso que permite criar uma relação de confiança entre a aplicação e o cliente é a restrição por IP. Desta forma, o API Gateway só vai processar requisições se o IP de origem for permitido. No caso da plataforma de e-commerce, quando os clientes por assinatura quiserem usar a plataforma deverão informar o IP de origem das requisições. Se por algum motivo aconteceu o vazamento das chaves de autenticação, o ofensor será barrado pelo IP, criando assim mais uma camada de segurança.
Deteccão de Bots
Geralmente os ataques são feitos por mecanismos conhecidos como ferramentas de testes de APIs e bibliotecas de linguagens de programação. Desta forma, o API Gateway pode aplicar regras para identificar estes bots e negar o acesso ao endpoint. Se o ofensor tentar criar uma automação usando curl por exemplo, o API Gateway pode negá-lo. Além disso, os clientes da plataforma de e-commerce tem a possibilidade de criar uma exceção para sua aplicação.
Estas formas de segurança geralmente são simples de configurar em um API Gateway, porém seriam bem complexas de ser desenvolvidas por conta própria, possivelmente cobrindo uma quantidade de cenários inferior.
É importante controlar como os dados estão chegando e saindo dos nossos serviços, pois desta forma é possível limitar as aplicações e fornecer recursos que ajudam a melhorar a performance e poupar recursos dos serviços.
Mesmo que um cliente esteja autenticado, isso não vai garantir que ela esteja fazendo bom uso da API. Pode acontecer do cliente fazer mais requisições que o necessário, comprometendo a infraestrutura em casos extremos.
Como ação preventiva, o recurso de throttling pode ser aplicado no API Gateway. Este recurso vai limitar a quantidade de requisições que uma aplicação pode fazer em um período de tempo.
No caso da plataforma de e-commerce, pode ser uma boa idéia limitar o cliente de acordo com planos de assinatura. Um plano básico pode permitir que sejam feitas 50 requisições por segundo ao serviço de catálogo, enquanto o plano mais avançado pode permitir 3000 requisições por segundo. Se a plataforma tiver uma sandbox, não é interessante que o número de requisições seja muito alto, pois este é um ambiente de validação, podendo ter um limite de 3 requisições por segundo. Se os limites forem ultrapassados, o API Gateway automaticamente começaria a responder com mensagem de erro e status 429 até que o novo ciclo de consumo se inicie.
Adicionar cache a aplicação é uma estratégia interessante pelo seguinte comportamento:
O backend responde a primeira requisição, e as seguintes são respondidas diretamente pelo API Gateway até que o cache expire;
Logo, como não há processamento, a entrega da requisição em cache é mais rápida.
Este tipo de estratégia pode ser usado quando os dados não tem mudanças constantes.
Mas é necessário ter um questionamento: o que acontece quando o valor foi atualizado no backend e mas já estiver no cache do API Gateway? Este é um cuidado que deve ser tomado para não entregar dados desatualizados a aplicação. Uma forma de resolver isso é invalidar o cache quando a informação é atualizada. Caso o tempo de atualização não seja crítico para a regra de negócio, o cache pode ser invalidado automaticamente após a expiração.
A plataforma de e-commerce pode ter o catálogo em cache, e quando tiver uma atualização de produto, o cache deve ser invalidado para que os dados sejam atualizados. Esta é mais uma estratégia que poupa tráfego do backend.
O serviço está seguro e tem o tráfego controlado, mas como ter certeza disso? O API Gateway pode fornecer informações sobre o ambiente, sobre a dados das requisições e rastreios dessas até os serviços. Estas informações são importantes para a tomada de decisões, já que quem controla as aplicações necessita saber quanto de recurso está sendo utilizado para manter as aplicações no ar, assim como precisa ter informações para diagnosticar e resolver possíveis problemas.
A partir do momento que um API Gateway está no meio do caminho entre o cliente a aplicação, é importante entender que há um possível ponto de falha e de latência que precisa ser monitorado. O API Gateway vai adicionar um leve tempo à requisição e isso precisa ser metrificado e comparado com o tempo que o backend responde. Em um momento de troubleshooting esta informação é necessária para identificar onde está o problema.
O API Gateway pode fornecer informações que compõem o The Four Golden Signals, que resumidamente são:
Latência: tempo de duração de uma requisição entre o gateway e o backend e o tempo total da requisição (processamento no API Gateway somado ao tempo de resposta ao backend)
Saturação: qual o percentual de recursos o seu API Gateway está consumindo (memória, CPU e I/O)
Erros: quantos erros estão ocorrendo no retorno das aplicações
Tráfego: quantas requisições estão passando pelo API Gateway
Se os clientes começam a reclamar que estão com lentidão no serviço de pedidos, recorrer a estas métricas vai permitir identificar de forma rápida onde está o problema. Se nas métricas apontar que o tempo de processamento do API Gateway é 500ms enquanto o backend responde em 10ms, ações devem ser tomadas no API Gateway. Outros dados permitirão tomar uma decisão sobre o que fazer. Por exemplo, se a saturação está alta indica que as configurações podem ser revisadas com o intuito de identificar o uso indevido de recursos ou o API Gateway necessita de mais recursos para funcionar.
Os logs do API Gateway irão dar informações suficientes para realizar a identificação de quem fez a requisição, o tempo que durou, a URL chamada, os headers recebidos e enviados, o método que foi utilizado, o código de status, entre outras informações.
Um cliente pode reclamar que está recebendo mensagem de erro NOT FOUND e não está entendendo o que está acontecendo. Uma pesquisa nos logs pode mostrar que ele está tentando acessar o recurso incorreto. Se estiver acontecendo de uma aplicação retornar o erro SERVER ERROR esporadicamente, o log pode mostrar que este problema está ocorrendo em uma rota específica ou com parâmetros específicos.
O API Gateway pode auxiliar a propagar informações de tracing entre as aplicações e reportar a um servidor específico. Desta forma, é possível ter o ciclo de vida completo de uma requisição. Porém, vale destacar que se uma aplicação faz tráfego leste-oeste com outra aplicações, ela deve ser responsável por trafegar estas informações. Em um momento de falha de requisição, ter o tracing da requisição ajuda a identificar onde a cadeia se quebrou.
Se um cliente da plataforma de e-commerce reclamar que os pedidos não estão sendo finalizados, consultar o tracing das últimas transações dele pode mostrar onde o processo foi interrompido.
Desafios em manter um API Gateway
Ter um API Gateway indica ter um ponto crítico entre a sua aplicação e o mundo externo. Se o API Gateway parar, todas as sua aplicações ficam inacessíveis. Considere:
Ter uma estrutura redundante que faça um fallback em caso de falha. Um API Gateway dividido em vários ambientes pode ajudar nisso.
Se o API Gateway adicionar latência que atrapalhe a regra de negócios, deve-se analisar os recursos que estão sendo utilizados, e possivelmente realizar ajustes de configuração ou aumento de recursos para resolver o problema.
Ser crítico ao adicionar e atualizar funcionalidades e configurações ao API Gateway. Uma configuração incorreta pode deixar as aplicações fora do ar.
Muitas funcionalidades podem ser delegadas ao API Gateway, permitindo que os desenvolvedores foquem nas regras de negócio. Além disso, o acesso centralizado aos serviços fornece uma melhor experiência aos clientes, além de um melhor controle das aplicações nos diferentes aspectos tratados neste artigo.
Insights de Ferramentas
A maior parte dos API Gateways podem ser conectados a outras ferramentas para executar suas funções.
Grafana, Kibana – visualização dos dados em forma gráfica
Prometheus – coleta de métricas
Zipkin e Jaeger – tracing de requisições
ElasticSearch – armazenamento de logs
Minha carreira tem sido dedicada a ajudar as empresas a tomarem as melhores decisões estratégicas em arquitetura e desenvolvimento de software.
Sou defensor do código limpo, acredito que sempre pode haver uma solução que pode facilitar o dia-a-dia dos usuários.