Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
O Gerenciamento de API do Azure é um serviço totalmente gerenciado que ajuda as organizações a publicar, proteger, transformar, manter e monitorar APIs. Este artigo descreve os recursos de confiabilidade no Gerenciamento de API, incluindo resiliência intrarregional por meio de zonas de disponibilidade, implantações em várias regiões, redundância de zona de gateway e failover automático. Saiba como configurar esses recursos para obter alta disponibilidade e atender aos requisitos de SLA. Para obter uma visão geral mais detalhada da confiabilidade no Azure, consulte Confiabilidade do Azure.
O Gerenciamento de API fornece vários recursos de confiabilidade projetados para garantir alta disponibilidade e tolerância a falhas para sua infraestrutura de API. O serviço fornece redundância interna por meio de várias unidades de implantação, recursos de failover automático entre zonas de disponibilidade e opções de implantação em várias regiões para distribuição global de API. O Gerenciamento de API inclui roteamento inteligente de tráfego, monitoramento de integridade e mecanismos de repetição automática que ajudam a manter a continuidade do serviço mesmo durante falhas de infraestrutura ou cenários de alto tráfego.
A fiabilidade é uma responsabilidade partilhada entre o Cliente e a Microsoft. Você pode usar este guia para determinar quais opções de confiabilidade atendem aos seus objetivos de negócios específicos e metas de tempo de atividade.
Visão geral da arquitetura de confiabilidade
O Gerenciamento de API usa uma arquitetura baseada em unidade de escala para fornecer redundância e escalabilidade integradas. Ao implantar uma instância de Gerenciamento de API, você configura uma ou mais unidades de escala ou unidades. Cada unidade é uma representação lógica da capacidade que contém os recursos de computação necessários para lidar com solicitações de API.
Quando você configura uma instância com duas ou mais unidades, as unidades disponíveis trabalham juntas para processar solicitações e fornecer balanceamento automático de carga. Se uma das unidades ficar indisponível, as restantes unidades continuam a lidar com o tráfego, mas com capacidade potencialmente reduzida.
Para obter níveis mais altos de confiabilidade, o Gerenciamento de API oferece suporte à distribuição de unidades entre zonas de disponibilidade dentro de uma região e em várias regiões.
As camadas de serviço do Gerenciamento de API fornecem diferentes níveis de confiabilidade:
Nível Premium (clássico): Suporta várias unidades que podem ser distribuídas entre zonas de disponibilidade e regiões para máxima resiliência. Na camada Premium, cada unidade consiste em duas máquinas virtuais (VMs) que fornecem os recursos de computação para lidar com solicitações de API.
Níveis Basic v2, Standard, Standard v2 e Premium v2 (visualização): Todos suportam várias unidades dentro de um único datacenter. Eles não oferecem suporte a zonas de disponibilidade ou implantações em várias regiões.
Nível de desenvolvedor: Suporta apenas uma única unidade e não fornece zona de disponibilidade ou suporte a várias regiões. Essa camada foi projetada para cenários de desenvolvimento e teste. Não é adequado para cargas de trabalho de produção.
Nível de consumo: Tem recursos de resiliência internos e é resiliente a uma variedade de falhas em um único datacenter do Azure. No entanto, a camada Consumo não fornece suporte para zonas de disponibilidade ou implantações em várias regiões. Para entender o tempo de atividade esperado de uma instância de Gerenciamento de API de camada de consumo, revise o contrato de nível de serviço (SLA).
As unidades dentro de uma instância trabalham juntas para processar solicitações e balancear automaticamente a carga entre as unidades disponíveis. Se uma unidade ficar indisponível, as unidades restantes continuarão a lidar com o tráfego, mas com capacidade potencialmente reduzida.
Observação
As camadas Developer e Premium do Gerenciamento de API suportam gateways auto-hospedados, que você pode executar em sua própria infraestrutura. Ao usar gateways auto-hospedados, você é responsável por configurá-los para atender aos seus requisitos de confiabilidade. Os gateways auto-hospedados estão fora do escopo deste artigo.
Recomendações de implantação de produção
Para saber como implantar o Gerenciamento de API para dar suporte aos requisitos de confiabilidade da sua solução e como a confiabilidade afeta outros aspetos da sua arquitetura, consulte Práticas recomendadas de arquitetura para Gerenciamento de API no Azure Well-Architected Framework.
Falhas transitórias e políticas de repetição
Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.
Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.
Ao usar o Gerenciamento de API na frente de uma API, talvez seja necessário repetir solicitações que falham devido a falhas transitórias. Para proteger sua API de back-end de ser sobrecarregada por muitas solicitações, o Gerenciamento de API fornece políticas de repetição, limite de taxa e cota. Você também pode configurar os recursos de balanceamento de carga e disjuntor usando recursos de back-end.
Suporte à zona de disponibilidade
As zonas de disponibilidade são grupos fisicamente separados de datacenters dentro de cada região do Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
O Gerenciamento de API fornece dois tipos de suporte à zona de disponibilidade quando você implanta uma instância de Gerenciamento de API Premium (clássica) em uma região suportada:
Automático: O Gerenciamento de API fornece suporte automático à zona de disponibilidade quando você não especifica quais zonas de disponibilidade usar.
Manual: O Gerenciamento de API fornece suporte manual à zona de disponibilidade quando você especifica explicitamente quais zonas de disponibilidade usar.
Com suporte à zona de disponibilidade, o Gerenciamento de API replica componentes de serviço entre zonas para alta disponibilidade. Na região primária, esses componentes incluem o gateway (unidades de escala), o plano de gerenciamento e o portal do desenvolvedor. Em regiões secundárias, apenas as unidades de gateway são replicadas. Para obter mais informações sobre regiões secundárias, consulte Suporte a várias regiões.
Suporte automático à zona de disponibilidade
Você pode usar o suporte automático à zona de disponibilidade para escolher uma configuração de instância de unidade única ou de várias unidades para obter redundância de zona:
Configuração de várias unidades (Recomendado): Se sua instância tiver duas ou mais unidades, o Gerenciamento de API fará uma tentativa de melhor esforço para distribuir as unidades da instância entre as zonas de disponibilidade da região. Não há como determinar em quais zonas de disponibilidade suas unidades são colocadas. Recomendamos que você implante um mínimo de duas unidades, que podem ser distribuídas em duas zonas.
O diagrama a seguir mostra uma instância de Gerenciamento de API com três unidades configurada para suporte automático à zona de disponibilidade:
O diagrama mostra três caixas rotuladas como Unidade 1, Unidade 2 e Unidade 3 implantadas em uma instância de Gerenciamento de API. Cada caixa de unidade contém dois ícones que representam VMs. Três caixas maiores são rotuladas como Zona de Disponibilidade 1, Zona de Disponibilidade 2 e Zona de Disponibilidade 3. A zona 1 contém a unidade 1, a zona 2 contém a unidade 2 e a zona 3 contém a unidade 3.
Configuração de unidade única: Se sua instância tiver uma única unidade, as VMs subjacentes da unidade serão distribuídas para duas zonas de disponibilidade. Não é possível determinar em quais zonas de disponibilidade as VMs da unidade são colocadas.
O diagrama mostra uma caixa rotulada como Unidade 1 implantada em uma instância de Gerenciamento de API. A caixa de unidade contém dois ícones que representam VMs. Três caixas maiores são rotuladas como Zona de Disponibilidade 1, Zona de Disponibilidade 2 e Zona de Disponibilidade 3. A caixa da Unidade 1 abrange as zonas 1 e 2. A zona 3 está vazia.
Suporte manual para zona de disponibilidade
Se pretender selecionar explicitamente as zonas de disponibilidade a serem utilizadas, pode optar entre configurações com zona redundante e zonais.
Zona redundante: Configure manualmente a redundância de zona para uma instância de Gerenciamento de API em uma região suportada para fornecer redundância para componentes de serviço. Quando você seleciona duas ou mais zonas de disponibilidade para usar, o Azure replica automaticamente os componentes de serviço nas zonas selecionadas.
O diagrama mostra três caixas rotuladas como Unidade 1, Unidade 2 e Unidade 3 implantadas em uma instância de Gerenciamento de API. Cada caixa de unidade contém dois ícones que representam VMs. Três caixas maiores são rotuladas como Zona de Disponibilidade 1, Zona de Disponibilidade 2 e Zona de Disponibilidade 3. A zona 1 contém a unidade 1, a zona 2 contém a unidade 2 e a zona 3 contém a unidade 3.
Zonal: Os componentes do serviço Gerenciamento de API são implantados em uma única zona selecionada dentro de uma região do Azure. Todas as unidades são colocadas na mesma zona de disponibilidade.
O diagrama mostra duas caixas rotuladas como Unidade 1 e Unidade 2 implantadas em uma instância de Gerenciamento de API. Cada caixa de unidade contém dois ícones que representam VMs. Três caixas maiores são rotuladas como Zona de Disponibilidade 1, Zona de Disponibilidade 2 e Zona de Disponibilidade 3. A Zona 1 contém as caixas da Unidade 1 e da Unidade 2. A Zona 2 e a Zona 3 não contêm unidades.
Importante
Afixe em uma única zona de disponibilidade somente se a latência entre zonas for muito alta para as suas necessidades e depois de verificar que a latência não atende aos seus requisitos. Por si só, uma instância zonal não fornece resiliência a uma interrupção da zona de disponibilidade. Para melhorar a resiliência de uma implantação zonal de Gerenciamento de API, você precisa implantar explicitamente instâncias separadas em várias zonas de disponibilidade e configurar o roteamento e failover de tráfego.
Suporte de região
O Gerenciamento de API dá suporte a zonas de disponibilidade para a camada Premium (clássica) em todas as regiões do Azure que oferecem suporte a zonas de disponibilidade.
Requerimentos
Você deve usar a camada Premium (clássica) para configurar o suporte à zona de disponibilidade. Atualmente, o Gerenciamento de API não oferece suporte a zonas de disponibilidade nas camadas clássicas Consumo, Desenvolvedor, Básico e Standard ou nas camadas Básico v2, Standard v2 e Premium v2. Para atualizar sua instância para a camada Premium (clássica), consulte Atualizar para a camada Premium.
Observação
O nível Premium v2 com capacidades empresariais está em pré-visualização. Para determinar se seu design deve depender de recursos de acesso antecipado ou recursos geralmente disponíveis, avalie seus cronogramas de projeto e implementação em relação às informações disponíveis sobre os caminhos de lançamento e migração do Premium v2.
Considerações
Número de unidades para instâncias redundantes de zona: Se você configurar manualmente a redundância de zona para uma instância, também precisará configurar várias unidades de gerenciamento de API que podem ser distribuídas uniformemente em todas as zonas de disponibilidade selecionadas. Por exemplo, se você selecionar duas zonas, deverá configurar pelo menos duas unidades. Em vez disso, você pode configurar quatro unidades ou outro múltiplo de duas unidades. Se você selecionar três zonas de disponibilidade, deverá configurar três unidades, seis unidades ou outro múltiplo de três unidades.
Se você usar o suporte à zona de disponibilidade automática, não há necessidade de usar um número específico de unidades. As unidades que você implanta são distribuídas entre as zonas de disponibilidade com o melhor esforço possível. Para redundância máxima de zona, recomendamos que você use pelo menos duas unidades para garantir que uma interrupção na zona de disponibilidade não afete sua instância.
Para determinar o número de unidades que proporcionam o desempenho de gateway necessário, use as métricas de capacidade e os seus próprios testes. Para obter mais informações sobre como dimensionar e atualizar sua instância de serviço, consulte Atualizar e dimensionar uma instância de gerenciamento de API.
Dimensionamento automático: Se você configurar manualmente as zonas de disponibilidade em uma instância de Gerenciamento de API configurada com dimensionamento automático, talvez seja necessário ajustar as configurações de dimensionamento automático após a configuração. Nesse caso, o número de unidades de gerenciamento de API em regras e limites de dimensionamento automático deve ser um múltiplo do número de zonas. Se você usar o suporte à zona de disponibilidade automática, não precisará ajustar as configurações de dimensionamento automático.
Requisitos de endereço IP: Ao habilitar o suporte à zona de disponibilidade em uma instância de Gerenciamento de API implantada em uma rede virtual externa ou interna, você deve especificar um recurso de endereço IP público para a instância a ser usada. Em uma rede virtual interna, o endereço IP público é usado apenas para operações de gerenciamento, não para solicitações de API. Para obter mais informações, consulte Endereços IP no Gerenciamento de API.
Custo
Independentemente da configuração da zona de disponibilidade, se adicionar mais unidades, incorrerá em mais custos. Para obter informações, consulte Preços de gerenciamento de API.
Configurar o suporte à zona de disponibilidade
Esta seção explica como configurar o suporte à zona de disponibilidade para sua instância de Gerenciamento de API.
Observação
Quando você seleciona quais zonas de disponibilidade usar, na verdade está selecionando a zona de disponibilidade lógica. Se você implantar outros componentes de carga de trabalho em uma assinatura diferente do Azure, eles poderão usar um número de zona de disponibilidade lógica diferente para acessar a mesma zona de disponibilidade física. Para obter mais informações, consulte Zonas de disponibilidade física e lógica.
Crie uma instância de Gerenciamento de API que ofereça suporte a zonas de disponibilidade: Quando você cria uma instância de Gerenciamento de API Premium (clássica) em uma região que oferece suporte a zonas de disponibilidade, a instância oferece suporte a zonas de disponibilidade por padrão. Você pode selecionar o suporte da zona de disponibilidade automática ou configurar manualmente o suporte zonal ou zona-redundante.
Habilite ou reconfigure o suporte à zona de disponibilidade: Você pode alterar a configuração da zona de disponibilidade para uma instância de Gerenciamento de API, incluindo a adição de zonas de disponibilidade e a movimentação de uma instância zonal entre zonas de disponibilidade. Para saber como configurar o suporte à zona de disponibilidade em uma instância de Gerenciamento de API, consulte Habilitar o suporte à zona de disponibilidade em instâncias de Gerenciamento de API. Não há requisitos de tempo de inatividade para nenhuma das opções de configuração.
Quando você altera a configuração da zona de disponibilidade, as alterações podem levar de 15 a 45 minutos ou mais para serem aplicadas. O gateway de Gerenciamento de API pode continuar a lidar com solicitações de API durante esse período.
A alteração da configuração da zona de disponibilidade aciona uma alteração de endereço IP público e privado.
Planejamento e gerenciamento de capacidade
Em um cenário de zone-down, não há garantia de que as solicitações de mais capacidade em outra zona de disponibilidade serão bem-sucedidas. O enchimento de unidades perdidas ocorre da melhor forma possível. Se precisar de capacidade garantida quando uma zona de disponibilidade falhar, crie e configure sua instância de Gerenciamento de API para contabilizar a perda de uma zona executando todas as seguintes ações:
Provisione além do necessário as unidades da sua instância de Gestão de API.
Use a configuração automática ou redundante da zona de disponibilidade.
Para obter mais informações, consulte Gerenciar a capacidade com provisionamento excessivo.
Use métricas de capacidade e seus próprios testes para determinar o número de unidades que fornecem o desempenho de gateway necessário. Para obter mais informações sobre como dimensionar e atualizar sua instância de serviço, consulte Atualizar e dimensionar uma instância de gerenciamento de API.
Funcionamento normal
Esta seção descreve o que esperar quando as instâncias de Gerenciamento de API são configuradas com suporte à zona de disponibilidade e todas as zonas de disponibilidade estão operacionais.
Roteamento de tráfego entre zonas: Durante as operações normais, o tráfego é roteado entre todas as unidades de gerenciamento de API disponíveis em todas as zonas de disponibilidade selecionadas.
Replicação de dados entre zonas: O Gerenciamento de API armazena e replica os dados a seguir.
A configuração do gateway, como APIs e definições de política, é sincronizada regularmente entre as zonas de disponibilidade selecionadas para a instância. A propagação de atualizações entre as zonas de disponibilidade normalmente leva menos de 10 segundos.
Dados no cache interno, se você usar o cache interno fornecido pelo Gerenciamento de API. As entradas de cache são distribuídas entre zonas de disponibilidade. O cache interno é volátil e não é garantido que os dados sejam persistentes. Considere o uso de um cache externo se precisar persistir os dados armazenados em cache.
Contadores de limite de taxa, se você usar os recursos de limitação de taxa fornecidos pelo Gerenciamento de API. Os contadores de limite de taxa são replicados de forma assíncrona entre as zonas de disponibilidade selecionadas para a instância.
Experiência de redução de zona
Esta seção descreve o que esperar quando as instâncias de Gerenciamento de API são configuradas com suporte à zona de disponibilidade e há uma interrupção da zona de disponibilidade.
Deteção e resposta: A responsabilidade pela deteção e resposta depende da configuração da zona de disponibilidade usada pela instância.
Automático e com redundância de zona: Para instâncias configuradas para usar o suporte automático à zona de disponibilidade ou configuradas manualmente para usar redundância de zona, a plataforma de Gerenciamento de API é responsável por detetar uma falha em uma zona de disponibilidade e responder. Você não precisa fazer nada para iniciar um failover de zona.
Zonal: Para instâncias configuradas para serem zonais, você precisa detetar a perda de uma zona de disponibilidade e iniciar um failover para uma instância secundária criada em outra zona de disponibilidade.
Solicitações ativas: Quando uma zona de disponibilidade não está disponível, todas as solicitações em andamento conectadas a uma unidade de Gerenciamento de API na zona de disponibilidade defeituosa são encerradas e precisam ser repetidas.
Notificação: o Gerenciamento de API do Azure não notifica você quando uma zona está inativa. No entanto, você pode usar a Integridade dos Recursos do Azure para monitorar a integridade do seu gateway. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço de Gerenciamento de API do Azure, incluindo quaisquer falhas de zona.
Configure alertas nesses serviços para receber notificações de problemas no nível da zona. Para obter mais informações, consulte Criar alertas de Integridade do Serviço no portal do Azure e Criar e configurar alertas de Integridade de Recursos.
Perda de dados esperada: O Gerenciamento de API armazena os seguintes dados.
Alterações na configuração do gateway, que são replicadas para cada zona de disponibilidade selecionada em aproximadamente 10 segundos. Se ocorrer uma interrupção de uma zona de disponibilidade, você poderá perder as alterações de configuração que não são replicadas.
Dados no cache interno, se você usar o recurso de cache interno. O cache interno é volátil e não é garantido que os dados sejam persistentes. Durante uma interrupção da zona de disponibilidade, você pode perder alguns ou todos os dados armazenados em cache. Considere o uso de um cache externo se precisar persistir os dados armazenados em cache.
Contadores de limitação de taxa, se utilizar a funcionalidade de limitação de taxa. Durante uma interrupção da zona de disponibilidade, os contadores de limite de taxa podem não estar up-todata nas zonas sobreviventes.
Tempo de inatividade esperado: O tempo de inatividade esperado depende da configuração da zona de disponibilidade usada pela instância.
Automático: Você pode esperar que as instâncias que usam o suporte automático à zona de disponibilidade não tenham tempo de inatividade durante uma interrupção da zona de disponibilidade. As unidades na zona ou zonas não afetadas continuam a funcionar.
Você também pode esperar que as instâncias que usam o suporte automático à zona de disponibilidade, mas têm uma única unidade, não tenham tempo de inatividade. Nesse caso, o Gerenciamento de API distribui as VMs subjacentes da unidade para duas zonas. A VM na zona não afetada continua a funcionar.
Zona redundante: Você pode esperar que as instâncias com redundância de zona não sofram interrupções durante uma falha na zona de disponibilidade.
Zonal: Para instâncias zonais, quando uma zona não está disponível, sua instância fica indisponível até que a zona de disponibilidade se recupere.
Reencaminhamento do tráfego: O comportamento de redirecionamento de tráfego depende da configuração da zona de disponibilidade usada pela instância.
Automático e com redundância de zona: Para instâncias configuradas para usar o suporte automático à zona de disponibilidade ou configuradas manualmente para usar redundância de zona, quando uma zona não está disponível, todas as unidades na zona afetada também ficam indisponíveis. Você pode optar por dimensionar sua instância para adicionar mais unidades.
Zonal: Para instâncias zonais, quando uma zona não está disponível, sua instância não está disponível. Se você tiver uma instância secundária em outra zona de disponibilidade, será responsável por redirecionar o tráfego para essa instância secundária.
Recuperação de zona
O comportamento de recuperação de zona depende da configuração da zona de disponibilidade usada pela instância.
Automático e com redundância de zona: Para instâncias configuradas para usar o suporte automático à zona de disponibilidade ou configuradas manualmente para usar redundância de zona, quando a zona de disponibilidade se recupera, o Gerenciamento de API restaura automaticamente as unidades na zona de disponibilidade e redireciona o tráfego entre as unidades normalmente.
Zonal: Para instâncias zonais, você é responsável por redirecionar o tráfego para a instância na zona de disponibilidade original após a recuperação da zona de disponibilidade.
Testagem para falhas de zona
As opções para testar falhas de zona dependem da configuração da zona de disponibilidade usada pela instância.
Automático e com redundância de zona: Para instâncias configuradas para usar suporte automático à zona de disponibilidade ou configuradas manualmente para usar redundância de zona, a plataforma de Gestão de API gere o roteamento de tráfego, assim como os processos de failover (mudança automática para outra zona) e failback (retorno à zona original). Esse recurso é totalmente gerenciado, portanto, você não precisa iniciar ou validar processos de falha na zona de disponibilidade.
Zonal: Para instâncias zonais, não há como simular uma interrupção da zona de disponibilidade que contém sua instância de Gerenciamento de API. No entanto, é possível configurar manualmente os gateways upstream ou os balanceadores de carga para redirecionar o tráfego para uma instância diferente numa zona de disponibilidade diferente.
Suporte multi-região
Com uma implantação de 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 implantação em várias regiões ajuda a reduzir qualquer latência de solicitação percebida pelos consumidores de API distribuídos geograficamente. Uma implantação em várias regiões também melhora a disponibilidade do serviço se uma região ficar offline.
O Gerenciamento de API só suporta implantações em várias regiões na camada Premium (clássica). Ele não suporta implantações de várias regiões nas camadas Consumo, Desenvolvedor, Básico, Básico v2, Padrão, Standard v2 e Premium v2 (visualização). Para obter mais informações, consulte Requisitos.
Ao adicionar uma região, você configura:
O número de unidades que a região hospeda.
Suporte à zona de disponibilidade, se essa região fornecer zonas de disponibilidade.
Configurações de rede virtual na região adicionada, se a rede estiver configurada na região ou regiões existentes.
Suporte de região
Você pode criar implantações de várias regiões na camada Premium (clássica) com qualquer região do Azure que ofereça suporte ao Gerenciamento de API. Para ver quais regiões oferecem suporte a implantações em várias regiões, consulte Disponibilidade do produto por região.
Requerimentos
Você deve usar a camada Premium (clássica) para configurar o suporte a várias regiões. Para atualizar sua instância para a camada Premium (clássica), consulte Atualizar para a camada Premium.
Observação
O nível Premium v2 com capacidades empresariais está em pré-visualização. Para determinar se seu design deve depender de recursos de acesso antecipado ou recursos geralmente disponíveis, avalie seus cronogramas de projeto e implementação em relação às informações disponíveis sobre os caminhos de lançamento e migração do Premium v2.
Considerações
Apenas gateway: 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 onde você implantou originalmente o serviço.
Requisitos de rede: 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 rede virtual e a região da sub-rede deverão corresponder ao local secundário que você configurar. Se você adicionar, remover ou habilitar a zona de disponibilidade na região primária, ou se alterar a sub-rede da região primária, o endereço IP virtual (VIP) da sua instância de Gerenciamento de API será alterado. Para obter mais informações, consulte Alterações em endereços IP. No entanto, se você adicionar 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.
Nomes DNS (Sistema de Nomes de Domínio): 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
.
Custo
Adicionar regiões implica custos. Para obter informações, consulte Preços de gerenciamento de API.
Configurar suporte a várias regiões
Para configurar o suporte a várias regiões em uma instância de Gerenciamento de API, consulte Implantar uma instância de Gerenciamento de API em várias regiões do Azure.
Para remover uma região de uma instância de Gerenciamento de API, consulte Remover uma região de serviço de Gerenciamento de API.
Planejamento e gerenciamento de capacidade
Em um cenário de região inativa, não há garantia de que as solicitações de mais capacidade em outra região serão bem-sucedidas. Se precisar de capacidade garantida quando uma região falhar, crie e configure sua instância de Gerenciamento de API para contabilizar a perda de uma região. Você pode fazer isso provisionando excessivamente a capacidade de sua instância de Gerenciamento de API. Para saber mais sobre o princípio do provisionamento excessivo, consulte Gerenciar a capacidade com provisionamento excessivo.
Em implantações de várias regiões, o dimensionamento automático se aplica apenas à região primária. As regiões secundárias exigem ajustes manuais de dimensionamento ou ferramentas personalizadas que você controla.
Funcionamento normal
Esta seção descreve o que esperar quando as instâncias de Gerenciamento de API são configuradas com suporte a várias regiões e todas as regiões estão operacionais.
Roteamento de tráfego entre regiões: O Gerenciamento de API roteia automaticamente as solicitações de entrada para um gateway regional. Uma solicitação é roteada para o gateway regional com a menor latência do cliente. Se precisar usar uma abordagem de roteamento diferente, você pode configurar seu próprio Gerenciador de Tráfego com regras de roteamento personalizadas. Para obter mais informações, consulte Usar roteamento personalizado para gateways regionais de Gerenciamento de API.
Quando uma solicitação chega a um gateway regional de Gerenciamento de API, ela é roteada para a API de back-end, a menos que uma política retorne uma resposta diretamente do gateway, como uma resposta em cache ou um código de erro. Em uma solução de várias regiões, você precisa ter o cuidado de rotear para uma instância da API de back-end que atenda aos seus requisitos de desempenho. Para obter mais informações, consulte Rotear chamadas de API para serviços de back-end regionais.
Replicação de dados entre regiões: A configuração do gateway, como APIs e definições de política, é sincronizada regularmente entre as regiões primária e secundária adicionadas. A propagação de atualizações para os gateways regionais normalmente leva menos de 10 segundos.
Os contadores de limite de taxa e os dados no cache interno são específicos da região, portanto, não são replicados entre regiões.
Experiência de redução na região
Esta seção descreve o que esperar quando as instâncias de Gerenciamento de API são configuradas com suporte a várias regiões e há uma interrupção em uma das regiões que você usa.
Deteção e resposta: O Gerenciamento de API é responsável por detetar uma falha em uma região e fazer failover automaticamente para um gateway em uma das outras regiões que você configurar.
Solicitações ativas: Todas as solicitações ativas que estão sendo processadas na região defeituosa podem ser descartadas e devem ser repetidas pelo cliente.
Perda de dados esperada: O Gerenciamento de API não armazena dados, exceto para configuração, cache e contadores de limite de taxa.
As alterações de configuração são replicadas para cada região em aproximadamente 10 segundos. Se ocorrer uma interrupção da região principal, você poderá perder as alterações de configuração que não são replicadas.
Os contadores de limite de taxa e os dados no cache interno são específicos da região, portanto, não são replicados entre regiões.
Tempo de inatividade esperado: Nenhum tempo de inatividade do gateway é esperado.
Se a região primária ficar offline, o plano de gestão de API e o portal do desenvolvedor ficarem indisponíveis, as regiões secundárias ainda continuarão a atender solicitações de API usando a configuração mais recente do gateway.
Reencaminhamento do tráfego: Se uma região ficar offline, as solicitações de API serão automaticamente roteadas pela região com falha para o gateway mais próximo.
Recuperação da região
Quando a região principal se recupera, o Gerenciamento de API restaura automaticamente as unidades na região e redireciona o tráfego entre as unidades.
Testes para detetar falhas na região
Para estar pronto para interrupções inesperadas na região, recomendamos que você teste regularmente suas respostas a falhas de região. Você pode simular alguns aspetos de uma falha de região desabilitando o roteamento para um gateway regional.
Cópias de segurança
O Gerenciamento de API não armazena a maioria dos dados de tempo de execução. No entanto, você pode fazer backup da configuração do serviço de Gerenciamento de API. Você também pode usar operações de backup e restauração para replicar configurações de serviço de Gerenciamento de API entre ambientes operacionais, por exemplo, desenvolvimento e preparação.
Importante
Em um procedimento de backup, dados de tempo de execução, como usuários e assinaturas, são incluídos, o que nem sempre é desejável.
O backup é suportado nas camadas Developer, Basic, Standard e Premium.
Para obter mais informações, consulte Como implementar a recuperação de desastres usando o backup e a restauração do serviço no Gerenciamento de API.
Para backup ou restauração de alguns componentes ou recursos de serviço, você também pode considerar opções gerenciadas pelo cliente, como ferramentas APIOps e soluções de infraestrutura como código (IaC).
Fiabilidade durante a manutenção do serviço
O Gerenciamento de API realiza atualizações regulares de serviços e outras formas de manutenção.
Nas camadas Basic, Standard e Premium (clássico), você pode personalizar quando no processo de atualização sua instância recebe uma atualização. Se você precisar validar o efeito das atualizações em sua carga de trabalho, considere configurar uma instância de teste para receber atualizações no início de um ciclo de atualização e defina sua instância de produção para receber atualizações no final do ciclo. Você também pode especificar uma janela de manutenção, que é a hora do dia em que você deseja que a instância aplique atualizações de serviço.
Para obter mais informações, consulte Definir configurações de atualização de serviço para suas instâncias de Gerenciamento de API.
Contrato de nível de serviço
O SLA para Gerenciamento de API descreve a disponibilidade esperada do serviço. Descreve igualmente as condições que devem ser satisfeitas para atingir essa expectativa de disponibilidade. Para entender essas condições, é importante que você revise os SLAs para serviços online.
Quando você implanta uma instância de Gerenciamento de API em várias zonas ou regiões de disponibilidade, a porcentagem de tempo de atividade definida no SLA aumenta.
O serviço fornece seu próprio SLA, mas você também precisa levar em conta a confiabilidade prevista de outros componentes da carga de trabalho, como os back-ends da API.
Conteúdo relacionado
- Recuperação de desastres e continuidade de negócios para gerenciamento de API
- Usar zonas de disponibilidade no Gerenciamento de API
- Implantação multirregional do Gerenciamento de API
- Monitorar o gerenciamento de API
- Planejamento de capacidade de gerenciamento de API
- Práticas recomendadas de arquitetura para gerenciamento de API