Arquitetura para escalar com integrações privadas do Amazon API Gateway

As organizações usam o Amazon API Gateway para criar APIs seguras e robustas que expõem serviços internos a outros aplicativos e usuários externos. Quando o ambiente evolui para muitos microsserviços, os clientes devem garantir que a camada de API possa lidar com a escala sem comprometer a segurança e o desempenho. O API Gateway fornece vários tipos de API e opções de integração, e os criadores devem considerar como cada opção afeta a capacidade de escalar a camada de API com segurança e desempenho à medida que o ambiente de microsserviços cresce.

Esta postagem do blog compara as opções de arquitetura para criar integrações privadas e escaláveis com o API Gateway para microsserviços. Ele aborda as APIs REST e HTTP, o uso de integrações privadas e mostra como desenvolver arquiteturas de microsserviços seguras e escaláveis.

Visão geral

Aqui está uma implementação típica do API Gateway com integrações de back-end a vários microsserviços:

O API Gateway gerencia a camada de API, ao mesmo tempo em que se integra aos microsserviços de back-end executados no Amazon EC2, no Amazon Elastic Container Service (ECS) ou no Amazon Elastic Kubernetes Service (EKS). Este blog se concentra em microsserviços em contêineres que expõem endpoints internos que a camada de API expõe externamente.

Para manter os microsserviços seguros e protegidos do tráfego externo, eles normalmente são implementados em uma Amazon Virtual Private Cloud (VPC) em uma sub-rede privada, que não pode ser acessada pela Internet. O API Gateway oferece uma maneira de expor esses recursos com segurança além da VPC por meio de integrações privadas usando o link da VPC. A integração privada encaminha o tráfego externo enviado às APIs para recursos privados, sem expor os serviços à Internet e sem sair da rede da AWS. Para obter mais informações, leia Melhores práticas para projetar APIs privadas e integração privada do Amazon API Gateway.

O cenário de exemplo tem quatro microsserviços que podem ser hospedados em uma ou mais VPCs. Ele mostra os padrões que integram os microsserviços com balanceadores de carga front-end e API Gateway por meio de links de VPC.

Embora os links de VPC permitam conexões privadas com microsserviços, os clientes podem ter necessidades adicionais:

• Aumento da escala: oferecem suporte a um número maior de microsserviços por trás do API Gateway.
• Implantações independentes: balanceadores de carga dedicados por microsserviço permitem que as equipes realizem implantações azul/verde de forma independente, sem afetar outras equipes.
• Redução da complexidade: capacidade de usar balanceadores de carga de microsserviços existentes em vez de introduzir outros para obter a integração do API Gateway
• Baixa latência: garante a latência mínima no fluxo de solicitação/resposta da API.

O API Gateway oferece APIs HTTP e APIs REST (consulte Escolha entre APIs REST e APIs HTTP) para criar APIs RESTful. Para grandes arquiteturas de microsserviços, o tipo de API influencia as considerações de integração:

Este post apresenta quatro opções de integração privada, levando em conta os diferentes recursos e cotas do VPC link para APIs REST e HTTP:

• Opção 1: API HTTP usando link de VPC para vários NLBs ou ALBs.
• Opção 2: API REST usando vários links de VPC.
• Opção 3: API REST usando link VPC com NLB.
• Opção 4: API REST usando link VPC com destinos NLB e ALB.

Opção 1: API HTTP usando link de VPC para vários NLBs ou ALBs

As APIs HTTP permitem conectar um único link de VPC a vários ALBs, NLBs ou recursos registrados com um serviço AWS Cloud Map. Isso fornece uma abordagem de expansão para se conectar a vários microsserviços de back-end. No entanto, os balanceadores de carga integrados a um link de VPC específico devem residir na mesma VPC.

Dois microsserviços estão em uma única VPC, cada um com seu próprio ALB dedicado.

Os ouvintes (listeners) do ALB direcionam o tráfego HTTPS para o respectivo grupo-alvo de microsserviços de back-end. Um único link de VPC é conectado a dois ALBs nessa VPC.

O API Gateway usa regras de roteamento baseadas em caminhos para encaminhar solicitações ao balanceador de carga apropriado e ao microsserviço associado. Essa abordagem é aplicada nas melhores práticas para projetar APIs privadas e integração privada — API HTTP do Amazon API Gateway. Modelos de exemplo (templates) do CloudFormation para implantar essa solução estão disponíveis no GitHub.

Você pode adicionar mais ALBs e microsserviços dentro dos limites de espaço IP da VPC. Use o Network Address Usage (NAU) para projetar a distribuição de microsserviços entre VPCs. Expanda além de uma VPC adicionando links de VPC para conectar mais VPCs, dentro das cotas de links de VPC. Você pode escalar ainda mais usando regras de roteamento, como roteamento baseado em caminhos no ALB visando conectar mais serviços por trás de um único ALB (consulte Cotas para seus balanceadores de carga de aplicativos). Essa arquitetura também pode ser construída usando um NLB.

Benefícios:

• Alto grau de escalabilidade. Distribuição para vários microsserviços usando um único link VPC e/ou recursos de multiplexação do ALB/NLB.
• A integração direta com os balanceadores de carga de microsserviços existentes elimina a necessidade de introduzir novos componentes e reduzir a carga operacional.
• Menor latência para solicitação/resposta da API graças à integração direta.
• Balanceadores de carga dedicados por microsserviço permitem implantações independentes para equipes de microsserviços.

Opção 2: API REST usando vários links de VPC

Para APIs REST, a arquitetura para suportar vários microsserviços pode ser diferente devido a estas considerações:

• O NLB é a única integração privada compatível com APIs REST.
• Os links de VPC para APIs REST podem ter somente um NLB de destino.

É necessário um link de VPC para cada NLB, mesmo que os NLBs estejam na mesma VPC. Cada NLB serve um microsserviço, com um ouvinte (listener) para rotear o tráfego do API Gateway para o grupo-alvo. O roteamento baseado em caminhos do API Gateway envia solicitações para o NLB apropriado e para o microsserviço correspondente. A configuração necessária para essa integração privada é semelhante ao exemplo descrito no Tutorial: Crie uma API REST com a integração privada do API Gateway.

Para escalar ainda mais, adicione mais links de VPC e integração de NLB para cada microsserviço, na mesma VPC ou em diferentes VPCs, com base em suas necessidades e requisitos de isolamento. Essa abordagem é limitada pela cota de links de VPC por conta por região.

Benefícios:

• Um único NLB no caminho da solicitação reduz a complexidade operacional.
• NLBs dedicados para cada um permitem implantações independentes de microsserviços.
• Nenhum salto adicional no caminho da solicitação da API, como resultado menor latência.

Considerações:

• Limita a escalabilidade devido a um mapeamento individual de links de VPC para NLBs e microsserviços limitado pela cota de links de VPC por conta por região.

Opção 3: API REST usando link VPC com NLB

O mapeamento individual de links de VPC para NLBs e microsserviços na opção 2 tem limites de escalabilidade devido às cotas de links de VPC. Uma alternativa é usar vários microsserviços por NLB.

Um único NLB oferece vários microsserviços em uma VPC usando vários ouvintes (listeners), com cada ouvinte em uma porta separada por microsserviço. Aqui, o NLB1 oferece dois microsserviços em uma VPC. O NLB2 oferece dois outros microsserviços em uma segunda VPC.

Com vários microsserviços por NLB, o roteamento é definido para a API REST ao escolher o ponto de integração para um método. Você define cada serviço usando uma combinação de selecionar o VPC Link, que é integrado a um NLB específico, e uma porta específica que é atribuída a cada microsserviço no NLB Listener e endereçada a partir do URL do Endpoint.

Para expandir ainda mais, adicione mais ouvintes (listener) aos NLBs existentes, limitados por cotas para seus balanceadores de carga de rede. Nos casos em que cada microsserviço tem seu balanceador de carga ou ponto de acesso dedicado, eles são configurados como destinos para o NLB. Como alternativa, integre microsserviços adicionais adicionando links de VPC adicionais.

Benefícios:

• Maior escalabilidade – limitada pelas cotas de ouvintes do NLB e pelas cotas de links de VPC.
• Gerenciar menos NLBs com suporte a vários microsserviços reduz a complexidade operacional.
• Baixa latência com um único NLB no caminho da solicitação.

Considerações:

• A configuração compartilhada do NLB limita as implantações independentes para equipes individuais de microsserviços.

Opção 4: API REST usando o link VPC com destinos NLB e ALB

Os clientes geralmente criam microsserviços com o ALB como ponto de acesso. Para expô-las por meio das APIs REST do API Gateway, você pode aproveitar o ALB como destino para o NLB. Esse padrão também aumenta o número de microsserviços suportados em comparação com a arquitetura da opção 3.

Um link VPC (VPClink1) é criado com NLB1 em um VPC1. O ALB1 e o ALB2 fazem front-end dos microsserviços mS1 e mS2, adicionados como alvos de NLB em ouvintes separados. O VPC2 tem uma configuração similar. Suas necessidades de isolamento e espaço IP determinam se os microsserviços podem residir em uma ou várias VPCs.

Para expandir ainda mais:

• Crie links de VPC adicionais para integrar novos NLBs.
• Adicione ouvintes do NLB para oferecer suporte a mais alvos do ALB.
• Configure o ALB com regras baseadas em caminhos para rotear solicitações para vários microsserviços.

Benefícios:

• Serviços de integração de alta escalabilidade usando NLBs e ALBs.
• Implantações independentes por equipe são possíveis quando cada ALB é dedicado a um único microsserviço.

Considerações:

• Vários balanceadores de carga no caminho da solicitação podem aumentar a latência.

Considerações e melhores práticas

Além das considerações de escalabilidade com a integração de links de VPC discutidas neste blog, há outras considerações:

• Avalie os recursos das APIs REST e das APIs HTTP para atender às suas necessidades.
• Escolha o tipo de balanceador de carga ideal para as necessidades do seu aplicativo.
• Para referência de arquitetura de várias contas Criação de APIs privadas entre contas usando o Amazon API Gateway e o AWS PrivateLink.
• Evite exceder rapidamente as cotas padrão e solicite um aumento de cota para requisitos de limites mais altos.
• Monitore as cotas de serviço para planejar proativamente e mitigar os riscos à medida que sua arquitetura evolui. Considere o uso da solução Quota Monitor para monitoramento.
• Veja as melhores práticas para projetar APIs privadas e integração privada do Amazon API Gateway — API Rest.

Conclusão

Este blog explora a criação de integrações escaláveis do API Gateway para microsserviços usando links de VPC. Os links de VPC permitem o encaminhamento de tráfego externo para microsserviços de back-end sem expô-los à Internet ou sair da rede da AWS. A postagem aborda considerações de escalabilidade com base no uso de APIs REST versus APIs HTTP e como elas se integram a NLBs ou ALBs em VPCs.

Embora o tipo de API e a seleção do balanceador de carga tenham outros fatores de design, é importante ter em mente as considerações de escalabilidade discutidas neste blog ao projetar sua arquitetura de camada de API. Ao otimizar a implementação do API Gateway para atender às necessidades operacionais, de latência e de desempenho, você pode criar uma API robusta e segura para expor microsserviços em grande escala.

Para obter mais recursos de aprendizado sem servidor, visite Serverless Land.