Ivan Kruglov, desenvolvedor principal da Booking.com, falou sobre o SlOmer DevOps com o tema SRE e, depois de falar, concordou em conversar sobre Kubernetes, Service Mesh, soluções de código aberto e "não padronizadas" na Booking.com, tomando uma xícara de café
Como o tópico do SRE se mostrou muito mais amplo, Ivan e seu colega Ben Tyler, desenvolvedor principal da Booking.com, concordaram em se tornar palestrantes do Slurm SRE, que será realizado de 3 a 5 de fevereiro de 2020 . Ele discutirá a teoria e a prática da aplicação do orçamento SLI / SLO / erro, análise post-mortem, eliminação eficaz de incidentes de TI, construção de sistemas confiáveis (monitoramento e alerta, degradação graciosa, injeção de falhas, planejamento de capacidade, prevenção de falhas em cascata) )
E agora uma palavra para Ivan.
Qual tem sido um desafio profissional interessante para você ultimamente?
Nos últimos dois anos, tenho feito duas coisas. Primeiro: fazer a nuvem interna da Booking.com. É construído no Kubernetes. Nesta ocasião, tive um relatório longo e abrangente sobre o Highload.
Tivemos uma maneira longa e interessante de como construímos nossa nuvem. Este é o meu projeto anterior, que deixei para um colega.
Agora, estou lidando com um tópico chamado Service Mesh. Este é, de fato, um tópico importante, como Big Data e Kubernetes ao mesmo tempo.
A idéia de que, por um lado, é simples, por outro lado, complexa - em uma arquitetura de microsserviço, toda a interação passa pela rede, bem, é como se fosse parte integrante dos microsserviços. E a interação em si é uma operação complexa, muita coisa pode dar errado por lá. Essa coisa toda precisa ser controlada. Em particular, restrições são impostas - se um monólito e duas funções funcionarem, e essas duas funções pudessem confiar uma na outra, porque fazem parte do mesmo processo, então agora, em teoria, os microsserviços não podem confiar uma na outra.
Como você sabe de onde vem a solicitação? Aqui está um microsserviço, uma solicitação HTTP é fornecida. Ele realmente veio do serviço do qual eu acho? E da mesma maneira, o serviço que outro serviço exige. Eu preciso ter certeza de que o serviço que eu chamo é o serviço que eu preciso, e não algum tipo de serviço falso. Nas pequenas organizações, isso provavelmente não é tão verdadeiro. E nos grandes, quando você tem milhares e dezenas de milhares de carros, não controla cada máquina. E para grandes empresas, esse é um problema bastante sério. Ou seja, digamos, tudo é construído com zero confiança. Sempre que você faz algum tipo de comunicação, deve verificar. Acontece que, no nível da interação da rede, é necessário autenticar e autorizar a operação. Todos esses são processos bastante difíceis em termos de implementação. E acontece que o Service Mesh assume essas tarefas para garantir uma interação segura. Esse é apenas um dos recursos do Service Mesh. Há muito mais - confiabilidade, monitoramento, rastreamento e outros.
E você acha que essa tecnologia é o futuro?
Service Mesh é uma tendência que está crescendo. Esta é a minha opinião pessoal. Já é bastante comum. Por exemplo, existe o Istio. Então, nas nuvens, na mesma Amazônia, apareceu o Service Mesh. Penso que todos os principais fornecedores em breve terão ou já terão um Service Mesh de pleno direito.
Ou seja, a mesma tecnologia inovadora de antes, e agora existem os Kubernetes?
Eu acho que sim. Embora seja interessante notar aqui que, na minha opinião, nem o Kubernetes nem o Service Mesh inventam algo novo. O Kubernetes pegou uma pilha de tecnologia existente e a automatizou. O Service Mesh faz aproximadamente a mesma coisa. Ele fornece novas ferramentas em uma base existente. O enviado apareceu no Service Mesh, que vou demonstrar hoje. (Observe que Ivan abordou esse problema em um discurso na Slurm DevOps Intensity ). A idéia é que o Service Mesh é um instrumento de nível superior que permite orquestrar as comunicações de uma grande frota de microsserviços. Vou explicar ... Para iniciar a arquitetura do microsserviço, você precisa, primeiro, do chamado tempo de execução - este é o local onde o aplicativo será iniciado. É isso que o Kubernetes faz. O Service Mesh o complementa, no sentido de fornecer a interação entre esses microsserviços que serão executados em tempo de execução.
Você desenvolverá essa tecnologia em um futuro próximo?
Eu posso falar por mim. Estou envolvido em infraestrutura. E em termos de infraestrutura, nos próximos anos, esse será um dos principais tópicos - Kubernetes e Service Mesh.
Eles desenvolverão em paralelo?
Certamente, porque eles se complementam. Kubernetes faz tempo de execução. O Service Mesh fornece interoperabilidade.
Mais precisamente, o Kubernetes possui alguns componentes que parecem abranger aspectos do Service Mesh. Mas em Kubernetes eles são muito básicos. Ou seja, o Kubernetes, em termos de rede, oferece apenas redes de baixo nível. Quero dizer, pacotes IP podem ir do ponto A ao ponto B. É isso. Ok, existem controladores do Ingress, há momentos de roteamento de nível superior, ou seja, não apenas interação de rede. No entanto, no Kubernetes, por exemplo, não existem mecanismos internos para garantir a confiabilidade da execução da consulta. Um exemplo muito simples. No Kubernetes, se o "under" (Pod) cair, o Kubernetes irá buscá-lo. Por padrão. Este é um mecanismo de nova tentativa. Mas, no nível da interação da rede, isso não acontece. Ou seja, se o serviço da página principal enviar uma solicitação ao serviço de cesta e, por algum motivo, isso não funcionou, a solicitação não será tentada novamente.
O Service Mesh a esse respeito adiciona funcionalidade. Ele permite que, se a solicitação falhar, repita-a novamente. Existem outros mecanismos, como a detecção de outlier. Se, por exemplo, tivermos uma frota de "lareiras" que trabalham para o serviço da "página principal" e uma frota de "lareiras" que são um serviço da "cesta". Se eles estão separados geograficamente, então pode parecer que uma parte dos "lares" vê uma parte dos "lares" e a outra parte dos "lares" vê a outra parte dos "lares". Portanto, no Service Mesh existem mecanismos que permitem criar dinamicamente uma imagem de quem está disponível para qualquer pessoa e alternar entre eles - tudo isso em tempo real. E se uma das “lareiras” tiver muita latência, jogue-a fora. Todo mundo que está “abaixo” pode decidir que, com esse “coração”, minha conversa é lenta - todo mundo é normal e tão lento - porque vou jogá-lo para fora da minha piscina. É assim que o mecanismo para detectar anomalias funciona. Quando temos dez "lareiras", nove "lareiras" funcionam sem erros e o décimo envia erros constantemente. Ou nove "lares" respondem com latência de 15 ms e um responde com latência de 400 ms. E o Service Mesh decide jogá-lo fora.
O Service Mesh também é bom para permitir a coleta de estatísticas no lado do cliente. Ou seja, temos um cliente e temos um servidor. Normalmente, as estatísticas são coletadas no lado do servidor. Bem, porque é o mais fácil. Queremos usar métricas para entender como nosso usuário interage com nosso serviço. Consequentemente, em teoria, você precisa medir no lado do cliente e não no lado do servidor. Porque existe uma grande lacuna entre eles, que é preenchida com interações de rede.
Cada componente dessa variedade inteira pode falhar.
E o Service Mesh é bom, pois coloca o agente para frente e para trás - e envia estatísticas de dois lados. E podem surgir situações quando, no lado do serviço, a latência é de 20 ms e no lado do cliente, 2 segundos. Por exemplo, no lado do servidor, coletamos estatísticas de um servidor da Web, mas temos 5% de pacotes perdidos por algum motivo. Como resultado, devido à retransmissão na pilha TCP, o cliente vê latência em 2 segundos. E no lado do servidor, ainda vemos uma latência excelente: como tudo foi enviado para o buffer, é isso! Estou bem, tenho uma latência de 20 ms. E como é o cliente ?!
E como você resolve isso?
Fundamentalmente, isso é resolvido pela instrumentação do cliente. De uma maneira boa, as estatísticas devem ser coletadas o mais próximo possível do cliente. Mas as ferramentas do cliente nem sempre são possíveis e nem sempre são convenientes.
Quais são as métricas de confiabilidade e disponibilidade da sua empresa?
Tudo é em geral padrão. Hoje vou falar sobre isso. (Nota. Ivan Speech no terceiro dia do Slurm DevOps ) Existem cinco ou seis indicadores principais. Os chamados Indicadores de Nível de Serviço: latência, durabilidade, frescor, correção ... Quando eu estava me preparando para a apresentação no Slurm, tentei encontrar casos não padronizados no Booking.com, exemplos interessantes de SLI que não se encaixavam nesse modelo. Como, em teoria, a ideia principal do SRE é baseada em uma declaração de alto nível - precisamos destacar uma métrica ou métrica que reflita a experiência do usuário. E para alguns serviços, latência, durabilidade é adequada, para outros, não. E como encontrar esse ponto de equilíbrio que refletiria a experiência do usuário - essa é uma tarefa interessante.
Que soluções únicas você viu na Booking.com quando veio trabalhar lá? Ou é tudo padrão?
Não. Temos muitas coisas que não são padrão. Vamos explicar por que não é padrão entre aspas. De onde vem o não padrão ... O não padrão geralmente vem do fato de a empresa ter encontrado um problema mais cedo que o mercado e, portanto, não existe uma solução "padrão". Nesse sentido, a Booking.com, sendo uma empresa que atua no mercado desde 1997 e cresceu para tal tamanho, enfrentou uma vez vários problemas que não foram resolvidos.
Por exemplo, o Google. De acordo com minhas observações, parece algo assim. No interior, eles fazem grandes desenvolvimentos, que são apresentados em público em cinco ou dez anos. Por exemplo, conversei com os caras do Google que corrigiram o kernel do Linux. Então tive alguns problemas na pilha TCP. Eu digo a eles: “Esse é claramente o principal problema. Como você luta contra isso? Eles dizem: “Ah, então temos um núcleo corrigido. Aqui podemos ajustar a configuração. Em 2013, corrigimos isso. E estamos lançando em código aberto em 2018. ”
Sobre o mesmo com o Service Mesh. Também é construído à imagem da tecnologia que o Google usa internamente. Mas eles não o enviam diretamente para o código aberto. O Istio é essencialmente uma reimplementação de código aberto do seu sistema interno. Com o Kubernetes também. Na minha opinião, isso ocorre porque quando uma empresa é pioneira, ela cria soluções para si mesma. Porque é mais rápido, mais barato. O código aberto é caro. E não importa quem diga que você precisa divulgá-lo, você realmente precisará construir uma comunidade. E para construir uma comunidade, você precisa investir muito esforço. E só então o retorno irá para você. Parece-me que, por trás de qualquer "farmácia" séria, existe um marketing ainda mais sério, no qual o dinheiro é naturalmente investido.
Por que estou ... Como disse, ao resolver um problema, a empresa faz muito por si mesma. E depois colocá-lo em código aberto é bastante difícil. Você precisa cortar a lógica de negócios e vários pequenos detalhes. Temos nosso próprio serviço Service Mesh, nosso próprio sistema de monitoramento. E para divulgá-lo em código aberto, ele precisa ser refeito. A publicação de código aberto tem suas vantagens ...
Quais, por exemplo?
Marca de tecnologia, lealdade, fácil integração. Eles são importantes.
Você não pode contá-los diretamente.
Sim está certo. Não conte diretamente. Este é um investimento estratégico a longo prazo. Eu não sou a favor ou contra o código aberto. Você precisa ser equilibrado, avaliando o que a empresa fornece para a publicação de uma tecnologia específica. Equilibre a estratégia de longo e curto prazo.
Voltando à pergunta, quanto é padrão e não padrão no Booking.com. Eu vou dizer isso, não a maioria não é padrão, mas muito. Porque estávamos resolvendo problemas que ainda eram desconhecidos no mercado ou outras empresas estavam apenas no início da jornada. Apenas para a empresa, é mais fácil e rápido, e mais barato resolver os problemas por conta própria.
PS : Não é possível abordar todo o tópico do SRE em uma apresentação. Não há apenas ferramentas, há também a filosofia da abordagem. Portanto, destacamos todo um SRE Slurm intensivo para este tópico , que será realizado de 3 a 5 de fevereiro de 2020 . Os palestrantes serão Ivan Kruglov, desenvolvedor principal da Booking.com, seu colega Ben Tyler, desenvolvedor principal da Booking.com, Eduard Medvedev , CTO da Tungsten Labs, Eugene Varavva, desenvolvedor de perfil amplo do Google.