Sistemas Distribuídos Escaláveis

Nos últimos 20 anos assistiu-se a um crescimento sem precedentes na dimensão, complexidade, e capacidade dos sistemas de software. Esta taxa de crescimento dificilmente abrandará nos próximos 20 anos — o aspeto destes futuros sistemas está perto de ser inimaginável agora. A única coisa que podemos garantir é que cada vez mais sistemas de software terão de ser construídos com crescimento constante — mais pedidos, mais dados, mais análises — como um motor de conceção primário.

Escalável é o termo utilizado na engenharia de software para descrever sistemas de software que podem acomodar o crescimento. Nesta primeira parte da série, vamos explorar o que se entende precisamente por capacidade de escala — conhecida, não surpreendentemente, como escalabilidade. Descreveremos também alguns exemplos que colocam números duros nas capacidades e características das aplicações contemporâneas e daremos uma breve história das origens dos sistemas massivos que construímos rotineiramente hoje em dia. Finalmente, descreveremos dois princípios gerais para alcançar a escalabilidade que se repetirão de várias formas ao longo do resto desta série de artigos e examinaremos a ligação indelével entre a escalabilidade e o custo.

O que é Escalabilidade?

Intuitivamente, a escalabilidade é um conceito bastante simples. Se pedirmos uma definição à Wikipédia, ela diz-nos que “a escalabilidade é propriedade de um sistema para lidar com uma quantidade crescente de trabalho, acrescentando recursos ao sistema”. Todos sabemos como escalar um sistema de autoestradas — acrescentamos mais faixas de tráfego para que este possa lidar com um maior número de veículos. Algumas das minhas pessoas favoritas sabem como escalar a produção de cerveja — acrescentam mais capacidade em termos do número e tamanho dos recipientes de fabrico de cerveja, do número de funcionários para executar e gerir o processo de fabrico de cerveja, e do número de barris que podem encher com saborosas cervejas frescas. Pense em qualquer sistema físico — um sistema de trânsito, um aeroporto, elevadores num edifício — e como aumentamos a capacidade é bastante óbvio.

Ao contrário dos sistemas físicos, o software é algo amorfo. Não é algo para o qual se possa apontar, ver, tocar, sentir, e obter uma sensação de como se comporta internamente a partir da observação externa. É um artefacto digital. No seu núcleo, o fluxo de 1’s e 0’s que compõem o código executável e os dados são difíceis de distinguir. Então, o que significa a escalabilidade em termos de um sistema de software?

Em termos muito simples, e sem entrar em guerras de definição, a escalabilidade define a capacidade de um sistema de software para lidar com o crescimento em alguma dimensão das suas operações. Exemplos de dimensões operacionais são:

• O número de utilizadores simultâneos ou externos (por exemplo, sensor) que um sistema pode processar
• A quantidade de dados que um sistema pode processar e gerir eficazmente
• O valor que pode ser obtido a partir dos dados que um sistema armazena

Por exemplo, imagine que uma grande rede de supermercados está abrindo rapidamente novas lojas e aumentando o número de quiosques de autoatendimento em cada loja. Isso exige que os principais sistemas de software de supermercado:

• Lide com o aumento do volume da digitalização de vendas de itens sem diminuir o tempo de resposta. Respostas instantâneas às verificações de itens são necessárias para manter os clientes satisfeitos.
• Processe e armazene os maiores volumes de dados gerados pelo aumento das vendas. Esses dados são necessários para gerenciamento de estoque, contabilidade, planejamento e provavelmente muitas outras funções.
• Obtenha resumos de dados de vendas em ‘tempo real’ (por exemplo, por hora) de cada loja, região e país e compare com tendências históricas. Esses dados de tendência podem ajudar a destacar eventos incomuns em regiões (por exemplo, condições climáticas inesperadas, grandes multidões em eventos etc.) e ajudar as lojas afetadas a responder rapidamente.
• Evoluir o subsistema de previsão de pedidos de estoque para poder antecipar corretamente as vendas (e, portanto, a necessidade de reordenar o estoque) à medida que o número de lojas e clientes cresce

Essas dimensões são efetivamente os requisitos de escalabilidade de um sistema. Se ao longo de um ano a rede de supermercados abrir 100 novas lojas e aumentar as vendas em 400 vezes (algumas das novas lojas são grandes), então o sistema de software precisa ser dimensionado para fornecer a capacidade de processamento necessária para permitir que o supermercado opere com eficiência. Se os sistemas não forem dimensionados, podemos perder vendas, pois os clientes estão insatisfeitos. Podemos manter estoques que não serão vendidos rapidamente, aumentando os custos. Podemos perder oportunidades de aumentar as vendas respondendo às circunstâncias locais com ofertas especiais. Tudo isso reduz a satisfação do cliente e os lucros. Nenhum é bom para os negócios.

O dimensionamento bem-sucedido é, portanto, crucial para o crescimento dos negócios do nosso supermercado imaginário e, na verdade, é a força vital de muitos aplicativos modernos de Internet. Mas para a maioria dos sistemas empresariais e governamentais, a escalabilidade não é um requisito primário de qualidade nos estágios iniciais de desenvolvimento e implantação. Novos recursos para melhorar a usabilidade e utilidade tornam-se os drivers de nossos ciclos de desenvolvimento. Contanto que o desempenho seja adequado sob cargas normais, continuamos adicionando recursos voltados para o usuário para aumentar o valor comercial do sistema.

Ainda assim, não é incomum que os sistemas evoluam para um estado em que o desempenho e a escalabilidade aprimorados se tornem uma questão de urgência ou até de sobrevivência. Recursos atraentes e alta utilidade geram sucesso, o que traz mais solicitações para lidar e mais dados para gerenciar. Isso muitas vezes anuncia um ponto de inflexão, onde as decisões de projeto que faziam sentido sob cargas leves agora são subitamente dívidas técnicas. Os eventos de gatilho externos geralmente causam esses pontos de inflexão — veja na mídia de março/abril de 2020 os muitos relatórios de desemprego do governo e sites de pedidos on-line de supermercados que falham sob demanda causada pela pandemia de coronavírus.

Aumentar a capacidade de um sistema em alguma dimensão por meio do aumento de recursos é comumente chamado de ampliação ou ampliação — exploraremos a diferença entre isso mais adiante nesta série. Além disso, ao contrário dos sistemas físicos, muitas vezes é igualmente importante poder reduzircapacidade de um sistema de reduzir custos. O exemplo canônico disso é a Netflix, que tem uma carga diurna regional previsível que precisa processar. Simplesmente, muito mais pessoas estão assistindo Netflix em qualquer região geográfica às 21h do que às 5h. Isso permite que a Netflix reduza seus recursos de processamento durante períodos de menor carga. Isso economiza o custo de execução dos nós de processamento usados ​​na nuvem da Amazon, bem como coisas socialmente valiosas, como reduzir o consumo de energia do data center. Compare isso com uma rodovia. À noite, quando há poucos carros na estrada, não retraímos faixas (exceto para reparos). A capacidade total da estrada está disponível para os poucos motoristas irem tão rápido quanto quiserem.

Há muito mais a considerar sobre escalabilidade em sistemas de software, mas vamos voltar a essas questões depois de examinar a escala de alguns sistemas de software contemporâneos por volta de 2020.

Escala do sistema no início de 2020: exemplos

Olhar para o futuro neste jogo de tecnologia é sempre cheio de perigos. Em 2008 escrevi [1]:

“ Embora conjuntos de dados de petabytes e fluxos de dados de gigabit sejam as fronteiras atuais para aplicativos com uso intensivo de dados, sem dúvida daqui a 10 anos lembraremos com carinho de problemas dessa escala e nos preocuparemos com as dificuldades que os aplicativos exascale iminentes estão apresentando .”

Uma grande fonte de informação que às vezes dá insights sobre escalas operacionais contemporâneas são os blogs técnicos das principais empresas de Internet. Há também sites que analisam o tráfego da Internet que são altamente ilustrativos dos volumes de tráfego. Vamos dar alguns exemplos de ‘ponto no tempo’ para ilustrar algumas coisas que sabemos hoje. Tenha em mente que eles parecerão quase pitorescos em um ano ou quatro.

• O blog de engenharia do Facebook descreve o Scribe , sua solução para coletar, agregar e fornecer petabytes de dados de log por hora, com baixa latência e alto rendimento. A infraestrutura de computação do Facebook compreende milhões de máquinas, cada uma das quais gera arquivos de log que capturam eventos importantes relacionados à integridade do sistema e do aplicativo. O processamento desses arquivos de log, por exemplo, a partir de um servidor Web, pode fornecer às equipes de desenvolvimento insights sobre o comportamento e o desempenho de seus aplicativos, além de oferecer suporte à detecção de falhas. O Scribe é uma solução de enfileiramento em buffer personalizado que pode transportar logs de servidores a uma taxa de vários terabytes por segundo e entregá-los para análise downstream e sistemas de armazenamento de dados. Isso, meus amigos, são muitos dados!
• Você pode ver o tráfego da Internet ao vivo para vários serviços em www.internetlivestats.com . Pesquise e você encontrará estatísticas como o Google lida com cerca de 3,5 bilhões de solicitações de pesquisa por dia, o Instagram carrega cerca de 65 milhões de fotos por dia e há algo como 1,7 bilhão de sites. É um site divertido com muitas informações para surpreendê-lo. Observe que os dados não são realmente ‘vivos’, apenas estimativas baseadas em análises estatísticas de várias fontes de dados.
• Em 2016, o Google publicou um artigo descrevendo as características de sua base de código . Entre os muitos fatos surpreendentes relatados está: “ O repositório contém 86 TBs de dados, incluindo aproximadamente dois bilhões de linhas de código em nove milhões de arquivos de origem únicos .” Lembre-se, isso foi em 2016.

Ainda assim, dados reais e concretos sobre a escala dos serviços fornecidos pelos principais sites da Internet permanecem envoltos em sigilo comercial. Felizmente, podemos obter alguns insights profundos sobre a solicitação e os volumes de dados tratados na escala da Internet por meio do relatório anual de uso de uma empresa de tecnologia. Você pode navegar pelas estatísticas de uso incrivelmente detalhadas aqui a partir de 2019 . É um vislumbre fascinante das capacidades dos sistemas de grande escala. Cuidado, porém, este é o Pornhub.com. O relatório não é para os mais sensíveis. Aqui está um ponto de dados ilustrativo PG-13 — eles tiveram 42 bilhões de visitas em 2019! Vou deixar os leitores interessados ​​navegarem pelos dados do relatório para o conteúdo de seu coração. Algumas das estatísticas definitivamente farão seus olhos se arregalarem!

A década de 1980

Uma era dominada por mainframes e minicomputadores. Estes eram basicamente sistemas multiutilizadores compartilhados onde os utilizadores interagiam com as máquinas por meio de terminais ‘burros’. Os computadores pessoais surgiram no início da década de 1980 e se desenvolveram ao longo da década para se tornarem máquinas úteis para negócios e (relativamente) poderosas máquinas de desenvolvimento. Eles raramente eram conectados em rede, no entanto, especialmente no início da década. A primeira encarnação limitada da Internet surgiu durante esse período . No final da década de 1980, laboratórios de desenvolvimento, universidades e cada vez mais empresas tinham e-mail e acesso a recursos exóticos baseados na Internet, como fóruns de discussão Usenet — pense em um Reddit relativamente primitivo e incrivelmente educado.

1990–1995

Computadores pessoais e tecnologia de rede, tanto LANs quanto WANS, continuaram a melhorar dramaticamente durante esse período. Isso criou um ambiente propício para a criação da World Wide Web (WWW) como a conhecemos hoje. O catalisador foi a tecnologia HTTP/HTML que foi pioneira no CERN por Tim Berners-Lee durante a década de 1980. Em 1993, o CERN disponibilizou a tecnologia WWW sem royalties. E o resto é história — uma plataforma para compartilhamento de informações e ganho de dinheiro havia sido criada. Em 1995, o número de sites era pequeno, mas as sementes do futuro foram plantadas com empresas como o Yahoo! em 1994 e Amazon e eBay em 1995

1996–2000

Durante este período, o número de sites cresceu de cerca de 10.000 para 10 milhões , um período de crescimento verdadeiramente explosivo. A largura de banda e o acesso de rede também cresceram rapidamente, com modems inicialmente discados para utilizadores domésticos (sim, discados) e, em seguida, as primeiras tecnologias de banda larga se tornando disponíveis.

Esse aumento de utilizadores com acesso à Internet anunciou uma mudança profunda na forma como tínhamos que pensar sobre a construção de sistemas. Tomemos por exemplo um banco de varejo. Antes de fornecer serviços online, era possível prever com precisão as cargas que os sistemas de negócios do banco sofreriam. Você sabia quantas pessoas trabalhavam no banco e usavam os sistemas internos, quantos terminais/PCs estavam conectados às redes do banco, quantos caixas eletrônicos você precisava suportar e o número e a natureza das conexões com outras instituições financeiras. Armados com esse conhecimento, poderíamos construir sistemas que suportassem, digamos, um máximo de 3.000 utilizadores simultâneos, com a certeza de que esse número não poderia ser excedido. O crescimento também seria relativamente lento e provavelmente na maioria das vezes (por exemplo, fora do horário comercial) a carga seria muito menor do que o pico.

Agora imagine que nosso banco de varejo decida permitir que todos os clientes tenham acesso ao Internet banking. E o banco tem 5 milhões de clientes. Qual é a nossa carga máxima agora? Como a carga será dispersa durante um dia útil? Quando são os períodos de pico? O que acontece se realizarmos uma promoção por tempo limitado para tentar cadastrar novos clientes? De repente, nosso ambiente de sistemas de negócios relativamente simples e contido é interrompido pelas cargas médias e de pico mais altas e pela imprevisibilidade que você vê nas populações de utilizadores baseados na Internet.

Durante este período, empresas como Amazon, eBay, Google, Yahoo! e similares foram pioneiros em muitos dos princípios de design e versões iniciais de tecnologias avançadas para sistemas altamente escaláveis. Eles precisavam, pois suas cargas de solicitações e volumes de dados estavam crescendo exponencialmente.

2000–2006

O final dos anos 1990 e o início dos anos 2000 viram investimentos maciços e inovações tecnológicas das chamadas empresas ‘ponto com’, todas procurando fornecer negócios on-line inovadores e valiosos. Os gastos foram enormes e nem todos os investimentos foram bem direcionados. Isso levou a um pequeno evento chamado ‘ dot com crash ‘ durante 2000/2001. Em 2002, o cenário tecnológico estava repleto de investimentos fracassados ​​– alguém se lembra da Pets.Com? Não. Nem eu. Cerca de 50% das empresas pontocom desapareceram durante este período. Dos que sobreviveram, embora com avaliações muito mais baixas, muitos se tornaram os itens básicos que todos conhecemos e usamos hoje.

O número de sites cresceu de cerca de 10 para 80 milhões durante esse período, e surgiram novos modelos de serviços e negócios. Em 2005, o YouTube foi lançado. 2006 viu o Facebook tornar-se disponível ao público. No mesmo ano, a Amazon Web Services, que teve um início discreto em 2004, foi relançada com seus serviços S3 e EC2. A era moderna da computação em escala da Internet e dos sistemas hospedados em nuvem nasceu.

2007–2020

Vivemos agora em um mundo com quase 2 bilhões de sites, dos quais cerca de 20% estão ativos. Há algo como 4 bilhões de utilizadores de Internet . Enormes data centers operados por operadoras de nuvem pública como AWS, GCP e Azure, juntamente com uma infinidade de data centers privados, por exemplo , a infraestrutura operacional do Twitter , estão espalhados pelo planeta. As nuvens hospedam milhões de aplicativos, com engenheiros provisionando e operando seus sistemas computacionais e de armazenamento de dados usando portais sofisticados de gerenciamento de nuvem. Serviços de nuvem poderosos e ricos em recursos nos permitem construir, implantar e dimensionar nossos sistemas literalmente com apenas alguns cliques do mouse. Tudo o que você precisa fazer é pagar a conta do provedor de nuvem no final do mês.

Este é o mundo que esta série de artigos visa. Um mundo onde nossos aplicativos precisam explorar os princípios-chave para construir sistemas escaláveis ​​e alavancar plataformas de infraestrutura altamente escaláveis. Lembre-se de que, em aplicativos modernos, a maior parte do código executado não é escrito por sua organização. Faz parte dos contêineres, bancos de dados, sistemas de mensagens e outros componentes que você compõe em seu aplicativo por meio de chamadas de API e diretivas de construção. Isso torna a seleção e o uso desses componentes pelo menos tão importantes quanto o design e o desenvolvimento de sua própria lógica de negócios. São decisões arquitetônicas que não são fáceis de mudar.

Princípios Básicos de Design de Escalabilidade

Como já discutimos, o objetivo básico de dimensionar um sistema é aumentar sua capacidade em alguma dimensão específica da aplicação. Uma dimensão comum é aumentar o número de solicitações que um sistema pode processar em um determinado período de tempo. Isso é conhecido como taxa de transferência do sistema. Vamos usar uma analogia para explorar dois princípios básicos que temos disponíveis para dimensionar nossos sistemas e aumentar o rendimento.

Em 1932, um dos grandes ícones do mundo, a Sydney Harbour Bridge , foi inaugurada. Agora, é uma suposição bastante segura que os volumes de tráfego em 2020 sejam um pouco maiores do que em 1932. Se você passou pela ponte no horário de pico nos últimos 30 anos, sabe que sua capacidade é excedida consideravelmente todos os dias. Então, como aumentamos o rendimento em infraestruturas físicas, como pontes?

Esta questão tornou-se muito proeminente em Sydney na década de 1980, quando se percebeu que a capacidade de travessia do porto deveria ser aumentada. A solução foi o túnel do porto de Sydney , bem menos icônico , que segue essencialmente a mesma rota por baixo do porto. Isso fornece mais 4 faixas de tráfego e, portanto, adicionou cerca de 1/3 a mais de capacidade para travessias portuárias.

Em Auckland não muito distante, a ponte do porto também teve um problema de capacidade, pois foi construída em 1959 com apenas 4 pistas. Em essência, eles adotaram a mesma solução de Sydney, ou seja, aumentar a capacidade. Mas, em vez de construir um túnel, eles engenhosamente dobraram o número de pistas, expandindo a ponte com os hilários ‘ Nippon Clipons’ , que alargaram a ponte de cada lado. Peça a um Kiwi para dizer ‘Nippon Clipons’ e você entenderá por que isso é engraçado.

Esses exemplos ilustram a primeira estratégia que temos em sistemas de software para aumentar a capacidade. Basicamente, replicamos os recursos de processamento de software para fornecer mais capacidade para lidar com solicitações e, assim, aumentar a taxa de transferência, conforme mostrado na Figura 1. Esses recursos de processamento replicados são análogos às vielas em pontes, fornecendo um caminho de processamento principalmente independente para um fluxo de solicitações que chegam. Felizmente, em sistemas de software baseados em nuvem, a replicação pode ser obtida com o clique de um mouse e podemos replicar efetivamente nossos recursos de processamento milhares de vezes. Temos muito mais facilidade do que os construtores de pontes a esse respeito.

Figura 1 Aumentando a capacidade por meio da replicação

A segunda estratégia para escalabilidade também pode ser ilustrada com nosso exemplo de ponte. Em Sydney, alguns observadores perceberam que de manhã muito mais veículos cruzam a ponte de norte a sul, e à tarde vemos o padrão inverso. Uma solução inteligente foi, portanto, desenvolvida — alocar mais pistas para a direção de alta demanda pela manhã e, em algum momento da tarde, mudar isso. Isso aumentou efetivamente a capacidade da ponte sem alocar novos recursos — otimizamos os recursos que já tínhamos disponíveis.

Podemos seguir essa mesma abordagem em software para dimensionar nossos sistemas. Se conseguirmos de alguma forma otimizar nosso processamento, talvez usando algoritmos mais eficientes, adicionando índices extras em nossos bancos de dados para agilizar as consultas, ou mesmo reescrevendo nosso servidor em uma linguagem de programação mais rápida, podemos aumentar nossa capacidade sem aumentar nossos recursos. O exemplo canônico disso é a criação do (agora descontinuado) HipHop for PHP pelo Facebook, que aumentou a velocidade de geração de páginas da web do Facebook em até 6 vezes ao compilar o código PHP para C++. Isso permitiu que o site processasse muito mais solicitações com os mesmos recursos.

Revisitaremos esses dois princípios de design — ou seja, replicação e otimização — muitas vezes no restante desta série. Você verá que há muitas implicações complexas de adotar esses princípios que surgem do fato de que estamos construindo sistemas distribuídos. Os sistemas distribuídos têm propriedades que tornam o projeto de sistemas escaláveis ​​’interessante’, onde o interesse neste contexto tem conotações positivas e negativas.

Escalabilidade e Custos

Vamos dar um exemplo hipotético trivial para examinar a relação entre escalabilidade e custos. Suponha que temos um sistema baseado na Web (por exemplo, servidor web e banco de dados) que pode atender a uma carga de 100 solicitações simultâneas com um tempo médio de resposta de 1 segundo. Recebemos um requisito de negócios para expandir esse sistema para lidar com 1.000 solicitações simultâneas com o mesmo tempo de resposta. Sem fazer nenhuma alteração, um simples teste de carga deste sistema revela o desempenho mostrado na Figura 2 (esquerda). À medida que a carga da solicitação aumenta, vemos o tempo médio de resposta aumentar constantemente para 10 segundos com a carga projetada. Claramente, isso não é escalável e não pode satisfazer nossos requisitos em sua configuração de implantação atual.

Figura 2 Dimensionando um aplicativo. (Esquerda) — desempenho não escalável. (Direita) — desempenho escalável

Claramente, algum esforço de engenharia é necessário para alcançar o desempenho exigido. A Figura 2 (direita) mostra o desempenho do sistema após sua modificação. Ele agora fornece o tempo de resposta especificado com 1.000 solicitações simultâneas. Assim, escalamos o sistema com sucesso. Hora da festa!

Uma grande questão paira, no entanto. Ou seja, quanto esforço e recursos foram necessários para alcançar esse desempenho? Talvez fosse simplesmente um caso de expansão executando o servidor Web em uma máquina (virtual) mais poderosa. A execução desse reprovisionamento em uma nuvem pode levar no máximo 30 minutos. Um pouco mais complexo seria reconfigurar o sistema para expandir e executar várias instâncias do servidor Web para aumentar a capacidade. Novamente, essa deve ser uma alteração de configuração simples e de baixo custo para o aplicativo, sem a necessidade de alterações de código. Estes seriam excelentes resultados.

No entanto, dimensionar um sistema nem sempre é tão fácil. As razões para isso são muitas e variadas, mas aqui estão algumas possibilidades:

• o banco de dados torna-se menos responsivo com 1.000 solicitações por segundo, exigindo uma atualização para uma nova máquina
• o servidor Web gera muito conteúdo dinamicamente e isso reduz o tempo de resposta sob carga. Uma possível solução é alterar o código para gerar o conteúdo com mais eficiência, reduzindo assim o tempo de processamento por solicitação.
• a carga da solicitação cria pontos de acesso no banco de dados quando muitas solicitações tentam acessar e atualizar os mesmos registros simultaneamente. Isso requer um redesenho do esquema e posterior recarregamento do banco de dados, bem como alterações de código na camada de acesso a dados.
• a estrutura de servidor da Web selecionada enfatizava a facilidade de desenvolvimento sobre a escalabilidade. O modelo que ele impõe significa que o código simplesmente não pode ser dimensionado para atender aos requisitos de carga da solicitação e uma reescrita completa é necessária. Outro quadro? Outra linguagem de programação mesmo?

Há uma infinidade de outras causas potenciais, mas esperamos que elas ilustrem o esforço crescente que pode ser necessário à medida que passamos da possibilidade (1) para a possibilidade (4).

Agora vamos supor que a opção (1), atualizar o servidor de banco de dados, requer 15 horas de esforço e mil dólares extras de custos de nuvem por mês para um servidor mais poderoso. Isso não é proibitivamente caro. E vamos supor que a opção (4), uma reescrita da camada de aplicação da Web, requer 10.000 horas de desenvolvimento devido à implementação em uma nova linguagem (por exemplo, Java em vez de Ruby). As opções (2) e (3) ficam em algum lugar entre as opções (1) e (4). O custo de 10.000 horas de desenvolvimento é seriamente significativo. Pior ainda, enquanto o desenvolvimento está em andamento, o aplicativo pode estar perdendo participação de mercado e, portanto, dinheiro devido à sua incapacidade de satisfazer as cargas de solicitações dos clientes. Esses tipos de situações podem fazer com que sistemas e negócios falhem.

Este cenário simples ilustra como os custos de recursos e esforços estão inextricavelmente ligados à escalabilidade. Se um sistema não for projetado intrinsecamente para escalar, os custos e recursos de downstream para aumentar sua capacidade de atender aos requisitos podem ser enormes. Para alguns aplicativos, como Healthcare.gov , esses custos (mais de US$ 2 bilhões) são suportados e o sistema é modificado para eventualmente atender às necessidades de negócios. Para outros, como a bolsa de saúde do Oregon, a incapacidade de escalar rapidamente a baixo custo pode ser uma sentença de morte cara (US$ 303 milhões).

Nunca esperaríamos que alguém tentasse aumentar a capacidade de uma casa de família para se tornar um prédio de escritórios de 50 andares. A casa não tem arquitetura, materiais e fundações para que isso seja uma possibilidade remota sem ser completamente demolida e reconstruída. Da mesma forma, não devemos esperar que sistemas de software que não empregam arquiteturas, mecanismos e tecnologias escaláveis ​​evoluam rapidamente para atender às necessidades de maior capacidade. As bases de escala precisam ser construídas desde o início, com o reconhecimento de que os componentes evoluirão ao longo do tempo. Ao empregar princípios de design e desenvolvimento que promovem a escalabilidade, podemos escalar sistemas de forma mais rápida e barata para atender às demandas em rápido crescimento.

Sistemas de software que podem ser escalonados exponencialmente enquanto os custos crescem linearmente são conhecidos como sistemas de hiperescala , definidos como:

“ Os sistemas de hiperescala exibem um crescimento exponencial em recursos computacionais e de armazenamento, ao mesmo tempo em que exibem taxas de crescimento linear nos custos dos recursos necessários para construir, operar, dar suporte e evoluir os recursos de software e hardware necessários .”

Você pode ler mais sobre sistemas de hiperescala neste artigo [3].

Resumo

A capacidade de dimensionar um aplicativo de forma rápida e econômica deve ser uma qualidade definidora da arquitetura de software dos aplicativos contemporâneos voltados para a Internet. Temos duas maneiras básicas de alcançar a escalabilidade, ou seja, aumentar a capacidade do sistema, normalmente por meio de replicação, e a otimização do desempenho dos componentes do sistema. O restante desta série de artigos se aprofundará em como esses dois princípios básicos se manifestam na construção de sistemas distribuídos escaláveis. Prepare-se para um passeio selvagem.

Referências

1. Ian Gorton, Paul Greenfield, Alex Szalay e Roy Williams. 2008. Computação Intensiva de Dados no Século XXI. Computador 41, 4 (abril de 2008), 30–32.

2. Rachel Potvin e Josh Levenberg. 2016. Por que o Google armazena bilhões de linhas de código em um único repositório. Comum. ACM 59, 7 (julho de 2016), 78–87.

3. Ian Gorton (2017). Capítulo 2. Hiperescalabilidade — A face mutante da arquitetura de software. 10.1016/B978–0–12–805467–3.00002–8.