🍶 🕴🏼 🖤 Houston, nós temos um problema. Falha no projeto do sistema 🚔 👐🏻 🤵🏼

Em 1970, os engenheiros americanos lançaram a espaçonave Apollo 13 na Lua. A bordo estão três baterias de células a combustível, não há com o que se preocupar, tudo é duplicado de forma confiável e repetida. Mas ninguém poderia imaginar que a explosão de um cilindro de oxigênio desativaria duas das três baterias. Tragédia! Os astronautas voltaram para casa, um longa-metragem foi feito sobre o evento com Tom Hanks e a frase do astronauta Jack Swigert: "Houston, temos um problema!", Entrou na história.

A história da Apollo 13 é outra prova do fato bem conhecido de que você não pode se preparar para todos os problemas possíveis. Essa é uma propriedade natural do mundo: o ferro quebra periodicamente, o código falha e as pessoas cometem erros. É impossível eliminar completamente isso.

Para grandes sistemas distribuídos, esse comportamento é normal, é uma consequência de economias de escala e estatísticas. É por isso que o Design for Failure (AWS) é o princípio básico de design dos serviços em nuvem da AWS. Os sistemas são inicialmente construídos de maneira a restaurar a operação em tempo integral o mais rápido possível e minimizar os danos causados por falhas conhecidas e ainda desconhecidas. No HighLoad ++, Vasily Pantyukhin, usando problemas da vida real com serviços de combate como exemplo, mostrou padrões de design para sistemas distribuídos que os desenvolvedores da AWS usam.

Vasily Pantyukhin (Galinha) É o arquiteto do Amazon Web Services na Europa, Oriente Médio e África. Ele começou como administrador do Unix, trabalhou na Sun Microsystem por 6 anos, ministrou cursos técnicos e, por 11 anos, ensinou a centralização de dados do mundo na EMC. Em uma equipe internacional, ele projetou e implementou projetos da Cidade do Cabo a Oslo. Agora, ajuda grandes e pequenas empresas a trabalhar em nuvens públicas.

Em 1949, um acidente de avião foi investigado em uma base da força aérea da Califórnia. Um dos engenheiros que fez isso foi Edward Murphy. Ele descreveu o trabalho dos técnicos locais da seguinte forma: "Se houver duas maneiras de fazer algo e uma delas levar ao desastre, alguém escolherá esse método".

Mais tarde, graças a Arthur Bloch, a declaração entrou na história como uma das leis de Murphy. Em russo - a lei da maldade. Sua essência é que não será possível evitar falhas e erros humanos e terá que conviver com isso de alguma forma. É por isso que, ao projetar, colocamos imediatamente falhas e falhas de componentes individuais em nossos sistemas.

Design de falha

No projeto de falha, estamos tentando melhorar três características:

acessibilidade (os mesmos "noves");
confiabilidade - a propriedade do sistema para fornecer o nível de serviço necessário;
tolerância a falhas - uma propriedade do sistema para impedir a ocorrência de problemas e se recuperar rapidamente após eles.

A confiabilidade tem a propriedade de " incógnitas conhecidas ". Nós nos protegemos de problemas conhecidos, mas não sabemos quando eles ocorrerão.

“ Un desconhecidos conhecidos” é adicionado à tolerância a falhas - estes são problemas surpresa que não sabem nada sobre. Muitos desses problemas na nuvem estão relacionados a economias de escala: o sistema cresce de tamanho quando novos efeitos surpreendentes e inesperados aparecem.

A falha geralmente não é um fenômeno binário. Sua principal propriedade é o "raio de explosão" ou o nível de degradação do serviço, raio de destruição. Nossa tarefa é reduzir o "raio de explosão" dos sistemas.

Se reconhecermos que os problemas não podem ser evitados, devemos nos preparar proativamente para eles. Isso significa que projetamos serviços de tal maneira que, em caso de problemas (certamente serão), controlamos os problemas e não vice-versa.

Quando respondemos a um problema, ele nos controla.

Plano de dados e plano de controle

Certamente, você tem eletrônicos em casa que são controlados por um controle remoto, como uma TV. A tela da TV faz parte do plano de dados - que executa diretamente a função. O controle remoto é a interface do usuário - plano de controle. É usado para gerenciar e configurar o serviço. Na nuvem, tentamos separar o plano de dados e o plano de controle para teste e desenvolvimento.

Os usuários, na maioria das vezes, não veem a complexidade do plano de controle. Mas erros em seu design e implementação são as causas mais comuns de falhas em massa. É por isso que meu conselho é focado no plano de controle - às vezes explicitamente, às vezes não.

A história de um problema

Em julho de 2012, uma forte tempestade passou no norte da Virgínia. O data center possui proteção, geradores a diesel etc., mas aconteceu que em um dos data centers de uma das zonas de disponibilidade (Zona de Disponibilidade, AZ) da região da Virgínia do Norte, a energia foi perdida. A eletricidade foi rapidamente restaurada, mas a restauração dos serviços se arrastou por horas.

Vou falar sobre os motivos do exemplo de um dos serviços básicos - CLB (Classic Load Balancer). Funciona de maneira simples: quando você inicia um novo balanceador em cada zona de disponibilidade, instâncias separadas são criadas, cujo IP resolverá o DNS.

Quando uma das instâncias falha, uma mensagem sobre isso é enviada para um banco de dados especial.

Em resposta, os procedimentos iniciam: excluindo registros do DNS, iniciando uma nova instância e adicionando um novo IP ao DNS.

Nota: É assim que o sistema funcionava no passado, agora tudo é fundamentalmente diferente.

Tudo é simples - não há nada para quebrar. Porém, durante uma falha em massa, quando milhares de instâncias entram em colapso ao mesmo tempo, um enorme Backlog aparece no banco de dados a partir de mensagens para processamento.

Mas ficou pior. O plano de controle é um sistema distribuído. Devido a um erro, recebemos duplicatas e milhares de registros no banco de dados aumentaram para centenas de milhares. Tornou-se muito difícil trabalhar com isso.

Quando ocorre uma falha em uma das instâncias, todo o tráfego é quase instantaneamente alternado para as máquinas sobreviventes e a carga dobra (no exemplo, por simplicidade, existem apenas duas zonas de acesso).

Não há recursos suficientes, uma instância ao vivo começa automaticamente a aumentar. O processo leva um tempo relativamente longo. Tudo acontece no pico e, ao mesmo tempo, com um grande número de instâncias - os recursos gratuitos da zona de disponibilidade estão terminando. A "luta" por recursos começa.

No norte da Virgínia, a automação não conseguiu lidar com a falha maciça, e os engenheiros manualmente (usando scripts) restauraram os serviços para funcionar. Tais problemas são raros. Durante o interrogatório, surgiram perguntas sobre as causas da falha, eles decidiram que a situação não deveria mais ser repetida e que todo o serviço deveria ser alterado.

Os oito padrões que abordarei são respostas a algumas das perguntas.

Nota. Esta é a nossa experiência em design de serviços, e não a sabedoria universal para uso generalizado. Os padrões são usados em situações específicas.

— . AWS . — , . . — . !

Para minimizar o impacto de falhas, muitas abordagens. Uma delas é responder à pergunta: "Como posso garantir que os usuários que não conhecem um problema não saibam nada sobre ele durante uma falha e durante a recuperação?"

Nosso enorme Backlog recebe não apenas mensagens de travamento, mas também outras, por exemplo, sobre dimensionamento ou que alguém está iniciando um novo balanceador. Essas mensagens precisam ser isoladas umas das outras, agrupando funcionalmente: um grupo separado de mensagens de recuperação após uma falha, iniciando separadamente um novo balanceador.

Suponha que dez usuários tenham notado um problema - um dos nós de seus balanceadores caiu. Os serviços de alguma forma funcionam com os recursos restantes, mas o problema é sentido.

Temos dez usuários frustrados. O décimo primeiro aparece - ele não sabe nada sobre o problema, mas simplesmente quer um novo balanceador. Se o seu pedido para colocar a fila para processamento, provavelmente ele não esperará. Enquanto outros procedimentos de processamento estiverem concluídos, o tempo de solicitação será encerrado. Em vez de dez usuários frustrados, teremos onze.

Para impedir que isso aconteça, priorizamos algumas solicitações - colocamos as filas no topo, por exemplo, solicitações de novos recursos. Com uma falha em massa, um número relativamente pequeno dessas solicitações não afetará o tempo de recuperação dos recursos de outros clientes. Mas no processo de recuperação, restringiremos o número de usuários envolvidos no problema.

Trabalho em tempo integral

A resposta aos relatórios de problemas é o lançamento de procedimentos de recuperação, em particular, o trabalho com o DNS. Falhas em massa são enormes cargas de pico no plano de controle. O segundo padrão ajuda o plano de Controle a ser mais estável e previsível em tal situação.

Utilizamos uma abordagem chamada Trabalho constante - trabalho permanente .

Por exemplo, o DNS pode ser um pouco mais inteligente: ele verifica constantemente as instâncias do balanceador, estejam elas ativas ou não. O resultado será um bitmap de cada vez: a instância responde - 1, morta - 0. O

DNS verifica as instâncias a cada poucos segundos, independentemente de o sistema ser restaurado após uma falha em massa ou estar operando normalmente. Ele faz o mesmo trabalho - sem picos, tudo é previsível e estável.

Outro exemplo simplificado: queremos alterar a configuração em uma grande frota. Em nossa terminologia, uma frota é um grupo de máquinas virtuais que, juntas, fazem algum trabalho.

Colocamos as alterações de configuração no bucket S3 e, a cada 10 segundos (por exemplo), enviamos toda essa configuração para nossa frota de máquinas virtuais. Dois pontos importantes

Fazemos isso regularmente e nunca infringimos a regra. Se você escolher um segmento de 10 segundos, pressione apenas dessa maneira, independentemente da situação.
Sempre fornecemos toda a configuração , independentemente de ela ter sido alterada ou não. O próprio plano de dados (máquinas virtuais) decide o que fazer com ele. Nós não pressionamos o delta. Pode tornar-se muito grande com grandes interrupções ou alterações. Potencialmente, isso pode contribuir para instabilidade e imprevisibilidade.

Quando realizamos algum tipo de trabalho permanente, pagamos mais por isso. Por exemplo, 100 máquinas virtuais solicitam uma configuração a cada segundo. Custa cerca de US $ 1200 por ano. Esse valor é essencialmente menor que o salário de um programador, a quem podemos confiar ao desenvolvimento de um plano de controle uma abordagem clássica - uma reação a uma falha e a distribuição de apenas alterações de configuração.

Se você alterar a configuração a cada poucos segundos, como no exemplo, isso será lento. Mas, em muitos casos, uma alteração na configuração ou o lançamento de serviços leva minutos - alguns segundos não resolvem nada.

Segundos são importantes para serviços nos quais a configuração deve mudar instantaneamente, por exemplo, ao alterar as configurações de VPC. Aqui "trabalho permanente" não é aplicável. Este é apenas um padrão, não uma regra. Se isso não funcionar no seu caso, não use.

Escalonamento preliminar

Em nosso exemplo, quando a instância do balanceador falha, a segunda instância sobrevivente recebe a carga dobrando quase imediatamente e começa a escalar. Em uma falha maciça, consome uma enorme quantidade de recursos. O terceiro padrão ajuda a controlar esse processo - para escalar antecipadamente .

No caso de duas zonas de disponibilidade, escalamos ao descartar menos de 50%.

Se tudo for feito com antecedência, em caso de falha, as instâncias sobreviventes do balanceador estarão prontas para aceitar o tráfego duplicado.

Anteriormente, escalávamos apenas com alta utilização, por exemplo, 80% e agora em 45%. O sistema fica ocioso na maioria das vezes e fica mais caro. Mas estamos prontos para aturar isso e usar ativamente o padrão, porque isso é seguro. Você tem que pagar pelo seguro, mas em caso de sérios problemas, a vitória cobre todas as despesas. Se você decidir usar o padrão, calcule todos os riscos e o preço com antecedência.

Arquitetura celular

Há duas maneiras de construir e dimensionar serviços: o monólito e a estrutura do favo de mel (com base em célula).

O monólito se desenvolve e cresce como um único recipiente grande. Adicionamos recursos, o sistema aumenta, corremos para limites diferentes, as características lineares tornam-se não lineares e entram em saturação, e o "raio de explosão" do sistema - todo o sistema.

Se o monólito for mal testado, aumenta a probabilidade de surpresas - "incógnitas desconhecidas". Mas um grande monólito não pode ser totalmente testado. Às vezes, para isso, você precisará criar uma zona de acesso separada, por exemplo, para um serviço popular que é criado como um monólito dentro da zona de acesso (são muitos data centers). Além de, de alguma forma, criar uma enorme carga de teste semelhante à atual, isso é impossível do ponto de vista financeiro.

Portanto, na maioria dos casos, usamos uma arquitetura celular - uma configuração na qual um sistema é construído a partir de células de tamanho fixo. Ao adicionar células, nós a escalamos.

A arquitetura celular é popular na nuvem da AWS. Ajuda a isolar falhas e reduzir o raio da explosão.para uma ou mais células. Podemos testar completamente células de tamanho médio, isso reduz seriamente os riscos.

Uma abordagem semelhante é usada na construção naval: o casco de um navio ou embarcação é dividido por partições em compartimentos. No caso de um buraco, um ou mais compartimentos são inundados, mas o navio não afunda. Sim, não ajudou o Titanic, mas raramente encontramos problemas de iceberg.

Ilustrarei a aplicação da abordagem de malha usando o Simple Shapes Service como exemplo. Este não é um serviço da AWS, eu mesmo o criei. Este é um conjunto de APIs simples para trabalhar com formas geométricas simples. Você pode criar uma instância de uma forma geométrica, solicitar o tipo de uma forma pelo seu ID ou contar todas as instâncias de um determinado tipo. Por exemplo, put(triangle)um objeto "triângulo" com algum ID é criado em uma solicitação .getShape(id)retorna o tipo "triângulo", "círculo" ou "losango".

Para tornar um serviço nublado, ele deve ser usado por usuários diferentes ao mesmo tempo. Vamos torná-lo multi-inquilino.

Em seguida, você precisa criar uma maneira de particionar - para separar as figuras em células. Existem várias opções para escolher a chave da partição. O mais simples tem a forma geométrica : todos os losangos na primeira célula, círculos na segunda, triângulos na terceira.

Este método tem prós e contras.

Se houver visivelmente menos círculos que outras figuras, a célula correspondente permanecerá subutilizada (distribuição desigual).
Algumas solicitações de API são fáceis de implementar. Por exemplo, contando todos os objetos na segunda célula, encontramos o número de círculos no sistema.
Outras consultas são mais complicadas. Por exemplo, para encontrar uma forma geométrica por ID, você deve passar por todas as células.

A segunda maneira é usar a identificação dos objetos por intervalos : os primeiros mil objetos na primeira célula, o segundo na segunda. Portanto, a distribuição é mais uniforme, mas há outras dificuldades. Por exemplo, para contar todos os triângulos, você precisa usar o método scatter/gather: distribuímos as solicitações em cada célula, conta os triângulos dentro de si, depois coleta as respostas, resume e produz o resultado.

A terceira via - divisão de inquilinos(para usuários). Aqui nos deparamos com um problema clássico. Geralmente, existem muitos usuários "pequenos" na nuvem que tentam algo e praticamente não carregam o serviço. Existem usuários de mastodonte. São poucos, mas consomem uma enorme quantidade de recursos. Esses usuários nunca se encaixam em nenhuma célula. Você precisa criar maneiras complicadas de distribuí-las entre muitas células.

Não existe uma maneira ideal, cada serviço é individual. A boa notícia é que a sabedoria mundana trabalha aqui - cortar lenha é mais conveniente ao longo das fibras do que cortá-las. Em muitos serviços, essas "fibras" são mais ou menos óbvias. Então você pode experimentar e encontrar a chave de partição ideal.

As células estão interconectadas (embora fracamente). Portanto, deve haver um nível de conexão. Muitas vezes, é chamada de camada de roteamento ou mapeamento. É necessário entender para quais células enviar solicitações específicas. Este nível deve ser o mais simples possível. Tente não colocar a lógica de negócios nela.

Surge a questão do tamanho das células: pequena - ruim, grande - também ruim. Não há conselho universal - decida de acordo com a situação.

Na nuvem da AWS, usamos células lógicas e físicas de tamanhos diferentes. Existem serviços regionais com um tamanho de célula grande, há serviços de zona, onde as células são menores.

Nota. Falei sobre microcélulas no Saint Highload ++ Online no início de abril deste ano. Lá, discuti em detalhes um exemplo do uso específico desse padrão em nosso serviço principal do Amazon EBS.

Multi inquilino

Quando um usuário inicia um novo balanceador, ele recebe instâncias em cada zona de disponibilidade. Independentemente de os recursos serem usados ou não, eles são alocados e pertencem exclusivamente a esse inquilino da nuvem.

Para a AWS, essa abordagem é ineficiente, porque a utilização dos recursos do serviço é, em média, muito baixa. Isso afeta o custo. Para usuários da nuvem, essa não é uma solução flexível. Ele não pode se adaptar às condições de mudança rápida, por exemplo, para fornecer recursos com uma carga inesperadamente aumentada no menor tempo possível.

O CLB foi o primeiro balanceador na nuvem da Amazon. Hoje, os serviços usam uma abordagem de vários locatários, como o NLB (Network Load Balancer). A base, o "mecanismo" desses serviços de rede é o HyperPlane. Trata-se de uma frota enorme de máquinas virtuais (nós) internas, invisíveis para os usuários finais.

Vantagens da abordagem multilocatário ou do quinto padrão.

A tolerância a falhas é fundamentalmente mais alta . No HyperPlane, um grande número de nós já está em execução e aguarda o carregamento. Os nós conhecem o estado um do outro - quando alguns recursos falham, a carga é instantaneamente distribuída entre os demais. Os usuários nem percebem falhas em massa.
Proteção de carga de pico . Os inquilinos vivem suas próprias vidas e suas cargas geralmente não se correlacionam. A carga média total no HyperPlane é bastante suave.
A utilização de tais serviços é fundamentalmente melhor . Portanto, proporcionando melhor desempenho, eles são mais baratos.

Isso parece legal! Mas a abordagem multitenant tem desvantagens. Na figura, a frota HyperPlane com três inquilinos (losangos, círculos e triângulos), distribuídos por todos os nós .

Isso levanta o problema clássico dos vizinhos ruidosos: a ação destrutiva do inquilino, que gera tráfego muito alto ou ruim, afetará potencialmente todos os usuários.

O "raio de explosão" nesse sistema é composto por todos os inquilinos. A probabilidade de um "vizinho barulhento" destrutivo na zona de disponibilidade real da AWS não é alta. Mas devemos estar sempre preparados para o pior. Nós nos defendemos usando uma abordagem de malha - selecionamos grupos de nós como células. Nesse contexto, chamamos de shards. Células, fragmentos, partições - aqui está a mesma coisa.

Neste exemplo, um losango, como um "vizinho barulhento", afetará apenas um inquilino - um triângulo. Mas o triângulo será muito doloroso. Para suavizar o efeito, aplique o sexto padrão - sharding de mistura.

Fragmento aleatório

Distribuímos aleatoriamente inquilinos para nós. Por exemplo, um losango pousa em 1, 3 e 6 nós e um triângulo em 2, 6 e 8. Temos 8 nós e um fragmento de tamanho 3.

Aqui, a combinatória simples funciona. Com uma probabilidade de 54%, haverá apenas uma interseção entre os inquilinos.

O "vizinho barulhento" afetará apenas um inquilino, e não toda a carga, mas apenas 30%.

Considere uma configuração próxima ao real - 100 nós, tamanho de fragmento 5. Com uma probabilidade de 77%, não haverá interseções.

A fragmentação aleatória pode reduzir significativamente o "raio de explosão". Essa abordagem é usada em muitos serviços da AWS.

“Uma pequena frota causa uma grande frota, e não vice-versa”

Ao se recuperar de uma falha em massa, atualizamos a configuração de muitos componentes. Uma pergunta típica nesse caso é enviar ou alterar uma configuração alterada? Quem é o iniciador das alterações: a fonte que contém as alterações na configuração ou seus consumidores? Mas essas perguntas estão erradas. A pergunta certa é qual frota é maior?

Considere uma situação simples: uma grande frota de máquinas virtuais de front-end e um certo número de back-end.

Utilizamos uma abordagem de malha - grupos de instâncias de front-end funcionarão com determinados back-end. Para fazer isso, determine o mapeamento de roteamento de back-end e front-end trabalhando com eles.

O roteamento estático não é adequado. Os algoritmos de hash não funcionam bem em falhas de massa, quando você precisa alterar rapidamente a maioria das rotas. Portanto, é melhor usarroteamento dinâmico . Junto às grandes frotas de instâncias de front-end e back-end, colocamos um pequeno serviço que lidará apenas com roteamento. Ele conhecerá e atribuirá um mapeamento de back-end e front-end a qualquer momento.

Suponha que tivemos um grande acidente, muitas instâncias de front-end caíram. Eles começam a se recuperar em massa e quase simultaneamente solicitam a configuração de mapeamento do serviço de roteamento.

Um pequeno serviço de roteamento é bombardeado com um grande número de solicitações. Ele não vai lidar com a carga, na melhor das hipóteses, ela se degradará e, na pior das hipóteses, ele morrerá.

Portanto, é correto não solicitar alterações na configuração de um serviço pequeno, mas criar seu sistema para que o "bebê" em simudanças de configuração iniciadas em direção a uma grande frota de instâncias .

Usamos o padrão de trabalho constante. Um pequeno serviço de roteamento enviará a configuração para todas as instâncias da frota de front-end a cada poucos segundos. Ele nunca será capaz de sobrecarregar um ótimo serviço. O sétimo padrão ajuda a melhorar a estabilidade e a resiliência .

Os sete primeiros padrões aprimoram o sistema. O último padrão funciona de maneira diferente.

Carga caindo

Abaixo está um gráfico clássico do atraso versus carga. No lado direito do gráfico está o “joelho”, quando em cargas extremamente altas, mesmo um pequeno aumento leva a um aumento significativo na latência.

No modo normal, nunca levamos nossos serviços para o lado direito da programação. Uma maneira fácil de controlar isso é adicionar recursos no prazo. Mas estamos nos preparando para qualquer problema. Por exemplo, podemos ir para o lado direito do gráfico se recuperando de uma falha em massa.

Colocamos o tempo limite do cliente no gráfico. Qualquer pessoa pode ser um cliente, por exemplo, outro componente dentro de nosso serviço. Para simplificar, desenhamos um gráfico de atraso de 50%.

Aqui estamos diante de uma situação chamada de apagão . Você pode estar familiarizado com o termo apagão quando a eletricidade é cortada na cidade. A interrupção ocorre quando algo funciona, mas é tão ruim e lento que, conte, não funciona.

Vamos olhar para o apagão da zona marrom. O serviço recebeu uma solicitação do cliente, processou e retornou o resultado. No entanto, na metade dos casos, os clientes já atingiram o tempo limite e ninguém espera o resultado. Na outra metade, o resultado retorna mais rápido que o tempo limite, mas em um sistema lento, leva muito tempo.

Enfrentamos um duplo problema: já estamos sobrecarregados e no lado direito do cronograma, mas, ao mesmo tempo, ainda estamos “aquecendo o ar”, realizando muito trabalho inútil. Como evitar isso?

Encontre o "joelho" - o ponto de inflexão no gráfico . Medimos ou estimamos teoricamente.

Solte o tráfego que nos obriga a ir para a direita do ponto de inflexão .

Devemos simplesmente ignorar parte dos pedidos. Nem tentamos processá-los, mas retornamos imediatamente um erro ao cliente. Mesmo com sobrecarga, podemos pagar por essa operação - é "barata". As solicitações não são atendidas, a disponibilidade geral do serviço é reduzida. Embora as solicitações rejeitadas sejam processadas mais cedo ou mais tarde, após uma ou várias tentativas dos clientes.

Ao mesmo tempo, outra parte das solicitações é processada com uma latência baixa garantida. Como resultado, não fazemos trabalho inútil, e o que fazemos, fazemos bem.

Breve aperto de padrões de projeto de sistemas para falhas

Isolamento e regulação . Às vezes, faz sentido priorizar certos tipos de consultas. Por exemplo, com um volume relativamente pequeno de solicitações para criar novos recursos, eles podem ser colocados na parte superior da fila. É importante que isso não infrinja outros usuários. Em uma interrupção maciça, os usuários que aguardam a recuperação de seus recursos não sentirão uma diferença significativa.

Trabalho em tempo integral . Reduza ou elimine completamente a alternância dos modos de serviço. Um modo, que funciona de forma estável e constante, independentemente de situações de emergência ou de trabalho, melhora fundamentalmente a estabilidade e a previsibilidade do plano de Controle.

Escalonamento preliminar. Escale com antecedência com valores mais baixos de descarte. Você terá que pagar um pouco mais por isso, mas este é um seguro que compensa durante falhas graves do sistema.

Arquitetura celular . Muitas células fracamente acopladas são preferidas a um monólito. A abordagem de malha reduz o "raio de explosão" e a probabilidade de erros de surpresa.

A abordagem multitenant melhora significativamente a utilização do serviço, reduz seu custo e reduz o "raio de explosão".

Fragmento aleatório . Essa é uma abordagem que se aplica aos serviços de vários locatários. Além disso, permite controlar o "raio de explosão".

“Uma pequena frota causa uma grande frota, e não vice-versa”. Tentamos criar serviços para que pequenos serviços iniciem alterações em configurações grandes. Costumamos usá-lo em conjunto com um padrão de carga constante.

Soltando a carga . Em situações de emergência, tentamos fazer apenas um trabalho útil, e fazemos bem. Para fazer isso, descartamos parte da carga, a qual ainda não conseguimos lidar.

— , Saint HighLoad++ Online. -- , Q&A-, , . - . , - .

telegram- @HighLoadChannel — , .

Houston, nós temos um problema. Falha no projeto do sistema