Compartilhar via

Práticas recomendadas de arquitetura para o Gerenciamento de API do Azure

O Gerenciamento de API do Azure é uma plataforma de gerenciamento e um gateway para APIs em todos os ambientes, incluindo híbrido e multinuvem. Como uma solução de PaaS (plataforma como serviço), o gerenciamento de APIs ajuda a dar suporte ao ciclo de vida da API.

Este artigo pressupõe que, como arquiteto, você revisou a árvore de decisão do Integration Services e escolheu o Gerenciamento de API como o serviço de integração para sua carga de trabalho. As diretrizes neste artigo fornecem recomendações arquitetônicas mapeadas para os princípios dos pilares da Estrutura Well-Architected.

Importante

Como usar este guia

Cada seção tem uma lista de verificação de design que apresenta áreas arquitetônicas preocupantes, juntamente com estratégias de design localizadas no escopo da tecnologia.

Também estão incluídas recomendações para os recursos de tecnologia que podem ajudar a materializar essas estratégias. As recomendações não representam uma lista completa de todas as configurações disponíveis para o Gerenciamento de API ou os servidores de API de back-end da carga de trabalho. Em vez disso, eles listam as principais recomendações alinhadas às perspectivas de design. Use as recomendações para criar sua prova de conceito ou otimizar seus ambientes existentes.

Arquitetura fundamental que demonstra as principais recomendações: arquitetura da zona de destino do Gerenciamento de API.

Escopo da tecnologia

Esta revisão se concentra nas decisões interrelacionadas para o seguinte recurso do Azure:

  • Gerenciamento de API do Azure

O escopo deste guia é o serviço de Gerenciamento de API, principalmente o componente de gateway (plano de dados), que encaminha solicitações de API de aplicativos cliente para APIs de back-end hospedadas em diferentes plataformas ou entre ambientes. A arquitetura de workload deve considerar o plano de controle do API Management e componentes relacionados, como aplicativos cliente que acessam o gateway e as APIs de back-end que processam solicitações roteadas. Ele também integra o suporte aos serviços do Azure, incluindo rede, monitoramento, gerenciamento de identidade e outros recursos.

Este guia não abrange o Centro de API do Azure. Ele aborda os tópicos no nível da API conforme eles se relacionam com o Gerenciamento de API, em vez de fornecer uma perspectiva bem arquiteta sobre considerações de design de API.

Observação

Nem todas as recomendações se aplicam a todas as camadas de serviço do Gerenciamento de API. Muitas recomendações neste guia se concentram nas camadas Standard v2 e Premium clássicas do Gerenciamento de API, que são as camadas de produção recomendadas para a maioria das cargas de trabalho corporativas.

Importante

A camada Premium v2 com recursos corporativos está em versão prévia. Para determinar se seu design deve contar com recursos de acesso antecipado ou recursos disponíveis em geral, avalie suas linhas do tempo de design e implementação em relação às informações disponíveis sobre os caminhos de versão e migração do Premium v2.

Fiabilidade

A finalidade do pilar confiabilidade é fornecer funcionalidade contínua criando resiliência suficiente e a capacidade de se recuperar rapidamente de falhas.

princípios de design de confiabilidade fornecem uma estratégia de design de alto nível aplicada a componentes individuais, fluxos do sistema e o sistema como um todo.

Lista de verificação de projeto

Inicie sua estratégia de design com base na lista de verificação de design para Confiabilidade. Determine sua relevância para seus requisitos de negócios, tendo em mente as camadas e os recursos do Gerenciamento de API e suas dependências. Estenda a estratégia para incluir mais abordagens conforme necessário.

  • Avalie os recursos de gateway para confiabilidade e redundância: Determine a camada de Gerenciamento de API e os recursos necessários para atender aos requisitos de confiabilidade da carga de trabalho para cada ambiente.

    Avalie os recursos de redundância de gateway, incluindo zonas de disponibilidade, várias unidades de gateway, várias regiões e espaços de trabalho. Todos esses recursos têm suporte na camada Premium. A camada de desenvolvedor, que não inclui um SLA (contrato de nível de serviço), não é adequada para cargas de trabalho de produção. Considere as desvantagens da adoção de recursos, como o cache externo, que podem introduzir possíveis pontos de falha e gargalos de desempenho.

  • Examine os recursos de observabilidade: Considere os recursos de observabilidade do serviço, incluindo logs e métricas do Azure Monitor, Application Insights, análise interna e diagnóstico interno. Use esses recursos para monitorar os sinais de confiabilidade da carga de trabalho.

    Por exemplo, considere usar alertas do Azure Monitor para notificar você sobre possíveis problemas com o gateway de Gerenciamento de API ou suas dependências.

  • Examine as estratégias de dimensionamento: Defina critérios para dimensionar o gateway adicionando unidades para manter a confiabilidade do serviço. Considere se deve escalar com base em solicitações, exceções ou ambos. Avalie o impacto da escala do componente de gateway em outros componentes da carga de trabalho. Por exemplo, seu efeito sobre o espaço de endereço de rede e os recursos de dimensionamento dos back-ends.

  • Isolar cargas de trabalho críticas: Determine se o isolamento de computação é necessário para atender aos requisitos de carga de trabalho, como soberania de dados ou otimização de desempenho, em suas APIs. Use gateways dedicados para APIs críticas e gateways compartilhados para APIs menos críticas.

    Escolha uma abordagem de isolamento, como usar um gateway de espaço de trabalho dedicado ou uma instância separada do Gerenciamento de API. Para várias instâncias, mantenha os ambientes sincronizados como parte de suas práticas de implantação seguras.

  • Alinhamento do objetivo de nível de serviço (SLO): Fatorar o escopo do SLA do gateway ao definir os SLOs da carga de trabalho. O serviço fornece seu próprio SLA, mas você também precisa considerar a confiabilidade prevista de outros componentes de carga de trabalho, como os back-ends da API.

  • Aborde as falhas de back-end: Planeje estratégias para lidar com falhas de back-end esperadas e inesperadas. Teste as experiências do cliente nesses cenários. Avalie as políticas de gateway para melhorar a resiliência e aprimorar a experiência do cliente. Concentre-se em cotas, limites de solicitação, políticas de repetição, disjuntores de back-end, balanceamento de carga e tratamento de exceções conforme documentado em suas especificações de API.

  • Definir estratégias de teste: Use uma solução de teste, como o Teste de Carga do Azure de dentro de sua rede, para refletir cargas de trabalho de produção reais. Não confie na taxa de transferência publicada ou em outras estimativas que podem não se aplicar à sua carga de trabalho.

  • Planejar recuperação de desastre (DR): Examine as opções de backup e restauração da infraestrutura e das APIs do gateway. Recursos integrados de backup e restauração podem ser úteis em alguns cenários. Mas opções gerenciadas pelo cliente, como ferramentas de APIOps e soluções de IaC (infraestrutura como código), também podem ser consideradas. Desenvolva estratégias para manter outros dados do sistema, incluindo assinaturas de usuário.

Recomendações

Essas recomendações de confiabilidade podem ser aplicadas ao próprio serviço ou ao tráfego que flui por meio de APIs e suas políticas. Os designadores (Serviço) ou (API) indicam se uma recomendação tem como destino o serviço ou as APIs.

Recomendação Benefício
(Serviço) Habilite a redundância de zona na camada Premium e tenha um mínimo de três unidades implantadas.

Nessa configuração, em condições operacionais normais, todas as unidades de escala em todas as zonas configuradas estão ativas e atendem ao tráfego do gateway.

Em qualquer cenário ativo-ativo, planeje dar suporte à expansão nas zonas ativas restantes para lidar com o tráfego que as unidades processavam originalmente na zona com falha.		 A resiliência é assegurada durante uma interrupção de datacenter em uma região. Durante uma perda completa do datacenter, o tráfego de API continuará a fluir pelas unidades restantes implantadas em outras zonas.
(Serviço) Habilitar expansão automática com base nas demandas de tráfego.

Em implantações de várias regiões, as regiões secundárias não têm capacidades automáticas de expansão ou redução. Você precisa implementar uma função personalizada ou um Aplicativo Lógico que seja ativado em resposta aos alertas de métrica do Azure Monitor para gerenciar ajustes de unidade com base na demanda.		 Recursos suficientes são garantidos para atender à demanda de clientes de API, o que impede falhas devido à capacidade insuficiente.
(Serviço) Use uma topologia de várias regiões para dar suporte à resiliência contra uma falha regional completa.

Essa abordagem exige que você coordene com outros componentes em sua carga de trabalho e entenda suas características de failover planejadas. Em qualquer cenário ativo-ativo, planeje dar suporte à expansão nas regiões ativas restantes para lidar com o tráfego que a região agora inativa processava originalmente.

Certifique-se de que a topologia de várias regiões esteja alinhada com todos os requisitos de conformidade para dados em trânsito ou dados armazenados no cache.		 A resiliência robusta é fornecida durante uma interrupção regional completa, o que ajuda a garantir o tráfego ininterrupto da API por meio de unidades implantadas em outras regiões.
(Serviço) Isolar APIs não relacionadas com workspaces ou instâncias adicionais de Gerenciamento de API. O impacto das falhas causadas por falhas de configuração ou interrupções é minimizado pela separação de APIs em diferentes instâncias de computação.
(API) Teste minuciosamente as expressões de política e a lógica e emparelhe-as com técnicas resilientes de tratamento de erros em políticas de gerenciamento de API. A experiência do cliente é aprimorada ao impedir novas fontes de falhas no gateway e fornecer degradação elegante ou tratamento seguro de falhas transitórias.
(Serviço &API) Coletar métricas de confiabilidade.

As métricas típicas de confiabilidade da API incluem:

- Limites de taxa e violações de cotas.
- Taxa de erro com base em códigos de status HTTP.
- Desvios da taxa de requisições em relação à linha de base.
- Verificações de integridade, incluindo integridade de dependências.		 Desvios do comportamento esperado e das linhas de base passadas são identificados. Esses dados podem ser usados para rastrear causas raiz, como comportamento alterado do usuário, interferência de operações de rotina, impactos inesperados de novos recursos ou falhas não planejadas na carga de trabalho.
(Serviço e API) Use o backup e restauração interno integrado no Gerenciamento de API como parte do seu guia estratégico de DR. Suplementar esses recursos com seus artefatos IaC e processos APIOps para uma solução robusta que pode lidar com vários cenários, incluindo coordenação de recuperação com dependências e back-ends. A continuidade dos negócios é assegurada permitindo a recuperação do gateway de API e a restauração de APIs definidas após uma perda completa do sistema.

Segurança

O objetivo do pilar Segurança é fornecer garantias de confidencialidade, integridade e disponibilidade à carga de trabalho.

Os princípios de design de segurança fornecem uma estratégia de design de alto nível para atingir essas metas aplicando abordagens ao design técnico na proteção do gateway de Gerenciamento de API.

Observação

A lista de verificação e as recomendações nesta seção se concentram na proteção do recurso de gateway de Gerenciamento de API. A proteção das APIs em si só é tratada brevemente. Para obter mais informações, consulte Atenuar a segurança da API OWASP top 10 no Gerenciamento de API.

Lista de verificação de projeto

Inicie sua estratégia de design com base na lista de verificação de revisão de design para Segurança e identifique vulnerabilidades e controles para melhorar a postura de segurança. Estenda a estratégia para incluir mais abordagens conforme necessário.

  • Estabelecer uma linha de base de segurança: Examine a linha de base de segurança para o Gerenciamento de API e incorpore as medidas aplicáveis em sua linha de base.

  • Proteja o pipeline de implantação: identifique as funções de controle de acesso baseado em função e os indivíduos necessários para gerenciar a plataforma de serviços, as pipelines de integração contínua e implantação contínua (CI/CD) e as APIs individuais. Verifique se somente pessoas autorizadas têm acesso para gerenciar o serviço e suas APIs.

  • Avaliar a confidencialidade de dados: Se os dados confidenciais fluem por meio de solicitações de API e respostas no gateway de Gerenciamento de API, garanta sua proteção durante todo o ciclo de vida. Considere os diferentes requisitos de proteção de dados de diferentes regiões. Avalie os recursos de serviço, como várias regiões , para isolar dados específicos. Além disso, confirme se sua estratégia de cache está alinhada com esses requisitos de isolamento.

  • Desenvolva estratégias de segmentação em gateways compartilhados: se a sua instância do Gerenciamento de API hospedar APIs para várias equipes de carga de trabalho, use espaços de trabalho para segregar funções, redes e, possivelmente, gateways. Essa abordagem garante que cada equipe tenha acesso e controle apropriados sobre as APIs que gerenciam, restringindo o acesso às APIs de outras equipes.

  • Considere os controles de rede: Identifique os requisitos e as opções para isolar ou filtrar o tráfego de gateway de entrada e saída usando redes virtuais. Determine se o acesso ao gateway pode ser restrito por meio do Link Privado do Azure ou se o acesso público ao gateway é necessário. Avalie se a arquitetura deve incluir um firewall de aplicativo Web, como o Firewall de Aplicativo Web do Azure no Gateway de Aplicativo do Azure ou no Azure Front Door, para obter o isolamento de rede necessário e filtrar o tráfego de rede.

  • Considere os recursos de autenticação e autorização da API: Avalie o uso de provedores de identidade, como a ID do Microsoft Entra, que inclui grupos internos, ou a ID Externa do Microsoft Entra para exibir solicitações de gateway e habilitar a autorização do OAuth para APIs de back-end.

  • Criptografar o tráfego de rede: Identifique as versões de protocolo TLS (Transport Layer Security) mais seguras e as criptografias que suas cargas de trabalho podem dar suporte. Não exija versões TLS inseguras. Use o TLS 1.3 quando tiver suporte para seus clientes.

  • Execute a modelagem de ameaças no Gerenciamento de API e reduza sua área de superfície: Determine se componentes específicos do Gerenciamento de API, como a API de gerenciamento direto ou o acesso público ao portal do desenvolvedor, podem ser desabilitados, restritos ou removidos.

  • Identifique os segredos que as cargas de trabalho exigem: A operação de gateway pode exigir certificados, chaves de API ou outros valores secretos. Examine os requisitos e os recursos do Azure Key Vault para armazenar segredos e certificados. Ou examine os recursos internos de Gerenciamento de API, como valores nomeados e certificados gerenciados.

Recomendações

Essas recomendações de segurança podem ser aplicadas ao próprio serviço ou ao tráfego que flui por meio de APIs e suas políticas. Os designadores (Serviço) ou (API) indicam se uma recomendação tem como destino o serviço ou as APIs.

Recomendação Benefício
(Serviço) Desabilite a API de gerenciamento direto, que foi preterida. Use o Azure Resource Manager como seu plano de controle. A área da superfície do serviço é reduzida pela remoção de um ponto de acesso do plano de controle.
(Serviço) Limite a exposição do gateway baseando-se exclusivamente no local onde os clientes legítimos se conectam.

- Use injeção de rede virtual sem um endereço IP público quando todos os clientes puderem rotear o tráfego por meio de uma rede virtual. Use um NSG (grupo de segurança de rede) para restringir ainda mais o tráfego apenas aos endereços IP de origem do cliente esperados.

– Use a integração de rede virtual com o Gateway de Aplicativo ou o Azure Front Door se algum tráfego precisar vir da Internet. Configure o NSG para aceitar apenas o tráfego do ponto único de entrada.		 A confidencialidade do tráfego de rede é protegida restringindo a exposição aos intervalos de endereços IP de origem que devem conter clientes legítimos. Essas restrições bloqueiam o acesso de fontes que não devem iniciar a comunicação legítima do cliente. Limitar a exposição a fontes de tráfego legítimas aprimora a confidencialidade, a integridade e a disponibilidade do serviço.
(Serviço) Desabilite o portal do desenvolvedor se ele não estiver em uso. Se o portal estiver em uso, desabilite a experiência de inscrição, desabilite o acesso anônimo e restrinja o acesso a apenas locais de rede confiáveis. A área da superfície do serviço e a chance de configuração incorreta ou negligência são reduzidas.
(Serviço) Defina explicitamente as versões, protocolos e criptografias TLS com suporte mais estreito para seus clientes e seus back-ends. As versões e as criptografias com suporte são reduzidas apenas para as opções que os clientes e os back-ends suportam. Essa abordagem ajuda a garantir que as conexões priorizem as conexões de nível mais alto possíveis para confidencialidade.
(Serviço) Armazene certificados personalizados no Key Vault. A funcionalidade de gerenciamento de certificados é fornecida usando o Key Vault, que dá suporte à rotação de rotina e audita o acesso aos certificados.
(Serviço) Os back-ends devem aceitar apenas o tráfego dos gateways de API e devem bloquear qualquer outro tráfego. O tráfego mal-intencionado é impedido de ignorar a segurança e outras preocupações transversais descarregadas no gateway.
(Serviço) Para instâncias de Gerenciamento de API que hospedam APIs para várias equipes ou cargas de trabalho segmentadas, você deve projetar uma estratégia robusta de isolamento de controle de acesso. Use workspaces ou implemente um rigoroso processo de APIOps para alcançar essa estratégia.

As equipes só devem ter acesso às APIs que possuem. Eles não devem ter acesso a outras APIs que possam ser hospedadas na mesma instância.		 O movimento lateral de invasores de um conjunto de APIs comprometidas para outras APIs não relacionadas é reduzido.
(API) Armazene segredos no Key Vault e exponha-os a políticas por meio de valores nomeados. Não use o Key Vault para armazenar não segredos. Use diretamente as propriedades de valor nomeadas para esses valores. A rotação de segredos é incentivada por meio de um único plano de gerenciamento no Key Vault, semelhante à abordagem usada para certificados. Esse processo garante que o Gerenciamento de API seja atualizado adequadamente. Os valores denominados também garantem uma experiência consistente para a configuração de política tanto para segredos quanto para informações não confidenciais. Todo o acesso secreto também é auditado no Key Vault para fornecer um histórico de acesso. Armazenar apenas segredos no Key Vault minimiza a dependência do Key Vault e não transforma o Key Vault em um serviço de configuração de aplicativo.
(API) Use identidades gerenciadas atribuídas pelo usuário diferentes para diferentes APIs usando a política authentication-managed-identity. Cada API está habilitada para ter uma identidade independente, que dá suporte a metas de segmentação por meio de acesso de privilégio mínimo para cada API. Ele também fornece melhor auditabilidade nos sistemas de back-end.
(API) Quando possível, exija que os clientes se autentiquem com fluxos OAuth 2.0 em vez de usar apenas chaves pré-compartilhadas, incluindo chaves de assinatura ou certificados de cliente. A identificação do cliente para fins de auditoria é aprimorada, a rotação de chaves é eliminada e a carga dos clientes para proteger segredos é reduzida em comparação com o uso de chaves pré-compartilhadas.
(API) Suprima os cabeçalhos HTTP das respostas da API usando a política set-header que pode expor detalhes de implementação. O custo para os invasores é aumentado retendo informações de implementação.
(API) Não use o rastreamento de API na produção. Os dados confidenciais são impedidos de serem expostos em rastreamentos de solicitações.
(API) Use o Defender para APIs. Informações sobre segurança da API, recomendações e detecção de ameaças são fornecidas.
(API) Proteja os recursos de back-end delegando verificações de segurança de chave na política de API, como validate-jwt, ip-filter, validate-headers, validate-content. A quantidade de tráfego nãolegítimo que atinge serviços de back-end é reduzida executando verificações de segurança no gateway. Essa abordagem de descarregamento ajuda a proteger a integridade e a disponibilidade desses recursos.
(API) Aplique práticas de SDL (ciclo de vida de desenvolvimento de segurança) às alterações da política de API da mesma forma que você aplica as alterações propostas ao código do aplicativo em sua carga de trabalho. As políticas são executadas com uma visão altamente privilegiada do tráfego da API. É evitado contornar as proteções de back-end para confidencialidade, integridade e disponibilidade por meio de um gateway de API comprometido.
(Serviço e API) Use identidades gerenciadas para dependências de serviço e API. As conexões com Key Vault, Hubs de Eventos do Azure e outras dependências, como certificados e valores nomeados, são estabelecidas sem depender de segredos pré-compartilhados.
(Serviço & API) Conecte-se a dependências como Key Vault, Event Hubs e sistemas de back-end em conexões de rede privada, quando possível. A confidencialidade do tráfego é protegida por não expor o tráfego além da rede privada.
(Serviço &API) O tráfego do cliente direcionado a APIs expostas à Internet deve passar primeiro por um firewall de aplicativo Web, como o Firewall do Aplicativo Web, antes de atingir o Gerenciamento de API. Além disso, proteja os pontos de extremidade públicos usando a Proteção contra DDoS do Azure. A quantidade de tráfego nãolegítimo que atinge o gateway e os serviços de back-end é reduzida pela realização de verificações de segurança com um firewall de aplicativo Web. Reduzir esse tráfego ajuda a proteger a integridade e a disponibilidade desses recursos.
(Serviço &API) Avalie e habilite todos os controles de Conformidade Regulatória do Azure Policy relevantes para sua carga de trabalho. A instância de Gerenciamento de API se alinha à postura desejada e permanece alinhada à medida que a carga de trabalho evolui, tendo políticas de segurança em vigor.

Otimização de custos

A otimização de custos se concentra na na detecção de padrões de gastos, na priorização de investimentos em áreas críticas e na otimização de outras para atender ao orçamento da organização e, ao mesmo tempo, aos requisitos comerciais.

Os princípios de design de Otimização de Custos fornecem uma estratégia de design de alto nível para atingir essas metas e fazer compensações conforme necessário no design técnico relacionado ao Gerenciamento de API e seu ambiente.

Lista de verificação de projeto

  • Considere o modelo de custo do Gerenciamento de API: Use a calculadora de preços do Azure com os benefícios da conta da sua organização e os critérios de SLA e escalabilidade para desenvolver estimativas precisas de custos do uso de uma camada de serviço de Gerenciamento de API. Determine se um modelo de cobrança é necessário e determine como calculá-lo com base em métricas, marcas e tokens.

    O modelo de custo de serviço é influenciado principalmente pela camada de serviço, número de unidades e número de gateways. Avalie os custos extras associados à manutenção de uma unidade de reserva ou à implementação de uma configuração de DR ativa-passiva.

    Se você implementar workspaces, avalie os custos de uso de gateways de workspace separados versus compartilhados para cumprir os requisitos de fluxo de API distintos de várias equipes de API ou partes interessadas.

  • Estimar custos de dimensionamento: Desenvolva critérios de dimensionamento para manter o alto uso dos recursos do gateway. Avalie os custos de linha de base em um ambiente de pré-produção e execute testes para modelar os custos de dimensionamento com base no tráfego de carga de trabalho previsto.

    Crie uma estratégia de mitigação para evitar o uso indevido de seus gateways, o que pode causar dimensionamento caro além do uso predefinido.

  • Avalie as configurações e políticas do serviço: Funcionalidades como rate-limit e limit-concurrency podem ser usadas como técnicas de otimização de custos para gerenciar cargas de solicitação.

  • Otimizar o posicionamento lógico: Avalie se os servidores de back-end são mais econômicos para a lógica de processamento ou se o gateway deve lidar com o uso do recurso. O gateway é um componente forte para implementar preocupações transversais, mas pode acabar executando funções além do necessário em determinados cenários. Identifique tarefas de processamento de solicitação pesadas de recursos executadas pelo gateway e determine se mover essa lógica para servidores de back-end pode reduzir custos.

Recomendações

Essas recomendações de otimização de custo podem se aplicar ao próprio serviço ou ao tráfego que flui por meio de APIs e suas políticas. Os designadores (Serviço) ou (API) indicam se uma recomendação tem como destino o serviço ou as APIs.

Recomendação Benefício
(Serviço) Use o nível mais barato que atende aos requisitos da carga de trabalho. Por exemplo, escolha uma camada Standard em vez de uma camada Premium se sua carga de trabalho não se beneficiar da funcionalidade adicionada de uma maneira que justifique o ROI (retorno sobre o investimento). A compra de recursos não utilizados ou subutilizados é evitada.
(Serviço) Use camadas de não produção ou infraestrutura transitória em ambientes mais baixos, como ambientes de desenvolvimento, implantações de prova de conceito e atividades de modelagem de custo inicial. Os custos de recursos são economizados para ambientes que podem permanecer úteis sem espelhar totalmente a configuração exata da produção ou os requisitos de tempo de atividade.
(Serviço) Expanda quando a demanda diminuir. Configure regras de dimensionamento automático ou outros processos automatizados para reduzir unidades quando a capacidade do gateway cair abaixo dos limites definidos. Os custos desnecessários são reduzidos pela capacidade correspondente à demanda.
(Serviço) Calcule as vantagens de custo de um modelo federado para gerenciamento de API usando workspaces para atender APIs e, ao mesmo tempo, fornecer isolamento de equipe. A superfície de implantação e gerenciamento é reduzida. Essa abordagem visa alcançar economias de escala a partir do tempo e compras de recursos.
(Serviço) Desative os espaços de trabalho quando eles não estiverem mais em uso. Os gastos com recursos não utilizados são evitados.
(Serviço) Use o cache interno se os dados armazenados em cache da sua carga de trabalho se encaixarem nas restrições do cache interno no seu nível. Os custos envolvidos na compra e manutenção de um cache externo compatível com Redis são evitados.
(Serviço) Bloqueie o tráfego mal-intencionado antes de chegar ao gateway usando controles de rede, proteção contra DDoS e firewalls de aplicativo Web. As camadas específicas do Gerenciamento de API são cobradas com base no número de solicitações HTTP que o gateway processa. Como resultado, o tráfego indesejável, como solicitações geradas por bot, pode aumentar os custos.

Avalie o custo do mecanismo de bloqueio em comparação com o custo estimado da redução da operação HTTP para avaliar se essa abordagem tem um ROI.		 As cobranças incorridas devido a operações HTTP mal-intencionadas ou incômodas excessivas contra o gateway são reduzidas.
(API) Otimize as expressões de política, o processamento e o código para evitar o uso excessivo de recursos de computação, como processador, rede ou memória. A implantação desnecessária de mais unidades para fornecer capacidade para implementações de políticas não otimizadas e código é evitada.
(API) Avalie o custo da colocação lógica entre o gateway, o back-end ou o ponto de entrada público, como o Azure Front Door. O mesmo processamento geralmente pode ocorrer em qualquer uma dessas camadas, cada uma com suas próprias compensações. No entanto, algumas camadas podem proporcionar economia de custos devido à capacidade não utilizada disponível nesse nível. Por exemplo, a lógica de cache originalmente implementada no back-end pode ser implementada de forma mais econômica no nível do gateway usando o cache interno. Essa abordagem reduz a sobrecarga extra de rede e computação em serviços de back-end. A carga em recursos de alto custo é minimizada colocando recursos na camada mais econômica. Essa abordagem desloca cargas de trabalho para camadas que têm capacidade de reposição ou opções de computação de menor custo.

Excelência operacional

A Excelência Operacional concentra-se principalmente em procedimentos relacionados às práticas de desenvolvimento , observabilidade e gerenciamento de lançamentos.

Os princípios de design da Excelência Operacional fornecem uma estratégia de design de alto nível para atingir essas metas para os requisitos operacionais da carga de trabalho.

Inicie sua estratégia de design com base na lista de verificação de revisão de design da Excelência Operacional para definir processos de observabilidade, teste e implantação relacionados ao Gerenciamento de API.

Lista de verificação de projeto

  • Examine os principais conhecimentos e habilidades necessários para operar o serviço: As áreas incluem ciclo de vida de API, processos de DevOps, rede e conectividade, monitoramento e observabilidade e desenvolvimento de software. Essa abordagem abrange a configuração de políticas, os testes unitários e a criação de pipelines de CI/CD.

  • Considere as necessidades de documentação: As organizações devem se comprometer a documentar processos para configuração no nível do serviço e no nível da API, operações de ciclo de vida e os diferentes padrões de acesso para as equipes de API.

  • Avalie as ferramentas padrão para dar suporte a operações de serviço. Por exemplo, adote métodos APIOps , como GitOps e CI/CD, para publicar APIs e gerenciar configurações de API. Use ferramentas de IaC para alterações de configuração no nível do serviço. Projete artefatos reutilizáveis que podem fazer a transição perfeita de ambientes de desenvolvimento para produção. Considere a integração de um linter como o Spectral, autogerenciado ou integrado a um serviço do Azure, como o Centro de API do Azure, em pipelines de aprovação de API.

  • Determine as principais métricas operacionais e logs: Examine as métricas de produção. Essas métricas incluem capacidade de gateway, uso da CPU, uso de memória e o número de solicitações. Examine os logs e as ferramentas de observabilidade, como o Azure Monitor e o Application Insights. Determine as estratégias e as ferramentas necessárias para gerenciar efetivamente grandes volumes de dados observacionais em ambientes de produção. Determine consultas que fornecem insights acionáveis para o operador de gateway e os stakeholders que monitoram APIs hospedadas específicas.

  • Planeje testes regulares de cargas de trabalho de produção usando testes de carga.

  • Identifique tarefas operacionais além dos processos de CI/CD ou IaC que exigem automação. Planeje a automação em áreas como gerenciamento de fonte de política de Gerenciamento de API, políticas do Azure e configurações específicas do portal do desenvolvedor.

Recomendações

Essas recomendações de excelência operacional podem se aplicar ao próprio serviço ou ao tráfego que flui por meio de APIs e suas políticas. Os designadores (Serviço) ou (API) indicam se uma recomendação tem como destino o serviço ou as APIs.

Recomendação Benefício
(Serviço) Configure Logs de recursos de diagnóstico do Azure para o Gerenciamento de API. Os logs gerados pela plataforma estão disponíveis para consulta para operações de rotina, necessidades sob demanda ou cenários urgentes, como auditorias de segurança.
(Serviço) Use a Grade de Eventos do Azure para automação com base em eventos significativos gerados pela instância de Gerenciamento de API, como APICreated. Tarefas de automação ou notificação podem ser criadas em torno dos principais eventos de ciclo de vida que ocorrem na instância de Gerenciamento de API.
(Serviço) Evite usar um gateway auto-hospedado se uma unidade de gateway hospedada pela Microsoft funcionar em seu cenário. Tarefas de automação ou notificação podem ser criadas em torno dos principais eventos de ciclo de vida que ocorrem na instância de Gerenciamento de API.
(Serviço) Aplique todas as políticas internas do Azure Policy que ajudam você a controlar sua instância e restringi-la para se alinhar aos requisitos de carga de trabalho, incluindo requisitos de segurança. Por exemplo, use políticas de negação para impedir que APIs sejam expostas por HTTP ou para impedir a habilitação da API REST de gerenciamento direto. Use políticas de auditoria se as políticas de negação não estiverem disponíveis ou crie políticas de negação personalizadas se isso for importante para sua carga de trabalho. A instância de Gerenciamento de API se alinha ao design e permanece alinhada à medida que a carga de trabalho evolui.
(Serviço) Familiarize-se com a funcionalidade Diagnosticar e resolver problemas no portal do Azure.

Use o painel de status da rede no portal para solucionar problemas de conectividade de rede.		 Os indivíduos de engenharia de confiabilidade do site podem identificar e solucionar problemas de desempenho, disponibilidade de serviço e conectividade de rede do gateway em todos os ambientes.
(API) Use o Hubs de Eventos para manipular logs ou fluxos de eventos de invocações de API que exigem reações quase em tempo real ou operações com janela de tempo curto. Disponibilidade quase em tempo real de entradas de log é fornecida. O atraso na ingestão de dados do log que ocorre ao registrar em log no Azure Monitor dentro de APIs é evitado.
(API) Dê suporte ao uso do rastreamento de API no desenvolvimento para ajudar os desenvolvedores a entender sua implementação de política. A produtividade do desenvolvedor é otimizada fornecendo insights sobre a implementação de políticas em uma API. Sem essa funcionalidade, os desenvolvedores precisam introduzir hacks na implementação de políticas para obter insights.
(API) Sempre defina back-ends usando o recurso de back-ends do Gerenciamento de API. Referencie esses back-ends por ID na política usando set-backend-service. Back-ends com balanceamento de carga devem ser definidos como um pool de back-end. As alterações de conexão de back-end se aplicam a todas as APIs que usam o back-end sem a necessidade de atualizações no código de política individual. O risco de configurações incorretas ou alterações de política de API ignoradas é reduzido e cenários em que várias APIs compartilham o mesmo back-end são adequados por meio dessa camada de abstração de configuração.
(API) Crie a abordagem de controle de versão de suas APIs para se alinhar com os recursos de controle de versão e revisão do Gerenciamento de API. Fatore essa abordagem em suas operações de implantação de API. Uma estratégia de versionamento de API integrada pelo API Management é usada para aproveitar as capacidades internas em vez de criar soluções personalizadas.
(Serviço &API) Defina um processo operacional consistente e sustentável para adicionar, modificar e excluir APIs. Determine se essa experiência deve ser gerenciada manualmente por meio do portal ou implementá-la por meio de um processo de APIOps. Prefira usar uma abordagem baseada em IaC em vez de uma abordagem baseada em portal.

A representação do Gerenciamento de API na API do Resource Manager consiste em muitos recursos filho, portanto, é importante adotar uma abordagem em camadas para o gerenciamento baseado em IaC dessa coleção de recursos.		 As especificações de API e suas implementações de gateway são integradas aos processos de controle de alteração da carga de trabalho. Essa abordagem impede o tratamento de alterações em APIs de back-end de forma diferente de como elas são expostas aos clientes de API por meio do gateway.

Eficiência de desempenho

Eficiência de desempenho significa manter a experiência do usuário mesmo quando há um aumento na carga por meio do gerenciamento da capacidade. A estratégia inclui dimensionamento de recursos, identificação e otimização de possíveis gargalos e otimização para o desempenho de pico.

Os princípios de design de eficiência de desempenho fornecem uma estratégia de design de alto nível para atingir essas metas de capacidade considerando o uso esperado.

Inicie sua estratégia de design com base na lista de verificação de revisão de design para Eficiência de Desempenho para definir uma linha de base com base nos principais indicadores de desempenho para o Gerenciamento de API.

Lista de verificação de projeto

  • Definir destinos de desempenho: As principais métricas para avaliar o desempenho do gateway de Gerenciamento de API incluem métricas de capacidade, como percentuais de uso de CPU e memória para infraestrutura de gateway, duração da solicitação e taxa de transferência de solicitação. Em implantações multirregionais, defina as metas de desempenho para cada região. O cliente precisa definir limites de dimensionamento apropriados com base em padrões de tráfego, cargas de trabalho de API e tempos de dimensionamento.

  • Coletar dados de desempenho: Examine os recursos de análise interna, métricas do Azure Monitor, logs do Azure Monitor, Application Insights e Hubs de Eventos para coletar e analisar o desempenho em diferentes níveis de granularidade.

  • Examine como identificar problemas de desempenho ao vivo: Os indicadores para problemas de desempenho ao vivo incluem disponibilidade do serviço do Azure, erros de resposta HTTP e erros gerados na seção Diagnosticar e resolver problemas no portal. Solucione problemas de desempenho e disponibilidade usando o Application Insights, consultas Kusto e recomendações do Diagnóstico de Gerenciamento de API no portal do Azure.

  • Desempenho do teste: Teste o desempenho em condições de produção usando o teste de carga.

  • Avalie os serviços adjacentes que podem melhorar o desempenho: Políticas de cache ou um cache externo podem melhorar o desempenho de operações de API específicas. O Azure Front Door e o Gateway de Aplicativo são opções comuns para descarregamento de TLS.

  • Examine os limites e restrições documentados: o Gerenciamento de API tem limites e restrições. Examine as restrições documentadas e compare-as com os requisitos da carga de trabalho para ver se você precisa criar uma solução que evite essas restrições.

Recomendações

Essas recomendações de eficiência de desempenho podem se aplicar ao próprio serviço ou ao tráfego que flui por meio de APIs e suas políticas. Os designadores (Serviço) ou (API) indicam se uma recomendação tem como destino o serviço ou as APIs.

Recomendação Benefício
(Serviço) Escalonável dinamicamente para atender à demanda. Configure regras de dimensionamento automático ou outros processos automatizados para ajustar as unidades do gateway para corresponder a uma capacidade de uso de destino. A elasticidade é obtida com base no uso simultâneo, o que impede o esgotamento de recursos de unidades implantadas no momento ou a alocação excessiva de capacidade.
(API) Minimize tarefas de processamento dispendiosas, como gerar grandes tamanhos de conteúdo em buffer, usando a política validate-content em corpos de solicitação grandes ou mantendo um alto número de WebSockets ativos. A carga nas unidades de escala é reduzida, o que permite processar mais solicitações simultaneamente antes de precisar expandir.
(Serviço &API) Coletar métricas de desempenho.

As métricas comuns de desempenho da API incluem:

– Solicitar tempo de processamento para o próprio gateway e para a operação completa.
- Métricas de uso de recursos da unidade de gateway.
- Medidas de taxa de transferência, como solicitações por segundo ou megabits por segundo.
- Taxa de ocorrência no cache.		 O desempenho real é medido em relação aos objetivos da carga de trabalho.
(Serviço &API) Defina um percentual de amostragem para o Application Insights que fornece visibilidade suficiente sem afetar o desempenho. As necessidades de dados de observabilidade são atendidas sem afetar o desempenho geral.
(Serviço &API) Avalie o impacto no desempenho do posicionamento lógico entre o gateway, o back-end ou o ponto de entrada público, como o Azure Front Door. As mesmas tarefas de processamento geralmente podem ocorrer em qualquer uma dessas camadas, com compensações de desempenho e limitações nas oportunidades de otimização para cada uma. Se uma tarefa, como uma política de API de gerenciamento de API, introduzir muita latência, considere se essa tarefa pode ser executada em outro lugar de uma maneira mais otimizada. As tarefas que adicionam latência às APIs são executadas na computação otimizada para atender aos requisitos de carga de trabalho.

Políticas do Azure

O Azure fornece um amplo conjunto de políticas internas relacionadas ao Gerenciamento de API e suas dependências. Algumas das recomendações anteriores podem ser auditadas por meio do Azure Policy. Por exemplo, você pode verificar se:

  • O gateway está configurado para redundância de zona.
  • Os controles de rede adequados estão implementados para o gateway de Gerenciamento de API, como a implantação em uma rede virtual.
  • Os pontos de extremidade de configuração do serviço não são acessíveis publicamente.
  • A API REST de Gerenciamento Direto está desabilitada.

Para governança abrangente, examine as definições internas do Azure Policy e outras políticas que podem afetar a segurança do gateway de Gerenciamento de API.

Recomendações do Assistente do Azure

O Assistente do Azure é um consultor de nuvem personalizado que ajuda você a seguir as práticas recomendadas para otimizar suas implantações do Azure.

Para obter mais informações, confira Assistente do Azure.

O consultor também pode exibir outras recomendações no sistema de produção, como:

  • Falha ao exigir tamanhos longos de chave JWT na política validate-jwt.
  • Você usou uma versão herdada da API do Resource Manager para implantar o recurso.
  • Os tokens de chave de API estão próximos da data de validade.
  • Falha em uma operação de rotação de certificado.

Compensações

Talvez você precise fazer compensações de design se usar as abordagens nas listas de verificação de pilares. Aqui estão alguns exemplos de vantagens e desvantagens.

Alta disponibilidade por meio de redundância e isolamento

  • Alta disponibilidade. Adicionar redundância a uma arquitetura afeta os custos. Por exemplo, provisionar pelo menos três unidades para evitar interrupções zonais pode não ser viável financeiramente para sua carga de trabalho. Os custos aumentam ainda mais com uma arquitetura de várias regiões, que exige pelo menos seis unidades ou três unidades por região. Uma configuração em várias regiões também abrange custos operacionais para coordenar implantações seguras, dimensionamento confiável e coordenação de contingência com os back-ends.

  • Isolamento. A isolação de cargas de trabalho entre os espaços de trabalho ou instâncias do Gerenciamento de API adiciona complexidade operacional, pois inclui o gerenciamento de um sistema multilocatário que tem isolamento de computação.

Escala para corresponder à demanda

  • Quando você expande para atender à demanda de clientes bem comportados, esses custos já estão incluídos nos seus modelos de custo. No entanto, essa funcionalidade de dimensionamento também permite que o serviço seja dimensionado para lidar com o tráfego de incômodo e tráfego mal-intencionado.

  • A mitigação de tráfego indesejado gera custos. Adicionar serviços como um firewall de aplicativo Web e proteção contra DDoS aumenta as despesas. Dimensionar seu serviço para lidar com o tráfego aumenta os custos devido a unidades adicionadas. Definir limites de dimensionamento superior pode limitar os gastos, mas pode resultar em problemas de confiabilidade para usuários legítimos se o tráfego mal-intencionado ou prejudicial sobrecarregar sua API.

Abordagem federada versus distribuída

Uma decisão fundamental no Gerenciamento de API é colocar cargas de trabalho diferentes em uma única instância de Gerenciamento de API ou isolar cargas de trabalho em várias instâncias em uma topologia totalmente autônoma.

Os espaços de trabalho do Gerenciamento de API permitem operações eficientes como uma plataforma de colocação multilocatária para várias equipes de API. Os modelos de preços em camadas são projetados para permitir que os custos de serviço sejam compartilhados entre todos os locatários que usam os gateways. No entanto, como qualquer plataforma de colocação, interrupções ou configurações incorretas podem resultar em efeitos generalizados em cargas de trabalho não relacionadas que compartilham a mesma infraestrutura.

Um modelo totalmente distribuído, em que cada equipe de carga de trabalho gerencia suas próprias instâncias, introduz custos duplicados e redundância em operações de rotina. No entanto, ele fornece mitigação de raio de explosão inerente para incidentes relacionados à confiabilidade, segurança e desempenho.

Próximas etapas

O Gerenciamento de API geralmente é combinado com os serviços a seguir. Examine os guias de serviço ou a documentação do produto se a carga de trabalho incluir os serviços a seguir.

Os artigos a seguir demonstram algumas das recomendações discutidas neste artigo.