Técnicas e Tecnologias de Computação em Nuvem Aplicadas Á Montagem Genômica

UNIVERSIDADE FEDERAL DO PARÁ
INSTITUTO DE TECNOLOGIA
FACULDADE DE ENGENHARIA DA COMPUTAÇÃO E
TELECOMUNICAÇÕES
BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO
AUGUSTO CÉSAR OLIVEIRA GONÇALVES
T ÉCNICAS E T ECNOLOGIAS DE C OMPUTAÇÃO EM N UVEM A PLICADAS

Á M ONTAGEM DE G ENOMAS
Belém
2019
T ÉCNICAS E T ECNOLOGIAS DE C OMPUTAÇÃO EM N UVEM A PLICADAS

Á M ONTAGEM DE G ENOMAS
Trabalho de Conclusão de Curso apresentado

para obtenção do grau de Bacharel em Engenha-
ria da Computação.
Orientador: Prof. Dr. Raimundo Viégas Jr.
Belém
2019
OLIVEIRA GONÇALVES, Augusto César
Técnicas e Tecnologias de Computação em Nuvem Aplicadas á Montagem de
Genomas/ AUGUSTO CÉSAR OLIVEIRA GONÇALVES. – Belém, 2019.
57 p. : il. (algumas color.) ; 30 cm.
Orientador: Prof. Dr. Raimundo Viégas Jr.
Monografia – UNIVERSIDADE FEDERAL DO PARÁ

INSTITUTO DE TECNOLOGIA
BACHARELADO EM ENGENHARIA DA COMPUTAÇÃO, 2019.
1. Orquestração de Containers. 2. Computação em nuvem. 3. Bioinformática. I.
Título.
T ÉCNICAS E T ECNOLOGIAS DE C OMPUTAÇÃO EM N UVEM

A PLICADAS Á M ONTAGEM DE G ENOMAS
Trabalho de Conclusão de Curso apresentado

para obtenção do grau de Bacharel em Engenha-
ria da Computação.
Data da Defesa: 20 de Dezembro de 2019

Conceito:
Banca Examinadora
Prof. Dr. Raimundo Viégas Jr.

Faculdade de Computação - UFPA
Orientador
Prof. Dr. Roberto Célio Limão de Oliveira

Faculdade de Engenharia da Computação e
Telecomunicações - UFPA
Membro da Banca
Profa. Dra. Regiane Silva Kawasaki Francês

Faculdade de Computação - UFPA
Membro da Banca
Belém
2019
Este trabalho é dedicado áqueles que decifram os segredos da realidade
e aplicam o seu conhecimento na elevação da condição humana e na superação dos limites
AGRADECIMENTOS
Em primeiro lugar gostaria de agradecer minha mãe, Ana Paula, e meu pai, Paulo César,
que sempre deram todo suporte para permitir que eu chegasse até aqui. Sem vocês talvez eu não
estivesse aqui hoje.
Quero agradecer a todos os professores que conheci durante toda a minha caminhada,
desde o ensino fundamental até o ensino superior. Todos vocês me ajudaram a compreender
diversos tipos de matérias e conceitos relacionados á computação e engenharia. Agradeço
também á todos e todas que se dedicam á disponibilizar conhecimento nas bibliotecas virtuais
e fórums da vasta Internet, onde pude obter o conhecimento para firmar e verificar técnicas,
conceitos e opiniões, e, acima de tudo, conhecer as ferramentas para se compreender a realidade.
Um agradecimento especial ao Prof. Dr. Raimundo Viégas, que aceitou me orientar
no desenvolvimento deste trabalho, e desde a primeira concepção do projeto, mostrou grande
entusiasmo com as tecnologias envolvidas e conceituou várias aplicações para estas.
Também sou grato à UFPA, por conceder toda a estrutura necessária para a realização
deste curso na instituição, e também ao CTIC, onde tive oportunidade de fazer estágio e tive
minha primeira exposição ás tecnologias de infraestrutura de TI e ao DevOps, e onde adquiri os
conhecimentos para a realização deste trabalho.
Não poderia deixar de agradecer ao Pedro Rocha, por ter sido uma pessoa fundamental
para o desenvolvimento do projeto. Sua contribuição foi essencial para o entendimento dos
aspectos práticos da montagem de genomas. No mais, agradeço pelo apoio e pela disponibilidade
ao sanar minhas dúvidas.
Um agradecimento especial ao Carlos Nogueira, que me guiou na minha iniciação na
área de infraestrutura de TI, e foi o responsável pela ideia inicial para a realização deste trabalho.
Gostaria de agradecer a todas as pessoas que sempre torceram por mim e que me ajudaram
de maneira direta ou indireta com minha evolução acadêmica. Fico muito feliz de poder ter vocês
por perto.
E por fim, agradeço á Jaqueline, que sempre torceu pelo meu sucesso.
“Eu não creio que exista algo mais emocionante para o coração humano do que a emoção
sentida pelo inventor quando ele vê alguma criação da mente se tornando algo de sucesso.
Essas emoções fazem o homem esquecer comida, sono, amigos, amor, tudo.” (Nikola Tesla)
RESUMO
A partir da união da expansão da infraestrutura de telecomunicações, avanços na teoria e técnicas

de sistemas distribuídos e da computação como serviço, nasce o conceito da computação em
nuvem, que abstrai aplicações do hardware físico propriamente dito, para concentrar ou distribuir
recursos de computação em magnitudes antes inviáveis. Uma aplicação para este conceito é a
resolução de problemas computacionalmente custosos, frequentes na pesquisa científica, como a
montagem genômica. Para comprovar experimentalmente a viabilidade da nuvem de computação
nesta função, criou-se, embasado nos conceitos de computação em nuvem, microserviços,
paralelismo e orquestração de contêineres, uma nuvem de computação orientada á montagem
genômica. Aplicada á demandas de pesquisa em bioinformática na Universidade Federal do
Pará, a solução se demonstrou robusta e eficiente, em comparação com montagem sequencial de
mútiplas amostras em máquinas individuais.
Palavras-chave: orquestração de containers. computação em nuvem. bioinformática.

ABSTRACT
From the union of expanding telecommunications infrastructure, advances in the theory and
techniques of distributed systems, and computing as utility, the concept of cloud computing is
born, which abstracts applications from proper physical hardware, to concentrate or distribuite
computing resources in magnitudes once impracticable. A application for this concept is the
resolution of computationally costly problems, frequently found in scientific research, as genome
assembly. To prove experimentally the viability of the computing cloud in this role, a computing
cloud was created, following the concepts of cloud computing, microservices, paralellism and
container orchestration, whose role is the assembly of genomes. Applied to bioinformatics
research demands in the Federal University of Pará, the solution was shown to be reliable
and efficient, in comparison to sequential assembly of mutiple genome samples in individual
machines.
Keywords: gamification. usability test. software development.

LISTA DE ILUSTRAÇÕES
Figura 1 – Representação visual de modelos de serviços de computação em nuvem. . . 20
Figura 2 – Diagrama de demonstração da relação entre modelos de implantação de
infraestrutura de nuvem de computação. . . . . . . . . . . . . . . . . . . . 22
Figura 3 – Complexidade e organização de infraestrura e aplicações em modelos de
arquitetura orientada a serviços. . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 4 – Comparação entre arquiteturas de virtualização em máquinas virtuais tradici-
onais e contêineres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figura 5 – Diagrama de reresentação do processo de montagem genômica. . . . . . . 30
Figura 6 – Arquitetura do orquestrador de contêineres Kubernetes. . . . . . . . . . . . 34
Figura 7 – Arquitetura da solução em camadas . . . . . . . . . . . . . . . . . . . . . . 38
Figura 8 – Filas de mensagens do protocolo AMQP. . . . . . . . . . . . . . . . . . . . 40
Figura 9 – Fluxograma e componentes da cadeia de processamento. . . . . . . . . . . 41
Figura 10 – Árvore de pastas de trabalho para a cadeia de processos. . . . . . . . . . . . 42
Figura 11 – Gráfico dos tempos de execução. . . . . . . . . . . . . . . . . . . . . . . . 44
LISTA DE TABELAS
Tabela 1 – Nós de controle e trabalho alocados ao cluster . . . . . . . . . . . . . . . . 43
Tabela 2 – Número de pods funcionais por aplicação . . . . . . . . . . . . . . . . . . 43
Tabela 3 – Tempos de execução do processamento de 10 amostras . . . . . . . . . . . 45
LISTA DE ABREVIATURAS E SIGLAS
AG Algoritmo genético
BaaS Backend-as-a-service
FaaS Function-as-a-service
SaaS Software-as-a-service
PaaS Platform as a Service
k8s Kubernetes
contigs Cadeia contínua de genomas montados
reads Fragmentos de genomas
SdBG Grafo sucinto de De Brujin
UFPA Universidade Federal do Pará

SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5 Contribuição do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1 Computação em nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.1 Modelos de serviço para computação em nuvem . . . . . . . . . . . . . . . 20
2.1.2 Modelos de infraestrutura para computação em nuvem . . . . . . . . . . . . 21
2.2 Modelos de arquitetura de software orientada a serviços . . . . . . . . . 21
2.2.1 Arquitetura monolítica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Arquitetura em microserviços . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 Arquitetura serverless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.4 Arquteturas de software reativa e assíncrona . . . . . . . . . . . . . . . . . 26
2.3 Virtualização baseada em contêineres . . . . . . . . . . . . . . . . . . . 27
2.3.1 Orquestração de contêineres . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.4 Montagem genômica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 TECNOLOGIAS DE ORQUESTRAÇÃO DE CONTÊINERES: O ES-
TADO DA ARTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Contêineres de virtualização Docker . . . . . . . . . . . . . . . . . . . . 31
3.2 Soluções de orquestração de contêineres . . . . . . . . . . . . . . . . . . 31
3.2.1 Docker Swarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 Mesos/Marathon/DC/OS – o “Mesosphere” . . . . . . . . . . . . . . . . . . 35
4 PROPOSTA E EXPERIMENTO EM PARALELIZAÇÃO ESCALONÁ-
VEL DE MONTAGEM DE SEQUÊNCIAS GENÔMICAS UTILIZANDO
RABBITMQ E KUBERNETES . . . . . . . . . . . . . . . . . . . . . . . 38
4.1 Arquitetura e componentes da aplicação . . . . . . . . . . . . . . . . . . 38
4.1.1 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.2 Prinseq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1.3 Megahit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.4 Metabat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.5 Metaquast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Descrição da cadeia paralelizada de processos . . . . . . . . . . . . . . . 41
4.3 Implementação prática da nuvem de computação . . . . . . . . . . . . . 42
5 TESTES E RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . 44
6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
APÊNDICES 49
APÊNDICE A – PROCEDIMENTOS DE INSTALAÇÃO E CONFIGU-
RAÇÃO DO CLUSTER . . . . . . . . . . . . . . . . . 50
APÊNDICE B – ARQUIVOS DE CONFIGURAÇÃO DE OBJETOS
DE TRABALHO DO KUBERNETES . . . . . . . . . 54
14
1 INTRODUÇÃO
O desenvolvimento da computação digital é um marco significativo na história da huma-

nidade: a capacidade de processar informações nunca antes disponível desatrelou a capacidade
intelectual humana de métodos comparativamente ponderosos e efêmeros de computação, busca
e armazenamento de dados e informações, facilitando e potencializando consideravelmente
vários tipos de processos industriais, científicos e burocráticos. A aplicação da computação
digital em qualquer campo do conhecimento humano, cedo ou tarde, resulta em progressos
exponenciais.
Desde seus primeiros dias, o computador eletrônico digital é empregado primordialmente
na resolução de problemas custosos, se tentada por outros meios: todo problema que envolve
cálculos em grande quantidade ou que possa ser reduzido e conceituado em tais termos, sempre
vai ter na história de sua solução um desenvolvedor com conhecimento, ou consultoria, profundos
sobre o problema em questão, e um computador, para realizar solenemente o trabalho árduo.
Porém, dado o crescimento do conhecimento humano e a capacidade crescente de
entender e modelar os aspectos da realidade, surgem problemas que até para o computador se
tornam complexos e custosos para serem resolvidos em tempo hábil, visto que o custo econômico
de provisionamento de hardware físico pode tornar-se significativo. Um componente evolutivo
na história da computação, além do desenvolvimento de hardwares com maior especialização,
capacidade de processamento e armazenamento de dados e o desenvolvimento da teoria da
computação, é a criação de técnicas e tecnologias de integração e provisionamento de redes de
computadores e aplicações e recursos computacionais distribuídos. Ao paradigma compreendido
pela consolidação de tais técnicas e tecnologias, convencionou-se chamar de "computação em
nuvem".
1.1 Contexto
Com o crescente aumento da informação digital e a grande massa de dados associada á
estas informações, a computação se vê desafiada a processar e interpretar de forma hábil, volumes
cada vez maiores de dados. Esta realidade, antes manifestada primariamente em aplicações
científicas e burocráticas, após a crescente integração da tecnologia digital com múltiplos
aspectos da vida diária de bilhões de pessoas, vem ganhando mais visibilidade na opinião pública.
García (2015) argumenta que "a computação em nuvem transformou a forma como sistemas e
aplicações são criados, distribuídos e escalonados, e é considerada um dos desenvolvimentos
tecnológicos mais importantes da última década. Esta tecnologia permite que indivíduos e
organizações compartilhem um conjunto de recursos de computação, armazenamento e conexão
em rede, permitindo o controle do hardware utilizado para operar parte significativa da Internet,
enquanto reduz a complexidade e custos operacionais."
Capítulo 1. Introdução 15
Diante disso, a aplicação da computação em nuvem á pesquisa científica facilita a

superação de barreiras econômicas e institucionais e contribui para o progresso e democratização
da ciência e das ferramentas e técnicas necessárias para sua produção e difusão.
"Bioinformática é a aplicação de tecnologia da informação ao campo da biologia, envol-
vendo a criação e avanço em algoritmos, bases de dados, técnicas computacionais e estatísticas, e
teorias para resolução de problemas formais e práticos decorrentes do gerenciamento e análise de
dados biológicos. O objetivo primátio da bioinformática é avançar o entendimento de processos
biológicos."Nisbet, Elder e Miner (2009)
Uma aplicação relevante da bioinformática, segundo Moreano e Melo (2017), "é a análise
de DNA e sequências proteicas de organismos sequenciados. A comparação de sequências de
dados é uma das operações fundamentais da bioinformática, servindo como base para mani-
pulações mais complexas. [...] Recursos e técnicas de computação de alta performance podem
ser utilizados para acelerar estas operações. Mútiplas soluções para comparação paralela de
sequências foram propostas, como arquiteturas multi-core, clusters e FPGAs."
Sendo assim, este trabalho propõe desenvolver uma nuvem de computação para executar
o processamento paralelo de montagem genômica, dada a grande quantidade de dados a processar
neste processo. Com o aumento do tamanho e quantidade de sequências genéticas a montar, este
processo pode se tornar inviável de executar individualmente em computadores pessoais comuns.
1.2 Justificativa
Em vários projetos de pesquisa, um problema recorrente é a existência de problemas de
resolução computacional custosa, e a falta de recursos de hardware suficientes para atender á
demanda da resolução de problemas em tempo hábil, de forma confiável, principalmente pelo
alto custo de aquisição de hardware de alta performance, e o custo do conhecimento técnico
associado á manutenção e implementação deste.
Assim, é importante procurar alternativas á estruturas de computação tradicionais, e
encontrar novas formas de provisionar recursos computacionais para a pesquisa científica, em
particular para seus problemas mais custosos. A computação em nuvem se mostra uma alternativa
econômica, eficiente e ajustável ás particularidades e necessidades dos problemas em questão,
e ao mesmo tempo que oferta tais benefícios, aplicações científicas vindicam o paradigma de
computação em nuvem e solidificam sua contribuição para o melhoramento da condição humana
e a compreensão da realidade.
Por esse motivo, decidiu-se desenvolver uma nuvem de computação, para atender de
forma eficiente ás demandas computacionais de pesquisas em bioinformática. Com esta fer-
ramenta, busca-se fornecer uma ferramenta sólida e eficiente para montagem genômica, e ter
um campo de aprendizado e prática para técnicas de computação em nuvem. Além disso, as
técnicas de processamento paralelo desenvolvidas neste trabalho podem ser expandidas para
outras aplicações que se sujeitem ao paralelismo em alto nível, não se mantendo restrita ao seu
propósito inicial aqui exposto.
1.3 Objetivos
Esta seção lista os objetivos gerais e específicos do presente trabalho.
1.3.1 Objetivo Geral

O objetivo geral do trabalho é desenvolver uma nuvem de computação, para atender de
forma eficiente ás demandas computacionais de pesquisas em bioinformática.
1.3.2 Objetivos Específicos

De forma a atingir o objetivo geral deste trabalho, foram traçados os seguintes objetivos
específicos:
• Criar um projeto de infraestrutura computacional para implementação de cluster computa-

cional e nuvem de computação.
• Traçar um método de processamento paralelo para os estágios da montagem genômica.
• Implementar na nuvem de computação métodos de controle e soluções de montagem

genômica, aproveitando o potencial da orquestração de contêineres para escalabilidade e
processamento paralelo.
1.4 Trabalhos Relacionados

Na computação bio-inspirada, em particular no desenvolvimento de arquiteturas eficientes
para execução de algoritmos genéticos, existem várias iniciativas baseadas em paralelização
de processos, por conta da natureza modular do AG, tanto implementações em baixo nível
quanto implementações em nuvem e clusters computacionais. Os trabalhos de Zheng et al. (2013)
e Salza e Ferruci (2018) conceituam e testam, respectivamente, cada uma destas abordagens.
Schatz et al. (2010) implementa a montagem genômica utilizando o modelo de programação
MapReduce sob o framwork de computação distribuída Hadoop.
No trabalho de Zheng et al. (2013), compara-se a performance e usabilidade de sistemas
multi-core (CPU) e many-core (GPU) para paralelização de AG’s. Individualmente, sistemas
baseados em GPU demonstraram maior rapidez na execução do algoritmo paralelizado, porém,
soluções de maior qualidade eram obtidas por sistemas baseados em CPU, abrindo a possibilidade
da computação em clusters distribuídos de CPUs, ou nuvem de computação, ser uma abordagem

viável para a paralelização de AG’s.
Já no trabalho de Salza e Ferruci (2018), foi provisionada uma nuvem de computação,
abrangendo todos os aspectos de implantação, testes e integração de aplicações em AG’s,
e comparações foram feitas entre AG’s executados sequencialmente e de forma paralela, o
paralelismo implantado por meio de contêineres orquestrados e protocolo de filas de mensagem
AMQP.
Em seu projeto de implementação de montagem genômica em nuvem, Schatz et al.
(2010) implementa a montagem genômica baseada grafos de de Brujin, no modelo MapReduce
com framework Hadoop em nuvem de computação, para realizar a montagem paralelizada de
genomas complexos. O uso desta abordagem foi aplicado na montagem de genomas parciais
humanos, gerando resultados úteis com o processamento paralelizado, distribuído entre centenas
de nós de computação, para processar em tempo hábil a quantidade significativa de dados
resultante do sequenciamento de genomas humanos.
A diferença do trabalho de Zheng et al. (2013) para o trabalho de Salza e Ferruci (2018)
está na abordagem utilizada para implementação do paralelismo de processos para a aplicação
em questão, visto que o objetivo geral é paralelizar um processo, dividi-lo em componentes, e
provar a eficiência das abordagens e qualidade das saídas geradas pelas técnicas de paralismo.
Schatz et al. (2010) implementa a montagem genômica paralelizada com técnicas e tecnologias
de computação em nuvem.
1.5 Contribuição do Trabalho

Tendo em vista os trabalhos de Salza e Ferruci (2018) e Schatz et al. (2010), planejou-se
criar uma nuvem de computação para implementar técnicas de paralelização em alto nível,
além das vantagens inerentes ás tecnologias de computação em nuvem, porém, uma nuvem
computacional orientada á execução dos processos de montagem de genomas. Esta pesquisa
também envolve um levantamento do estado da arte de tecnologias de computação em nuvem, e
os conceitos gerais por trás destas.
1.6 Metodologia
A pesquisa bibliográfica foi feita por meio de buscas em repositórios de artigos online uti-
lizando palavras-chave como: computação em nuvem, virtualização, orquestração de contêiners,
montagem de genomas. Foi verificado quais artigos implementavam paralelização de processos
em nuvem aplicados á problemas computacionalmente custosos. Feito isso, procurou-se nas
referências bibliográficas dos trabalhos os autores mais citados para, então, obter a composição
do referencial teórico deste trabalho.
Para o desenvolvimento da solução de montagem paralelelizada de genomas, utilizaram-

se ferramentas e softwares de código aberto: sistema operacional Linux Debian, engine de
contêineres Docker, orquestrador de contêineres Kubernetes, servidor de filas de mensagem
RabbitMQ, e aplicações de estágios de montagem genômica: Prinseq (tratamento de qualidade),
Megahit (montagem genômica de novo por meio de grafos de De Brujin) e Metabat (binning
metagenômico). Para fins de comparação, fez-se uma comparação do tempo de execução do
processo completo de tratamento de qualidade, montagem genômica e binning metagenômico,
comparando resultados obtidos no cluster e com a execução sequencial das aplicações em
máquinas virtuais monolíticas com quantidades equivalentes de recursos computacionais.
1.7 Estrutura do Trabalho

Assim, o presente trabalho está organizado da seguinte forma:
Capítulo 1: Contém uma breve introdução do assunto, a contextualização, a justificativa,
objetivo geral e específicos, trabalhos relacionados, a contribuição do trabalho, a metodologia e
a estrutura do trabalho.
Capítulo 2: Apresenta o referencial teórico, a definição de conceitos fundamentais em
computação em nuvem, arquiteturas de software voltadas á serviços, virtualização de hardware e
montagem genômica.
Capítulo 3: Expõe o estado da arte de tecnologias de orquestração de contêineres.
Capítulo 4: O capítulo mostra como foi feita a organização do projeto e detalhes do
desenvolvimento do experimento e seus componentes.
Capítulo 5: Expõe os resultados comparativos, tanto de performance quanto de qualidade
do processamento das amostras de genomas, e apresenta as conclusões do trabalho e possíveis
trabalhos futuros.
19
2 REFERENCIAL TEÓRICO
Este capítulo apresenta o referencial teórico que fundamentou este trabalho, elucidando
os conceitos básicos para o entendimento do tema abordado.
2.1 Computação em nuvem

Segundo definição elaborada por Mell e Grance (2011) para o NIST (National Institute
of Standards and Technology, Instituto Nacional de Padrões e Tecnologia dos Estados Unidos da
América), “Computação em nuvem é um modelo que permite acesso conveniente, onipresente e
sob demanda á redes de conjuntos compartilhados de recursos computacionais configuráveis
(redes, servidores, armazenamento, aplicações e serviços), que podem ser provisionados rapi-
damente e liberados com esforço administrativo mínimo e pouca ou nenhuma interação com o
provedor de serviços.”
Embora a origem do termo "computação em nuvem"seja incerta, a teoria e prática de
sistemas de computação distribuída vem sendo desenvolvida desde a origem das primeiras redes
de computadores, sendo uma de suas primeiras implementações a computação compartilhada
entre mútiplos usuários, conectados por terminais, em uma mesma máquina, e softwares e rotinas
diretamente programados para execução paralela distribuída em baixo nível.
García (2015) divide a "nuvem de computação"em três blocos fundamentais: proces-
samento, ou a computação propriamente dita, armazenamento e networking, ou conexão via
redes.
O bloco de computação abrange as variáveis de uma oferta de trabalho em computação:
memória RAM, CPUs, leitura e escrita de dados, e largura de banda para intercomunicação
entre nós distintos da nuvem. Combinações diferentes destas variáveis produzem servidores
com especializações distintas, para atender ás diferentes necessidades de cada problema em
relação á demanda sob cada uma destas variáveis. Estas ofertas de trabalho podem ser entregues
tanto em forma de acesso á máquinas virtuais ou mesmo físicas, plataformas especializadas de
frameworks e linguagens particulares, ou mesmo softwares executados na nuvem de computação
em questão.
O bloco de armazenamento abrange os aspectos de armazenamento de dados na nuvem
de computação, e as técnicas relacionadas á segurança, integridade e disponibilização destes
dados. Estruturas de armazenamento podem ser implementadas desde o uso simples de discos
rígidos físicos ou lógicos até infraestruturas complexas de storages (servidores otimizados para
operações de armazenamento de dados) de acesso ágil, distribuídos geograficamente, combinados
com sistemas RAID e políticas de backup.
O bloco de networking abrange "um vasto número de soluções e técnicas, incluindo
Capítulo 2. Referencial Teórico 20
sistemas de resolução de nomes de domínio (DNS), capacidade de criação de sub-redes, compar-

tilhamento de endereços IP, redes locais virtuais (VLANs), e a largura de banda para conectar
todos os componentes da infraestrutura, em especial máquinas virtuais e soluções de armazena-
mento."García (2015)
2.1.1 Modelos de serviço para computação em nuvem

Expandindo o conceito, Mell e Grance (2011) propõe 3 modelos abrangentes de serviço
para computação em nuvem, e estes modelos são organizados sob um ou múltiplos modelos de
implantação em nuvem:
Figura 1 – Representação visual de modelos de serviços de computação em nuvem.
Fonte: Autor
Infrastructure-as-a-Service(IaaS), ou infraestrutura como serviço, onde “a capacidade

oferecida ao consumidor é o provisionamento de processamento, armazenamento, redes e outros
recursos fundamentais de computação, onde o consumidor é capaz de implantar e executar
software arbitrário, que podem incluir sistemas e aplicações. O consumidor não gerencia nem
controla a nuvem de infra-estrutura subjacente, mas tem controle sobre sistemas operacionais,
armazenamento e aplicativos implantados, e possivelmente controle limitado de componentes de
rede selecionados (por exemplo, firewalls de host).”Mell e Grance (2011)
Platform-as-a-Service(PaaS), ou plataforma como serviço, no qual “a capacidade forne-
cida ao consumidor é implantar na infraestrutura em nuvem aplicações adquiridas ou criadas
pelo consumidor por meio de linguagens de programação, bibliotecas, serviços e ferramentas
suportadas pelo provedor. O consumidor não gerencia ou controla a infraestrutura de nuvem
subjacente, [...] mas tem controle sobre os aplicativos implantados e possivelmente definições de
configuração para o ambiente de hospedagem de aplicativos.”Mell e Grance (2011)
Software-as-a-Service(SaaS), ou software como serviço: “A capacidade oferecida ao
consumidor é usar as aplicações do provedor executadas em infraestrutura de nuvem. Os aplicati-
vos são acessíveis a partir de vários dispositivos do cliente por de meio interfaces como cliente
magro, como um navegador da web (por exemplo, e-mail baseado na web) ou uma interface em
programa ou aplicação móvel. O consumidor não gerencia ou controla a infra-estrutura de nuvem

subjacente, [...] com a possível exceção de configurações limitadas de aplicativos específicos do
usuário.”Mell e Grance (2011)
2.1.2 Modelos de infraestrutura para computação em nuvem

Estes modelos são implantados sob nuvens privadas, públicas, comunitárias ou híbridas:
Nuvem privada: “A infraestrutura em nuvem é provisionada para uso exclusivo por uma
única organização compreendendo vários consumidores (por exemplo, unidades de negócios).
Sua propriedade, gerência e operação é dada pela organização, terceiros, ou alguma combinação
deles, e pode existir dentro ou fora de instalações.”Mell e Grance (2011)
Nuvem comunitária. “A infraestrutura em nuvem é provisionada para uso exclusivo
por uma comunidade de consumidores de organizações que compartilham preocupações (por
exemplo, missão, requisitos de segurança, políticas e considerações de conformidade). Sua pro-
priedade, gerência e operação é dada por uma ou mais organizações da comunidade interessada,
terceiros, ou alguma combinação deles, e pode existir dentro ou fora de instalações.”Mell e
Grance (2011)
Nuvem pública. “A infraestrutura de nuvem é provisionada para uso aberto pelo público
em geral. Pode ser de propriedade, gerenciado e operado por uma organização comercial,
acadêmica ou governamental, ou alguma combinação deles. Ele existe nas premissas do provedor
de nuvem, estas não sendo necessariamente limitadas geograficamente.”Mell e Grance (2011)
Nuvem híbrida: “A infraestrutura da nuvem é uma composição de duas ou mais nuvens
distintas infra-estruturas (privadas, comunitárias ou públicas) que permanecem como entidades
únicas, mas congregadas por tecnologia padronizada ou proprietária que permite portabilidade de
dados e aplicações (por exemplo, estouro de nuvens para balanceamento de carga entre nuvens
em momentos de pico de demanda).”Mell e Grance (2011)
2.2 Modelos de arquitetura de software orientada a serviços

2.2.1 Arquitetura monolítica
O modelo de arquitetura monolítica, também denominado modelo tradicional cliente-
servidor, é caracterizada por aplicações organizadas em componentes e funções reunidos em
um único executável lógico: bancos de dados, interfaces para usuários e a lógica de negócio
executada em back-end. Atualizações ou modificações em qualquer componente da aplicação
obrigatoriamente exigem refatoração e implantação.Huang e Wu (2017)
A aplicação monolítica é implementada como um único arquivo (exemplo: executáveis)
ou arquivos em um único diretório, e o seu processo de escalonamento basicamente consiste em
Figura 2 – Diagrama de demonstração da relação entre modelos de implantação de infraestrutura

de nuvem de computação.
Fonte: Autor
réplicas da aplicação e seu ambiente de execução completo, em conjunto com um balanceador de

carga para distribuir e equilibrar demandas entre cada réplica implantada na plataforma.Fowler
(2015)
Tais características resultam em menor complexidade nos processos de implantação,
desenvolvimento, segurança e monitoramento da aplicação em geral, em pequenas escalas de
implantação e complexidade: logs, caches, debuggers e outras ferramentas de monitoramento
e testes podem ser concentradas em uma única instância, e a internalização de componentes
em única instância reduz as dificuldades associadas com distribuições de chaves criptográficas,
controle de acesso á dados de aplicação sensitivos e armazenamento distribuído de valores-chave.
Todavia, estas mesmas características podem se tornar barreiras ao hábil desenvolvimento
e implantação da aplicação, principalmente em contextos de replicação em grande escala dos
serviços providos pela aplicação monolítica: o atendimento á aumentos de demanda sob um
componente particular da aplicação (armazenamento, bancos de dados, requisições HTTP,
upload e processamento de arquivos, etc) só se resolve pela replicação de instâncias completas
da aplicação, resultando em uso ineficiente de recursos computacionais. Fowler (2015)
2.2.2 Arquitetura em microserviços

A arquitetura em microserviços compreende a organização dos diferentes componentes de
uma aplicação em pequenos módulos, cada módulo definido como uma unidade de software cujos
processos de desenvolvimento, atualização e substituição são realizáveis de forma independente
do sistema como um todo. Lewis e Fowler (2014)
A funcionalidade completa da aplicação é fornecida por estes módulos e seu conjunto de
interações. O modelo de microserviços é apropriado para uso em conjunto com virtualização
baseada em contêineres, por conta das características comuns aos dois paradigmas: economia de
recursos, modularidade e alta disponibilidade.

Conceitualmente, a arquitetura em microserviços é concebida a partir de requerimentos
de capacidade da lógica de negócio de aplicações, cada requerimento podendo ser atendido de
forma diferente, de modo a permitir o uso de soluções independentes umas da outras: linguagens,
frameworks e plataformas de execução para programação, tecnologias de armazenamento de
dados; esta heterogeneidade de tecnologias implica em gerenciamento central reduzido. Portanto,
o modelo de microserviços é desenvolvido em oposição ao modelo monolítico, favorecendo o
desenvolvimento e implantação modular de componentes de aplicação em formato de suítes
de serviços, de modo a reduzir ou eliminar as deficiências e dificuldades que emergem da
implementação em grande escala de aplicações monolíticas. Lewis e Fowler (2014)
No processo de divisão da aplicação em componentes, as unidades consideradas como
componentes são bibliotecas e serviços: as primeiras definidas como componentes compartilha-
dos porém fortemente acoplados e internalizados aos processos, e os últimos sendo componentes
externos, constituídos por um ou mais processos e “fracamente acoplados” aos processos, por
meio de chamadas de procedimento remoto (RPCs) ou requisições HTTP. Lewis e Fowler (2014)
O serviço, por meio destas características, permite a implantação e desenvolvimento independen-
tes, necessários ao modelo em microserviços por meio da modularidade e acoplamento fraco,
apesar do incremento em overhead gerado pelo uso de RPCs ou requisições HTTP associadas
ao uso da API. Para garantir o aspecto modular da aplicação em nível de projeto, o processo de
desenvolvimento é dividido em equipes multidisciplinares com capacidades abrangendo todo o
espectro do desenvolvimento de software: front-end, back-end, bancos de dados, UI e gerência
de projetos, dentre outros[8]. Cada componente é desenvolvido por uma equipe multidisciplinar,
em processo de desenvolvimento, implantação e execução contínuo, por todo o ciclo de vida
da aplicação e do componente em particular. Porém, mesmo ostensivamente separadas e utili-
zando soluções e tecnologias diferentes, equipes de desenvolvimento em microserviços mantém
intercomunicação e compartilham bibliotecas e ferramentas: a este conjunto de padrões e boas
práticas dá-se o nome de governança descentralizada. Lewis e Fowler (2014)
Por conta de seu caráter modular, aplicações divididas em microserviços são menos
vulneráveis á falhas em componentes individuais, desde que introduzidas as devidas técnicas para
mitigação de falhas em componentes: transparência, soluções de monitoramento para métricas re-
levantes de negócio(throughput, latência, carga) e elementos arquitetônicos(saúde de contêineres,
logs, comportamentos inusitados), cadeia de testes (funcional, aceitação, integração, aceitação
de usuário e performance) apropriadas ao ambiente de execução distribuído, e infraestrutura
automatizada para testes, implantação e produção. Para gerenciamento e persistência de dados,
cada microserviço utiliza bancos de dados próprios para a função específica do microserviço em
questão, podendo ser compartilhado entre várias instâncias do microserviço. O gerenciamento
de dados descentralizado garante exclusividade e persistência para os bancos de dados de micro-
serviços, porém a implementação de transações distribuídas em bancos de dados organizados
segundo tal padrão é difícil e gera um overhead oneroso tanto em termos de tempo quanto
consumo de dados. Uma forma de contornar estas dificuldades é coordenar microserviços e seus
dados sem o uso de transações distribuídas, porém esta prática implica em perdas de consistência
eventuais entre os bancos de dados distribuídos. Lewis e Fowler (2014)
Todas estas técnicas de compartimentalização e decomposição de aplicações em mi-
croserviços, sejam estes efêmeros ou persistentes, levam a um processo de desenvolvimento e
implantação evolucionário, onde melhoramentos, reduções e atualizações mantém a aplicação
eficiente e alinhada com requerimentos de negócio frequentemente reformulados, enquanto que
a estrutura modular mitiga as dificuldades associadas ao constante versionamento e implantação
associado ao ciclo de desenvolvimento contínuo. Lewis e Fowler (2014)
2.2.3 Arquitetura serverless

A arquitetura serverless parte da ideia de abstrair completamente o gerenciamento de in-
fraestrutura e recursos computacionais, fornecendo uma plataforma gerenciada para hospedagem
e execução, onde funções do código-fonte da aplicação do cliente são invocadas e executadas sob
demanda, e os seus requerimentos de infraestrutura e recursos computacionais são fornecidos de
forma efêmera, ou apenas na quantidade e no tempo de execução exigidos pela função invocada
em particular pelo usuário da aplicação. Roberts (2018)
Duas formas conceituais existem para definir uma arquitetura para aplicações serverless:
BaaS(Backend-as-a-service): aplicações, serviços e sistemas hospedados em nuvem, projetados
como plataformas de cliente ricas, com backend, lógica de servidor, bancos de dados, autenticação
e gerenciamento de estado e infraestrutura em geral fornecidos por plataformas terceirizadas(ex.
Firebase, Auth0, AWS). Roberts (2018)
Function-as-a-service(FaaS): aplicações com lógica de backend própria, executada em
um ecossistema de contêineres stateless (sem preservação de estados), efêmeros e invocados sob
demanda, gerenciados por terceiros. O “servidor” e sua infraestrutura associada se manifestam
e são disponiblizados apenas no momento de invocação de funções da lógica de backend da
aplicação. Roberts (2018)
Estas formas não são mutualmente exclusivas, e em todo caso o cliente não deve se
preocupar com lógica de backend, gerenciamento, segurança e escalonamento de recursos
computacionais e infraestrutura: esta é fornecida “como serviço”, e a ideia central é manter
ao cliente apenas a responsabilidade de fornecer o código de aplicação, e organizar chamadas
ao código por meio de eventos ou requisições diretas de plataformas web ou clientes móveis.
Serviços FaaS não são restritos a uma tecnologia, e permitem o uso de várias linguagens de
programação e frameworks, conquanto que o código seja interpretável ou compilável ao ponto
de resultar em um processo executável pela plataforma (exemplo: processo Unix).
Entretanto, a natureza efêmera e imediatista do ambiente de execução serverless impõem
restrições quanto á duração da execução do código, e armazenamento de estados. Em aplicações

stateful executadas em ambientes serverless, é necessário o uso de um ambiente de armazena-
mento persistente, externo á instância de execução da aplicação, seja local ou outro serviço
nativo á nuvem, e para funções de longa duração, faz-se separação entre a tarefa executável em
si e a tarefa de coordenação e invocação da função. Roberts (2018)
Figura 3 – Complexidade e organização de infraestrura e aplicações em modelos de arquitetura

orientada a serviços.
Fonte: Autor
Logo, a arquitetura serverless não é a forma mais viável para implementação direta de
aplicações que exijam armazenamento de estado e/ou execução e monitoramento de estado
contínuos, exigindo a refatoração da arquitetura da aplicação. Outros desafios, tanto inerentes à
natureza da arquitetura quanto gerados pela falta de maturidade em tecnologia e organização de
serviços, incluem vulnerabilidades em segurança por conta de terceirização de responsabilidades
e o fato da concorrência e hospedagem de múltiplas aplicações e instâncias na mesma máquina
física, refatorações de aplicação impostas por mudanças no serviço hospedeiro, impossibilidade
de otimizações em servidores, latência no lançamento de instâncias e execução de funções, e
dificuldades de configuração, testes e monitoramento (este último principalmente por conta do
contêiner efêmero). Roberts (2018)
Por outro lado, instâncias de execução efêmeras e automatização de escalonamento
sob demanda permitem um ajuste fino e maior aproveitamento de recursos computacionais
no lado do serviço de hospedagem da aplicação, afirma Lewis e Fowler (2014), reduzindo
custos operacionais e danos ao meio ambiente por meio de ganhos em eficiência energética, e a
terceirização de backend e implantação reduz o custo, complexidade e tempo de desenvolvimento.
2.2.4 Arquteturas de software reativa e assíncrona

Software reativo e software assíncrono são design patterns empregados no desenvol-
vimento de aplicações e sistemas “mais robustas, mais resilientes, mais flexíveis e melhor
posicionadas para atender demandas modernas.”, afirma Bonér et al. (2014). Tais demandas exis-
tem em função do paradigma mobile combinado á alta disponiblidade, com “usuários esperando
respostas em milisegundos, uptime de 100%, e fluxos de dados medidos em petabytes.” Bonér
et al. (2014). Estas arquiteturas existem em oposição á arquiteturas síncronas, organizadas em
formas monolíticas, características de aplicações e sistemas legado.
Segundo Debski et al. (2018), “o Manifesto Reativo enfatiza a necessidade de construir
sistemas escalonáveis e responsivos. Ele define os traços básicos de uma aplicação reativa:
uma abordagem orientada por mensagens, elasticidade, resiliência e capacidade de resposta.
Também sugere técnicas adequadas para alcançá-las. De acordo com o manifesto, isso leva a
sistemas mais flexíveis, fracamente acoplados, escaláveis e tolerantes a falhas.” Responsividade,
ou capacidade de resposta, é conceituada como “sistema que retorna respostas em tempo hábil,
se possível. Responsividade é a pedra fundamental da usabilidade e utilidade, mas mais do que
isso, responsividade significa que problemas podem ser detectados rapidamente e tratados com a
máxima eficácia.
Sistemas Responsivos são focados em fornecer tempos de resposta rápidos e consistentes,
estabelecendo limites superiores de confiança para que eles entreguem qualidade de modo con-
sistente. Esse comportamento consiste em simplificar o tratamento de erro, reforçar a confiança
do usuário final e incentivar futuras interações.” Bonér et al. (2014)
Sistemas resilientes são “sistemas com capacidade de responder em caso de falha. Isto é
aplicável não apenas para sistemas de missão crítica ou para alta disponibilidade — qualquer
sistema que não é resiliente ficará fora do ar depois de uma falha. Resiliência é alcançada por
replicação, contenção, isolamento e delegação. A contingência a falhas é feita dentro de cada
componente, isolando-os uns dos outros e assim garantindo que partes do sistema podem falhar
e se recuperar sem comprometer o sistema como um todo. A recuperação de cada componente é
feita por outro componente (externo) e alta disponibilidade é garantida por replicação quando
necessário. Os clientes de cada componente não são sobrecarregados com o tratamento de falhas.”
Bonér et al. (2014)
Elasticidade em sistemas reativos se dá por meio de projetos “responsivos mesmo sob
variações de demanda. Sistemas Reativos podem reagir a mudanças na taxa de entrada através do
aumento ou diminuição dos recursos alocados para lidar com essas entradas. Isso requer projetos
que não tenham pontos de contenção ou gargalos centrais, resultando na habilidade de dividir ou
replicar componentes e distribuir a demanda entre eles. Sistemas Reativos suportam algoritmos
de escalonamento preditivos, assim como Reativos, provendo métricas relevantes e em tempo
real. Eles conseguem elasticidade com custo efetivo em hardware padrão e em plataformas de
software.” Bonér et al. (2014)

Sistemas orientados a mensagens são sistemas com uma forma de implantação de arquite-
tura de software assíncrona(definda como uma arquitetura de aplicações onde o “processamento
de uma requisição ocorre em um tempo após ter sido transmitido do cliente para o serviço, e o
cliente não observa diretamente ou sincroniza-se com a execução que ocorre dentro do serviço.”,
argumenta Bonér et al. (2014)), baseados em “passagem de mensagens assíncronas para estabe-
lecer fronteiras entre os componentes e garantir baixo acoplamento, isolamento, transparência na
localização e provêem meios para delegar o tratamento de erros através de mensagens. Empregar
explicitamente a passagem de mensagens, modelar e monitorar as filas do sistema e aplicar
contrapressão quando necessário, permite gerenciamento de demanda, elasticidade e controle
de fluxo. Mensagens com transparência na localização como um meio de comunicação tornam
possível o gerenciamento de falhas da mesma maneira seja em um cluster ou em um único
host. Comunicação não bloqueante permite que destinatários consumam recursos quando ativos,
evitando desgaste do sistema.” Bonér et al. (2014)
2.3 Virtualização baseada em contêineres

Contêineres são pacotes de software leves, que incluem os requisitos mínimos para
execução de aplicações(software executado em camada superior a software de sistema, estes
definidos como programas de baixo nível): código-fonte, ambiente de execução, ferramentas de
SO, bibliotecas e configurações. Docker (2019)
A principal distinção de contêineres para outras técnicas de virtualização(processos
para execução de instâncias virtuais de sistemas computacionais em uma camada abstraída do
hardware no qual o sistema opera) é a ausência da necessidade de execução de um sistema
operacional completo para cada aplicação, possibilitando a configuração de diferentes ambientes
de execução rodando sob o SO da máquina hospedeira, para criar múltiplas instâncias isoladas
de espaços de usuários. Para a execução e hospedagem de aplicações projetadas para um mesmo
sistema operacional, esta técnica permite maior especialização voltada para a aplicação a ser
executada, enquanto gera economia de espaço de armazenamento, exclui a necessidade de
parada completa do SO, facilita manutenção, portabilidade e atualização de aplicações, e reduz o
overhead associado a operação de máquinas virtuais. Casalicchio (2017)
Em aplicações com grande quantidade de componentes concorrentes, contêineres podem
ser aplicados para aumentar a eficiência de cada componente por meio de especialização do
ambiente de execução, alta escalabilidade, e a facilidade de redimensionamento. O conceito de
contêiner, em ciência da computação, foi inicialmente formulado em 1992, sendo o namespace
Linux um componente chave no desenvolvimento do contêiner, evoluindo da virtualização de
sistema operacional para o contêiner de aplicação. Casalicchio (2017)
Figura 4 – Comparação entre arquiteturas de virtualização em máquinas virtuais tradicionais e

contêineres.
Fonte: Autor
2.3.1 Orquestração de contêineres

Orquestração de contêineres se entende como o conjunto de operações de adminis-
tração de contêineres: implantação, monitoramento, dimensionamento e controle de recursos,
objetivando alto nível de disponibilidade e QoS (qualidade de serviço).
Segundo Casalicchio (2017), “A orquestração de contêineres não se atém apenas á entrega
de aplicações em múltiplos contêineres, mas também trata da gerência do ambiente de execução,
por exemplo: escalonar uma aplicação dividida em contêineres como uma única entidade; con-
trolar aplicações baseadas em contêineres em múltiplos hospedeiros; compor contêineres em
arquiteturas de software de alta disponibilidade; otimizar a conectividade da aplicação, execu-
tando processamento próximo ao armazenamento de dados. Por conta do ambiente complexo e
dinâmico de operação de contêineres, as ações de orquestração devem ser adaptadas em tempo
real, sem intervenção humana, implicando em mecanismos de orquestração autônomos”.
Desafios da orquestração de contêineres autônoma incluem gerência de recursos em
tempo de execução, sincronização entre ambientes de desenvolvimento e produção, monitora-
mento, perfilamento, caracterização e modelagem de performance, e definição de modelos de
otimização para orquestração e adaptação.
A missão do orquestrador envolve todo o ciclo de vida do contêiner. Em um modelo de
orquestração centralizada, o orquestrador acessa o repositório de imagens de contêineres, e deve
decidir quando, e em qual nó de computação, será executado o contêiner. Nós de computação
são clusters de máquinas hospedeiras, que podem ser distribuídas (nuvem de computação) ou
concentradas geograficamente. Cada nó pode executar de um a vários contêiner, dependendo do
gerenciamento da container engine(CE) para cada nó. Cada CE em cada nó se comunica com o
orquestrador, para coordenar a execução de contêineres. Casalicchio (2017)

Para gerenciamento de segurança, o orquestrador implementa o conceito de segredo
de aplicação, um objeto(arquivo) que contém dados sensíveis: senhas, tokens, certificados e
chaves criptográficas, contido preferencialmente em um espaço separado dos nós contendo os
ambientes de produção ou desenvolvimento de aplicações, e fornecido em um nó separado, de
acesso privilegiado e , segundo o modelo 12-factor, como variável de ambiente
As decisões tomadas pelo orquestrador são baseadas no sistema e em informações do
estado de ambiente, coletadas pelo componente monitor e analisadas por módulo de análise.
O componente planejador executa a política de orquestração para encontrar a configuração
apropriada para o sistema, isto é, resolve um modelo de sistema ou executa um algoritmo
heurístico. Tipicamente, a política de adaptação encontra o configuração ideal ou sub-ótima
do sistema que maximiza a utilidade de provedor e que satisfaz restrições não-funcionais
e funcionais. O componente executor implementa o plano de adaptação, interagindo com o
orquestrador de contêiner. Casalicchio (2017)
2.4 Montagem genômica

Em bioinformática, o processo de montagem de sequências genômicas consiste no
alinhamento e fusão de fragmentos de uma sequência de DNA longa. Tal processo é necessário
por conta das limitações de técnicas e tecnologias de sequenciamento, as quais não possibilitam
a leitura contínua e completa de genomas. Giani et al. (2019)
Técnicas de sequenciamento, como sequenciamento shotgun e transcrição genômica em
RNA, produzem resultados fragmentados, necessitando do processo de montagem para se obter
uma representação computacional do genoma completo. O processo de montagem genômica é
algorítmico, feito a partir de sobreposições nos fragmentos produzidos pelo sequenciamento. O
processo de montagem pode ser feito de 3 formas: algoritmo guloso, consenso de sobreposição e
ciclo hamiltoniano, e grafos de De Brujin com caminhos eulerianos. Angel et al. (2018)
Antes da montagem em si, o primeiro procedimento realizado sob os reads (amostras
genômicas) é o tratamento de qualidade e filtragem. Neste estágio, a quantidade de fragmen-
tos, presença de adaptadores e contaminantes é analisada, e se determina se a quantidade de
fragmentos na amostra em questão representa o genoma como um todo.
Para reconstruir os genomas presentes na amostra, o conjunto de fragmentos (reads)
é tipicamente reduzido á um número menor de sequências contínuas (contigs), por meio da
combinação de grupos de reads com sobreposição significativa na menor superstring possível,
no processo de montagem. Como metagenomas contém tanto sequências muito similares porém
distintas, assim como sequências de baixa abundância, a montagem genômica é complexa, e
a maioria dos genomas é representada por fragmentos de contigs. Para reconstituir genomas a
Figura 5 – Diagrama de reresentação do processo de montagem genômica.
Fonte: Universidade de Ghent, 2019
partir de dados obtidos do sequenciamento de metagenoma, deve-se agrupar contigs a partir do

seu genoma de origem. Tal processo é denominado binning metagenômico. Nissen et al. (2018)
31
3 TECNOLOGIAS DE ORQUESTRAÇÃO DE CONTÊI-

NERES: O ESTADO DA ARTE
Nesta seção será feita uma breve exposição sobre as principais soluções de orquestração
de contêineres, suas características e particularidades. Um foco especial será dado ao orques-
trador Kubernetes, ferramenta fundamental para a realização do experimento a ser descrito
posteriormente neste trabaho.
3.1 Contêineres de virtualização Docker

Docker é um projeto de código aberto, criado para automatizar de forma sistemática a
implantação de aplicações Linux em contêineres portáteis. A base de seu funcionamento é a
junção de APIs a nível de kernel e aplicação com contêineres Linux, estes baseados em cgroups,
a biblioteca libcontainer, cuja função é comunicar contêineres com a API do sistema hospedeiro,
e isolamento via espaços de nomes(namespaces), repartições distintas de recursos de kernel para
conjuntos de processos isolados do resto do sistema. Richardson e Smith (2016) Assim, cada
contêiner possui um ambiente de execução completo próprio, com exclusividade de recursos
de hardware, isolado de outros processos em execução em outros contêineres ou na máquina
hospedeira. Huang e Wu (2017)
O contêiner Docker é criado a partir de uma imagem-base(base image), que pode
variar de um SO com os requisitos e bibliotecas mínimas para seu propósito, a uma aplicação
completa, pronta para uso em produção. Para execução de comandos e parâmetros relacionados
ao processo de automação de implantação e criação de contêineres, existe o Dockerfile, um
arquivo configurável composto de vários comandos e argumentos. Contêineres Docker são o
padrão dominante para conteinerização de aplicações, e várias aplicações de orquestração de
contêineres existem voltadas para Docker. Bernstein (2014)
3.2 Soluções de orquestração de contêineres

3.2.1 Docker Swarm
Docker Swarm (ou swarm mode, modo de enxame, em tradução livre) é o orquestrador
de contêiner nativo do projeto Docker. Primeiramente sendo uma ferramenta de integração
de clusters com ferramentas open source de integração e deployment, o Docker Swarm autô-
nomo é lançado em 2016, contendo serviços de contêineres otimizados para clusters: alocação,
escalonamento e persistência de contêineres.
Um dos focos do Swarm é a facilidade de criação de um cluster e uma instância de
gerenciamento a partir de uma instância simples do Docker, com simplicidade de operação e
Capítulo 3. Tecnologias de orquestração de contêineres: o estado da arte 32
uso eficiente de recursos. Instâncias podem ser lançadas a partir de terminais, e o gerenciador
distribui estas entre as máquinas físicas alocadas para o cluster, com comunicação fornecida por
VPN autoconfigurável e DNS próprio, rodando sob rede definida por software(SDN), facilitando
a interação entre contêineres distribuídos em redes diferentes[11].
Farcic (2017) pontua que o Swarm fornece suporte nativo para importantes aspectos do
processo de conteinerização: 1. Gerenciamento de clusters 2. Orquestração de contêineres 3.
Descoberta de serviços e balanceamento de carga 4. Segurança avançada e gerenciamento de
segredos
Para definir corretamente o modelo de arquitetura Swarm, não se pode deixar de fa-
lar da arquitetura base da engine Docker. Segundo Farcic (2017), o Docker se compõe dos
seguintes elementos: Servidor (ou daemon dockerd): recebe toda chamada à API Docker, e
gerencia recursos: imagens-base, volumes de armazenamento ou segredos, comunicação entre
daemons e configurações de redes. runC e containerd: processos, respectivamente, de execução e
gerenciamento de contêineres API REST: interface de comunicação entre clientes e daemons,
acessível via linha de comando ou HTTP CLI: interface de linha de comando Tais processos são
a base da gerência de contêineres Docker, e importantes em contexto de baixo nível para um
cluster Swarm.
As funções de gerenciamento de clusters e orquestração são fornecidas pelo utilitário
Swarmkit: uma versão mais avançada do Swarm, caracterizada pelo uso do algoritmo raft
consensus e TLS em toda comunicação entre nós.
Um cluster (ou swarm) é definido a partir da necessidade de recursos de um serviço:
quantidade de réplicas de hospedeiro de nós(nodes), tanto trabalhadores (workers) executores de
tarefas (tasks), como administradores (managers), posicionamento em nós específicos, portas de
rede abertas, recursos de rede e armazenamento disponíveis, entre outros, e o swarm mantém
o estado do serviço, utilizando o algoritmo raft consensus, descrito em Hausenblas (2018).
Paralelamente ao swarm, podem ser executados contêineres Docker avulsos, exceto aqueles
contêineres para fins de administração, que devem ser executados dentro do swarm em questão a
ser administrado.
A função do algoritmo raft consensus é manter a integridade da replicação de configura-
ções e atividades entre os nós administradores, para garantir a continuidade da administração,
em particular a função de replicação de logs do swarm em caso de falha em um nó. O algoritmo
mantém o estado do cluster consistente por meio de consenso entre uma maioria [(N/2)+1],
sendo N o número de nós executando o algoritmo, de nós administradores em relação à variáveis
de configuração, e tolera eventos de falha até a perda de [(N-1)/2] de nós. Assim, o algoritmo
implementa as seguintes características de sistemas distribuídos no cluster: concordância de
valores de configuração, exclusão mútua (utilizada no processo de seleção do nó administrador
líder), sequenciamento consistente de objetos e tarefas e gerenciamento de membros no cluster.
No contexto Swarm, serviços são tarefas a executar, definidas a partir de comandos e

imagens de contêiner, no nó gerenciador ou nós trabalhadores. Para replicação ou disponibiliza-
ção global de serviços dentro do cluster, o gerenciador replica a tarefa no número necessário
de nós trabalhadores. O Swarm não permite a mudança de tarefas entre nós, apenas replicação:
tarefas devem ser executadas ou terminar dentro apenas do nó para o qual foram alocadas.
Para balanceamento de carga, o Swarm cria malhas de roteamento para ingressar na rede
interna do cluster: um artifício para redirecionar requisições de serviços vindas de conexões em
portas ativas em todo nó do cluster, até atingir um nó com o serviço desejado ativo. O gerenciador
pode publicar portas para serviços tanto manual quanto automaticamente. Farcic (2017)
O gerenciamento de segredos, definidos como dados como senhas, chaves criptográficas,
variáveis e dados sensíveis do ambiente de execução, ou qualquer outro dado que seja definido
como sensível no processo de desenvolvimento da aplicação e não deva ser transmitido sem
encriptação, é realizado por nós gerenciadores, dentro do log criptografado do algoritmo raft, e
mantido em storages persistentes. O storage em si é acessível por todos os nós em um cluster,
e os segredos de um cluster também são acessíveis por dentro do log do algoritmo raft, por
todos os nós gerenciadores do cluster ou pelo serviço executado em um nó ao qual uma chave
criptográfica do segredo em questão tenha sido designada.
Para garantir a inviolabilidade de segredos, o segredo no storage não pode ser atualizado,
devendo ser substituído por um novo segredo no momento que atualizações às informações
contidas no segredo sejam necessárias, e ao se assignar um segredo a um nó, o segredo é montado
em um filesystem dentro da memória do contêiner. Dentro do contêiner, o segredo só persiste até
o final da execução da tarefa do contêiner, não sendo modificável enquanto a execução está em
curso.
3.2.2 Kubernetes
Kubernetes, termo do grego antigo que significa "timoneiro, governador ou capitão", é
um orquestrador de contêineres desenvolvido a partir do Borg, uma solução de orquestração de
uso interno do Google. Seu foco de operação é balanço de carga, isolação e posicionamento de
contêineres, e opera a partir do paradigma de serviços em contêineres Docker. Cada serviço deve
possuir um escopo bem limitado, preferencialmente ao ponto de haver apenas um processo, e o
mínimo de dependências necessárias, rodando em um contêiner, para facilitar a escalabilidade e
melhorar a estabilidade de um sistema dividido em contêineres. Linux Foundation (2019)
Em uma infraestrutura de nuvem, ou em termos reais, máquinas físicas concentradas ou
dispersas geograficamente, cada máquina pode hospedar um ou vários contêineres Docker, e
algumas outras executam o software orquestrador. Os hospedeiros de contêineres são chamados
nós(nodes) e os hospedeiros do orquestrador, mestres(másters). Conjuntos de nós e mestres são
chamados de clusters.
Em cada máquina mestre Kubernetes, executam-se três serviços Linux Foundation

(2019): 1. Servidor API: sua função é atender requisições API realizadas por componentes
na máquina mestre ou nos nós. 2. containerd: um serviço de gerência de configuração para
contêineres baseado em armazenamento de chaves de valores. 3. Gerenciador de controle e
agendamento(Scheduler and Controller Manager): O serviço que agenda a criação, manutenção
e destruição de contêineres em cada nó.
Em cada nó Kubernetes, executam-se outros três serviços: 1. Kubelet: um daemon cuja
função é obedecer os comandos enviados pelo gerenciador de controle na máquina mestre 2.
Proxy: separa o IP do serviço fornecido pelo contêiner do IP do próprio contêiner 3. cAdvisor:
coleta estatísticas de execução de contêineres Seguindo o espírito distribuído e escalável de
contêineres, estes serviços podem ser distribuídos em várias máquinas, ou executados em um
único hospedeiro.
Figura 6 – Arquitetura do orquestrador de contêineres Kubernetes.
Fonte: Autor
Objetos e cargas de trabalho são definidos camadas de abstração construídas sob a

interface de contêineres, cuja função é auxiliar nos processos de escalonamento e ciclo de vida,
e criar uma infraestrutura computacional mais robusta. O usuário irá lidar com estas camadas, ao
invés de gerenciar contêineres diretamente.
Contêineres são organizados em pods, compartilhando recursos em comum, como um
endereço IP ou sistema de arquivos, e a comunicação interna no pod se dá via endereço localhost.
Pods são estruturados de forma á dividir os processos utilizados por um serviço individualmente
por cada contêiner no pod, sendo tal modelo necessário para a correta execução do orquestrador:
o Kubernetes não administra diretamente os processos internos ao contêiner, apenas o contêiner
em si. Dependendo da demanda apresentada ao cluster e o seu estado geral de funcionamento, um
pod pode ser desmontado de um cluster, e reconstruído em outro, considerando que os clusters
em questão possuem um volume lógico compartilhado, acessível aos pods. Pods também podem
montar sistemas de arquivos NFS, para armazenar dados mais persistentes, como bancos de
dados, logs ou dados armazenados a longo prazo. Farcic (2017)
O deployment é o primeiro objeto a ser comandado por iniciativa do usuário. Um deploy-
ment é um conjunto de replication sets, que realizam em conjunto o processo de atualizações e
rollbacks, e repassam ordens de configurações para os replication sets. Para fins de gerenciamento
e documentação de infraestrutura, o Kubernetes fornece um sistema de consulta e roteamento
de comandos e dados baseado em labels (etiquetas) e annotations (anotações). O label segue
o formato par chave-valor, podendo receber qualquer nome e conteúdo, seguindo a norma de
etiquetas DNS, e fora dos nomes reservados pelo Kubernetes. Linux Foundation (2019)
O replication controller (controlador de replicação) é o responsável pela criação, a partir
de um modelo pré-definido de pods, e multiplicação e desativação de pods, com base na demanda
de serviços, saúde dos pods e sua infraestrutura, e a configuração do cluster. Também organiza o
processo de atualizações e rollbacks de forma a não prejudicar a disponibilidade dos serviços
hospedados na infraestrutura conteinerizada.
Um tipo especial de controlador é o stateful set, que possui as funções de um controlador
de replicação, em conjunto com rotinas adicionais voltadas á preservação do estado de dados no
contêiner
Replication sets (conjuntos de replicação) são mais um tipo especial de controlador de
replicação que identifica de forma inteligente os pods a serem gerenciados, porém não possuem
a mesma habilidade de gerenciar atualizações e rollbacks, pelo fato de trabalharem em conjunto
com outros objetos de nível mais alto. Linux Foundation (2019)
3.2.3 Mesos/Marathon/DC/OS – o “Mesosphere”

Soluções desenvolvidas e mantidas pela Fundação Apache que fornecem múltiplas funci-
onalidades para execução, sistema operacional, provisionamento e gerenciamento de sistemas de
computação distribuída em nuvem.
Mesos é definido por Hindman et al. (2011) como “uma plataforma de compartilhamento
de clusters de recursos computacionais para frameworks de computação distribuída”, com
componentes em baixo nível simples e expansão de funcionalidades por uso de bibliotecas de
alto nível onde conjuntos de recursos são oferecidos seguindo a demanda imposta pela demanda
dos frameworks clientes executados no grupo de clientes e recursos, utilizando a aplicação
Zookeeper para armazenar valores-chave de configuração e seleção de nós mestres.
A habilidade de executar múltiplos frameworks permite o uso de tecnologias diferentes

ou mesmo o gerenciamento de instâncias de testes e produção do mesmo tipo de framework
utilizado por clientes. A distribuição de recursos é realizada de forma centralizada: o nó mestre
dispõe de recursos ao receber mensagens de daemons em nós escravos, e distribui estes recursos
em ofertas (que podem ser tanto reguladas automaticamente pelo mestre ou feitas a partir de
políticas, filtros, padrões e valores máximos e mínimos pré-configurados para certos tipos de
frameworks), estas ofertas podendo ser aceitas ou recusadas pelo framework cliente. Rodadas
de ofertas e aceitações são executadas até que a distribuição de recursos esteja mais próxima
do ideal implementado pelo algoritmo de distribuição ou política selecionado para o nó mestre.
Após aceitar uma oferta, o framework agenda tarefas em um módulo de execução no nó escravo
onde se localizam os recursos da oferta.Hindman et al. (2011)
Marathon é um sistema de orquestração de contêineres completo, com suporte á aplica-
ções stateful (aplicações com preservação de estados), balanceamento de carga e contêineres
Docker, além dos contêineres nativos Mesos, fornecendo contêineres orquestrados para a criação
de grupos de recursos computacionais e satisfação de demandas do Mesos. Assim, Marathon
também participa do processo de distribuição e orquestração de aplicações e frameworks. Me-
sosphere (2018a)
Para manter serviços de alta disponibilidade, o Marathon executa várias instâncias de
contêineres, apontadas ao Zookeeper, realizando automaticamente um novo nó mestre em caso
de falhas. Volumes de dados persistentes para aplicações stateful podem ser criados em pods ou
volumes externos, com suporte para segredos, e políticas de restrição para tarefas de aplicação
servem para distribuir entre vários nós ou restringir a distribuição de tarefas em um cluster ou nó
particular. Métricas de performance são coletadas automaticamente e podem ser visualizadas em
vários formatos (contador, histograma, medidor temporal, entre outros).
DC/OS é um sistema operacional distribuído, agnóstico para infraestrutura (suporta uso
tanto local quanto nuvem púlica ou privada), reunindo as funções do Mesos e Marathon, expan-
dindo funcionalidades e adicionando uma camada adicional de abstração e fornecendo serviços
para aplicações e clusters implementados em seu escopo de administração, focados para o uso
em grande escala[17]. O sistema é dividido em espaços reservados(ou camada de plataforma),
para alocação de recursos, administração de redes virtuais internas e segurança, isolamento
de processos e gerenciamento e orquestração de contêineres, volumes de armazenamento e
clusters, e espaços de usuário, onde se executam serviços, tarefas, agendadores e aplicações
conteinerizadas.
Nós são divididos em nós mestres, criados em números ímpares para garantir um quórum
mínimo (50%+1) para tolerância a falhas, ou nós agentes(ou escravos), estes últimos diferenci-
ados entre agentes públicos, expostos á conexões externas ao cluster, e agentes privados, com
acesso restrito. Cargas de trabalho são divididas entre agendadores de tarefas, e executores, que
invocam os frameworks e suas tarefas definidas no Mesos.Mesosphere (2018a)
Processos são distribuídos sequencialmente: Cliente > Agendador de tarefas > Nó mestre
> Nó agente > Executor E na ordem inversa fluem mensagens com informações atualizadas sobre
o estado da tarefa.
O DC/OS também fornece serviços de identidade e autenticação com LDAP, multitenân-
cia verdadeira de aplicações, isolamento de recursos, interfaces gráficas e linha-de-comando,
conexão segura entre clusters e componentes validados em testes de integração. Mesosphere
(2018b)
38
4 PROPOSTA E EXPERIMENTO EM PARALELIZAÇÃO

ESCALONÁVEL DE MONTAGEM DE SEQUÊNCIAS
GENÔMICAS UTILIZANDO RABBITMQ E KUBERNE-
TES
Este capítulo detalha a proposta e experimento de implementação de nuvem de compu-
tação para montagem genômica paralelizada, os componentes utilizados para a elaboração da
solução, e os conceitos e desafios práticos da computação em nuvem e microserviços,
4.1 Arquitetura e componentes da aplicação

Inspirado nas pesquisas de Salza e Ferruci (2018) e Schatz et al. (2010), propõe-se nesta
monografia uma plataforma voltada á montagem de genomas, constituída por camadas: base do
sistema constituída por nuvem de computação distribuída, podendo ser fornecida por provedores
comerciais ou in-premises (nuvem privada). Os recursos computacionais (processamento, memó-
ria volátil e armazenamento) fornecido pela combinação de serviços de nuvens empregados são
gerenciados e alocados pelo orquestrador Kubernetes.
Figura 7 – Arquitetura da solução em camadas
Fonte: Autor
Constituindo o núcleo da camada de sistema em conjunto com o sistema operacional

hospedeiro selecionado, Linux Debian, o Kubernetes realiza o provisionamento em clusters
de nós gerenciadores e trabalhadores, intercomunicação, agendamento de tarefas e gerência
Capítulo 4. Proposta e experimento em Paralelização Escalonável de Montagem de Sequências Genômicas
utilizando RabbitMQ e Kubernetes 39
de configuração para contêineres Docker, nos quais são distribuídas e executadas as etapas de
montagem: o nó-mestre fornece os arquivos com genomas a montar, e posta os nomes dos
arquivos, e mensagens de disparo para os nós-escravos em forma de mensagens na fila de
requisições do protocolo AMQP.
Os nós-escravos recolhem os dados no final da fila de requisições e recebem os indivíduos
fornecidos pelo nó-mestre, e executam as funções de tratamento de qualidade, montagem, binning
e análise de qualidade. Na conclusão da etapa de análise de qualidade, o nome de cada genoma
processado é postado na fila de retorno, e anunciado no nó-mestre.
Seguindo os postulados do modelo de arquitetura em microserviços, cada componente
é provisionado individualmente, em um container próprio, e com políticas de persistência e
replicação adequadas para cada aplicação componente do sistema, comandadas pelo orquestrador,
o qual também realiza a abstração entre contêineres e o hardware virtualizado a ser distribuido á
todos os habitantes do cluster.
4.1.1 RabbitMQ
RabbitMQ é um servidor de mensageria de código aberto, que implanta o protocolo
AMQP (advanced message queuing protocol, protocolo avançado de enfileiramento de mensa-
gens), compatível com outras plataformas de barramento de mensagens. A base do programa é o
mecanismo assíncrono de publicação e assinatura de mensagens: mensagens são publicadas em
uma fila de requisições, replicadas para o número de consumidores, e recebidas pelos assinantes
em sequência.
Mensagens podem ser definidas de várias formas, sem as limitações tradicionais impostas
por tamanhos de pacotes, e o mecanismo de mensagens possui vários utilitários: filtros, logs,
usuários e grupos, estados de transações e outras ferramentas de monitoramento. A ausência de
polling entre publicadores e assinantes diminui o overhead associado a mensagens síncronas.
Maatkamp (2015)
4.1.2 Prinseq
A aplicação Prinseq é definida por Schmieder e Edwards (2011) como "solução de
controle de qualidade e prepocessamento rápido e fácil de dados genômicos e conjuntos de
dados de metagenomas. Sumários de estatísticas, para arquivos FASTA, QUAL e FASTQ, são
gerados em forma gráfica e tabular, e sequências podem ser filtradas, reformatadas e aparadas
com várias opções para análise posterior. [...] o PRINSEQ permite ao cientista verificar e preparar
seus conjuntos de dados antes de processos de análise posteriores. Os resultados revelam se
o sequenciamento obteve êxito, se a amostra correta foi sequenciada, e se a amostra contém
contaminantes."
Figura 8 – Filas de mensagens do protocolo AMQP.
Fonte: Autor
4.1.3 Megahit
A aplicação Megahit é definida por Li et al. (2015) como "um montador de novo, de
sequenciamentos de nova geração, feito para montar dados metagenômicos grandes e complexos
de forma eficiente em tempo e custo. Finalizou a montagem de um conjunto de 252 GB de dados
metagenômicos de solos em 44,1 e 99,6 h, respectivamente, com e sem o uso de GPU. O Megahit
monta os dados por completo, sem a necessidade de pre-processamento como particionamento ou
normalização necessários. [...] O MEGAHIT utiliza grafos de De Brujin sucintos, representações
comprimidas deste tipo de grafo."
4.1.4 Metabat
A aplicação Metabat é definida por Kang et al. (2015) como "um software automatizado,
que integra distâncias probabilísticas empíricas de abundância de genomas e frequência de tetra-
nucleotídeos para realizar com precisão o binning metagenômico. [...] MetaBAT foi desenvolvido
como uma ferramenta de software eficiente, automatizada, capaz de performar o binning em
milhões de contigs de milhares de ferramentas."
4.1.5 Metaquast
Metaquast, segundo Mikheenko, Saveliev e Gurevich (2015), é "uma modificação da
ferramenta QUAST, o estado da arte para avaliação da montagem genômica a partir do alinha-
mento de contigs como referência. O MetaQUAST atende a características de conjuntos de
dados metagenômicos como (i) conteúdo de espécies desconhecidas por detecção e download de
sequências de referências, (ii) imensa diversidade por meio da produção de relatórios substanciais
para mútiplos genomas e (iii) presença de espécies fortemente relacionadas por detecção de
contigs quiméricas."
4.2 Descrição da cadeia paralelizada de processos

O transporte e publicação de mensagens entre os vários nós trabalhadores do sistema é
realizado por um nó executando o utilitário RabbitMQ, para implementar o protocolo AMQP
como um serviço disponibilizado para todos os nós trabalhadores no cluster. O RabbitMQ opera
com um serviço do tipo ClusterIP, para expor o servidor de AMQP.
As etapas da montagem (tratamento de qualidade e filtragem, montagem, binning e
análise de qualidade) são implementadas, respectivamente, pelos softwares Prinseq, Megahit,
Metabat e Metaquast, em imagens de contêineres Docker contendo o ambiente de execução e os
scripts com as partes do seu respectivo processo.
O controle de execução do fluxo de trabalho é feito por scripts de terminal e rotinas
em Python, cujas funções abrangem o disparo da execução dos aplicativos de montagem, e a
detecção, consumo e produção de mensagens nas filas AMQP. Como objeto de trabalho do
orquestrador, foi criado um controlador de replicação para provisionamento e gerenciamento dos
pods do RabbitMQ, e uma configuração geral de stateful set foi desenvolvida para provisionar e
gerenciar os pods dos softwares de montagem, apenas com adaptações pontuais necessárias para
cada aplicação diferenciando a sua configuração do stateful set.
Figura 9 – Fluxograma e componentes da cadeia de processamento.
Fonte: Autor
Adaptações e configurações adicionais necessárias para o funcionamento correto do

cluster com vários nós de trabalho incluem a criação de um repositório privado local de imagens
de contêineres Docker, hospedado no nó mestre, alterações na configuração do daemon do
Docker em todos os nós para apontar o endereço e permitir o acesso ao repositório local, e o
provisionamento de um servidor de arquivos NFS de acesso comum a todos os nós, para manter
a árvore de diretórios de trabalho utilizada pelos softwares. O NFS é fornecido ao orquestrador
como volume físico persistente, este volume sendo fornecido para todos os pods de trabalho nos
stateful sets.
O processamento de genomas é realizado de forma assíncrona, com cada etapa iniciada
Figura 10 – Árvore de pastas de trabalho para a cadeia de processos.
Fonte: Autor
pela recepção de mensagem de confirmação emitida pelo processo anterior, de forma que cada
etapa é iniciada assim que o primeiro pod disponível consome a mensagem de confirmação da
fila. Desta forma, os processos são disparados apenas quando há arquivos disponíveis na fila para
trabalhar, e evita-se condições de corrida que poderiam levar a falhas catastróficas no processo
de montagem genômica.
4.3 Implementação prática da nuvem de computação

Para implementar a plataforma em questão, criou-se um cluster de computação distribuída
com 5 máquinas virtuais, com 1 máquina mestre de orquestração, e 4 máquinas trabalhadoras,
onde se executam os pods com as aplicações de montagem genética, e o orquestrador Kuber-
netes. Dentro deste cluster, executam-se pods com várias funções cada: funções do plano de
controle (DNS, API, rede interna Flannel e o orquestrador Kubernetes em si), e pods funcionais
gerenciados, executando o servidor de mensagens RabbitMQ e os aplicativos Prinseq, Megahit,
Metabat e Metaquast.
Para cada um dos aplicativos da montagem genômica, criaram-se imagens de contêiner
Docker baseadas na imagem Miniconda, adicionada dos ambientes de execução e instalações dos
aplicativos mencionados, além dos utilitários necessários para a operação das filas de mensagens.
Para acesso comum a arquivos e pastas de trabalho, provisiona-se um servidor de NFS,
apontado para a pasta onde se localizam os scripts e pastas utilizadas pelos processos. Para dar
início á cadeia de processos de montagem genômica (representada pelos aplicativos Prinseq,
Megahit e Metabat), coloca-se os arquivos de amostras na pasta samples, e executa-se o script
starter.sh.
Os procedimentos e comandos para instalação e configuração de componentes, imagens

de contêineres nós de trabalho e sistemas operacionais necessários estão localizados em apên-
dice ao final deste trabalho, junto com os arquivos de configuração de objetos de trabalho do
Kubernetes.
Tabela 1 – Nós de controle e trabalho alocados ao cluster
Nós de computação VCPUS Memória RAM Disco

Master 2 2048 MB 20 GB
Worker 1 2 4096 MB 5 GB
Fonte: (Próprio autor)
Tabela 2 – Número de pods funcionais por aplicação
Pods Qtd
RabbitMQ 2
Prinseq 2
Megahit 6
Metabat 2
Metaquast 4
Fonte: (Próprio autor)
44
5 TESTES E RESULTADOS
Foram realizados testes de tempo de execução do processo, realizando a montagem de

10 amostras genômicas. As medições do tempo de execução foram feitas por meio de cronome-
tragem, considerando como início a execução do script starter.sh, e como final do processamento
a exibição de mensagens com o nome de cada uma das amostras processadas correspondentes
ao total de amostras fornecidas. Desta forma, inclui-se o tempo de processamento do overhead
inerente ao cluster de containers orquestrados, além do overhead induzido pela geração, troca e
consumo de mensagens AMQP, e o overhead induzido pela execução de scripts. Os resultados
do teste de tempo de execução foram comparados com medições do tempo de execução do
processo das amostras, distribuídas entre máquinas "monolíticas"individuais, com configurações
de hardware equivalentes ás máquinas que integram os nós de trabalho do cluster, para fins de
controle e validação.
Figura 11 – Gráfico dos tempos de execução.
Fonte: Autor
Por inspeção do gráfico, pode-se concluir que o cluster executa o processamento de uma
amostra, em média, em 29% do tempo de execução em máquina individual, e 123% do tempo
deduzido teoricamente, assumindo distribuição de cargas perfeitas entre 4 máquinas individuais.
O acréscimo de tempo é explicado pelo tempo de processamento do servidor de mensagens, e o
próprio overhead induzido pelo orquestrador..
Capítulo 5. Testes e Resultados 45
Tabela 3 – Tempos de execução do processamento de 10 amostras
Execução no cluster VM Individual Distribuição teórica entre 4 VMs

02:41:55 09:25:19 02:21:20
02:44:52 09:34:02 02:23:30
02:37:15 08:39:23 02:09:51
02:39:22 09:12:02 02:18:00
02:34:16 08:49:22 02:12:21
02:56:53 09:19:33 02:19:53
02:46:54 09:12:02 02:18:00
02:44:14 09:32:09 02:23:02
02:47:38 09:55:02 02:28:45
02:38:54 09:42:38 02:25:39
02:47:35 09:32:34 02:23:08
02:49:32 09:42:45 02:25:41
02:38:21 08:58:13 02:14:33
02:51:37 08:49:25 02:12:21
02:55:58 09:14:43 02:18:41
02:43:48 09:12:03 02:18:01
03:01:54 09:22:54 02:20:43
02:38:49 09:44:24 02:26:06
02:45:19 09:02:54 02:15:44
02:51:28 09:25:17 02:21:19
Médias totais e por amostra
02:45:50 09:19:20 02:19:50
00:16:35 00:55:56 00:13:59
46
6 CONCLUSÃO
O trabalho demonstrou a viabilidade da nuvem de computação no apoio á pesquisa

científica, o que também foi demonstrado por Schatz et al. (2010) e Salza e Ferruci (2018),
ao aplicarem técnicas de paralelismo em processos, e no caso do último, divisão de aplicação
em microserviços e contêineres. Com o uso de softwares e serviços livres, foi realizado o
desenvolvimento de uma nuvem de computação, com o objetivo de executar a montagem
genômica e processos associados de forma rápida e eficiente.
A contribuição deste trabalho, além da nuvem de computação em si, é o fornecimento
de uma ferramenta para apoio á pesquisas em bioinformática na instituição, e a aquisição de
know-how no desenvolvimento e implementação prática de plataformas de computação em
nuvem. Além de realizar a montagem genômica propriamente dita, a plataforma também fornece
os serviços de tratamento de qualidade, binning e análise de qualidade dos genomas montados.
A validação da plataforma foi realizada com amostras de sequência genômica reais.
Embora a plataforma tenha sido criada voltada á execução de montagens genômicas,
também pode receber qualquer outra aplicação que possa ser dividida em componentes executá-
veis em contêineres Docker, não sendo restrita á área da bioinformática, ou mesmo á pesquisa
científica em si, como aplicações para web, sistemas de bancos de dados ou mesmo automação e
controle distribuídos.
6.1 Trabalhos futuros

Como possíveis trabalhos futuros, pode-se apontar:
• Desenvolver o cluster computacional da nuvem de computação utilizando máquinas com

diferentes distribuições Linux, e maior grau de separação geográfica.
• Implementar medidas de segurança na nuvem de computação, seguindo os conceitos de

segurança de informação específícos para contêineres orquestrados, condição sine qua non
ambientes de produção, expostos á Internet.
• Implementar aplicações adicionais na nuvem de computação, ou mesmo refatorar toda

a configuração de trabalho da nuvem de forma á otimizá-la à resolução de diferentes
problemas.
47
REFERÊNCIAS
ANGEL, V. D. D. et al. Ten steps to get started in genome assembly and annotation. ELIXIR,
p. 148, feb 2018.
BERNSTEIN, D. Containers and cloud: From lxc to docker to kubernetes. IEEE Cloud
Computing, sep 2014.
BONéR, J. et al. The Reactive Manifesto. 2014. Disponível em: <https://www.

reactivemanifesto.org/>.
CASALICCHIO, E. Autonomic orchestration of containers: Problem definition and

research challenges. In: 10th EAI International Conference on Performance Evaluation
Methodologies and Tools. [S.l.: s.n.], 2017.
DEBSKI, A. et al. A scalable, reactive architecture for cloud applications. IEEE Software,
v. 35, p. pp. 62–71, mar 2018.
DOCKER, I. What is a container. 2019. Disponível em: <https://www.docker.com/resources/

what-container>.
FARCIC, V. The DevOps 2.1 Toolkit: Docker Swarm. first. [S.l.]: Packt Publishing, 2017.
FOWLER, M. Monolith First. 2015. Disponível em: <https://martinfowler.com/bliki/

MonolithFirst.html>.
GARCíA, A. L. The evolution of the Cloud : the work, progress and outlook of cloud
infrastructure. Dissertação (Mestrado) — Massachusetts Institute of Technology, 2015.
GIANI, A. M. et al. Long walk to genomics: History and current approaches to genome
sequencing and assembly. Computational and Structural Biotechnology Journal, v. 18, p.
pp. 9–19, nov 2019.
HAUSENBLAS, M. Container Networking: From Docker to Kubernetes. first. [S.l.]:

O’Reilly Media, 2018.
HINDMAN, B. et al. Mesos: A platform for fine-grained resource sharing in the data center. In:
8th USENIX Symposium on Networked Systems Design and Implementation. [S.l.: s.n.],
2011.
HUANG, D.; WU, H. Mobile Cloud Computing: Foundations and Service Models. first.
[S.l.]: Morgan Kaufmann, 2017. ISBN 9780128096444.
KANG, D. D. et al. Metabat, an efficient tool for accurately reconstructing single genomes from
complex microbial communities. PeerJ Life and Enviroment, 2015.
LEWIS, J.; FOWLER, M. Microservices. 2014. Disponível em: <https://martinfowler.com/

articles/microservices.html>.
LI, D. et al. Megahit: an ultra-fast single-node solution for large and complex metagenomics
assembly via succinct de bruijn graph. Oxford Bioinformatics, 2015.
Linux Foundation. Kubernetes Documentation. 2019.

Referências 48
MAATKAMP, M. W. H. Unidirectional Secure Information Transfer via RabbitMQ.

Dissertação (Mestrado) — School of Computer Science and Informatics, University College
Dublin, dec 2015.
MELL, P.; GRANCE, T. The NIST Definition of Cloud Computing. 2011.
MESOSPHERE, I. Marathon: a container orchestration platform for Mesos and DC/OS.

2018.
MESOSPHERE, I. What is DC/OS? 2018.
MIKHEENKO, A.; SAVELIEV, V.; GUREVICH, A. Metaquast: evaluation of metagenome

assemblies. Oxford Bioinformatics, 2015.
MOREANO, N.; MELO, A. C. M. A. de. Biological sequence analysis on gpu. In: . [S.l.]:
Morgan Kaufmann, 2017. cap. book chapter 6, H. Sarbazi-Azad. (Org.), Advances in GPU
Research and Practice.
NISBET, R.; ELDER, J.; MINER, G. Handbook of Statistical Analysis and Data Mining
Applications. [S.l.]: Academic Press, 2009. ISBN 9780123747655.
NISSEN, J. N. et al. Binning microbial genomes using deep learning. 2018. Preprint.
RICHARDSON, C.; SMITH, F. Microservices - From Design to Deployment. first. [S.l.]:

NGINX Inc., 2016.
ROBERTS, M. Serverless Architectures. 2018. Disponível em: <https://martinfowler.com/

articles/serverless.html>.
SALZA, P.; FERRUCI, F. Speed up genetic algorithms in the cloud using software containers.
Future Generation Computer Systems, oct 2018.
SCHATZ, M. C. et al. De Novo Assembly of Large Genomes Using Cloud Computing.

2010.
SCHMIEDER, R.; EDWARDS, R. Quality control and preprocessing of metagenomic datasets.

Oxford Bioinformatics, 2011.
ZHENG, L. et al. Architecture-based design and optimization of genetic algorithms on multi-

and many-core systems. Future Generation Computer Systems, 2013.
Apêndices
50
APÊNDICE A – PROCEDIMENTOS DE INSTALAÇÃO E

CONFIGURAÇÃO DO CLUSTER
0 - Instalar o Oracle VM VirtualBox e baixar a ISO do Linux Debian 10 em
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.2.0-amd64-netinst.iso
1 - Criar uma Máquina Virtual com 2048 MB de RAM, 2 VCPUs e, de preferência, 30 GB de

armazenamento (para uso de NFS e volumes). Configuração para nó mestre.
Criar Máquina Virtual com 4096 MB de RAM e 2 VCPUs. Configuração de nós trabalhadores. Crie
quantas achar necessário e onde achar melhor, conquanto que todas as máquinas hospedeiras
estejam na mesma rede local (ou ligadas por VPN, se for o caso).
2 - Dar início á instalação do Linux na VM.

Ao particionar os discos, selecionar a opção "disco inteiro", "todos os arquivos em uma
partição", na tela de partições, excluir a partição de swap e redimensionar a partição primária
para usar todo o disco. Fora isso, manter configurações padrões(partição montada no /, sistema
de arquivos ext4)
Na seleção de software, selecionar área de trabalho LXDE(para acesso ao dashboard), servidor
web, servidor SSH e utilitários de sistema padrão.
Após a instalação, desligar a VM, configurar a placa de rede para "modo bridge" e ligar a VM
novamente
3 - Abrir terminal e instalar utilitários básicos: sudo apt update && apt upgrade && apt install
curl ssh net-tools vim sudo apt-transport-https ca-certificates software-properties-common
Usar o comando "ip a" para obter o endereço IP da VM
Como root, colocar o nome de usuário criado na instalação do Linux no arquivo sudoers para dar
privilégios administrativos ao seu usuário comum.
4 - Instalar o docker:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
curl -fsSL https://get.docker.com | sh;
5 - Reinicializar a VM
6 - Configurar o docker para usar o systemd como driver de cgroup:

Como root, ir até ao diretório do docker: cd /etc/docker
Criar o arquivo de texto daemon.json, com o sequinte conteúdo:
{
"insecure-registries": ["master:5000"],
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}
Estas modificações ativam o uso do systemd, e criam permissões para uso de um repositório
privado local, hospedado na máquina master, porta 5000
6.3 - Executar os seguintes comandos:

mkdir -p /etc/systemd/system/docker.service.d
systemctl daemon-reload
systemctl restart docker
7 - Instalar os componentes do Kubernetes:
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
touch /etc/apt/sources.list.d/kubernetes.list
echo 'deb http://apt.kubernetes.io/ kubernetes-xenial main' >

/etc/apt/sources.list.d/kubernetes.list
apt -y -qq update && apt -y -qq upgrade

apt install -y kubeadm=1.15.4-00 kubelet=1.15.4-00 kubectl=1.15.4-00
Manter na versão listada no tutorial por conta de problemas com a versão 1.16 do k8s
apt-mark hold kubeadm=1.15.4-00 kubelet=1.15.4-00 kubectl=1.15.4-00
8 - - Configurar /etc/hosts em todas as VMs (acrescentar o ip e nome dos nodes do cluster), e

Modificar /etc/hostname de cada VM (deve ficar igual ao nome do node que está no /etc/hosts)
Acresentar ao arquivo /etc/hosts
----200.129.137.XXX nome-master
----200.129.137.XXX nome-worker)
Acresentar ao arquivo /etc/hostname
---- no Master: nome-master

---- no Worker: nome-worker
9 - Criar os arquivos firewall e firewall.service
Conteúdo arquivo firewall:
#!/bin/bash
### BEGIN INIT INFO

# Provides: firewall.sh
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time
# Description: Enable service provided by daemon.
### END INIT INFO
iptables -P FORWARD ACCEPT
firewall.service
[Unit]
After=docker.service
[Service]
ExecStart=/etc/init.d/firewall
[Install]
WantedBy=default.target
Executar os seguintes comandos para aplicar os arquivos às configurações de firewall do sistema:
---- sudo cp firewall /etc/init.d/firewall ## (copia arquivo firewall para /etc/init.d/firewall)

---- sudo cp firewall.service /usr/lib/systemd/system/firewall.service ## copiar arquivo
firewall.service para /usr/lib/systemd/system/firewall.service
---- sudo chmod 755 /etc/init.d/firewall && chmod 644 /usr/lib/systemd/system/firewall.service
---- sudo systemctl enable firewall.service
---- systemctl start firewall.service
10 - (Máquina mestre) Inicializar o cluster: kubeadm init --pod-network-cidr=10.244.0.0/16 --

service-cidr=10.244.10.0/12 --ignore-preflight-errors=cri \
--apiserver-advertise-address=ACRESCENTAR_IP_DO_MASTER --kubernetes-version "1.15.4"
Os IP's da Pod Network e Service CIDR definidos são necessários para que o cluster funcione com
a rede interna Flannel.
11 - (Máquina mestre) Após iniciar o cluster, executar os seguintes comandos:

- rm -rf .kube
- mkdir -p $HOME/.kube
- sudo cp /etc/kubernetes/admin.conf $HOME/
- sudo chown $(id -u):$(id -g) $HOME/admin.conf
- export KUBECONFIG=$HOME/admin.conf
12 - (Máquina mestre) Instalar o Flannel
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-

flannel.yml
13 - Adicionar máquina trabalhadora ao cluster
(Máquina mestre) Executar o seguinte comando:
kubeadm token list
Coletar o hash gerado
(Máquina(s) trabalhadora(s)) Executar em todas:
kubeadm join --discovery-token-unsafe-skip-ca-verification --token=HASH_DO_TOKEN_COLETADO

172.17.0.16:6443
(Máquina mestre) Verificar se as máquinas trabalhadoras estão listadas corretamente no cluster:
kubectl get nodes
14 - Gerar as imagens de containers customizadas a partir da imagem continuumio/miniconda, além

dos softwares de
montagem, é necessária a instalação do módulo do Python pika(para instalar módulos do Python é
necessário o gerenciador de pacotes pip), e o utilitário amqp-tools
Executar a imagem base e rodar terminal: docker run -it continuumio/miniconda bash
Dentro do terminal, executar os comandos de instalação de cada aplicação
Instalar Pip: sudo apt install python-pip
Instalar amqp-tools: apt-get install -y curl ca-certificates amqp-tools python dnsutils
Instalar módulo Pika: pip install pika
Instalar a aplicação na imagem. Instalar apenas 1 aplicação por imagem.
Comandos para instalação de programas usando o anaconda:

-Prinseq:
conda create --name prinseq-env
conda activate prinseq-env
conda install -c bioconda prinseq
-Megahit:
conda create --name megahit-env
conda activate megahit-env
conda install -c bioconda megahit
-MetaBat:
conda create --name metabat-env
conda activate metabat-env
conda install -c bioconda metabat2
-MetaQuast:
conda create --name metaquast-env
conda activate metaquast-env
conda install -c bioconda quast
Criar um repositório local de imagens Docker na máquina mestre:
sudo docker run -d -p 5000:5000 --restart=always --name registry registry:2
Sair do shell do container, e usar o comando sudo docker ps --all para localizar a imagem no
registro. Procurar a imagem com o menor tempo de saída ("exited x minutes ago") e copiar o nome
da imagem
Rodar o comando:
sudo docker commit "nome_imagem" master:5000/"aplicação"
Enviar as imagens comitadas para o repositório:

sudo docker push master:5000/"aplicação"
15 – Instalar e Configurar NFS

Instalar NFS-common em TODOS os nós: sudo apt install -y nfs-common
Instalar no nó onde vai ser provisionado o servidor NFS: sudo apt install -y nfs-kernel-server
Dar permissões 777 para o diretório a ser provisionado em NFS: chmod -R 777 /mnt/data
Modificar o arquivo /etc/exports e adicionar a seguinte linha:
/mnt/data *(rw,sync,fsid=0,crossmnt,no_subtree_check,no_root_squash)
Em qualquer nó, testar o acesso ao servidor de NFS com o seguinte comando:

mount IP_DO_SERVIDOR_NFS:/mnt/data /mnt/nfs/data/
16 - Criar seus pods, deployments e serviços a partir de arquivos .YAML descritos no Apêndice 2
kubectl create -f ARQUIVO.yaml

54
APÊNDICE B – ARQUIVOS DE CONFIGURAÇÃO DE

OBJETOS DE TRABALHO DO KUBERNETES
-Stateful Sets p/aplicativos de montagem
Prinseq
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: prinseq
spec:
serviceName: "prinseq"
replicas: 2
selector:
matchLabels:
app: prinseq
template:
metadata:
labels:
app: prinseq
spec:
containers:
- name: prinseq
image: master:5000/prinseq
imagePullPolicy: IfNotPresent
env:
- name: PRINSEQCMD
value: "conda activate prinseq-env && python /opt/prinseq/worker-prinseq.py"
command: ["/bin/bash"]
args: ["-i", "-m", "-c", "$(PRINSEQCMD)"]
# command: [ "/bin/bash", "-c", "--" ]
# args: [ "while true; do sleep 30; done;" ]
ports:
- containerPort: 80
name: prinseq
volumeMounts:
- name: nfs-volume
mountPath: /opt/prinseq
volumes:
- name: nfs-volume
nfs:
# URL for the NFS server
server: 200.239.72.34 # Change this for your NFS server address
path: "/mnt/data/"
Megahit
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: megahit
spec:
serviceName: "megahit"
replicas: 6
selector:
matchLabels:
app: megahit
template:
metadata:
labels:
app: megahit
spec:
containers:
- name: megahit
image: master:5000/megahit
env:
- name: MEGAHITCMD
value: "conda activate megahit-env && python /opt/megahit/worker-megahit.py"
args: ["-i", "-m", "-c", "$(MEGAHITCMD)"]
ports:
- containerPort: 80
name: megahit
volumeMounts:
- name: nfs-volume
mountPath: /opt/megahit
volumes:
- name: nfs-volume
nfs:
path: "/mnt/data/"
Metabat
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: metabat
spec:
serviceName: "metabat"
replicas: 2
selector:
matchLabels:
app: metabat
template:
metadata:
labels:
app: metabat
spec:
containers:
- name: metabat
image: master:5000/metabat
env:
- name: METABATCMD
value: "conda activate metabat-env && python /opt/metabat/worker-metabat.py"
args: ["-i", "-m", "-c", "$(METABATCMD)"]
ports:
- containerPort: 80
name: metabat
volumeMounts:
- name: nfs-volume
mountPath: /opt/metabat
volumes:
- name: nfs-volume
nfs:
path: "/mnt/data/"
MetaQUAST
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: metaquast
spec:
serviceName: "metaquast"
replicas: 4
selector:
matchLabels:
app: metaquast
template:
metadata:
labels:
app: metaquast
spec:
containers:
- name: metaquast
image: master:5000/metaquast
env:
- name: METAQUASTCMD
value: "conda activate metaquast-env && python /opt/metaquast/worker-metaquast.py"
args: ["-i", "-m", "-c", "$(METAQUASTCMD)"]
ports:
- containerPort: 80
name: metaquast
volumeMounts:
- name: nfs-volume
mountPath: /opt/metaquast
volumes:
- name: nfs-volume
nfs:
path: "/mnt/data/"
- Controlador de replicação e definição de serviço do RabbitMQ

RabbitMQ Controller:
apiVersion: v1
kind: ReplicationController
metadata:
labels:
component: rabbitmq
name: rabbitmq-controller
spec:
replicas: 1
template:
metadata:
labels:
app: taskQueue
component: rabbitmq
spec:
containers:
- image: rabbitmq
name: rabbitmq
ports:
- containerPort: 5672
resources:
limits:
cpu: 100m
RabbitMQ Service
apiVersion: v1
kind: Service
metadata:
labels:
component: rabbitmq
name: rabbitmq-service
spec:
ports:
- port: 5672
selector:
app: taskQueue
component: rabbitmq
NFS Persistent Volume
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
nfs:
server: 200.239.72.34 # trocar pelo endereço IP do seu servidor de NFS
path: "/mnt/data"

Técnicas e Tecnologias de Computação em Nuvem Aplicadas Á Montagem Genômica

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Técnicas e Tecnologias de Computação em Nuvem Aplicadas Á Montagem Genômica

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO PARÁ

AUGUSTO CÉSAR OLIVEIRA GONÇALVES

T ÉCNICAS E T ECNOLOGIAS DE C OMPUTAÇÃO EM N UVEM A PLICADAS

T ÉCNICAS E T ECNOLOGIAS DE C OMPUTAÇÃO EM N UVEM A PLICADAS

Trabalho de Conclusão de Curso apresentado

Orientador: Prof. Dr. Raimundo Viégas Jr.

Orientador: Prof. Dr. Raimundo Viégas Jr.

Monografia – UNIVERSIDADE FEDERAL DO PARÁ

T ÉCNICAS E T ECNOLOGIAS DE C OMPUTAÇÃO EM N UVEM

Trabalho de Conclusão de Curso apresentado

Data da Defesa: 20 de Dezembro de 2019

Prof. Dr. Raimundo Viégas Jr.

Prof. Dr. Roberto Célio Limão de Oliveira

Profa. Dra. Regiane Silva Kawasaki Francês

A partir da união da expansão da infraestrutura de telecomunicações, avanços na teoria e técnicas

Palavras-chave: orquestração de containers. computação em nuvem. bioinformática.

Keywords: gamification. usability test. software development.

PaaS Platform as a Service

contigs Cadeia contínua de genomas montados

reads Fragmentos de genomas

SdBG Grafo sucinto de De Brujin

UFPA Universidade Federal do Pará

O desenvolvimento da computação digital é um marco significativo na história da huma-

Diante disso, a aplicação da computação em nuvem á pesquisa científica facilita a

1.3.1 Objetivo Geral

1.3.2 Objetivos Específicos

• Criar um projeto de infraestrutura computacional para implementação de cluster computa-

• Traçar um método de processamento paralelo para os estágios da montagem genômica.

• Implementar na nuvem de computação métodos de controle e soluções de montagem

1.4 Trabalhos Relacionados

da computação em clusters distribuídos de CPUs, ou nuvem de computação, ser uma abordagem

1.5 Contribuição do Trabalho

Para o desenvolvimento da solução de montagem paralelelizada de genomas, utilizaram-

1.7 Estrutura do Trabalho

2.1 Computação em nuvem

sistemas de resolução de nomes de domínio (DNS), capacidade de criação de sub-redes, compar-

2.1.1 Modelos de serviço para computação em nuvem

Figura 1 – Representação visual de modelos de serviços de computação em nuvem.

Infrastructure-as-a-Service(IaaS), ou infraestrutura como serviço, onde “a capacidade

programa ou aplicação móvel. O consumidor não gerencia ou controla a infra-estrutura de nuvem

2.1.2 Modelos de infraestrutura para computação em nuvem

2.2 Modelos de arquitetura de software orientada a serviços

Figura 2 – Diagrama de demonstração da relação entre modelos de implantação de infraestrutura

réplicas da aplicação e seu ambiente de execução completo, em conjunto com um balanceador de

2.2.2 Arquitetura em microserviços

recursos, modularidade e alta disponibilidade.

2.2.3 Arquitetura serverless

restrições quanto á duração da execução do código, e armazenamento de estados. Em aplicações

Figura 3 – Complexidade e organização de infraestrura e aplicações em modelos de arquitetura

2.2.4 Arquteturas de software reativa e assíncrona

software.” Bonér et al. (2014)

2.3 Virtualização baseada em contêineres

Figura 4 – Comparação entre arquiteturas de virtualização em máquinas virtuais tradicionais e

2.3.1 Orquestração de contêineres

orquestrador, para coordenar a execução de contêineres. Casalicchio (2017)

2.4 Montagem genômica

Figura 5 – Diagrama de reresentação do processo de montagem genômica.

Fonte: Universidade de Ghent, 2019

partir de dados obtidos do sequenciamento de metagenoma, deve-se agrupar contigs a partir do

3 TECNOLOGIAS DE ORQUESTRAÇÃO DE CONTÊI-

3.1 Contêineres de virtualização Docker

3.2 Soluções de orquestração de contêineres