Alta Disponibilidade e Resiliência com App Gateway e Múltiplos APIMs: Uma Arquitetura Estratégica
Resiliência como Pilar do Azure Well-Architected Framework A resiliência é um dos pilares fundamentais do WAF e desempenha papel crítico na construção de arquiteturas modernas em nuvem. Este artigo explora o design de alta disponibilidade (HA) utilizando a oferta Premium Tier do Azure API Management (APIM) em cenários multi-região ou mesmo intra-região, com foco na aplicação de Availability Zones — uma prática recomendada no pilar de Confiabilidade. A configuração Premium permite que as regiões primária e secundária compartilhem a mesma instância de APIM. No entanto, dependendo dos requisitos de negócio e tolerância a falhas, pode ser estratégico operar com duas instâncias separadas, garantindo continuidade de serviço mesmo diante de falhas regionais ou em uma das instâncias. Essa abordagem está alinhada ao modelo de DR Ativo-Ativo, promovendo tolerância a falhas, escalabilidade horizontal e resiliência operacional, conforme descrito no modelo de maturidade de confiabilidade. A imagem acima representa os componentes do APIM nas regiões primária e secundária. Em cenários com instâncias separadas, esses componentes também estariam presentes em cada região. Já em uma configuração com Availability Zones, os elementos podem escalar dentro da mesma região, conforme a demanda — prática que também se conecta ao pilar de excelência operacional, ao permitir automação e monitoramento contínuo. O fluxo de comunicação entre a API e os serviços de backend pode ocorrer por rotas diretas ou por meio de balanceadores de carga, dependendo do caso de uso. Essa arquitetura inspirou uma solução personalizada para um de nossos clientes, que buscava alta disponibilidade com baixa latência, mesmo em cenários de falha regional. Configuração do APIM como gateway de saída para o cluster de aplicações Press enter or click to view image in full size Em alguns casos, por questões de compliance, não é possível operar fora de um regions específica . Ainda assim, essa arquitetura já proporciona ganhos significativos mesmo dentro da mesma região, como maior resiliência, escalabilidade e eficiência operacional. Visão Geral da Arquitetura Componentes principais: Usuário: Inicia a requisição. WAF: Protege contra ameaças e ataques na borda. AKS: Gerencia APIs e aplicações containerizadas. App Gateway (AppGW): Roteia o tráfego para os APIMs. APIM001 e APIM002: Instâncias do Azure API Management, com IPs distintos e potencialmente em regiões diferentes. Sistemas legados (kubernets / VMS): Integração com sistemas on-premises. Essa arquitetura é interessante, pois, neste caso de uso, o APIM atua como ponto de saída do cluster de aplicações — exatamente o caminho crítico que queremos proteger Com duas instâncias de APIM atrás do AppGW, é possível: Realizar manutenções planejadas em uma instância sem impactar os usuários. Redirecionar o tráfego automaticamente para a instância saudável. Garantir zero downtime, mesmo durante atualizações críticas. Essa abordagem é especialmente útil em ambientes com alta exigência de SLA, como bancos, governo e telecom. Testes Blue-Green com Segurança e Controle A arquitetura permite implementar estratégias Blue-Green com facilidade: Uma instância do APIM pode representar o ambiente “Blue” (produção atual). A outra instância representa o ambiente “Green” (nova versão). O AppGW pode direcionar parte do tráfego para o ambiente Green para testes controlados. Após validação, o tráfego pode ser totalmente migrado para o Green, promovendo a nova versão com segurança. Isso reduz riscos de regressão e permite deploys mais confiáveis Redução de Riscos em Caminhos Críticos Ao distribuir o tráfego entre dois APIMs: Reduz-se o risco de ponto único de falha. A arquitetura se torna mais resiliente a falhas regionais ou de serviço. Em caso de falha de uma instância, o AppGW garante continuidade do serviço. Essa redundância é essencial para caminhos críticos de negócio, como autenticação, transações financeiras ou integrações com sistemas legados. Outros Benefícios Estratégicos ✅ Disaster Recovery Ativo-Ativo As duas instâncias de APIM podem operar em modo ativo-ativo. Em caso de desastre em uma instancia, o tráfego é automaticamente redirecionado. Reduz o tempo de recuperação (RTO) e garante continuidade. ✅ Mitigação de Esgotamento de IPs Com múltiplas instâncias, é possível distribuir o consumo de IPs. Evita gargalos e limitações de rede. ✅ Escalabilidade Regional A arquitetura permite escalar horizontalmente com facilidade. Suporta crescimento de demanda em diferentes regiões. Como configurar o APPGW para uma POC de balanceamento entre dois APIMs O Azure Application Gateway é um balanceador de carga de camada 7 (HTTP/HTTPS) que permite gerenciar o tráfego de aplicações web com inteligência, segurança e escalabilidade. Ele opera com base em um conjunto de configurações como Listeners, Routing Rules, Backend Targets entre outras. Além disso, o Application Gateway oferece recursos avançados como WAF (Web Application Firewall), SSL offloading, redirecionamento baseado em caminho e afinidade de sessão, tornando-o ideal para cenários que exigem alta disponibilidade e proteção contra ameaças web. Press enter or click to view image in full size 📦 Descrição de cada componente do diagrama Listener (porta 80): Detecta conexões de entrada na porta especificada (ex: 80 para HTTP). É o ponto inicial onde o tráfego chega ao gateway. Routing Rule: Define como o tráfego será roteado com base em critérios como URL, cabeçalhos ou métodos. É o cérebro da decisão de encaminhamento. Backend Targets: Especifica os destinos finais para o tráfego, como VMs, instâncias de App Service ou containers. 🔁 Relação com Backend Pools: 1 para N — uma regra pode apontar para vários destinos. Backend Setting: Configurações aplicadas ao tráfego, como tempo de timeout, protocolo (HTTP/HTTPS), e afinidade de sessão. 🔁 Relação com Health Probes: 1 para 1 — cada configuração tem uma sonda associada. Backend Pools: Agrupamento lógico dos destinos (targets). Permite distribuir carga entre múltiplas instâncias. 🔁 Relação com Backend Targets: 1 para N — um pool pode conter vários destinos. Health Probes (path:/status-0123456789abcdef) Verifica a saúde dos destinos usando um caminho específico. Se um destino estiver inativo, ele é automaticamente removido do balanceador. Vamos apresentar algumas telas de configuração e destacar pontos de atenção no Application Gateway (AppGW). Um detalhe importante que acabei não mencionando: à frente do Listener existe uma configuração de Frontend IP, que define se o IP do AppGW será público ou privado. Para facilitar os testes iniciais, recomendo começar com o Frontend IP público,alem disso mantenha o Listener configurado na porta 80. Isso evita complicações com certificados SSL durante os testes. Observe a imagem abaixo: o Frontend IP está corretamente vinculado ao Listener1, como indicado. Essa associação é essencial para garantir que o tráfego seja direcionado corretamente, conforme a configuração do IP público ou privado definida no Frontend. Press enter or click to view image in full size O Listener1, configurado na porta 80, está associado à Rule1, que define como o tráfego será roteado para o backend correspondente. Press enter or click to view image in full size A Rule1 está associada às configurações de Backend Settings, que definem como o tráfego será encaminhado para os recursos de backend — incluindo o pool de servidores, o protocolo, a porta e os critérios de saúde. Press enter or click to view image in full size As Backend Settings do Application Gateway incluem configurações importantes, como “Pick host name from backend target” e a associação a um Custom Probe. Por padrão, o AppGW encaminha ao backend o mesmo cabeçalho HTTP Host recebido do cliente. No entanto, se o serviço ou aplicação no backend exigir um valor específico para o cabeçalho Host, é possível sobrescrevê-lo utilizando essa configuração. Com isso, o Application Gateway passa a usar o host do backend para resolver o balanceamento e validar o probe de integridade, garantindo compatibilidade com serviços que dependem de hostname específico para funcionar corretamente. Press enter or click to view image in full size Perceba que o Health Probe também está vinculado às Backend Settings, e utiliza a configuração “Pick host name from backend settings”. Essa associação é fundamental para garantir que o probe de integridade seja executado corretamente, especialmente em cenários onde o backend exige um cabeçalho Host específico. Ao ativar essa opção, o Application Gateway passa a usar o hostname do backend tanto para o roteamento quanto para a validação do probe, assegurando compatibilidade com serviços que dependem dessa configuração. Press enter or click to view image in full size Esse endereço /status-0123456789abcdef é o endereço de sondagem do apim (helth cehck) do APIM Voltando à Rule1, podemos observar que ela também define o Backend Target, que neste caso aponta para o serviço de backend do APIM (Azure API Management). Essa configuração é essencial para garantir que o tráfego roteado pelo Application Gateway seja direcionado corretamente ao endpoint do APIM, respeitando as regras de roteamento, cabeçalhos e probes definidos nas Backend Settings. Press enter or click to view image in full size Nos Backend Pools, temos o pool de backend do APIM, que contém duas instâncias do serviço Azure API Management. Essa configuração permite distribuir o tráfego entre as instâncias, garantindo alta disponibilidade e escalabilidade para os serviços expostos via AppGW. Press enter or click to view image in full size Do lado do APIM Para observar o processo de balanceamento entre instâncias do APIM (por exemplo, APIM A e APIM B), podemos criar uma API de mock que responda de forma simples, identificando qual instância está respondendo. Principais Objetos do APIM Políticas: São regras aplicadas às requisições HTTP, permitindo manipulações como transformação de payloads, controle de acesso, limitação de chamadas (rate limiting), entre outras. API: Representa um conjunto de operações agrupadas sob um único endpoint. Cada API pode conter múltiplas operações. Operações: São as ações HTTP específicas, como os verbos GET, POST, PUT, DELETE, etc. Cada operação define o comportamento de uma rota dentro da API. Como criar um mock no Azure API Management (APIM) Adicionar uma nova API Acesse o menu lateral e clique em “Add API”. Selecione a opção para criar uma API manualmente. Na caixa de diálogo exibida, preencha os dados necessários (nome, URL base, etc.). eu criei uma APIA, com sufixo apim Press enter or click to view image in full size Definir o response da operação Clique em “add operation” e preencha o verbo como get a url como /moq Após criar a operação desejada, clique na aba “Responses”. Clique em “Add response” e selecione o código 200. Em Content type, escolha application/json. No campo Sample, insira um JSON de exemplo para identificar a instância, como: JSON { "name": "APIMA" } Press enter or click to view image in full size Adicionar a política de mock Vá para a aba “Design” da operação. Na seção Inbound processing, clique em “Add policy”. Selecione a política “Mock response”. Verificação Após salvar, o pipeline da requisição exibirá uma tarja amarela, indicando que o mock está ativo. Press enter or click to view image in full size Repita esse processo para a instância dois. Agora já podemos testar o balanceamento de carga pelo Application Gateway Press enter or click to view image in full size Sincronização das Instâncias com o API OPS Conforme mencionado no início deste artigo, a arquitetura “by the book” foi projetada para utilizar o recurso nativo de multi-região do Azure API Management (APIM), o que elimina a necessidade de esforços adicionais para sincronizar configurações entre instâncias. No entanto, ao optarmos por manter duas instâncias separadas na mesma região, com o objetivo de obter os benefícios citados anteriormente, passamos a ter o desafio de manter ambas sincronizadas — ou seja, com as mesmas APIs, endpoints e políticas. Para atender a essa necessidade de sincronização, utilizaremos o API Ops, que automatiza o processo de publicação e atualização das configurações entre as instâncias, garantindo consistência e reduzindo o risco de divergências operacionais. Press enter or click to view image in full size Resumo do Fluxo de API Ops para Sincronização com o APIM Press enter or click to view image in full size Operadores de API executam o pipeline de extração para sincronizar o repositório Git com a instância do API Management, populando o repositório com os objetos no formato necessário. Se houver alterações detectadas na instância do APIM, é criado um Pull Request (PR) para revisão. Após aprovação, os operadores fazem o merge das mudanças no repositório. Desenvolvedores de API clonam o repositório, criam uma branch e definem as APIs usando especificações OpenAPI ou ferramentas de sua preferência. Quando um desenvolvedor envia alterações para o repositório, um novo PR é gerado para revisão. O PR pode ser aprovado automaticamente ou revisado manualmente, conforme o nível de controle exigido. Após a aprovação e o merge, o pipeline de publicação implanta as alterações na instância do API Management. Os operadores também podem criar ou modificar políticas, diagnósticos, produtos e outros objetos relevantes, e então comitar essas alterações. Após o merge, o pipeline publica as mudanças usando o processo de definição de APIs. Conclusão A adoção de uma arquitetura com App Gateway à frente de múltiplos APIMs, integrada com Akamai WAF, Azure Functions, Key Vault e sistemas legados, oferece uma solução robusta, segura e altamente disponível. Essa abordagem não apenas melhora a experiência do usuário, mas também reduz riscos operacionais e facilita a evolução contínua da plataforma. Referencias Estrutura de Well-Architected do Azure — Microsoft Azure Well-Architected Framework | Microsoft Learn Princípios de design de confiabilidade — Microsoft Azure Well-Architected Framework | Microsoft Learn Modelo de maturidade de confiabilidade — Microsoft Azure Well-Architected Framework | Microsoft Learn Links rápidos de excelência operacional — Microsoft Azure Well-Architected Framework | Microsoft Learn Implantações de API automatizadas usando APIOps — Azure Architecture Center | Microsoft LearnDataEX Bootcamp: Data Women Engineers 2025
DataEX Bootcamp Data Women Engineers 2025: Uma Oportunidade Imperdível para Mulheres que Querem Iniciar na Carreira de Engenharia de Dados Se você é uma mulher apaixonada por tecnologia e busca uma oportunidade para se aprofundar em Data Engineering, o DataEX Bootcamp Data Women Engineers 2025 pode ser o seu ponto de partida. Este programa exclusivo e gratuito foi desenvolvido para capacitar mulheres que desejam ingressar na área de dados, com um foco prático e realista, visando proporcionar uma imersão completa nas habilidades e ferramentas mais requisitadas pelas empresas de tecnologia. O que é o DataEX Bootcamp Data Women Engineers? O DataEX Bootcamp é um programa de capacitação totalmente gratuito que oferece 50 vagas para mulheres cisgêneras e transgêneras com interesse em aprender sobre engenharia de dados. Durante o bootcamp, as participantes terão acesso a aulas teóricas e práticas, onde serão treinadas para atuar na criação e manipulação de grandes volumes de dados, utilizando ferramentas e tecnologias de ponta como SQL Server, Microsoft Fabric, Python, e muito mais. O curso foi projetado para atender a uma demanda crescente por profissionais qualificados em Data Engineering, uma das áreas mais promissoras da tecnologia. As alunas terão a oportunidade de trabalhar com cenários reais, desenvolvendo habilidades essenciais para o mercado de trabalho. Conteúdo Programático O bootcamp vai além das aulas tradicionais. Ele foca no desenvolvimento de competências técnicas essenciais para o trabalho com engenharia de dados. Durante o curso, você aprenderá: Criação e gerenciamento de Data Warehouses e DataMarts; Processamento de dados com tecnologias avançadas; Segurança e otimização de dados em ambientes corporativos; Monitoramento de dados em tempo real; Uso do Microsoft Fabric para análise e manipulação de dados; Fundamentos de Python aplicados ao trabalho com dados. O programa combina teoria e prática, permitindo que as participantes desenvolvam seus próprios projetos e desafios, como seria o caso em um ambiente corporativo. Isso garante que as habilidades adquiridas sejam imediatamente aplicáveis no mercado de trabalho. Etapas do Processo Seletivo O processo seletivo para o DataEX Bootcamp Data Women Engineers 2025 é simples, mas exige comprometimento e dedicação. As etapas são: Inscrição Online: Você deve acessar a página do bootcamp e preencher o formulário de inscrição até o dia 31 de dezembro de 2024. É importante completar todos os campos corretamente para garantir sua candidatura. Desafio Cloud Skills: Após a inscrição, será necessário realizar o Desafio Cloud Skills. Este desafio é um teste introdutório que ajuda a avaliar seu nível de conhecimento e familiaridade com conceitos básicos de cloud computing. A conclusão deste desafio deve ser confirmada até o dia 07 de janeiro de 2025. Seleção: As participantes que cumprirem todas as etapas com sucesso receberão um e-mail de confirmação até 21 de janeiro de 2025. O bootcamp começa em 03 de fevereiro de 2025. Agenda e Modalidade O bootcamp terá aulas de 03 de fevereiro a 14 de fevereiro de 2025, com encontros programados de segunda a sexta-feira, das 13h30 às 17h30. As participantes terão que se comprometer a comparecer a todas as aulas, que ocorrerão de forma 100% online. Durante esse período, será possível aprender em tempo real e tirar dúvidas diretamente com os instrutores. Certificação e Desafio Final Ao final do bootcamp, todas as alunas que completarem o programa com sucesso receberão um certificado de participação, confirmando suas novas habilidades adquiridas. Além disso, todas as participantes serão desafiadas a realizar o Desafio Data Engineer, um teste prático que avaliará seus conhecimentos e habilidades adquiridos ao longo das aulas. O desafio ocorrerá entre 14 e 23 de fevereiro de 2025. Requisitos para Participação Para ser selecionada, você precisa atender aos seguintes critérios: Identificar-se como mulher cis ou trans; Ter mais de 18 anos; Ensino Médio completo; Disponibilidade para participar de todas as aulas durante o período de 03 a 14 de fevereiro de 2025 (exceto 08 e 09 de fevereiro, que são dias de descanso); Acesso a um computador ou notebook com conexão à internet; Interesse em trabalhar no mercado de tecnologia. Por que Participar? Este bootcamp é uma excelente oportunidade para mulheres que buscam entrar no mercado de tecnologia, especialmente em um campo de alta demanda como a engenharia de dados. Ao final do programa, as participantes estarão preparadas para enfrentar os desafios do mercado e poderão se destacar em processos seletivos de grandes empresas. Além disso, o bootcamp proporciona um ambiente de aprendizado colaborativo, onde as alunas terão a oportunidade de interagir com outras mulheres que compartilham os mesmos interesses, criando uma rede de apoio importante para o futuro profissional de cada uma. Como Se Inscrever? A inscrição para o DataEX Bootcamp Data Women Engineers 2025 pode ser feita diretamente na página oficial do programa: DataEX Bootcamp. Lembre-se de que as inscrições vão até o dia 31 de dezembro de 2024 e as vagas são limitadas, então não perca tempo! Dúvidas? Se você tem alguma dúvida ou precisa de mais informações, não hesite em entrar em contato com a equipe organizadora através do e-mail treinamentos@dataex.com.br. A equipe estará disponível para esclarecer todas as suas perguntas.DAPR, KEDA on ARO (Azure RedHat OpenShift): passo a passo
Veja também o artigo AKS: Configurando DAPR, KEDA no AKS Neste artigo, teremos foco nas configurações necessárias para rodar DAPR, KEDA on ARO (Azure RedHat OpenShift). Desta forma, aproveitei para montar este repositório no GitHub chamado "App-Plant-Tree" que cobre conceitos sobre Arquitetura Cloud-Native combinando as seguintes tecnologias: Go - Producer/Consumer App Distributed Application Runtime - DAPR Kubernetes Event Driven Autoscaling - KEDA Azure RedHat OpenShift (ARO) Azure Container Registry (ACR)How to Delete Microsoft Teams Cache for All Users via PowerShell
Improve Microsoft Teams performance by deleting the cache for all users. This article provides detailed steps on how to clear the cache, which can reduce clutter and improve application speed. By following these steps, you can ensure that your Microsoft Teams application is running smoothly and efficiently.
