{"id":4186,"date":"2022-05-10T09:47:47","date_gmt":"2022-05-10T12:47:47","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=4186"},"modified":"2024-01-12T09:51:14","modified_gmt":"2024-01-12T12:51:14","slug":"fundamentos-para-arquitetura-de-sistemas-escalaveis","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/fundamentos-para-arquitetura-de-sistemas-escalaveis\/","title":{"rendered":"Cap 2.2 Fundamentos para arquitetura de sistemas escal\u00e1veis"},"content":{"rendered":"

A google define boa engenharia de software como a capacidade de suportar as mudan\u00e7as de escala, ao longo do tempo, preservando a efici\u00eancia<\/strong>. A arquitetura adequada \u00e9 fundamental para que sistemas “escalem bem”.<\/p>\nEmbora frequentemente mencionada, a escalabilidade nem sempre \u00e9 devidamente tratada nas arquiteturas. A consequ\u00eancia grave disso \u00e9 a incapacidade de atender o crescimento inesperado do workload <\/em>e, quando n\u00e3o h\u00e1 componentes adequados de reten\u00e7\u00e3o,\u00a0instabilidades.\n

\n

Arquiteturas n\u00e3o planejadas para a escalabilidade – onde todas as esperan\u00e7as para suportar aumentos s\u00fabitos de demanda ficam depositadas na utiliza\u00e7\u00e3o de\u00a0load balancers\u00a0<\/i>ou na contrata\u00e7\u00e3o de recursos na nuvem – se convertem rapidamente em custo. Pior que isso, algumas vezes, nem mesmo “despejar dinheiro” \u00e9 suficiente.<\/p>\n

Antes de falar sobre escalabilidade, disponibilidade<\/h2>\n

De pouco importam as features\u00a0<\/em>de um sistema se elas n\u00e3o estiverem dispon\u00edveis quando os usu\u00e1rios precisam.<\/p>\n

Um sistema est\u00e1 dispon\u00edvel quando est\u00e1 funcionando conforme esperado com desempenho adequado. Um servi\u00e7o, por exemplo, est\u00e1 dispon\u00edvel quando responde corretamente, em um\u00a0response time <\/em>igual ou menor do que o acordado.<\/strong><\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Se o tempo de resposta de um servi\u00e7o for maior do que o acordado, mesmo que este responda corretamente, n\u00e3o poder\u00e1 ser considerado dispon\u00edvel.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A f\u00f3rmula para calcular a disponibilidade de um sistema \u00e9:<\/p>\n

\"\"<\/p>\n

Onde\u00a0Tu\u00a0<\/em>representa em u<\/em>ptime, <\/em>quando tudo est\u00e1 funcionando com desempenho adequado, e\u00a0Td<\/em> representa o\u00a0downtime,\u00a0<\/em>quando o comportamento do sistema est\u00e1 incorreto ou o desempenho \u00e9 insuficiente.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Manuten\u00e7\u00f5es programadas e paradas planejadas devem ser consideradas tempo em downtime<\/em>, logo afetando a disponibilidade.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Definindo escalabilidade (e elasticidade)<\/h2>\n

Um sistema \u00e9 escal\u00e1vel quando consegue suportar varia\u00e7\u00f5es nos workloads\u00a0<\/em>– aumentos ou redu\u00e7\u00f5es -, mantendo-se dispon\u00edvel, com ajustes proporcionalmente favor\u00e1veis nos recursos alocados.<\/strong> Ou seja, um sistema web, por exemplo, ser\u00e1 escal\u00e1vel se conseguir suportar o dobro de usu\u00e1rios ativos, no m\u00e1ximo, dobrando a infra.<\/p>\n

Quanto mais favor\u00e1veis forem as demandas de aloca\u00e7\u00e3o de recursos frente ao aumento das cargas, melhor ser\u00e1 a escalabilidade de um sistema.<\/p>\n

As mudan\u00e7as nos recursos podem acontecer pelo scaling up\/down<\/em> (vertical) –\u00a0a\u00a0atualiza\u00e7\u00e3o dos dispositivos computacionais utilizados em termos de mem\u00f3ria, processador, etc – ou pelo scaling out, <\/em>modificando a quantidade de dispositivos computacionais.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" A escalabilidade horizontal \u00e9 prefer\u00edvel a vertical pois mitiga riscos de indisponibilidade.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A diferen\u00e7a principal da escalabilidade para a elasticidade \u00e9 que a segunda acontece de forma r\u00e1pida e din\u00e2mica, incrementando recursos quando o\u00a0workload <\/em>cresce ou decrementando quando diminui. A elasticidade \u00e9 extremamente importante na nuvem, quando o investimento \u00e9 determinado pelo uso.<\/p>\n

A necessidade da escalabilidade (e elasticidade)<\/h2>\n

No passado, sistemas eram desenvolvidos para serem utilizados em contextos bem demarcados. Tanto volume de dados quanto taxas de mudan\u00e7a eram caracter\u00edsticas relativamente f\u00e1ceis de serem previstas. Entretanto, em tempos de transforma\u00e7\u00e3o digital,\u00a0 tudo mudou.<\/p>\n

Hoje, as empresas usam tecnologia para estreitar rela\u00e7\u00f5es com clientes, fornecedores e parceiros – sistemas de software<\/em> inicialmente desenvolvidos para utiliza\u00e7\u00e3o dentro das empresas, est\u00e3o “vazando” para uso externo. Dessa forma, aumentos significativos de workloads\u00a0<\/em>tem acontecido rapidamente e, n\u00e3o raro, de maneira inesperada.<\/p>\n

O impacto da escalabilidade no custo<\/h2>\nPlanejar um sistema para escalar implica em priorizar tamb\u00e9m disponibilidade e desempenho, impactando diretamente o custo.\n
\n

Suportar disponibilidade implica em aplicar redund\u00e2ncia como forma de suportar manuten\u00e7\u00f5es previstas ou dificuldades imprevistas.<\/p>\n

Quase todos os padr\u00f5es e estilos arquiteturais voltados para a escalabilidade tamb\u00e9m exercem press\u00e3o de custos de deploy<\/em> e opera\u00e7\u00e3o\u00a0<\/em>para, por exemplo, suportar orquestra\u00e7\u00e3o e mensageria.<\/p>\n

Escalar \u00e9 a “arte de gerenciar gargalos”<\/h2>\n

Em todo sistema que precisa escalar, h\u00e1 sempre, um elemento que oferece a restri\u00e7\u00e3o. N\u00e3o raro, esse recurso \u00e9 o banco de dados.<\/strong><\/p>\n

O trabalho da arquitetura de software, nessa perspectiva, \u00e9 identificar esse gargalo e adotar estrat\u00e9gias de mitigar riscos inerentes dele.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Usando Teoria das Restri\u00e7\u00f5es para melhorar a escalabilidade e performance de sistemas<\/p>\r\nA teoria das restri\u00e7\u00f5es \u00e9 frequentemente associada a gest\u00e3o fabril, mas tem, tamb\u00e9m aplica\u00e7\u00e3o direta para a arquitetura de software. Nesse v\u00eddeo, explico com mais detalhes como usar teoria das restri\u00e7\u00f5es para projetar sistemas escal\u00e1veis.\r\n

Acessar v\u00eddeo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A teoria das restri\u00e7\u00f5es nos ensina que h\u00e1 tr\u00eas medidas para tratar gargalos:<\/p>\n

    \n
  1. elevar a capacidade de vaz\u00e3o – seja com otimiza\u00e7\u00e3o, scale up<\/em> ou scale out –<\/em>\u00a0“quebrando” a restri\u00e7\u00e3o;<\/li>\n
  2. subordinar toda a arquitetura aos limites do gargalo, estabelecendo alguma esp\u00e9cie de\u00a0rate limiting<\/em><\/li>\n
  3. admitir a forma\u00e7\u00e3o de um “pulm\u00e3o” maior, frente a restri\u00e7\u00e3o, tornando todas as suas interfaces ass\u00edncronas.<\/li>\n<\/ol>\n
    \n

    A segunda “solu\u00e7\u00e3o”, na pr\u00e1tica, raramente \u00e9 aplic\u00e1vel pois restringe as capacidades do sistema de suportar a nova escala e deve ser adotada, apenas para preservar a estabilidade.<\/p>\nDe qualquer forma, \u00e9 importante lembrar que sempre que um gargalo \u00e9 “quebrado”, emerge um outro gargalo. Por exemplo, “escalar” servidores de aplica\u00e7\u00e3o que n\u00e3o est\u00e3o conseguindo suportar a demanda, frequentemente move o gargalo para o “cache” ou para o banco. Ent\u00e3o, ao “escalar” estes componentes, a restri\u00e7\u00e3o volta a ser, com muita frequ\u00eancia os servidores de aplica\u00e7\u00e3o. O ponto importante \u00e9: ajustar a arquitetura para suportar a escala implica em, sempre, fazer an\u00e1lise hol\u00edstica – a for\u00e7a de uma corrente \u00e9 sempre determinada pelo seu elo mais fraco.<\/strong>\n

    Escalar \u00e9 a “arte de gerenciar filas”<\/h2>\n

    Na medida que identificamos, em nossos sistemas, componentes com diferentes n\u00edveis de capacidade para processamento, \u00e9 necess\u00e1rio reconhecer que, eventualmente, “fazer o todo funcionar” implica em tratar adequadamente as filas que se formam.<\/strong><\/p>\n

    A necessidade, por exemplo, de escalar na horizontal um servidor de aplica\u00e7\u00e3o \u00e9 demonstrada quando a ritmo de chegada<\/span> de novas requisi\u00e7\u00f5es \u00e9 maior de que a ritmo de atendimento.<\/span><\/p>\n

    Segue algumas ideias fundamentais para come\u00e7armos a avaliar filas em sistemas:<\/p>\n