Partilhar via

Confiabilidade no Gerenciamento de API do Azure

O Azure API Management é um serviço totalmente gerido que ajuda as organizações a publicar, proteger, transformar, manter e monitorizar 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 oferecer 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 na zona de disponibilidade, interrupções de região e manutenção de serviços. Ele também descreve como você pode usar backups para se recuperar de outros tipos de problemas e destaca algumas informações importantes sobre o contrato de nível de serviço (SLA) do 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.

Units

Cada unidade consiste em dois recursos de computação (VMs ou servidores semelhantes, dependendo do nível de serviço) que tratam os pedidos de API em conjunto. Não vês estas VMs nem outros servidores. A plataforma gere automaticamente a sua criação e monitorização da saúde. Se um recurso de computação falhar, a unidade continua a operar, mas com capacidade reduzida, proporcionando alguma proteção de fiabilidade incorporada.

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.

Observação

A Gestão de APIs utiliza unidades para os componentes do gateway. As unidades não são aplicáveis ao portal de programadores ou ao plano de gestão.

Níveis de serviço

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.

  • Nível premium v2: Suporta múltiplas unidades que podem ser distribuídas entre zonas de disponibilidade. Atualmente, não suporta implementações multi-região.

  • Níveis básicos v2, Standard e Standard v2: Todos suportam múltiplas unidades num único centro de dados. 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).

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

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 Práticas recomendadas de arquitetura para gerenciamento de API.

Resiliência a falhas transitórias

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.

Resiliência a falhas na zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.

Para consultar informações sobre o suporte a zonas de disponibilidade para os níveis Premium e Premium v2, certifique-se de selecionar o nível de serviço apropriado no início desta página.

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 (Recomendado): A Gestão de API fornece suporte automático de zonas de disponibilidade quando não especifica quais as zonas de disponibilidade a utilizar.

  • 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 Resiliência a falhas em toda a região.

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 multi-unidade (Recomendado): Se a sua instância tiver duas ou mais unidades, a API Management faz um esforço máximo para distribuir as unidades da sua instância entre as zonas de disponibilidade da região. Não consegues determinar em que zonas de disponibilidade as tuas unidades estão colocadas. Desdobrar no mínimo duas unidades, que podem ser distribuídas por 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:

    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 a sua instância tiver uma única unidade, os recursos de computação subjacentes da unidade são distribuídos por duas zonas de disponibilidade. Não se pode determinar em que zonas de disponibilidade estão colocados os recursos de computação da unidade.

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

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.

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

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

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

    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.

No nível Premium v2, podes ativar a redundância de zonas para uma instância de Gestão de API numa região suportada.

Com suporte a zonas de disponibilidade, a API Management replica o gateway (unidades de escala), o plano de gestão e o portal do programador. Pode escolher uma configuração de instância de unidade única ou de múltiplas unidades para alcançar redundância de zonas:

  • Configuração multi-unidade (Recomendado): Se a sua instância tiver duas ou mais unidades, a API Management faz um esforço máximo para distribuir as unidades da sua instância entre as zonas de disponibilidade da região. Não consegues determinar em que zonas de disponibilidade as tuas unidades estão colocadas. Desdobrar no mínimo duas unidades, que podem ser distribuídas por duas zonas.

    O diagrama seguinte mostra uma instância de Gestão de API com três unidades configurada para suporte a zonas de disponibilidade:

    Diagrama que mostra três unidades de gestão de API distribuídas por zonas de disponibilidade.

  • Configuração de unidade única: Se a sua instância tiver uma única unidade, os recursos de computação subjacentes da unidade são distribuídos por duas zonas de disponibilidade. Não se pode determinar em que zonas de disponibilidade estão colocados os recursos de computação da unidade.

    Diagrama que mostra uma única unidade de Gestão de API distribuída por duas zonas de disponibilidade.

Requerimentos

  • Apoio regional: A Gestão de APIs suporta zonas de disponibilidade para os níveis Premium (clássico) e Premium v2 em regiões onde o nível de Gestão da API está disponível e a região suporta zonas de disponibilidade.

  • Requisito de nível: Deve usar o nível Premium (clássico) ou Premium v2 para configurar o suporte a zonas de disponibilidade. Atualmente, a Gestão de APIs não suporta zonas de disponibilidade nos níveis clássicos de Consumo, Desenvolvedor, Básico e Standard, nem nos níveis Basic v2 e Standard v2. Para opções de atualização, consulte Atualizar e escalar uma instância de Gestão de API.

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 máxima redundância de zona, use pelo menos duas unidades para que uma falha na zona de disponibilidade não afete o desempenho do seu gateway.

    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.

Considerações

  • Número de unidades para instâncias redundantes de zona: No nível 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 com o melhor esforço possível. Para máxima redundância de zona, use pelo menos duas unidades para fornecer capacidade suficiente para que uma falha na zona de disponibilidade não afete o desempenho do seu gateway.

    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.

  • Autoescalonamento: No nível Premium v2, não precisas de ajustar as definições de autoescala quando ativas o suporte a zonas de disponibilidade.

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. Para mais informações, consulte Ativar suporte de zonas de disponibilidade em instâncias de Gestão de APIs.

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

    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.

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

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. Para mais informações, consulte Ativar suporte de zonas de disponibilidade em instâncias de Gestão de APIs.

  • Crie uma instância de Gestão de API que suporte zonas de disponibilidade: No nível Premium v2, ativa opcionalmente a redundância de zonas quando criares uma instância de Gestão de API numa região que suporta zonas de disponibilidade. Se a redundância de zonas não puder ser ativada devido a restrições de capacidade ou outros problemas, a implementação do serviço falha.

  • Ativar ou reconfigurar o suporte à zona de disponibilidade: Não podes alterar a configuração da zona de disponibilidade depois de a instância ser criada.

Planejamento e gerenciamento de capacidade

Num cenário de zona reduzida, não há garantia de que os pedidos de mais capacidade noutra zona de disponibilidade tenham sucesso. O enchimento de unidades perdidas ocorre da melhor forma possível. Se precisar de capacidade garantida quando uma zona de disponibilidade falha, crie e configure a sua instância de Gestão de API para compensar a perda de uma zona, tomando 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.

Comportamento quando todas as zonas estão íntegras

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íticas, sincroniza-se regularmente entre as zonas de disponibilidade que seleciona 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.

Comportamento durante uma falha 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.

  • 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. Neste caso, a API Management distribui os recursos computacionais subjacentes da unidade por duas zonas. O recurso 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.

Comportamento durante uma falha 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: No nível Premium v2, a plataforma de Gestão de API é responsável por detetar uma falha numa 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 defeituosa 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 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 previsto: Pode esperar que as instâncias 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.

    Também podes esperar que instâncias com uma única unidade não tenham tempo de inatividade. Nesta configuração, a API Management distribui os recursos de computação subjacentes da unidade por duas zonas. O recurso na zona não afetada continua a funcionar.

  • Redirecionamento de tráfego: Quando uma zona está indisponível, quaisquer unidades na zona afetada também ficam indisponíveis. Podes escalar a tua instância para adicionar mais unidades.

Recuperação de zona

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

Recuperação de zona

No nível Premium v2, quando a zona de disponibilidade recupera, a API Management restaura automaticamente as unidades na zona de disponibilidade e redireciona o tráfego entre as unidades normalmente.

Teste de falhas de zona

  • 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 podes simular uma falha da zona de disponibilidade que contém a tua instância de Gestão 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.

Teste de falhas de zona

No nível Premium v2, a plataforma de Gestão de API gere o encaminhamento de tráfego, failover e failback. Esse recurso é totalmente gerenciado, portanto, você não precisa iniciar ou validar processos de falha na zona de disponibilidade.

Resiliência a falhas em toda a região

Ao usar uma implementação multi-região, pode adicionar gateways regionais de API a uma instância de Gestão de APIs existente numa ou mais regiões Azure suportadas. A implementação multi-região ajuda a reduzir qualquer latência de pedidos que seja percebida pelos consumidores de APIs geograficamente distribuídos. Uma implantação em várias regiões também melhora a disponibilidade do serviço se uma região ficar offline.

Importante

Implementações multi-região são suportadas apenas na camada Premium (clássica) da API Management.

Para ver informações sobre suporte multi-região, certifique-se de selecionar o nível Premium (clássico) no início desta página.

Implantação multirregional gerenciada pela Microsoft

Ao adicionar uma região, você configura:

Requerimentos

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

  • Requisito do nível: 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.

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 adicionar, remover ou ativar a zona de disponibilidade na região primária, ou se alterar a sub-rede da região principal, o endereço IP virtual (VIP) da sua instância de Gestão de API muda. 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 exemplo https://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

Num cenário de falha de região, não há garantia de que os pedidos por mais capacidade noutra região tenham sucesso. 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.

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

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 na cache interna são específicos de cada região, por isso não são replicados entre regiões.

Comportamento durante uma interrupção regional

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.

  • Pedidos ativos: Quaisquer pedidos ativos que estejam a ser processados na região defeituosa podem ser cancelados e o cliente deve tentar novamente.

  • 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 na cache interna são específicos de cada região, por isso não são replicados entre regiões.

  • Tempo de inatividade esperado: Nenhum tempo de inatividade do gateway é esperado.

    Se a região principal ficar offline, o plano de gestão de gestão de API e o portal de programadores tornam-se indisponíveis. No entanto, as regiões secundárias continuam a servir pedidos de API utilizando a configuração de gateway mais recente.

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

Teste para falhas regionais

Para estar preparado para interrupções regionais inesperadas, teste regularmente as suas respostas a falhas regionais. Você pode simular alguns aspetos de uma falha de região 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. Também pode usar operações de backup e restauro para replicar configurações de serviços de Gestão de APIs entre ambientes operacionais, como desenvolvimento e staging.

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

Resiliência à manutenção de serviços

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 contrato de nível de serviço (SLA) para serviços do Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte Acordos de Nível de Serviço (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

  • Last updated on