Eu descrevi uma
entrevista típica de
codificação anteriormente. Além da codificação, quase sempre há uma pergunta sobre o design do sistema. Projeto de sistema (grande). No caso de entrevistas sobre SRE, essa é uma fera ainda mais interessante (quanto a mim) - NALSD. Projeto de sistema grande não abstrato. A principal diferença entre SWE e SRE está justamente nessas letras “NA”.
Qual é a diferença e como se preparar para isso? Vejamos um exemplo. Como exemplo, pegaremos algo muito material, algo que ninguém jamais pedirá para uma entrevista real (no Google) :)
Por exemplo - vamos criar uma biblioteca. Para livros de papel, o habitual. O texto inteiro abaixo foi escrito em uma sessão em cerca de uma hora para mostrar aproximadamente o que você pode fazer e o que é importante fazer. Então, perdoe-me pela confusão, mas acho que sim (e, portanto, existe).
Pergunta NALSD: crie uma biblioteca pública.
Primeiro, estamos interessados nas características da carga ou fazemos uma suposição razoável. Como se trata de um sistema escalável, é uma cidade mínima de um milhão de pessoas. Vale a pena considerar as opções - um prédio grande ou bibliotecas distritais mais armazenamento. Parece-me que o último é mais razoável. Especialmente se não uma cidade, mas uma cidade.
Portanto, focaremos no momento o sistema de uma cidade (com algumas reservas, podemos aplicar um mecanismo semelhante em um nível mais alto para expandir para muitas cidades). Então, a cidade é um milhão de pessoas. Arredondamos os números para a conveniência das estimativas - que haja 1 milhão de leitores prováveis. Os leitores vão ler a qualquer momento, independentemente um do outro. Então, podemos descobrir isso como um simples processo de Poisson. Porém, a contagem "on the run" normalmente será difícil, portanto, execute outra etapa de simplificação e apenas 1% dos leitores desejarão fazer um livro por dia. No total, para cálculos adicionais, levamos 10.000 livros por dia.
Nossa tarefa é oferecer a possibilidade de emitir 10.000 livros por dia (além de devolver os mesmos 10.000 em qualquer outro dia no futuro, a propósito) na cidade de mais de um milhão. Neste ponto, a questão da mono-biblioteca ou distrito já está desaparecendo (a propósito, para que todo o milhão seja um potencial leitor, eles devem poder chegar à biblioteca em um período de tempo razoável, caso contrário, o desejo de levar o livro certamente cairá com o tempo limite). Portanto, precisamos avaliar a capacidade de cada biblioteca local. É certo fazer isso levando em consideração a densidade e a acessibilidade da população, mas como isso não afeta muito o sistema em si, para simplificar os cálculos, vamos imaginar que os colocamos uniformemente. Mas isso ainda não significa como podemos compartilhá-los. Obviamente, colocar 10.000 bibliotecas com um livro uniformemente pela cidade não faz sentido; portanto, você precisa entender o que faz sentido. Saímos para o nível abaixo.
Então, uma biblioteca. Para que faça sentido, a maioria dos que vêm devem encontrar o livro de que precisam. Isso significa que precisaremos manter um registro e uma previsão das consultas mais populares e manter esses livros prontos. Então, precisamos manter o sortimento em princípio. Imediatamente, eu diria que uma biblioteca local deve ter pelo menos 1000 itens, os mais altos deles em uma infinidade de cópias, mais os melhores, menos os de cauda. O livro médio em nossa biblioteca é lido de 3 dias a 2 semanas (de fato, a característica depende do livro, é necessária uma análise separada aqui), consideramos o valor igual à semana média e seguimos em frente. Ou seja, o livro retirado está ausente por cerca de uma semana, portanto, os livros mais importantes precisam ser armazenados por uma semana (eles começarão a se recuperar dos retornos).
Vamos considerar um fator de inflação médio de 6. Portanto, a capacidade de armazenamento começa em 6.000 livros. Menos significa que este é apenas um pequeno tampo, o que ainda pode ajudar em alguns casos (por exemplo, uma ilha com "crepúsculo" em um supermercado perto da sala de jogos infantil), mas vamos deixá-lo do lado de fora por enquanto.
No estado de "equilíbrio", eles retornam e levam aproximadamente um dia aproximadamente, mais ou menos a dispersão, mas ainda precisamos da capacidade de aceitar um número aumentado de números de pico de retorno (por exemplo, devido a sincronização externa, como feriados ou uma mudança de moda). É isso mesmo - simular. Mas aqui e agora tomaremos um terço como reserva. No total, apoiamos 6.000 livros disponíveis para emissão, além de um local para outros 2.000 em reserva.
Portanto, precisamos de uma unidade que possa armazenar 8000 livros. O reabastecimento diário é muito caro, o que significa que dura uma semana ou duas. Duas semanas, 6.000 livros, com um viés de retorno, isso é cerca de 300 por dia. No momento da abertura, podemos pontuar todos os 8000 livros para criar o 2000 inicial em circulação antes dos primeiros retornos. 2000 por 3 dias = cerca de 600 livros por dia, mais buffer = 800 livros por dia.
Vamos estimar a largura de banda e os limites de armazenamento. Um livro ocupa uma média de 2 centímetros de espaço linear, 8000 livros - 160 metros. gire 4 vezes na vertical, 40 metros. Arrombamos até racks de 5 metros, temos 8 racks de 4 prateleiras de 5 metros de comprimento. Um bibliotecário (ou um robô-bibliotecário) poderá trabalhar com dois racks, a extração de um livro levará até 5 segundos para alcançá-lo, 5 segundos para sair ou colocar o livro, 5 segundos ao contrário, por um total de 15 segundos. 4 bibliotecários nos fornecerão aproximadamente 15 livros por minuto, no máximo, ou seja, 900 livros por hora a partir do armazém aproximadamente.
Adicionamos tempo para processar a solicitação (10s), pesquisar (5s), entrar no sistema de recebimento e emissão (2s) => 400 livros por hora. Portanto, o armazenamento em seu pico pode emitir 400 livros por hora, portanto, 800 livros por dia são alcançáveis em 2 horas úteis.
Agora, consideramos outras características: para distribuir 400 livros por hora por 4 pessoas, é necessário acomodar 100 pessoas na sala de espera em uma fila em frente à janela de processamento, para que essas pessoas não criem multidões na entrada e na saída. Ou seja, o grupo de entrada deve passar 400 pessoas por hora nas duas direções. Acontece que o limitador principal nem será o armazenamento, mas a capacidade do salão e do grupo de entrada.
Isso significa que será possível encontrar a proporção ideal de armazenamento e armazenamento com cálculos mais precisos.
Assim, com a unidade resolvida, retornamos ao nível acima. Estimamos a carga total na biblioteca em cerca de 10.000 livros por dia, contamos uma unidade com 800 livros por dia, ou seja, precisamos de 12,5 unidades. Com a distribuição geográfica pela cidade, uma ou duas unidades alternativas (nos limites da cidade) ou até 3-4 (dentro) serão acessíveis a cada leitor, o que permite suavizar levemente os picos de tráfego e / ou aumentar a demanda por posições específicas.
Também sabemos que, a qualquer momento, qualquer biblioteca pode ser fechada (incêndio, inspeção sanitária, pintura das alças dos refrigeradores ou algo mais), com um aumento no número deles, a probabilidade de dois cair fora da vida coincide, por isso precisamos de uma unidade sobressalente para a cada 5-6 unidades. No total, 15 unidades devem garantir o desempenho necessário, desde que mantenham o estoque estimado em seus armazéns.
Para manter o estoque estimado, precisamos atualizar uma vez por semana ou duas (pensamos acima de duas) cerca de metade do sortimento para acompanhar as tendências e assim por diante. Isso significa que cada unidade precisa transportar e exportar 4.000 livros a cada duas semanas. A cada importação e exportação, esses mesmos 4.000 livros devem ser removidos do repositório e outros são colocados lá. A 400 livros por hora, a atualização do sortimento levará 10 horas com carga máxima. O que, ao que parece, ainda não é tão ruim, mais uma vez, com o carregamento em massa, muitas coisas vão mais rapidamente, no entanto, manter a variedade leva 5 vezes mais do que trabalhar com a população.
O livro médio (2 cm * 20 cm * 30 cm) é de cerca de 1,5 l, ou seja, 4000 livros = 6 metros cúbicos. Cabe facilmente em uma gazela. O peso de um metro cúbico de papel é de 600 kg, ou seja, 6 metros cúbicos é de 3,6 toneladas. A capacidade de carga da gazela é de uma tonelada e meia, portanto serão necessárias três gazelas. Mais um backup. Temos 15 unidades, atualizamos a cada 2 semanas, com uma distribuição uniforme, estamos no limite, temos que adicionar outra gazela.
E não tivemos tempo para pensar sobre onde e onde essas gazelas foram transportadas, para que os armazéns dos fornecedores e os pontos de descarga de livros que perdessem relevância aparecessem no diagrama ...
Então o tempo acabou. O que é tão anormal na pergunta NALSD? Escalabilidade deve estar em qualquer projeto de sistema grande. O principal é
concretude .
Fiz muitas suposições e suposições acima, mas todas as estimativas subsequentes foram baseadas nas anteriores. Para números, também tentei dar "como avaliar corretamente", no entanto, é muito fácil esquecer de fazê-lo, você se cansa e esquece. Ainda é muito fácil manter algum número da memória, sem explicação ... Mas, como o design é concreto, se alguma das suposições for incorreta, ela poderá ser corrigida e recontada mais tarde.
Como me lembro agora, em minha entrevista com as estimativas, tirei um IOPS de um disco de 600, simplesmente porque o otimizei recentemente e trabalhei com uma matriz, onde _array_ distribuiu 600 IOPS ... O entrevistado me perguntou um pouco surpreso: 600 IOPS em disco? : DDurante a entrevista, o entrevistador pode corrigir qualquer uma de suas suposições. Ou adicione algum tipo de restrição (que você não conhecia, não pensava, não perguntava ou apenas a mudança usual de TK em tempo real). Ao mesmo tempo, como você está operando exclusivamente com números específicos, isso será apenas uma atualização trivial dos números.
Se o ajuste da suposição causa um redesenho do sistema, isso é um erro de design, um ajuste incorreto ou está além da aplicabilidade do sistema, o que também não é uma situação rara na vida real. É importante não perder esses momentos e avaliar os valores recebidos quanto à realidade durante a fase de projeto e com quaisquer ajustes.
Como SRE, somos obrigados a pensar em termos de escala de sistemas reais sob as limitações reais de hardware real. Pode haver um excelente
algoritmo que troque enormes custos de tempo por uma pequena quantidade de memória ... Mas, ainda assim, você não pode colocar um petabyte de RAM no núcleo de um processador em condições reais. Portanto, se temos um petabyte de RAM, temos pelo menos dez mil processadores. Ou vinte. Ou trinta. E devemos procurar o melhor, não global, mas aqui e agora, nas condições dadas.
Você não precisa se lembrar dos números exatos, mas deve ter uma idéia da ordem: o mesmo IOPS, que o HDD tem cerca de cem, e o SSD, centenas de milhares. Mas essas centenas de milhares acompanham a razão entre o custo de um terabyte de HDD e o custo de um terabyte de SSDs como um em três a quatro. E isso não conta o equipamento - um lugar no rack, lâminas para eles, portas nos switches e outras coisas que deixam de ser um centavo quando a conta chega a petabytes.
Agora, recoste-se um pouco na cadeira, relaxe e tente criar um sistema para fornecer ovos de galinha frescos por assinatura.
Se houver um desejo de compartilhar com colegas de língua inglesa, existe uma
opção em inglês (assim como no
hub em
inglês ).