Existem muitas postagens sobre como é uma entrevista típica de codificação no Google. Mas, embora não seja tão amplamente descrito e discutido, também há muitas vezes uma entrevista de design de sistema. Para uma posição SRE, é NALSD: projeto de sistema grande não abstrato. A principal diferença entre as entrevistas SWE e SRE consiste nessas duas cartas: NA.
Então, qual é a diferença? Como se preparar para esta entrevista? Sejamos não abstratos e usemos um exemplo. Para ser mais não-abstrato, vamos pegar algo do mundo material, para que você não seja perguntado exatamente a mesma coisa na entrevista real (pelo menos, não na entrevista do Google) :)
Então, vamos projetar um sistema de biblioteca pública. Para os livros em papel, como você já viu em todos os lugares. O texto inteiro abaixo foi escrito de uma só vez em cerca de uma hora, para mostrar aproximadamente as áreas que você deve cobrir / tocar durante a entrevista. Por favor, desculpe algum distúrbio, é assim que eu penso (logo existo).
Entrevista NALSD: projetar um sistema de biblioteca pública.
Primeiro, reunimos as características da carga, seja por perguntas ao entrevistador ou fazendo um palpite razoável (sem esquecer de dizer em voz alta). Como a entrevista diz respeito a sistemas escaláveis, esperamos uma cidade com uma população grande (digamos, 1 milhão ou mais). Temos algumas opções: um prédio enorme ou bibliotecas locais mais armazenamento. Eu acho que o último é mais razoável, pois também nos permite expandir o sistema para várias cidades.
Agora vamos nos concentrar no sistema para uma única cidade; poderemos aplicar o mesmo design (com correções menores) novamente para expandi-lo para o nível do país. Então, nós temos uma cidade com mais de 1 milhão de habitantes. Para facilitar os cálculos, vamos arredondar para 1 milhão de leitores possíveis. Todo leitor quer ler algo independentemente um do outro, em momentos arbitrários no tempo. Assim, podemos modelar o fluxo de leitores como um processo de Poisson. Fazer a matemática corretamente é um pouco difícil durante o período da entrevista, então vamos simplificar mais uma vez e apenas dizer que cerca de 1% dos possíveis leitores viria a pegar um livro todos os dias. Portanto, presuma 10000 solicitações de livros por dia.
Portanto, nossa tarefa agora se tornou: fornecer a capacidade de distribuir 10.000 livros por dia (isso também significa que precisamos recuperar esses 10.000 livros mais tarde) em uma cidade com mais de 1 milhão. Essa estimativa mostra que a solução de construção única não será válida (para fornecer os livros para mais de 1 milhão de pessoas, nossa biblioteca deve ser alcançada dentro de um período de tempo razoável, caso contrário, a vontade de levar um livro expirará no engarrafamento). Então, vamos tentar adivinhar qual é o tamanho razoável para as bibliotecas locais que precisamos construir. Uma estimativa absolutamente correta envolveria densidade populacional, latências de acessibilidade, etc., mas como isso não afetará o design geral, podemos novamente simplificá-lo, considerando uma distribuição uniforme de unidades semelhantes. Ainda não sabemos o tamanho das unidades; por exemplo, poderíamos espalhar 10.000 bibliotecas com 1 livro cada uma na cidade, mas obviamente não vai funcionar. Indo um nível mais baixo.
Uma única unidade de biblioteca local. Para que seja útil, a maioria dos visitantes deve encontrar o livro que deseja. Isso significa que precisamos rastrear o uso e prever a demanda das solicitações mais populares para estar pronto para atendê-las. Além disso, devemos ter uma grande variedade de itens menos populares. Meu palpite é uma biblioteca com menos de 1000 nomes de livros, com dezenas de cópias para os mais populares e peças únicas para as caudas. O tempo médio para ler um livro em nossa biblioteca varia de 3 dias a 2 semanas (é claro, o tempo real depende do livro em si, o que, em um caso real, exigiria análises adicionais); vamos estimar uma semana por livro. Isso significa que um livro que foi entregue voltará em uma semana; portanto, devemos fornecer os principais livros por uma semana (depois de uma semana, eles são reabastecidos pelos retornos).
Suponha um fator de expansão médio de 6, o que nos levaria a uma capacidade de armazenamento unitário de 6.000 livros. Menos armazenamento significaria uma escassez nos nomes mais populares (bem, unidades menores ainda podem ser úteis - como um pequeno quiosque de shopping com “Crepúsculo”, mas vamos mantê-lo fora do nosso design agora).
Em um estado estacionário, os retornos e empréstimos todos os dias são quase semelhantes (com alguma dispersão), mas também devemos planejar retornos de pico (que podem ser eventos de sincronização externos: feriados, tendências etc.). A maneira correta é criar e executar um modelo estatístico. Mas, por enquanto, vamos manter ⅓ como um buffer. Isso significa que devemos manter 6000 livros prontos para distribuição e mais espaço para 2000.
Em resumo: precisamos de uma unidade de biblioteca com 8000 livros armazenados. Espera-se que seja caro reabastecê-lo todos os dias, portanto, devemos esperar que isso seja suficiente por uma semana ou duas. Duas semanas, 6000 livros, com possíveis retornos inclinados, são cerca de 300 livros por dia. Para o dia da abertura, podemos encher todo o estoque (8000 livros) para semear o volume inicial de 2000 livros. 2000 em 3 dias = 600 livros por dia, com buffer de inclinação = 800 livros por dia.
Vamos estimar a taxa de transferência e as limitações do nosso armazenamento. 1 livro mede cerca de 2 cm lineares de espaço, 8000 livros = 160 metros. Podemos dobrá-lo verticalmente 4 vezes, então são 40 metros lineares. Se o dividirmos em racks de ~ 5 metros, obteremos 8 racks com 4 prateleiras, cada uma com 5 metros de comprimento. Um bibliotecário (ou robô-bibliotecário) deve ser capaz de trabalhar com dois racks; uma extração de um único livro levará: 5 segundos para caminhar até as prateleiras, 5 segundos para pegar / colocar o livro em seu lugar, 5 segundos para voltar (15 segundos no total). Quatro bibliotecários fornecerão um rendimento máximo de 15 livros por minuto. Assim, uma manipulação de 900 livros por hora, no máximo.
Se também considerarmos o tempo de processamento de solicitações (10s), o tempo de pesquisa (5s), o tempo para rastrear o sistema (2s), obteremos um pico de 400 livros / hora. Portanto, devemos ser capazes de lidar com nossa estimativa de 800 livros por dia em 2 horas.
Vamos calcular outros aspectos: para poder distribuir 400 livros / hora por 4 bibliotecários, precisamos ter espaço suficiente para 100 pessoas esperando na fila, e as portas de entrada devem permitir que 400 pessoas / hora passem nas duas direções . Isso significa que nossa principal limitação seria o espaço de espera e a construção de portas.
Isso significa que devemos conseguir encontrar um equilíbrio ideal entre o espaço de armazenamento e a área de espera durante os cálculos adequados para o projeto real.
É isso neste nível, é hora de seguir em frente. Temos uma estimativa das demandas gerais da rede de bibliotecas como 10.000 livros / dia. Uma unidade é de 800 livros / dia, por isso precisamos de 12,5 unidades. Se fizermos uma distribuição geográfica uniforme, todos os leitores devem estar entre 1-2 unidades (no limite da cidade) e 3-4 (dentro da cidade). Isso daria a capacidade de suavizar um pouco os picos e / ou cobrir a escassez dos principais livros.
Também sabemos que todas as bibliotecas podem ser fechadas a qualquer momento (incêndio, inspeção, maçanetas das portas de geladeira pintadas, etc.) e que quanto mais unidades tivermos, maior a probabilidade de coincidência desses eventos. Portanto, precisamos de 1 unidade redundante para cada 5-6 unidades. Portanto, no total, precisamos de 15 unidades para atender às demandas da cidade, se mantemos o suprimento necessário dentro de cada unidade.
Como já pensávamos anteriormente, precisamos reabastecer o armazenamento a cada semana ou duas (antes adivinhávamos duas) - cerca de metade do armazenamento deve ser substituída, para acompanhar as tendências etc. Então, 4000 livros de entrega nova e 4000 livros foram removidos. Em cada reabastecimento, precisamos extrair 4000 livros e inserir 4000 novas entradas novamente. Com nossa taxa de transferência de 400 livros / hora, uma reposição será de 10 horas muito intensas. Bem, ainda parece estar bom, especialmente porque as operações em massa geralmente são mais baratas; de qualquer maneira - lembre-se de que a operação de reabastecimento é 5 vezes mais cara do que apenas servir.
Um livro médio (2 cm * 20 cm * 30 cm) é de 1,5 litros de volume, então 4000 livros = 6 metros cúbicos. Isso deve caber em um único veículo de carga leve médio. 1 metro cúbico de papel pesa 600kg, 6m ^ 3 = 3,6 toneladas. Um veículo de carga leve médio é capaz de lidar com ~ 1,5 toneladas, por isso precisamos de 3 deles. Mais um para redundância. Temos 15 unidades de bibliotecas atualizadas a cada 2 semanas, o que significa que o cronograma é curto, portanto precisamos de mais um carro.
E ainda não pensávamos como e de onde esses carros moveriam os livros, portanto, nosso design também precisará de armazéns de fornecedores e pontos de coleta de lixo para deixar de ser livros populares ...
O tempo acabou. Então, o que há de tão especial na pergunta NALSD? A escalabilidade é esperada em qualquer projeto de sistema grande. Mas em uma entrevista do NALSD, é preciso ser
específico .
Você pode ver acima muitas suposições e suposições, mas todos os cálculos foram baseados em números feitos anteriormente. Também tentei explicar como chegar ao número certo, mas é fácil ficar cansado / entediado e começar a sentir falta disso. Além disso, é fácil manter algum número da memória, sem fornecer uma boa explicação de seus motivos ... Mas, como o design é muito específico, se você cometer algum erro, poderá alterar o número e apenas recalcular o restante.
Ainda me lembro de como, durante minha entrevista ao NALSD, mantive IOPS de um único HDD igual a 600, apenas porque recentemente trabalhei na otimização de uma matriz de ataques, onde toda a matriz tinha 600 IOPS ... O entrevistador ficou um pouco surpreso: 600 IOPS por dirigir? : DDurante a entrevista, qualquer uma de suas suposições e suposições pode ser corrigida pelo entrevistador. Além disso, o entrevistador pode adicionar algumas restrições adicionais (que você esqueceu, não sabia, não perguntou ou simplesmente ajustou a tarefa, porque gostariam ou acham que essa é a melhor maneira de continuar). Como você está operando apenas em números específicos, isso exigiria pequenas atualizações de números seguindo as equações já fornecidas.
Se a correção de uma suposição requer uma reformulação completa do sistema, é um erro de design ou uma correção incorreta ou a nova suposição nos leva além da aplicabilidade do design (e não é tão raro na vida real). É importante não perder esse fato: você deve validar os números que obtém, para garantir que sejam realistas, durante o design e após qualquer correção.
Como SREs, temos que pensar na escalabilidade de sistemas reais dentro das restrições das limitações reais de hardware. Poderia haver um belo
algoritmo que troque uma complexidade de tempo gigantesca para uma quantidade de RAM ... Mas, ainda assim, 1PiB de RAM por 1 CPU não é algo que podemos construir hoje. Portanto, se tivermos 1 PiB de RAM, também teremos cerca de 10k de CPUs. Ou 20k. Ou até 30k. Isso significa que devemos nos concentrar no ideal real (local), alcançável hoje na realidade, e não no ideal global alcançável em condições ideais.
Você não deve se lembrar de números precisos, mas deve poder aplicar regras práticas para obter ordens de magnitude. IOPS: HDD é de cerca de 100s, SSD é de cerca de 100s milhares. Mas esses milhares vêm com uma diferença de preço entre HDD e SSD, como 1: 3 ou 1: 4. Também está ignorando tudo ao seu redor: espaço em rack, blades para as unidades, portas de rede e outras coisas, que não são mais baratas quando você trabalha em peta e exala.
Agora fique confortável em sua cadeira, relaxe e tente projetar um sistema de crescimento e entrega de ovos de galinha frescos na assinatura.