{"id":2260,"date":"2021-06-19T08:34:32","date_gmt":"2021-06-19T11:34:32","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=2260"},"modified":"2024-01-16T15:05:38","modified_gmt":"2024-01-16T18:05:38","slug":"back-of-the-envelope-calculations","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/back-of-the-envelope-calculations\/","title":{"rendered":"AP-C Back-of-the-envelope calculations"},"content":{"rendered":"Boas pr\u00e1ticas de arquitetura de software devem ajudar a determinar a quantidade certa de recursos computacionais necess\u00e1ria para suportar demandas de escala e escopo. Nem mais, nem menos!\n
\n

Sistemas com recursos insuficientes “caem” em ambiente produtivo, comprometendo a confiabilidade e amea\u00e7ando a continuidade dos neg\u00f3cios. Por outro lado, sistemas com recursos excessivos, corroem reservas financeiras, abreviando o tempo de vida de\u00a0startups\u00a0<\/i>ou o lucro.<\/p>\n

Conceitos simples para resolver problemas complexos<\/h2>\n

Jeff Dean<\/a>, da Google, defende a utiliza\u00e7\u00e3o de uma t\u00e9cnica simples para estimativas, chamada \u201cBack-of-the-Envelope calculations<\/em>“. Trata-se do uso combinado da imagina\u00e7\u00e3o criativa com algum conhecimento de n\u00fameros relacionados \u00e0 performance.<\/p>\n

\r\n

Jeff Dean, Google Senior Fellow<\/p>\r\n<\/p>\n

A Google mant\u00e9m 11 n\u00edveis de distin\u00e7\u00e3o para seus engenheiros. O n\u00edvel mais alto – Google Senior Fellow – foi conferido a apenas dois profissionais na organiza\u00e7\u00e3o: Jeff Dean e Sundar Pichai.<\/p>\n

Sundar Pichai \u00e9 o atual CEO da Google.<\/p>\n

Jeff Dean \u00e9 o SVP da Google Research e tem no curr\u00edculo, al\u00e9m do pr\u00f3prio buscador, BigTable<\/a>, MapReduce<\/a> e ProtocolBuffers<\/a>\u00a0e o TensorFlow<\/a>.<\/p>\n

<\/div>\n

Seguindo as recomenda\u00e7\u00f5es de Dean, ao projetar uma API, por exemplo, dever\u00edamos estimar quantas requisi\u00e7\u00f5es os principais endpoints<\/em> t\u00eam que atender (importante, tamb\u00e9m, para o estabelecimento de Rate Limiters<\/em>) por um per\u00edodo. Da\u00ed, considerando hor\u00e1rios comuns de consumo, \u00e9 poss\u00edvel inferir quantas requisi\u00e7\u00f5es precisam ser suportadas por hora, minuto e segundo balizando o throughput <\/em>ideal. Adicionadas \u00e0s margens de seguran\u00e7a, tem-se uma boa ideia de dimensionamento de infraestrutura, frente a arquitetura.<\/p>\n

\r\n

Rate Limiters<\/p>\r\n<\/p>\n

Em sistemas distribu\u00eddos, um rate limiter<\/em> \u00e9 utilizado para restringir o tr\u00e1fego de uma aplica\u00e7\u00e3o cliente para os servidores. Toda vez que um limite de requisi\u00e7\u00f5es \u00e9 atingido, o excedente \u00e9 contido (em uma fila, por exemplo) para processamento posterior ou \u00e9 descartado. S\u00e3o essenciais, mas precisam ser implementados adequadamente.<\/p>\n

A ado\u00e7\u00e3o de rate limiters<\/em> previne problemas de nega\u00e7\u00e3o de servi\u00e7o (DoS), em fun\u00e7\u00e3o de uso abusivo, intencional ou n\u00e3o, de um recurso. Por isso, eles s\u00e3o comuns nas arquiteturas de sistemas projetados para a escalabilidade. O Twitter, por exemplo, restringe o n\u00famero de tu\u00edtes, por usu\u00e1rio, a 2400 por dia<\/a>. No Instagram, \u00e9 poss\u00edvel realizar no m\u00e1ximo 200 chamadas \u00e0s APIs por hora com um mesmo token<\/em>.<\/p>\n

Al\u00e9m de evitar a nega\u00e7\u00e3o de servi\u00e7os, rate limiters <\/em>ajudam a controlar custos, sobretudo em ambientes onde os gastos estejam associados a pagamentos para terceiros conforme ordem de uso.<\/p>\n

Rate limiters <\/em>podem ser implementados em client-side<\/em>, server-side <\/em>ou em um middleware<\/em>. Implementa\u00e7\u00f5es em client-side <\/em>tem como m\u00e9rito principal a redu\u00e7\u00e3o da press\u00e3o sobre a rede. J\u00e1 implementa\u00e7\u00f5es em server-side <\/em>ou middleware<\/em> s\u00e3o mais \u201cconfi\u00e1veis\u201d, por estarem em ambientes gerenciados, e robustas, visto que permitem regras mais complexas.<\/p>\n

<\/div>\n

O custo computacional e de tempo para o atendimento de cada requisi\u00e7\u00e3o tamb\u00e9m pode ser calculado considerando opera\u00e7\u00f5es como busca e leitura de dados em dispositivos de armazenamento, transfer\u00eancia de dados na rede, compacta\u00e7\u00e3o e etc. Da\u00ed, projetando o volume de requisi\u00e7\u00f5es esperadas, pode-se avaliar a efici\u00eancia de uma solu\u00e7\u00e3o proposta.<\/p>\n

H\u00e1 tr\u00eas conceitos b\u00e1sicos para a pr\u00e1tica de Back-of-the-Envelope<\/em> calculations:<\/p>\n

    \n
  1. Unidades b\u00e1sicas de medida de volumes de dados (pot\u00eancias de 2)<\/li>\n
  2. M\u00e9tricas de lat\u00eancia<\/li>\n
  3. Disponibilidade<\/li>\n<\/ol>\n
    \n

    Em uma palestra em que Dean conta um pouco da trajet\u00f3ria da arquitetura do sistema de buscas da Google<\/a>, ele demonstra a efic\u00e1cia da t\u00e9cnica para projetar um sistema de thumbnails <\/em>(ali\u00e1s, esse \u00e9 um desafio cl\u00e1ssico em entrevistas de System Design para grandes companhias).<\/p>\n

    Unidades b\u00e1sicas de medida de volumes de dados<\/h3>\n

    Mesmo em sistemas gigantescos, que lidam com quantidades monstruosas de dados, \u00e9 fundamental expressar corretamente volumes, usando informa\u00e7\u00f5es b\u00e1sicas.<\/p>\n

    A unidade fundamental de medida de volumes de dados \u00e9 o\u00a0byte<\/em>, que \u00e9 uma sequ\u00eancia de 8\u00a0bits\u00a0<\/em>(binary digits).\u00a0<\/em>As demais unidades importantes s\u00e3o expressas em pot\u00eancias de 2 (2n<\/sup>).<\/p>\n