Confiabilidade no Gerenciamento de API do Azure

Gerenciamento de API do Azure. é um serviço totalmente gerenciado que ajuda as organizações a publicar, proteger, transformar, manter e monitorar APIs. Como um serviço do Azure, o Gerenciamento de API fornece uma variedade de recursos para dar suporte aos seus requisitos de confiabilidade.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Gerenciamento de API resiliente a uma variedade de possíveis interrupções e problemas, incluindo falhas transitórias, interrupções de zona de disponibilidade, interrupções de região e manutenção do serviço. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e realça algumas informações importantes sobre o SLA (contrato de nível de serviço) de Gerenciamento de API.

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 de carga automático. Se uma das unidades ficar indisponível, as unidades restantes continuarão 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 em zonas de disponibilidade dentro de uma região e em várias regiões.

Os níveis de serviço de Gerenciamento de API fornecem diferentes níveis de confiabilidade:

• Nível Premium (clássico): oferece suporte a diversas unidades que podem ser distribuídas entre zonas de disponibilidade e regiões para máxima resiliência. No nível 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 Básico v2, Padrão, Padrão v2 e Premium v2 (prévia): Todos oferecem suporte a várias unidades em um único datacenter. Eles não oferecem suporte a zonas de disponibilidade ou implantações multirregionais.

• Nível de desenvolvedor: Suporta apenas uma única unidade e não fornece zona de disponibilidade ou suporte multirregional. Essa camada foi projetada para cenários de desenvolvimento e teste. Não é adequado para cargas de trabalho de produção.

• Camada de consumo: possui recursos de resiliência integrados e é resiliente a uma série de falhas em um único datacenter do Azure. No entanto, o nível de Consumo não oferece suporte para zonas de disponibilidade ou implantações multirregionais. Para entender o tempo de atividade esperado de uma instância de Gerenciamento de API da 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.

Recomendações de implantação de produção

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, desempenho, segurança, custo e operações. Para entender como essas áreas influenciam umas às outras e contribuem para uma solução confiável de Gerenciamento de API, consulte as práticas recomendadas de arquitetura para o Gerenciamento de API.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para 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 backend de ser sobrecarregada por muitas solicitações, o Gerenciamento de API fornece políticas de nova tentativa, limite de taxa e cota. Você também pode configurar recursos de balanceamento de carga e disjuntor usando recursos de backend.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

O Gerenciamento de API fornece dois tipos de suporte de zona de disponibilidade quando você implanta uma instância de Gerenciamento de API Premium (clássica) em uma região com suporte:

• 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 em todas as 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, somente as unidades de gateway são replicadas. Para obter mais informações sobre regiões secundárias, consulte resiliência a falhas em toda a região.

Suporte automático de zona de disponibilidade

Você pode usar o suporte automático de 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á o máximo possível para distribuir as unidades da sua instância entre as zonas de disponibilidade da região. Não há como determinar em quais zonas de disponibilidade suas unidades estão localizadas. Recomendamos que você implante no mínimo 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 configuradas 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 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 em duas zonas de disponibilidade. Não há como determinar em quais zonas de disponibilidade as VMs da unidade estão colocadas.

  

  O diagrama mostra uma caixa rotulada 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 Zona de Disponibilidade 1, Zona de Disponibilidade 2 e Zona de Disponibilidade 3. A caixa Unidade 1 abrange as Zonas 1 e 2. A Zona 3 está vazia.

Suporte à zona de disponibilidade manual

Se quiser selecionar explicitamente as zonas de disponibilidade a serem usadas, você pode escolher entre configurações redundantes de zona e zonais:

• Redundância de zona: Configure manualmente a redundância de zona para uma instância do Gerenciamento de API em uma região com suporte 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 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 de 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 Zona de Disponibilidade 1, Zona de Disponibilidade 2 e Zona de Disponibilidade 3. A Zona 1 contém as caixas Unidade 1 e Unidade 2. A Zona 2 e a Zona 3 não contêm nenhuma unidade.

  Importante

  Fixe em uma única zona de disponibilidade somente se a latência entre zonas for muito alta para 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 de zona de disponibilidade. Para melhorar a resiliência de uma implantação de Gerenciamento de API zonal, você precisa implantar explicitamente instâncias separadas em várias zonas de disponibilidade e configurar o roteamento de tráfego e o failover.

Requisitos

• Suporte à 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 dão suporte a zonas de disponibilidade.

• Requisito de camada: 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 nos níveis clássico Consumo, Desenvolvedor, Básico e Padrão, nem nos níveis Básico v2, Padrão v2 e Premium v2. Para atualizar sua instância para o nível Premium (clássico), veja Atualizar para o nível Premium.

Considerações

• Número de unidades para instâncias com redundância de zona: se você configurar manualmente a redundância de zona para uma instância, também precisará configurar um número de unidades de Gerenciamento de API que podem ser distribuídas uniformemente entre todas as suas zonas de disponibilidade selecionadas. Por exemplo, se você selecionar duas zonas, deverá configurar pelo menos duas unidades. 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 de 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 da melhor maneira possível. Para redundância de zona máxima, 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 fornecem o desempenho de gateway necessário, use métricas de capacidade e seus próprios testes. Para obter mais informações sobre como dimensionar e atualizar sua instância de serviço, veja Atualizar e dimensionar uma instância de Gerenciamento de API.

• Dimensionamento automático: Se você configurar manualmente zonas de disponibilidade em uma instância do Gerenciamento de API configurada com dimensionamento automático, talvez seja necessário ajustar suas 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 de zona de disponibilidade automática, não precisará ajustar suas configurações de dimensionamento automático.

• Requisitos de endereço IP: ao habilitar o suporte à zona de disponibilidade em uma instância do 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 usar. Com 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, veja Endereços IP no Gerenciamento de API.

Custo

Independentemente da configuração da sua zona de disponibilidade, se você adicionar mais unidades, incorrerá em mais custos. Para obter mais informações, veja Preços do Gerenciamento de API.

Configurar o suporte à zona de disponibilidade

Essa seção explica como configurar o suporte à zona de disponibilidade para sua instância de Gerenciamento de API.

• Crie uma instância do Gerenciamento de API que suporte zonas de disponibilidade: quando você cria uma instância do API Management Premium (clássica) em uma região que suporta zonas de disponibilidade, a instância suporta zonas de disponibilidade por padrão. É possível selecionar o suporte de zona de disponibilidade automática ou configurar manualmente o suporte zonal ou com redundância de zona.

• Habilitar ou reconfigurar o suporte à zona de disponibilidade: você pode alterar a configuração da zona de disponibilidade para uma instância do Gerenciamento de API, incluindo adicionar zonas de disponibilidade e mover 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, veja Habilitar 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 tratar solicitações de API durante esse tempo.

  Alterar a 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 redução de zona, não há garantia de que as solicitações de mais capacidade em outra zona de disponibilidade serão bem-sucedidas. O preenchimento de unidades perdidas ocorre com base no melhor esforço. Se precisar de capacidade garantida quando uma zona de disponibilidade falhar, você deverá criar e configurar sua instância de Gerenciamento de API para compensar a perda de uma zona, executando todas as seguintes ações:

• Provisione excessivamente as unidades da sua instância de Gerenciamento de API.

• Use a configuração de zona de disponibilidade automática ou redundante de zona.

Para obter mais informações, consulte Gerenciar 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, veja Atualizar e dimensionar uma instância de Gerenciamento de API.

Comportamento quando todas as zonas estão saudáveis

Essa seção descreve o que esperar quando as instâncias do 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 suas unidades de Gerenciamento de API disponíveis em todas as zonas de disponibilidade selecionadas.

• Replicação de dados entre zonas: Gerenciamento de API armazena e replica os seguintes dados.

  • 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 há garantia de que os dados serão persistidos. Considere usar um cache externo se precisar persistir 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.

Comportamento durante uma falha de zona

Essa seção descreve o que esperar quando instâncias de Gerenciamento de API são configuradas com suporte a zona de disponibilidade e há uma interrupção na zona de disponibilidade.

• Detecção e resposta: a responsabilidade pela detecção e resposta depende da configuração da zona de disponibilidade que sua instância usa.

  • Automático e redundante de zona: para instâncias configuradas para usar suporte automático de zona de disponibilidade ou configuradas manualmente para usar redundância de zona, a plataforma de Gerenciamento de API é responsável por detectar 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 como zonais, você precisa detectar 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 com falha são encerradas e precisam ser repetidas.

• Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar o Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas do Resource Health para notificá-lo de problemas. Você também pode usar a Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e pode configurar alertas de Integridade do Serviço para notificá-lo de problemas.

• 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 indisponibilidade de uma zona de disponibilidade, você poderá perder alterações de configuração que não forem replicadas.

  • Dados no cache interno, se você usar o recurso de cache interno. O cache interno é volátil e não há garantia de que os dados serão persistidos. Durante uma indisponibilidade da zona de disponibilidade, você pode perder alguns ou todos os dados armazenados em cache. Considere usar um cache externo se precisar persistir dados armazenados em cache.

  • Contadores de limite de taxa, se você usar o recurso de limite de taxa. Durante uma interrupção da zona de disponibilidade, os contadores de limite de taxa podem não estar atualizados nas zonas sobreviventes.

• Tempo de inatividade esperado: o tempo de inatividade esperado depende da configuração da zona de disponibilidade que sua instância usa.

  • Automático: você pode esperar que instâncias que usam suporte automático à zona de disponibilidade não tenham tempo de inatividade durante uma interrupção da zona de disponibilidade. Unidades na(s) zona(s) não afetada(s) continuam trabalhando.

    Você também pode esperar que instâncias que usam suporte de zona de disponibilidade automática, mas têm uma única unidade, não tenham tempo de inatividade. Nesse caso, o Gerenciamento de API distribui as VMs subjacentes da unidade em duas zonas. A VM na zona não afetada continua funcionando.

  • Redundância de zona: você pode esperar que instâncias redundantes de zona não tenham tempo de inatividade durante uma interrupção de 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 seja recuperada.

• Redirecionamento de tráfego: o comportamento de redirecionamento de tráfego depende da configuração da zona de disponibilidade usada pela sua instância.

  • Automático e redundante de zona: para instâncias configuradas para usar suporte de zona de disponibilidade automática 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 escolher 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 que sua instância usa.

• Automático e redundante de zona: para instâncias configuradas para usar suporte automático de zona de disponibilidade ou configuradas manualmente para usar redundância de zona, quando a zona de disponibilidade é recuperada, o Gerenciamento de API restaura automaticamente as unidades na zona de disponibilidade e redireciona o tráfego entre suas 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.

Testar falhas em zonas

As opções para testar falhas de zona dependem da configuração da zona de disponibilidade usada pela sua instância.

• Automático e redundante de zona: para instâncias configuradas para usar suporte automático de zona de disponibilidade ou configuradas manualmente para usar redundância de zona, a plataforma de Gerenciamento de API gerencia o roteamento de tráfego, o failover e o failback. Esse recurso é totalmente gerenciado, então você não precisa iniciar ou validar processos de falha de zona de disponibilidade.

• Zonal: Para instâncias zonais, não há como simular uma indisponibilidade da zona de disponibilidade que contém sua instância de Gerenciamento de API. No entanto, você pode configurar manualmente gateways upstream ou balanceadores de carga para redirecionar o tráfego para uma instância diferente em uma zona de disponibilidade diferente.

Resiliência a falhas em toda a região

Com uma implantação multirregional, 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 multirregional ajuda a reduzir qualquer latência de solicitação percebida por consumidores de API distribuídos geograficamente. Uma implantação multirregional também melhora a disponibilidade do serviço caso uma região fique offline.

Implantação de várias regiões gerenciada pela Microsoft

O Gerenciamento de API oferece suporte apenas a implantações multirregionais no nível Premium (clássico). Ele não oferece suporte a implantações multirregionais nos níveis Consumo, Desenvolvedor, Básico, Básico v2, Padrão, Padrão v2 e Premium v2 (prévia). Para saber mais, confira Requisitos.

Ao adicionar uma região, você configura:

• O número de unidades que a região hospeda.

• Resiliência a falhas de 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.

Requisitos

• Suporte à região: Você pode criar implantações de várias regiões na camada Premium (clássica) com qualquer região do Azure que dê suporte ao Gerenciamento de API. Para ver quais regiões oferecem suporte a implantações multirregionais, veja Disponibilidade do produto por região.

• Requisito de camada: Você deve usar a camada Premium (clássica) para configurar o suporte a várias regiões. Para atualizar sua instância para o nível Premium (clássico), veja Atualizar para o nível Premium.

Considerações

• Somente gateway: somente o componente de gateway da instância do 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 o serviço originalmente.

• 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 região da rede virtual e da sub-rede deverá corresponder ao local secundário configurado. 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, veja Alterações em endereços IP. Entretanto, se você adicionar uma região secundária, o VIP da região primária não muda porque cada região tem seu próprio VIP privado.

• Nomes do Sistema de Nomes de Domínio (DNS): 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 exemplo https://contoso-westus2-01.regional.azure-api.net.

Custo

Adicionar regiões gera custos. Para obter mais informações, veja Preços do Gerenciamento de API.

Configurar o suporte a várias regiões

Para configurar o suporte multirregional em uma instância de Gerenciamento de API, veja 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, veja Remover uma região de serviço de gerenciamento de API.

Planejamento e gerenciamento de capacidade

Em um cenário de indisponibilidade regional, não há garantia de que solicitações de mais capacidade em outra região serão bem-sucedidas. Se precisar de capacidade garantida quando uma região falhar, você deverá criar e configurar sua instância de Gerenciamento de API para compensar a perda de uma região. Você pode fazer isso provisionando excessivamente a capacidade da sua instância de Gerenciamento de API. Para saber mais sobre o princípio de superprovisionamento, veja Gerenciar capacidade com superprovisionamento.

Em implantações multirregionais, o dimensionamento automático se aplica somente à região primária. Regiões secundárias exigem ajustes de escala manuais ou ferramentas personalizadas que você controla.

Comportamento quando todas as regiões estão saudáveis

Essa seção descreve o que esperar quando instâncias de Gerenciamento de API são configuradas com suporte multirregional e todas as regiões estão operacionais.

• Roteamento de tráfego entre regiões: o Gerenciamento de API roteia automaticamente as solicitações recebidas 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, veja 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 armazenada em cache ou um código de erro. Em uma solução multirregional, você precisa tomar cuidado para rotear para uma instância da API de backend que atenda aos seus requisitos de desempenho. Para obter mais informações, veja Chamadas de API de rota para serviços de backend regionais.

• Replicação de dados entre regiões: a configuração do gateway, como APIs e definições de políticas, é sincronizada regularmente entre as regiões primárias e secundárias que você adiciona. Normalmente, a propagação de atualizações para os gateways regionais leva menos de dez 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.

Comportamento durante uma falha de região

Essa seção descreve o que esperar quando instâncias de Gerenciamento de API são configuradas com suporte multirregional e há uma interrupção em uma das regiões que você usa.

• Detecção e resposta: o Gerenciamento de API é responsável por detectar 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: quaisquer solicitações ativas que estejam 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 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 sua região primária, você poderá perder alterações de configuração que não forem 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: Não é esperado nenhum tempo de inatividade do gateway.

  Se a região primária ficar offline, o plano de gerenciamento do Gerenciamento de API e o portal do desenvolvedor ficarão indisponíveis, mas as regiões secundárias continuarão a atender às solicitações de API usando a configuração de gateway mais recente.

• Redirecionamento de tráfego: se uma região ficar offline, as solicitações de API serão roteadas automaticamente em torno da região com falha para o gateway mais próximo.

Recuperação de região

Quando a região primária é recuperada, o Gerenciamento de API restaura automaticamente as unidades na região e redireciona o tráfego entre elas.

Teste de falhas na região

Para estar preparado para interrupções inesperadas de região, recomendamos que você teste regularmente suas respostas a falhas de região. Você pode simular alguns aspectos de uma falha regional desabilitando o roteamento para um gateway regional.

Backup e restauração

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.

O backup é suportado nos níveis Desenvolvedor, Básico, Padrão e Premium.

Para obter mais informações, veja Como implementar a recuperação de desastres usando o backup e a restauração de 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).

Resiliência à manutenção do serviço

O Gerenciamento de API realiza atualizações regulares de serviço e outras formas de manutenção.

Nos níveis Básico, Padrão e Premium (clássico), você pode personalizar quando, no processo de atualização, sua instância receberá uma atualização. Se você precisar validar o efeito das atualizações na 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 é o horário do dia em que você deseja que a instância aplique atualizações de serviço.

Para obter mais informações, veja Configurar as definições de atualização de serviço para suas instâncias de Gerenciamento de API.

Contrato de nível de serviço

O acordo de nível de serviço (SLA) dos serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para alcançar essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

Quando você implanta uma instância do Gerenciamento de API em várias zonas de disponibilidade ou regiões, 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 backends 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 o Gerenciamento de API