A Okta está constantemente evoluindo nossa infraestrutura de nuvem para atender às necessidades de nossos clientes. Colocamos confiabilidade e escalabilidade no centro de nossas decisões de design para serviços que processam bilhões de autenticações por mês. Este artigo explora como um projeto recente para remover um de nossos serviços mais movimentados gerou melhorias significativas na operação e na confiabilidade.
Um vislumbre da vantagem da Okta
No passado, três serviços principais recebiam e facilitavam a maior parte do tráfego de clientes para o Workforce Identity Cloud da Okta na borda: um Application Load Balancer para proteger contra inundações de solicitações, um serviço baseado em Apache para encerramento de SSL e um serviço baseado em Nginx para roteamento e lógicas de negócios.
Esses serviços são implementados globalmente e dimensionados para lidar com grandes volumes de tráfego que a Okta processa diariamente. Embora com bom desempenho, o forte acoplamento desses serviços gradualmente se tornou um desafio operacional. Sempre procurando melhorar nossa infraestrutura, uma equipe multifuncional se propôs a reavaliar esses serviços.
Um demais?
Os clientes da Okta esperam um serviço de alto desempenho e disponível, e é imperativo que atendamos a essas expectativas. Embora processe rotineiramente inúmeros fluxos de login, estar na internet pública convida ao inesperado. Seja por iniciativa do cliente ou não, a Okta às vezes recebe grandes influxos de tráfego em um curto período de tempo.
Ao examinar de perto os serviços que operamos, determinamos que o gargalo por thread do Apache limitava nossa capacidade de lidar com grandes influxos de tráfego sem impacto e decidimos remover este serviço de nossa borda completamente. Isso moveria a arquitetura orientada a eventos do Nginx para frente em nossa pilha como um meio melhor de lidar com padrões de tráfego imprevisíveis.
Com o aumento da confiabilidade como o principal fator motivador, a oportunidade de encerrar vários centenas de servidores Apache traria uma redução significativa no esforço operacional. Entre melhorar a confiabilidade do serviço, reduzir nosso volume de agregação de logs do sistema, eliminar o esforço operacional e economizar custos, nos beneficiaríamos muito com a desativação de nosso serviço Apache.
Nossa equipe desenvolveu uma coreografia robusta para desviar o tráfego do serviço Apache e diretamente para o Nginx, permitindo-nos iterar rapidamente sobre problemas descobertos em ambientes de teste antes de aplicar gradualmente essa alteração aos nossos ambientes de produção global.
Em testes
O serviço Apache da Okta executa um aplicativo Java leve com configurações personalizadas para processar as solicitações de entrada antes de passá-las para o nosso serviço Nginx. Ao remover o Apache, tivemos que garantir que qualquer funcionalidade fornecida pelo serviço fosse recriada dentro do Nginx. Por meio de testes sintéticos, nossa equipe identificou rapidamente vários padrões de solicitações de entrada que não eram mais tratadas adequadamente com o serviço Apache removido.
O problema da “barra dupla”
Como o Apache já foi o aplicativo inicial a receber tráfego de clientes, ele continha uma lógica desenvolvida ao longo dos anos para identificar e responder adequadamente a solicitações malformadas. À medida que a infraestrutura de ponta da Okta amadureceu ao longo dos anos, essa funcionalidade foi amplamente movida para o início da stack. Ainda assim, um problema com a remoção do Apache foi rapidamente identificado — não éramos mais capazes de lidar adequadamente com solicitações contendo //.
Em ambientes de teste sem o serviço Apache, o Nginx retornava códigos de status impróprios para qualquer solicitação contendo //. Como um exemplo artificial, as chamadas de API para /api/v1/users continuaram a se comportar como esperado, mas as chamadas para //api/v1/users foram observadas retornando respostas HTTP de erro do cliente.
Nosso serviço Apache lidava com essas solicitações com uma regra de reescrita simples, mas o Nginx retornava códigos de erro para solicitações sem a reescrita, então tivemos que introduzir uma nova regra de reescrita para restaurar essa funcionalidade.
Observando a RFC 3986, este seria nosso primeiro contato com a Hyrum's Law.
O problema da “query string”
Com um conjunto robusto de testes sintéticos para validar a resolução do problema da “barra dupla”, iniciamos uma implementação faseada da remoção do serviço Apache em nossos ambientes de staging. À medida que a quantidade de tráfego processado sem o Apache aumentava gradualmente, observamos novamente o Nginx retornando códigos de resposta impróprios para certas solicitações processadas anteriormente pelo Apache sem problemas.
Como antes, descobrimos um caso em que o Apache reescrevia anteriormente solicitações mal formadas em um formato que o Nginx pudesse processar. Contra RFC 1738, o Apache estava reescrevendo strings de consulta codificadas em valores decodificados. Como um exemplo, as solicitações para /api/v1/users%3Flimit=1 estavam sendo decodificadas e passadas para o Nginx como /api/v1/users?limit=1. Sem o Apache no caminho da solicitação, o Nginx não conseguiu processar strings de consulta codificadas e retornou um erro ao cliente que originou a solicitação. Para resolver isso, uma regra de reescrita adicional foi introduzida em nossa configuração Nginx, e fomos capazes de continuar a implantação.
Várias iterações depois
Remover um serviço tão proeminente não foi uma tarefa simples, mas, em última análise, foi alcançada sem impacto sustentado ao cliente. Este esforço teve várias iterações ao longo do tempo, mas o foco no resultado permaneceu o mesmo:
- Remova um gargalo de desempenho
- Melhorar a confiabilidade do serviço
- Reduzir o trabalho operacional
Tendo concluído este esforço em todos os ambientes, os benefícios rapidamente se tornaram aparentes e a equipe já está planejando nossas próximas melhorias.
Tem perguntas sobre esta postagem do blog? Entre em contato conosco em eng_blogs@okta.com.
Explore mais Blogs de Engenharia perspicazes da Okta para expandir seu conhecimento.
Pronto para se juntar à nossa equipe apaixonada de engenheiros excepcionais? Visite nossa página de carreiras.
Desbloqueie o potencial do gerenciamento de identidade moderno e sofisticado para sua organização. Contate o departamento de vendas para obter mais informa ções.
