Em uma arquitetura baseada em microsserviços para um sistema de nível empresarial como o Clumio, não é viável ter um endpoint público para cada microsserviço. Um dos principais problemas é o forte acoplamento que isso gera entre o cliente e o servidor. Além disso, cada microsserviço precisa implementar e manter os componentes comuns, como registro de logs, rastreamento e segurança (autenticação, autorização e limitação de taxa).
Um API Gateway fica entre um cliente e um servidor para atuar como proxy nas solicitações e respostas entre os dois.
Contar com um API Gateway oferece um ponto de entrada unificado para todos os clientes externos e uma estrutura que cuida de todos os elementos comuns mencionados acima. Isso também permite que cada microsserviço implemente seu próprio protocolo de comunicação, aquele que melhor atenda às suas necessidades, independentemente do Gateway.
AWS API Gateway
Além das vantagens mencionadas acima, oferecidas pelos API Gateways, também tínhamos outros requisitos que influenciaram na escolha de um deles:
- Dispor de um mecanismo de integração com o API Gateway de forma que a introdução de novas APIs e a manutenção das já existentes ocorram sem atritos ou com o mínimo possível de atritos, permitindo que os desenvolvedores se concentrem principalmente em sua lógica de negócios
- Como um API Gateway pode, potencialmente, ser um ponto único de falha, ele deve ser um serviço totalmente gerenciado, resiliente e altamente escalável
- Suporte a WebSockets
O AWS API Gateway atende a todos esses requisitos e oferece uma boa integração com outros serviços da AWS, permitindo o desenvolvimento de soluções com base nele.
Aproveitando o AWS API Gateway
Especificação do Swagger
O Swagger oferece uma representação poderosa para APIs RESTful.
Utilizamos a ferramenta go-swagger, que é capaz de gerar uma especificação Swagger a partir de código Go anotado.
Com isso, os desenvolvedores precisam apenas anotar sua API REST de acordo com a especificação acima e deixar que nossa estrutura (mencionada mais adiante) cuide da integração dessa API com o AWS API Gateway.
Integração com o AWS API Gateway
Na Clumio, toda a nossa infraestrutura da AWS é gerenciada como código por meio do Terraform. O AWS API Gateway pode ser configurado utilizando os recursos do Terraform que ele oferece.
Utilizamos o recurso `aws_api_gateway_rest_api`, que nos permite inserir toda a especificação Swagger no AWS API Gateway. O AWS API Gateway, no entanto, não consegue processar uma especificação Swagger bruta. Ele espera que várias extensões (como x-amazon-apigateway-integration) façam parte da especificação Swagger para que ele possa configurar uma API sem problemas. É aí que implementamos uma estrutura que injeta as extensões necessárias em uma especificação Swagger bruta para que ela funcione com o AWS API Gateway!
Tipo de integração do VPC Link
O AWS API Gateway oferece diversas integrações com seus servidores de back-end para atuar como proxy nas solicitações de API recebidas.
Como todos os nossos microsserviços estão vinculados a uma VPC para garantir maior segurança, utilizamos a VPC Link integração. Isso permite que o AWS API Gateway acesse pontos de extremidade de API privados dentro da VPC com segurança.
Nomes de domínio personalizados e mapeamentos de API
Por padrão, o AWS API Gateway gera um nome de domínio exclusivo para a API, algo como aabbccdd12.execute-api.us-west-2.amazonaws.com. Para uma grande empresa, obviamente gostaríamos de personalizar o nome de domínio público das APIs para nossos usuários. O AWS API Gateway nos permite fazer isso por meio dos Nomes de Domínio Personalizados.
Além disso, também criamos APIs separadas no API Gateway correspondentes a algumas das nossas rotas mais movimentadas na base de APIs. Todas essas APIs são, então, integradas por meio de mapeamentos de API, conforme mostrado abaixo. Isso nos permite escalar horizontalmente nossas APIs e, ainda assim, manter um único nome de domínio público para elas.
Lambda Authorizer, planos de uso e chaves de API
Conforme mencionado anteriormente, um dos principais casos de uso de um API Gateway é garantir a autenticação e a autorização logo no início do ciclo de vida da solicitação de API, de modo que apenas o tráfego relevante chegue aos servidores de back-end.
Utilizamos o Lambda Authorizer para autenticação e autorização, enquanto os Planos de Uso e as Chaves de API são empregados para aplicar limitação de taxa/restrição de tráfego às nossas APIs.
Implementamos um Autorizador Lambda baseado em token que espera a seguinte entrada:
O authorizationToken (na forma de um JWT) pode ser usado para implementar a lógica de autenticação/autorização necessária no Autorizador Lambda, a fim de retornar a saída conforme abaixo:
A decisão de autenticação/autorização é determinada pelo valor de Effect (Allow|Deny) e a decisão de limitação de tráfego é determinada pelo identificador da chave de API em usageIdentifierKey. A chave de API deve estar associada a um Plano de Uso, que determina a cota de solicitações a ser aplicada (em termos de solicitações por segundo). Emitimos uma chave de API para cada cliente e, portanto, podemos aplicar o controle de taxa por cliente.
Outro aspecto interessante na saída é context que ela pode conter quaisquer pares chave-valor, conforme exigido pela aplicação. Utilizamos isso amplamente para capturar as informações do cliente, que depois passamos ao longo de todo o ciclo de vida da solicitação da API. Isso elimina a necessidade de consultar os detalhes do cliente enquanto a solicitação percorre vários microsserviços no back-end.
Conclusão
Esperamos que você tenha obtido uma visão sobre como aproveitamos o AWS API Gateway na Clumio e também uma prévia dos esforços mais amplos de engenharia que realizamos. Damos a máxima atenção à segurança, à escalabilidade e, acima de tudo, à adoção de processos que facilitem o trabalho dos desenvolvedores. Isso facilita a manutenção dos produtos à medida que amadurecemos e crescemos, ao mesmo tempo em que nos mantemos suficientemente flexíveis para acomodar novas funcionalidades.
