O caso de uso de atendimento ao paciente de missão crítica que se tornou uma odisseia do Kubernetes

O tempo de inatividade pode levar a consequências sérias.

Essas palavras são mais verdadeiras para empresas no campo da tecnologia médica do que na maioria dos outros setores – no caso delas, as "consequências sérias" podem literalmente incluir a morte. Recentemente, tivemos a oportunidade de dissecar a pilha de tecnologia de uma empresa que busca transformar a manutenção de registros médicos de caneta e papel para dados digitais seguros que podem ser acessados a qualquer hora e em qualquer lugar do mundo. Esses dados variam de informações do paciente a diretrizes de cuidados, marcadores biológicos, análises médicas, registros históricos e tudo o mais compartilhado entre equipes de saúde.

Desde o início, a empresa procurou responder a uma questão aparentemente simples: “Como podemos ajudar os profissionais de saúde a registrar dados facilmente em tempo real?” No entanto, à medida que a empresa cresceu, a necessidade de escalar e disponibilizar dados constantemente tornou a solução desse desafio cada vez mais complexa. Aqui descrevemos como a jornada tecnológica da empresa os levou a adotar o Kubernetes e o NGINX Ingress Controller .

Tech Stack em resumo

• SO – Linux
• Orquestração de contêineres – Microsoft Azure Kubernetes Service
• Rede – Kubernetes , NGINX Ingress Controller baseado em NGINX Plus
• Linguagem/framework de desenvolvimento de software – .Net 
• Monitoramento, observabilidade e alerta – Prometheus
• Painel de monitoramento – Grafana
• Registro – Grafana Loki
• Banco de dados – Serviço SQL do Azure
• Servidor de aplicativos – Azure App Service , .Net
• Mensagens e streaming – Azure Event Hubs
• Cache – Redis
• Segurança – NGINX App Protect
• Localização e infraestrutura – Duas zonas de disponibilidade, 2 clusters Kubernetes, 15–20 nós, 60–100 pods 
• DevOps – Serviços Azure DevOps

Aqui está uma olhada em onde o NGINX se encaixa em sua arquitetura:

O problema com o papel

Capturar o status do paciente e informações sobre cuidados em intervalos regulares é uma tarefa essencial dos profissionais de saúde. Tradicionalmente, eles registravam as informações dos pacientes em papel ou, mais recentemente, em laptops ou tablets. Existem algumas desvantagens sérias:

• Os profissionais de saúde podem interagir com dezenas de pacientes por dia, por isso geralmente não é prático escrever notas detalhadas ao fornecer cuidados. Como resultado, os trabalhadores acabam escrevendo suas anotações no final do turno. Nesse ponto, o cansaço mental e físico faz com que seja tentador registrar apenas comentários genéricos.
• Os trabalhadores também devem confiar em sua memória de detalhes sobre o comportamento do paciente. Imprecisões podem mascarar padrões que facilitam o diagnóstico de problemas de saúde maiores se documentados de forma correta e consistente ao longo do tempo.
• Registros em papel não podem ser facilmente compartilhados entre departamentos dentro de um único departamento, muito menos com outras entidades, como paramédicos, equipes de pronto-socorro e seguradoras. A situação não é muito melhor com laptops ou tablets se eles não estiverem conectados a um armazenamento de dados central ou à nuvem.

Para enfrentar esses desafios, a empresa criou um sistema simplificado de registro de dados que fornece atalhos para acessar informações do paciente e registrar eventos comuns, como dispensação de medicamentos. Essa facilidade de acesso e uso torna possível registrar as interações dos pacientes em tempo real, à medida que elas acontecem.

Todos os dados são armazenados em sistemas de nuvem mantidos pela empresa, e o aplicativo se integra a outros sistemas de registros médicos eletrônicos para fornecer uma visão longitudinal abrangente dos comportamentos dos residentes. Isso ajuda os cuidadores a fornecer melhor continuidade do cuidado, cria um registro histórico seguro e pode ser facilmente compartilhado com outros sistemas de software de saúde.

Médicos e outros especialistas também usam a plataforma ao admitir ou interagir com pacientes. Há um registro de preferências e necessidades pessoais que acompanham o paciente para qualquer unidade. Eles podem ser usados para ajudar os pacientes a se sentirem confortáveis em um novo ambiente, o que melhora resultados como o tempo de recuperação.

Existem requisitos legais rigorosos sobre por quanto tempo as empresas devem armazenar dados de pacientes. Os desenvolvedores da empresa construíram o software para oferecer disponibilidade extremamente alta com SLAs de tempo de atividade muito melhores do que aqueles de aplicativos de nuvem genéricos. Manter uma ambulância esperando porque o arquivo de um paciente não carrega não é uma opção.

A viagem da garagem para a nuvem e para o Kubernetes

Como muitas startups, a empresa inicialmente economizou dinheiro executando o primeiro aplicativo de prova de conceito em um servidor na casa de um cofundador. Quando ficou claro que a ideia tinha força, a empresa migrou sua infraestrutura para a nuvem em vez de gerenciar o hardware em um data center. Sendo uma loja Microsoft, eles escolheram o Azure. A arquitetura inicial executava aplicativos em máquinas virtuais (VMs) tradicionais no Azure App Service, um serviço gerenciado de entrega de aplicativos que executa o servidor web IIS da Microsoft. Para armazenamento e recuperação de dados, a empresa optou por usar o SQL Server da Microsoft em execução em uma VM como um aplicativo gerenciado.

Depois de vários anos operando na nuvem, a empresa estava crescendo rapidamente e enfrentando dificuldades de escala. Era preciso escalar infinitamente, e horizontalmente em vez de verticalmente porque o último é lento e caro com VMs. Esse requisito levou naturalmente à conteinerização e ao Kubernetes como uma possível solução. Outro ponto a favor da conteinerização é que os desenvolvedores da empresa precisam enviar atualizações para o aplicativo e a infraestrutura com frequência, sem correr o risco de interrupções. Com notas de pacientes sendo constantemente adicionadas em vários fusos horários, não há tempo de inatividade natural para enviar alterações para a produção sem o risco de os clientes serem afetados imediatamente por falhas.

Um ponto de partida lógico para a empresa foi a oferta de Kubernetes gerenciado da Microsoft, o Azure Kubernetes Services (AKS). A equipe pesquisou as melhores práticas do Kubernetes e percebeu que precisava de um controlador Ingress em execução na frente de seus clusters Kubernetes para gerenciar com eficiência o tráfego e os aplicativos em execução em nós e pods no AKS.

O roteamento do tráfego deve ser flexível, mas preciso

A equipe testou o controlador Ingress padrão do AKS, mas descobriu que seus recursos de roteamento de tráfego simplesmente não conseguiam entregar atualizações aos clientes da empresa da maneira necessária. Quando se trata de atendimento ao paciente, não há espaço para ambiguidade ou informações conflitantes – é inaceitável que um profissional de saúde veja uma bandeira laranja e outro uma bandeira vermelha para o mesmo evento, por exemplo. Portanto, todos os usuários em uma determinada organização devem usar a mesma versão do aplicativo. Isso representa um grande desafio quando se trata de atualizações. Não há um momento natural para fazer a transição de um cliente para uma nova versão, então a empresa precisava de uma maneira de usar regras no nível do servidor e da rede para encaminhar diferentes clientes para diferentes versões do aplicativo.

Para conseguir isso, a empresa executa a mesma plataforma de backend para todos os usuários de uma organização e não oferece multilocação com segmentação na camada de infraestrutura dentro da organização. Com o Kubernetes, é possível dividir o tráfego usando rotas de rede virtuais e cookies em navegadores, juntamente com regras de tráfego detalhadas. No entanto, a equipe técnica da empresa descobriu que o controlador Ingress padrão do AKS pode dividir o tráfego apenas em uma base percentual, não com regras que operam no nível da organização do cliente ou do usuário individual, conforme necessário.

Em sua configuração básica, o NGINX Ingress Controller baseado no NGINX Open Source tem a mesma limitação, então a empresa decidiu migrar para o NGINX Ingress Controller mais avançado baseado no NGINX Plus, um produto de nível empresarial que oferece suporte ao controle granular de tráfego. Encontrar recomendações do NGINX Ingress Controller da Microsoft e da comunidade Kubernetes com base no alto nível de flexibilidade e controle ajudou a solidificar a escolha. A configuração oferece melhor suporte à necessidade da empresa de gerenciamento de pods (em oposição ao gerenciamento de tráfego clássico), garantindo que os pods estejam sendo executados nas zonas apropriadas e que o tráfego seja roteado para esses serviços. Às vezes, o tráfego é roteado internamente, mas na maioria dos casos de uso, ele é roteado de volta por meio do NGINX Ingress Controller por motivos de observabilidade.

Aqui há dragões: Monitoramento, Observabilidade e Desempenho de Aplicações

Com o NGINX Ingress Controller, a equipe técnica tem controle total sobre a experiência do desenvolvedor e do usuário final. Depois que os usuários efetuam login e estabelecem uma sessão, eles podem ser imediatamente encaminhados para uma nova versão ou revertidos para uma versão mais antiga. Os patches podem ser enviados simultaneamente e quase instantaneamente para todos os usuários de uma organização. O software não depende da propagação de DNS ou atualizações na rede na plataforma de nuvem.

O NGINX Ingress Controller também atende aos requisitos da empresa para monitoramento granular e contínuo. O desempenho do aplicativo é extremamente importante na área da saúde. Latência ou tempo de inatividade podem prejudicar o sucesso do atendimento clínico, especialmente em situações de vida ou morte. Após a mudança para o Kubernetes, os clientes começaram a relatar tempo de inatividade que a empresa não havia percebido. A empresa logo descobriu a origem do problema: O Serviço de Aplicativo do Azure depende de dados amostrados. A amostragem é boa para médias e tendências amplas, mas ignora completamente coisas como solicitações rejeitadas e recursos ausentes. Também não mostra os picos de uso que geralmente ocorrem a cada meia hora, quando os cuidadores fazem check-in e registram os dados dos pacientes. A empresa estava obtendo apenas uma imagem incompleta da latência, fontes de erro, solicitações incorretas e serviço indisponível.

Os problemas não pararam por aí. Por padrão, o Azure App Service preserva os dados armazenados por apenas um mês – muito aquém das dezenas de anos exigidas por leis em muitos países.  Expandir o armazenamento de dados conforme necessário para preservação mais longa era proibitivamente caro. Além disso, a solução do Azure não consegue ver o interior da pilha de rede do Kubernetes. O NGINX Ingress Controller pode monitorar parâmetros de infraestrutura e de aplicativo enquanto lida com tráfego de Camada 4 e Camada 7.

Para monitoramento de desempenho e observabilidade, a empresa escolheu um banco de dados de séries temporais Prometheus anexado a um mecanismo de visualização e painel Grafana. A integração com o Prometheus e o Grafana é pré-integrada ao plano de dados e controle do NGINX; a equipe técnica precisou fazer apenas uma pequena alteração na configuração para direcionar todo o tráfego pelos servidores Prometheus e Grafana. As informações também foram encaminhadas para um banco de dados de registro Grafana Loki para facilitar a análise de registros e dar à equipe de software mais controle sobre os dados ao longo do tempo. 

Essa configuração também protege contra incidentes que exigem amostragem de dados extremamente frequente e de alto volume para solução de problemas e correção de bugs. Lidar com esses tipos de incidentes pode ser custoso com os sistemas de monitoramento de aplicativos fornecidos pela maioria das grandes empresas de nuvem, mas o custo e a sobrecarga do Prometheus, Grafana e Loki neste caso de uso são mínimos. Todos os três são produtos estáveis de código aberto que geralmente exigem pouco mais do que patches após o ajuste inicial.

Mantenha o curso: Foco em alta disponibilidade e segurança

A empresa sempre teve um foco duplo: na segurança para proteger um dos tipos de dados mais sensíveis que existem e na alta disponibilidade para garantir que o aplicativo esteja disponível sempre que necessário. Na mudança para o Kubernetes, eles fizeram algumas mudanças para aumentar ambas as capacidades.

Para obter a mais alta disponibilidade, a equipe técnica implanta um projeto de infraestrutura distribuída ativa-ativa, multizona e multigeográfica para redundância completa, sem nenhum ponto único de falha. A equipe mantém uma infraestrutura ativa-ativa N+2 com clusters Kubernetes duplos em duas geografias diferentes. Em cada região geográfica, o software abrange vários data centers para reduzir o risco de tempo de inatividade, fornecendo cobertura em caso de falhas em qualquer camada da infraestrutura. Regras de afinidade e antiafinidade podem redirecionar instantaneamente usuários e tráfego para pods ativos e em execução para evitar interrupções de serviço. 

Por segurança, a equipe implanta um firewall de aplicativo da web (WAF) para proteger contra solicitações incorretas e agentes mal-intencionados. A proteção contra o OWASP Top 10 é uma aposta básica fornecida pela maioria dos WAFs. Ao criar o aplicativo, a equipe pesquisou vários WAFs, incluindo o Azure WAF nativo e o ModSecurity. No final, a equipe escolheu o NGINX App Protect com seu WAF em linha e proteção contra negação de serviço distribuída (DDoS).

Uma grande vantagem do NGINX App Protect é sua colocalização com o NGINX Ingress Controller, que elimina um ponto de redundância e reduz a latência. Outros WAFs devem ser colocados fora do ambiente do Kubernetes, contribuindo para latência e custo. Até mesmo atrasos minúsculos (digamos, 1 milissegundo extra por solicitação) aumentam rapidamente com o tempo.

Missão secundária surpresa: Sem tempo de inatividade para desenvolvedores

Após concluir a transição para o AKS para a maior parte de sua infraestrutura de aplicativos e redes, a empresa também percebeu melhorias significativas em sua experiência de desenvolvedor (DevEx). Os desenvolvedores agora quase sempre identificam problemas antes que os clientes percebam qualquer problema. Desde a mudança, o volume de chamadas de suporte sobre erros caiu cerca de 80%!

As equipes de segurança e desempenho de aplicativos da empresa têm um painel detalhado do Grafana e alertas unificados, eliminando a necessidade de verificar vários sistemas ou implementar gatilhos para textos de aviso e chamadas provenientes de diferentes processos. As equipes de desenvolvimento e DevOps agora podem enviar atualizações de código e infraestrutura diariamente ou até mesmo várias vezes por dia e usar padrões azul-esverdeados extremamente granulares. Anteriormente, eles enviavam atualizações uma ou duas vezes por semana e tinham que ficar lá em períodos de baixo uso, uma proposta estressante. Agora, o código é enviado quando pronto e os desenvolvedores podem monitorar o impacto diretamente observando o comportamento do aplicativo.

Os resultados são positivos em todos os aspectos: aumento na velocidade de desenvolvimento de software, melhora no moral dos desenvolvedores e mais vidas salvas.