Um sistema distribuído é aquele em que a falha de um computador que você nem sabia que existia pode inutilizar seu próprio computador.
Esta famosa citação de Leslie Lamport, ganhadora do prêmio AM Turing, resume os desafios na construção e manutenção de um sistema distribuído. Mas por que há necessidade de sistemas tão complicados?
Com o advento da Internet e de dispositivos mais inteligentes, a quantidade de dados que precisam ser processados explodiu. Atividades simples do dia a dia, como pedir um Uber, assistir a um programa no Netflix, uma simples pesquisa no Google, fazer compras online ou interagir com as redes sociais, todas ações triviais que consideramos certas são alimentadas por centenas de serviços de distribuição. Todos esses serviços são construídos na espinha dorsal de alguns documentos fundamentais em sistemas distribuídos.
Embora esta lista definitivamente não seja abrangente, aqui estão alguns dos meus artigos favoritos que tiveram um impacto enorme no mundo dos sistemas distribuídos.
Embora não seja um artigo tradicional, Eric Brewer o apresentou pela primeira vez como uma conjectura em um discurso no Simpósio ACM sobre Princípios de Computação Distribuída (PODC) de 2000. O artigo foi posteriormente formalizado e comprovado por Nancy Lynch e Seth Gilbert no artigo Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
O teorema CAP de Eric Brewer é um conceito fundamental na teoria de sistemas distribuídos, afirmando que é impossível para um armazenamento de dados distribuído fornecer simultaneamente mais de duas das três garantias: consistência, disponibilidade e tolerância de partição. Todos os outros artigos mencionados aqui aplicam o princípio acima e fazem as compensações necessárias em seu sistema.
O teorema CAP sempre leva a muitas discussões com base na compreensão do artigo pelos leitores. " A Critique of the CAP Theorem " de Martin Kleppmann fornece uma estrutura melhor para discutir as compensações.
Neste artigo seminal de 2001, Leslie Lamport apresenta o algoritmo Paxos para alcançar consenso em um sistema distribuído de maneira fácil e acessível. Os protocolos de consenso baseados em Paxos formam a espinha dorsal de muitos bancos de dados distribuídos, sistemas de armazenamento, plataformas de mensagens e serviços de coordenação usados por muitas empresas de tecnologia. Influenciou fortemente outras tecnologias como Chubby do Google, Spanner do Google, Apache ZooKeeper, Apache BookKeeper, etc.
O artigo do Google File System (GFS) apresenta um sistema de arquivos distribuído escalonável para grandes aplicativos distribuídos com uso intensivo de dados em hardware comum, que é a base para muitos sistemas de arquivos distribuídos que se seguiram. O GFS serviu como uma grande inspiração para o HDFS, o sistema de arquivos distribuído usado pela estrutura Apache Hadoop e, eventualmente, pelo Amazon S3 (mesmo que o s3 seja fundamentalmente diferente).
Este artigo apresenta o modelo de programação MapReduce, que demonstra uma abordagem escalável para processar conjuntos de dados em grande escala usando infraestrutura de computação distribuída. O MapReduce desempenhou um papel fundamental na revolução do “big data”, permitindo que as organizações aproveitassem o poder da computação distribuída para analisar e obter insights de enormes conjuntos de dados. Você pode ver como a combinação do GFS e do MapReduce permitiu ao Google processar petabytes de dados para organizar os dados da “internet”.
O artigo MapReduce (junto com GFS) inspirou o desenvolvimento de todo um ecossistema de ferramentas e bibliotecas construídas em torno do Apache Hadoop, como Apache Hive (infraestrutura de data warehouse construída em Hadoop), Apache Pig (linguagem de fluxo de dados de alto nível para Hadoop), Apache Spark (mecanismo de processamento de dados na memória), Apache HBase (banco de dados NoSQL distribuído) e muitos outros.
O artigo da Bigtable representa um sistema de armazenamento distribuído para gerenciamento de dados estruturados no Google. Depois que o MapReduce e o GFS permitiram que o Google processasse dados em escala e de maneira econômica, a próxima etapa foi permitir o acesso aos dados de maneira confiável e altamente disponível. A BigTable foi capaz de fornecer uma solução flexível e de alto desempenho para aplicativos como indexação da web, Google Earth e Google Finance.
Assim como o MapReduce revolucionou a era do “big data”, o papel BigTable foi a força motriz da era “NoSQL”. Muitos dos princípios de design e conceitos arquitetônicos introduzidos no artigo do Bigtable foram usados em tecnologias como "Apache HBase", "Cassandra", "MongoD" etc. Embora alguns desses aplicativos possam usar diferentes modelos de dados (por exemplo, MongoDB), eles compartilham princípios comuns, como escalabilidade horizontal, tolerância a falhas e fragmentação automática.
O artigo Dynamo apresenta o design e implementação de um armazenamento de valores-chave altamente disponível desenvolvido pela Amazon. O Dynamo atendeu à necessidade de acesso em tempo real a dados altamente dinâmicos, como itens em seu carrinho de compras. O artigo introduziu o conceito de "consistência eventual" como um princípio fundamental do projeto de sistemas distribuídos, permitindo garantias de consistência relaxadas para alcançar alta disponibilidade e desempenho (olá, teorema CAP!).
Do próprio artigo, “Comparado ao Bigtable, o Dynamo tem como alvo aplicativos que exigem apenas acesso de chave/valor com foco principal em alta disponibilidade, onde as atualizações não são rejeitadas mesmo após partições de rede ou falhas de servidor”.
Semelhante ao BigTable, o artigo do Dynamo influenciou fortemente tecnologias subsequentes como Riak, Voldemort, Cassandra e até mesmo tecnologias de streaming de eventos como Apache Kafka.
O rápido crescimento do Facebook exigiu uma solução de banco de dados capaz de lidar com grandes quantidades de dados e suportar um grande número de usuários simultâneos. Embora BigTable e Dynamo tenham sido bastante influentes por si só, Cassandra foi a primeira tecnologia que deu um passo à frente das outras. Ao liberá-lo como uma contribuição de código aberto sob a licença Apache, juntamente com a publicação do artigo , o Facebook foi fundamental para permitir o acesso a essa tecnologia para toda a indústria.
Cassandra se diferenciou dos dois anteriores ao fornecer um modelo de consistência ajustável, permitindo aos usuários escolher entre consistência forte (como BigTable) e consistência eventual (como Dynamo) com base nos requisitos de sua aplicação.
Este artigo apresenta o Apache ZooKeeper e apresenta seus princípios e algoritmos de design para fornecer serviços de coordenação altamente confiáveis e escaláveis em sistemas distribuídos. Antes da introdução do ZooKeeper, os desenvolvedores de software muitas vezes tinham que implementar suas próprias soluções ad-hoc para coordenação distribuída e consenso em sistemas distribuídos.
O ZooKeeper propôs um serviço centralizado para coordenação distribuída, oferecendo primitivas como bloqueios distribuídos, eleição de líder e gerenciamento de configuração. Isso permitiu simplificar o desenvolvimento de aplicativos distribuídos, descarregando lógica de coordenação complexa para o ZooKeeper. Um dos casos de uso mais comuns do Zookeeper é para descoberta de serviço.
Este artigo apresenta o Apache Kafka, um sistema de mensagens distribuídas projetado para processamento de fluxos de eventos de alto rendimento e tolerante a falhas. A publicação de Kafka como um artigo de pesquisa e seu lançamento de código aberto como um projeto Apache o estabeleceram como um sistema de mensagens padrão para processamento de dados em tempo real altamente escalável e tolerante a falhas e arquiteturas orientadas a eventos.
Kafka introduziu um sistema de mensagens altamente escalável e tolerante a falhas, projetado para lidar com grandes volumes de fluxos de dados em tempo real. Kafka foi bastante influente ao permitir o desenvolvimento da arquitetura Lambda, que combina processamento em lote e processamento de fluxo para lidar com grandes volumes de dados com baixa latência e alto rendimento.
Este artigo apresenta conjuntos de dados distribuídos resilientes (RDDs), a abstração principal do Apache Spark, que permite o processamento de dados na memória tolerante a falhas em clusters distribuídos. O mecanismo de execução na memória do Spark oferece desempenho significativamente mais rápido em comparação ao MapReduce (que possui um modelo de execução baseado em disco), especialmente para algoritmos iterativos, aprendizado de máquina e análises interativas.
Esses artigos cobrem uma ampla gama de tópicos em sistemas distribuídos, incluindo sistemas de armazenamento, algoritmos de consenso, tolerância a falhas e escalabilidade. A leitura deles fornecerá uma base sólida nos princípios e práticas de construção e gerenciamento de sistemas distribuídos.
Se você está iniciando sua jornada em sistemas distribuídos e deseja aprender mais, ou se já é um especialista e simplesmente deseja atualizar seus fundamentos, não há melhor maneira de aprender do que lendo alguns desses artigos fundamentais sobre sistemas distribuídos.