BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias Entrevista com Ben Sigelman sobre "Sistemas Profundos" de microservices

Entrevista com Ben Sigelman sobre "Sistemas Profundos" de microservices

Favoritos

O InfoQ conversou recentemente com Ben Sigelman, CEO da LightStep e fundador dos projetos OpenTracing e OpenTelemetry, para discutir os desafios do gerenciamento de microservices em sistemas profundos, onde proprietários de serviços individuais interagem com um grande número de dependências de serviços que não possuem acesso.

Conforme descrito na recente palestra de Sigelman na Systems @ Scale, o problema reside na diferença entre controle e responsabilidade e nas maneiras pelas quais as equipes podem determinar com precisão o que está acontecendo dentro e entre cada serviço. As equipes de desenvolvimento geralmente controlam vários serviços que chamam ou são chamados por outros, porém, herdam a responsabilidade desses outros serviços conectados, apesar de não serem dessas equipes. À medida que os serviços fazem as chamadas, a cadeia de comunicação cresce profundamente e complica a capacidade de uma equipe de diagnosticar rapidamente onde especificamente ocorre um erro ou gargalo.

Ao contrário do monitoramento de desempenho padrão, os problemas de desempenho nos microservices podem surgir devido a alterações em um padrão de comunicação. Por exemplo, o monitoramento pode indicar uma lentidão em um serviço quando o código é executado dentro dos parâmetros estabelecidos, mas o problema é causado por uma diferença no serviço de chamada que aumentou significativamente a demanda.

A solução para problemas nos sistemas de microservices resultam da ativação da observabilidade e controle nos serviços, para identificar rapidamente onde existem problemas de desempenho, dentro ou entre os microservices, removendo ambiguidades. "Apontar dedos ocorre quando os dados não estão claros", explica Sigelman. "Quando ocorre um problema, existe um termo MTTI, que significa Tempo Médio Para Inocência (do inglês, Mean-Time-To-Innocence). Quando os dados são claros, o MTTI é baixo e, quando não há dados ou os dados não são claros, o MTTI é alto". MTTI alto leva a longas reuniões com muitas pessoas para analisar a causa raiz e a culpa, o que pode levar a altos custos de reunião.

A observabilidade significa a capacidade de ver rapidamente o que está acontecendo dentro e entre os serviços, sem exigir uma alteração dos mesmos. O controle é a capacidade de agir sobre o que observamos. O objetivo da observabilidade é ganhar controle. Tanto a observabilidade quanto o controle se beneficiam da padronização do OpenTelemetry, que permite que diferentes ferramentas extraiam as métricas e KPIs corretos, da maneira certa, para que as equipes possam agir de acordo com o que observam.

A transcrição das perguntas e respostas do InfoQ com Ben Sigelman pode ser encontrada a seguir:

InfoQ: Qual é o papel entre o OpenTracing e o OpenTelemetry?

Ben Sigelman: OpenTelemetry é o padrão para dados de telemetria, sua estrutura e o que reunir. Em essência, o sistema inicia o fluxo de captação de telemetria. O OpenTracing era semelhante, porém mais fechado, concentrando-se especificamente na instrumentação de rastreamento distribuído. Para alguém que começou hoje, direcionaria a atenção para o OpenTelemetry, pois faz mais e leva o OpenTracing adiante.

InfoQ: Na palestra foi abordado o papel dos "sistemas profundos". Por que os sistemas estão se tornando "profundos"? Que problema conseguem resolver e que novos problemas criam?

Sigelman: Quando dizemos microservices, todos pensam nos serviços, não no sistema como um todo. Se possuirmos muitos microservices, eles crescem profundamente, não há apenas vários serviços, mas também muitas camadas. Se possuirmos 500 serviços, não é como se um roteador ou gateway de API conversasse com todos. Os serviços conversam entre si, e um serviço só pode ser tão rápido quanto a sua dependência mais lenta, portanto, cada camada adiciona uma nova maneira das coisas darem errado.

A razão pela qual a indústria mudou para microservices foi para facilitar a autonomia e a independência entre as equipes de devops, embora ironicamente a profundidade desses sistemas geralmente cria atritos, ineficiências e reduções da velocidade. Isso ocorre porque é muito difícil rastrear problemas entre os microservices, entender as maneiras complexas de dependências um do outro e determinar qual serviço precisa de ajustes para restaurar um SLO (objetivo de nível de serviço).

InfoQ: Como o controle e a responsabilidade são considerados nos microservices?

Sigelman: Em qualquer sistema, somos responsáveis pelas dependências, pelas dependências das dependências, e assim por diante, mas só controlamos os serviços que podemos criar e implantar. Em um sistema profundo, o tamanho da árvore de dependência aumenta geometricamente com a profundidade do sistema, e há muitas métricas e logs para filtrar usando as ferramentas convencionais. A única maneira de resolver isso é aproveitar os dados de rastreamento no núcleo do sistema de observabilidade. Dados de rastreamento são os únicos dados com contexto sobre as camadas do sistema.

InfoQ: Para o Java, a equipe do OpenJDK recentemente gravou o Flight Recorder/Mission Control, que é o monitoramento de desempenho de uma JVM com pouca sobrecarga. Qual a diferença para o OpenTelemetry e onde cada um deles se destaca?

Sigelman: O Flight Recorder/Mission Control é ótimo para analisar uma JVM específica, mas os microservices são diferentes. A maioria dos incêndios técnicos que ocorrem nas organizações são resultado de um push do código ou configuração. Por exemplo, uma equipe acima altera a maneira como chamam nosso serviço para 100 vezes ao invés de apenas 1, talvez precisem parar de fazer isso. A criação de perfil pode mostrar que o código está sendo processado muitas vezes, mas não mostrará por que está operando com tanta frequência e como está conectado a outros serviços. Porém, se precisarmos criar um perfil de uma JVM independente, essa ferramenta será fenomenal.

InfoQ: Se o objetivo do OpenTelemetry é obter observabilidade desses serviços profundos, quais são os aspectos principais que as equipes devem observar?

Sigelman: Os serviços devem medir o sucesso nos olhos dos consumidores. Isso significa estabelecer um SLI ou SLO que mede o sucesso: coisas como tempo de resposta, custo de erros e assim por diante. Devemos saber com o que os consumidores se preocupam e ter objetivos precisos com base nestes dados. Se as investigações começarem com um SLI/SLO, o sistema de observabilidade saberá qual o problema que estamos tentando solucionar, o que reduz bastante o tamanho e o escopo das possíveis causas principais.

InfoQ: Quando as equipes estabelecem o que significa sucesso para os consumidores, que conceitos costumam parecer atraentes, mas na verdade levam a problemas?

Sigelman: As métricas básicas do sistema de rastreamento, como CPU e RAM, geralmente não são indicativas do problemas de raiz. Outra questão são as equipes com microservices que pensam que o acoplamento flexível significa total independência e autonomia para tomar decisões completamente diferentes. A Netflix, por exemplo, possui um "caminho pavimentado" de ferramentas e estruturas que funcionam bem. Quando as pessoas escolhem esse caminho pavimentado, têm suporte de linguagens, bibliotecas, verificações de segurança e outras assistências. Assumir total autonomia e seguir esse caminho, sair do menu para algo que ninguém mais conhece dificulta o controle, porque outras equipes não podem nos ajudar de maneira fácil.

InfoQ: Para quem precisa analisar microservices complexos, quais são as ferramentas específicas que podem ajudá-los?

Sigelman: Como um primeiro passo para a observabilidade moderna, o OpenTelemetry pode ser integrado aos sistemas para coletar dados de telemetria de alta qualidade. As equipes podem fazer isso sem alterações no código, por meio do Auto Instrumentation Agent. Este agente ajuda a obter acesso aos dados, mas não fornece ferramentas analíticas. Para aqueles que desejam analisar e visualizar esses dados, recomendaria o versão gratuita LightStep gratuito.

Tanto eu quanto Liz Fong-Jones, da Honeycomb, discutimos regularmente o papel do gerenciamento dos microservices em escala no Twitter.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT