Garanta a disponibilidade e a confiabilidade do Gerenciamento de API
APLICA-SE A: Premium
Este artigo é uma visão geral dos recursos de serviço para garantir que sua instância de Gerenciamento de API continue a atender solicitações de API se ocorrerem interrupções do Azure.
O Gerenciamento de API oferece os seguintes recursos para soluções confiáveis e resilientes do Azure. Utilize-os individualmente ou em conjunto para aumentar a disponibilidade:
Zonas de disponibilidade: resiliência a interrupções no nível do datacenter
Implantação multirregional: resiliência a interrupções regionais
Nota
- As zonas de disponibilidade e a implantação em várias regiões são suportadas na camada Premium .
- Para configuração, consulte Migrar o gerenciamento de API para o suporte à zona de disponibilidade e Implantar o gerenciamento de API em várias regiões.
Zonas de disponibilidade
As zonas de disponibilidade do Azure são locais fisicamente separados dentro de uma região do Azure que são tolerantes a falhas no nível do datacenter. Cada zona é composta por um ou mais datacenters equipados com infraestrutura independente de energia, refrigeração e rede. Para garantir a resiliência, um mínimo de 3 zonas de disponibilidade separadas estão presentes em todas as regiões habilitadas para zona de disponibilidade. Mais informações
Habilitar a redundância de zona para uma instância de Gerenciamento de API em uma região suportada fornece redundância para todos os componentes de serviço: gateway, plano de gerenciamento e portal do desenvolvedor. O Azure replica automaticamente todos os componentes de serviço nas zonas selecionadas.
Ao habilitar a redundância de zona em uma região, considere o número de unidades de escala do Gerenciamento de API que precisam ser distribuídas. No mínimo, configure o mesmo número de unidades que o número de zonas de disponibilidade, ou um múltiplo para que as unidades sejam distribuídas uniformemente pelas zonas. Por exemplo, se você selecionar 3 zonas de disponibilidade em uma região, poderá ter 3 unidades para que cada zona hospede uma unidade.
Nota
Use métricas de capacidade e seus próprios testes para decidir o número de unidades de escala que fornecerão o desempenho do gateway para suas necessidades. Saiba mais sobre como dimensionar e atualizar sua instância de serviço.
Implementação em várias regiões
Com a implantação em várias regiões, você pode adicionar gateways de API regionais a uma instância de Gerenciamento de API existente em uma ou mais regiões do Azure com suporte. A implementação em várias regiões ajuda a reduzir a latência de pedidos detetada pelos consumidores de API distribuídas geograficamente e melhora a disponibilidade do serviço se uma região ficar offline.
Somente o componente de gateway da instância de Gerenciamento de API é replicado para várias regiões. O plano de gerenciamento da instância e o portal do desenvolvedor permanecem hospedados apenas na região primária , a região onde você implantou originalmente o serviço.
Se você quiser configurar um local secundário para sua instância de Gerenciamento de API quando ela for implantada (injetada) em uma rede virtual, a região de rede virtual e sub-rede deverá corresponder ao local secundário que você está configurando. Se você estiver adicionando, removendo ou habilitando a zona de disponibilidade na região primária, ou se estiver alterando a sub-rede da região primária, o endereço VIP da sua instância de Gerenciamento de API será alterado. Para obter mais informações, consulte Endereços IP do serviço de Gerenciamento de API do Azure. No entanto, se você estiver adicionando uma região secundária, o VIP da região primária não será alterado porque cada região tem seu próprio VIP privado.
As configurações do gateway, como as APIs e as definições de política, são sincronizadas regularmente entre as regiões primárias e secundárias que adicionar. A propagação de atualizações para os gateways regionais normalmente leva menos de 10 segundos. A implementação em várias regiões fornece disponibilidade do gateway de API em mais do que uma região e fornece disponibilidade de serviço se uma região ficar offline.
Quando o Gerenciamento de API recebe solicitações HTTP públicas para o ponto de extremidade do gerenciador de tráfego (aplica-se aos modos VNet externo e não conectado em rede do Gerenciamento de API), o tráfego é roteado para um gateway regional com base na latência mais baixa, o que pode reduzir a latência experimentada pelos consumidores de API distribuídos geograficamente. No modo VNet interno, os clientes devem configurar sua própria solução para rotear e balancear a carga do tráfego entre os gateways regionais. Para obter detalhes, consulte Considerações sobre rede.
O gateway em cada região (incluindo a região primária) tem um nome DNS regional que segue o padrão de URL de
https://<service-name>-<region>-01.regional.azure-api.net
, por exemplohttps://contoso-westus2-01.regional.azure-api.net
.Se uma região ficar offline, os pedidos de API são automaticamente encaminhados em torno da região que falhou para o gateway mais próximo seguinte.
Se a região primária ficar offline, o plano de gestão da Gestão de API e o portal do programador ficam indisponíveis, mas as regiões secundárias continuam a fornecer pedidos de API com a configuração de gateway mais recente.
Combine zonas de disponibilidade e implantação em várias regiões
A combinação de zonas de disponibilidade para redundância dentro de uma região e implantações em várias regiões para melhorar a disponibilidade do gateway se houver uma interrupção regional ajuda a melhorar a confiabilidade e o desempenho da sua instância de Gerenciamento de API.
Exemplos:
Usar zonas de disponibilidade para melhorar a resiliência da região primária em uma implantação de várias regiões
Distribua unidades de escala entre zonas de disponibilidade e regiões para melhorar o desempenho do gateway regional
Considerações sobre SLA
O Gerenciamento de API fornece um SLA de 99,99% quando você implanta pelo menos uma unidade em duas ou mais zonas ou regiões de disponibilidade. Para obter mais informações, veja os Preços.
Nota
Enquanto o Azure se esforça continuamente para obter a maior resiliência possível no SLA para a plataforma de nuvem, você deve definir seus próprios SLAs de destino para outros componentes de sua solução.
Disponibilidade de back-end
Dependendo de onde e como seus serviços de back-end estão hospedados, talvez seja necessário configurar back-ends redundantes em diferentes regiões para atender aos seus requisitos de disponibilidade de serviço. Você também pode configurar propriedades de back-end para melhorar a resiliência e a disponibilidade de seus serviços de back-end.
Backends regionais
Você pode gerenciar back-ends regionais e lidar com failover por meio do Gerenciamento de API para manter a disponibilidade. Por exemplo:
Em implantações de várias regiões, use políticas para rotear solicitações por meio de gateways regionais para back-ends regionais.
Configure políticas para rotear solicitações condicionalmente para backends diferentes se houver falha de back-end em uma região específica.
Use o cache para reduzir chamadas com falha.
Para obter detalhes, consulte a postagem de blog Redundância de API de back-end com o Gerenciador de API do Azure.
Configurar propriedades de back-end para disponibilidade
As entidades de back-end do Gerenciamento de API permitem gerenciar e aplicar propriedades de back-end para melhorar a disponibilidade de back-ends. Por exemplo:
- Distribuir e balancear a carga do tráfego para um pool de URLs
- Configurar regras de disjuntor para aplicar o padrão de disjuntor para proteger o back-end de muitas solicitações
Próximos passos
- Saiba mais sobre a fiabilidade no Azure
- Saiba mais sobre como criar aplicativos confiáveis do Azure
- Leia Gerenciamento de API e confiabilidade no Azure Well-Architected Framework