Compartilhar via

Confiabilidade no Gerenciamento de API do Azure

O 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.

Unidades

Cada unidade consiste em dois recursos de computação (VMs ou servidores semelhantes, dependendo da camada de serviço) que lidam com solicitações de API em conjunto. Você não vê essas VMs ou outros servidores. A plataforma gerencia automaticamente a criação deles e o monitoramento do estado de integridade. Se um recurso de computação falhar, a unidade continuará operando, mas com capacidade reduzida, fornecendo alguma proteção de confiabilidade interna.

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.

Observação

O Gerenciamento de API usa unidades para os componentes do gateway. As unidades não são aplicáveis ao portal do desenvolvedor ou ao plano de gerenciamento.

Níveis de serviço

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.

  • Camada Premium v2: suporta várias unidades que podem ser distribuídas entre zonas de disponibilidade. Atualmente, ele não dá suporte a implantações de várias regiões.

  • Básico v2, Padrão e Padrão v2: Todas suportam 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).

Observação

Os níveis Desenvolvedor e Premium do Gerenciamento de API oferecem suporte a 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. Gateways auto-hospedados estão fora do escopo deste artigo.

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.

Para exibir informações sobre o suporte à zona de disponibilidade para as camadas Premium e Premium v2, selecione a camada de serviço apropriada no início desta página.

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 (Recomendado): 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á uma tentativa de melhor esforço para espalhar as unidades da instância entre as zonas de disponibilidade da região. Você não pode determinar em quais zonas de disponibilidade suas unidades são colocadas. 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:

    Diagrama que mostra três unidades de Gerenciamento de API distribuídas entre zonas de disponibilidade para suporte automático à zona de disponibilidade.

  • Configuração de unidade única: Se sua instância tiver uma única unidade, os recursos de computação subjacentes da unidade serão distribuídos para duas zonas de disponibilidade. Não é possível determinar em quais zonas de disponibilidade os recursos de computação da unidade são colocados.

    Diagrama que mostra uma única unidade de Gerenciamento de API distribuída entre duas zonas de disponibilidade para suporte automático à zona de disponibilidade.

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.

    Diagrama que mostra três unidades de Gerenciamento de API distribuídas entre zonas de disponibilidade para redundância manual de zona.

  • 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.

    Diagrama que mostra uma implantação de Gerenciamento de API zonal que tem duas unidades, em uma única zona de disponibilidade.

    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.

Na camada Premium v2, você pode habilitar a redundância de zona para uma instância de Gerenciamento de API em uma região com suporte.

Com o suporte à zona de disponibilidade, o Gerenciamento de API replica o gateway (unidades de escala), o plano de gerenciamento e o portal do desenvolvedor. Você pode escolher uma única unidade ou uma configuração de instância multiunit 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 espalhar as unidades da instância entre as zonas de disponibilidade da região. Você não pode determinar em quais zonas de disponibilidade suas unidades são colocadas. 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 à zona de disponibilidade:

    Diagrama que mostra três unidades de Gerenciamento de API distribuídas entre zonas de disponibilidade.

  • Configuração de unidade única: Se sua instância tiver uma única unidade, os recursos de computação subjacentes da unidade serão distribuídos para duas zonas de disponibilidade. Não é possível determinar em quais zonas de disponibilidade os recursos de computação da unidade são colocados.

    Diagrama que mostra uma única unidade de Gerenciamento de API distribuída entre duas zonas de disponibilidade.

Requirements

  • Suporte à região: O Gerenciamento de API dá suporte a zonas de disponibilidade para as camadas Premium (clássica) e Premium v2 em regiões em que a camada de Gerenciamento de API está disponível e a região dá suporte a zonas de disponibilidade.

  • Requisito de camada: Você deve usar a camada Premium (clássica) ou Premium v2 para configurar o suporte à zona de disponibilidade. Atualmente, o Gerenciamento de API não dá suporte a zonas de disponibilidade nas camadas de Consumo, Desenvolvedor, Básico e Standard clássicos ou nas camadas Basic v2 e Standard v2. Para obter opções de atualização, consulte Atualizar e dimensionar uma instância de Gerenciamento de API.

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 a máxima redundância de zona, utilize no mínimo duas unidades, para que uma interrupção em uma zona de disponibilidade não afete o desempenho do seu gateway.

    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.

Considerações

  • Número de unidades para instâncias com redundância de zona: Na camada Premium v2, 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 máxima de zona, use pelo menos duas unidades para fornecer capacidade suficiente para que uma interrupção de zona de disponibilidade não afete o desempenho do gateway.

    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.

  • Autoscaling: Na camada Premium v2, você não precisa ajustar as configurações de dimensionamento automático ao habilitar o suporte à zona de disponibilidade.

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. Para obter mais informações, consulte Habilitar o suporte à zona de disponibilidade em instâncias 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.

    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 podem 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, confira Zonas de disponibilidade físicas e lógicas.

  • 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. Nenhuma das opções de configuração exige tempo de inatividade.

    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.

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. Para obter mais informações, consulte Habilitar o suporte à zona de disponibilidade em instâncias de Gerenciamento de API.

  • Crie uma instância de Gerenciamento de API que dê suporte a zonas de disponibilidade: Na camada Premium v2, opcionalmente, habilite a redundância de zona ao criar uma instância de Gerenciamento de API em uma região que dá suporte a zonas de disponibilidade. Se a redundância de zona não puder ser habilitada devido a restrições de capacidade ou outros problemas, a implantação do serviço falhará.

  • Habilitar ou reconfigurar o suporte à zona de disponibilidade: Você não pode alterar a configuração da zona de disponibilidade depois que a instância é criada.

Planejamento e gerenciamento de capacidade

Em um cenário de indisponibilidade da zona, não há garantia de que as solicitações de maior capacidade em outra zona de disponibilidade tenham êxito. O preenchimento de unidades perdidas ocorre com base no melhor esforço. Se você precisar de capacidade garantida quando uma zona de disponibilidade falhar, crie e configure sua instância de Gerenciamento de API para considerar 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, sincroniza 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.

  • 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 os recursos de computação subjacentes da unidade para duas zonas. O recurso 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.

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: Na camada Premium v2, 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.

  • 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.

  • 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: Você pode esperar que as instâncias 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 as instâncias que têm uma única unidade não tenham tempo de inatividade. Nessa configuração, o Gerenciamento de API distribui os recursos de computação subjacentes da unidade para duas zonas. O recurso na zona não afetada continua funcionando.

  • Redirecionamento de tráfego: Quando uma zona não está disponível, todas as unidades na zona afetada também ficam indisponíveis. Você pode dimensionar sua instância para adicionar mais unidades.

Recuperação de zona

  • 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.

Recuperação de zona

Na camada Premium v2, 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 suas unidades normalmente.

Testar falhas em zonas

  • 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, você não pode simular uma interrupção 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.

Testar falhas em zonas

Na camada Premium v2, 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.

Resiliência a falhas em toda a região

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

Importante

As implantações de várias regiões têm suporte apenas na camada Premium (clássica) do Gerenciamento de API.

Para exibir informações sobre o suporte a várias regiões, selecione a camada Premium (clássica) no início desta página.

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

Ao adicionar uma região, você configura:

Requirements

  • 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 VIP (IP virtual) da 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 de região, não há garantia de que as solicitações de mais capacidade em outra região sejam 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, eles 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: Todas as solicitações ativas que estão sendo processadas na região com falha podem ser descartadas e o cliente deve repeti-las.

  • 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, eles 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. No entanto, as regiões secundárias continuam a atender 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 pronto para interrupções inesperadas de região, teste regularmente suas respostas a falhas na 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 as configurações do serviço de Gerenciamento de API entre ambientes operacionais, como desenvolvimento e preparo.

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 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

  • Last updated on