Weather Search System

Transcrição

1 Weather Search System PROJECTO DE COMPUTAÇÃO EM NUVEM RELATÓRIO Grupo 2 Gonçalo Carito - Nº57701 Bernardo Simões - Nº63503 Guilherme Vale - Nº64029

2 Índice Weather Search System A Solução Implementada Overview Requisitos Principais MapReduce no Weather Search System (processamento de dados) Aplicação Web para sistema amostragem e pesquisa no Weather Search System Requisitos Adicionais Capacidade de processamento elástico (Amazon EC2) e Load Balancing Armazenamento de dados na cloud (DynamoDB) Armazenamento no Amazon S Elastic MapReduce Testes 3. Conclusão 4. Bibliografia

3 1. A Solução Implementada 1.1. Overview No projecto de Computação em Nuvem implementámos um site a correr em Ruby on Rails numa instancia EC2 que comunica com uma base de dados dynamodb para obter os resultados de querys relacionadas com o estado do tempo que são processadas pelo Elastic Map Reduce da Amazon. O elastic-mapreduce (que pode ser executado uma vez por dia) vai buscar as funções de map e reduce ao S3 e coloca tambem lá o output do mesmo. Num passo seguinte este output é tirado do S3 para um pc local, feito parse e introduzido na dynamodb.

4 1.2. Requisitos Principais MapReduce no Weather Search System (processamento de dados) Um dos principais requisitos do projecto era desenvolver uma aplicação MapReduce que corresse o algoritmo de processamento dos dados de tempo - como tal, desenvolvemos duas funções: uma para o mapper e outra para o reducer. De forma a desenvolvermos e testarmos, primeiro num ambiente local, escolhemos a instalação do Apache Hadoop em modo cluster virtualizando assim na nossa máquina local uma cluster a correr o MapReduce divindo as tasks pelas várias instâncias virtualizadas. De forma a permitir a escrita de funções de map/reduce em outras linguagens (que não Java) o Hadoop fornece uma API - o Hadoop Streaming. Este usa fluxos standard de Unix como interface entre o Hadoop e o MapReduce permitindo assim usar qualquer linguagem de programação que seja capaz de ler de um stdin e escrever para um stdout : foi esta API que usamos para suporte à nossa aplicação de MapReduce - desenvolvida em Ruby. O streaming é adequado para o processamento de dados em formato texto. Os dados de input são passados através do input (stdin) para a função de Map que processaos linha-a-linha e escreve as linhas para o output (stdout). O output do map - que é no formato pares de chave-valor - é escrito como uma simples linha com as chaves-valor separadas por tab. O input da função de Reduce é, naturalmente, no mesmo formato e passado, também, pelo stdin. A função de Reduce lê as linhas através do stdin e escreve no output (stdout). A própria framework garante que os dados estão ordenados pela chave. Como precisamos de identificar valores com o dia, cidade e tipo de valor usamos a seguinte configuração em streaming : -jobconf stream.num.map.output.key.fields=3 \ -jobconf stream.num.reduce.output.key.fields=3 \ Assim os 3 primeiras palavras de output do mapper e reducer para o stdou são tratados como uma só chave e a ultima como valor. O funcionamento do mapreduce pode ser visto na imagem seguinte, na entrada do mapper temos bastantes valores que são removidos pelo reducer de forma a ficarmos com um output na forma: {tipo de valor}/t{dia}/t{cidade}/t{valor} Neste caso o tipo de valor, dia, e cidade são uma key e o valor dessa key é o valor.

5 Depois de implementarmos o hadoop localmente movemo-lo para a amazon usando o elastic mapreduce este topico será abordado em mais profundidade mais à frente Aplicação Web para sistema amostragem e pesquisa no Weather Search System De forma a cumprirmos mais uma vez os requisitos do projecto (neste caso: uma aplicação web a permitir simples pedidos de pesquisa ao output da aplicação MapReduce) implementamos num servidor web Ruby on Rails uma framework Model View Controller (não utilizámos modelos neste projecto) que funciona por pedidos REST e que foi desenvolvido e testado localmente. O servidor Rails recebe pedidos REST sempre que se faz uma query no site, esta query passa inicialmente por uma cache que que é organizada por pesos. As querys mais frequentes são guardadas num vector e retornadas sem se aceder à dynamodb reduzindo assim a latência (e preço) de múltiplos acessos à base de dados. Este vector de cache é reiniciado todos os dias quando são adicionados novos resultados à base de dados dynamodb.

6 1.3. Requisitos Adicionais Capacidade de processamento elástico (Amazon EC2) e Load Balancing A Amazon disponibiliza serviços que permitem fazer escalabilidade de máquinas e balanceamento da carga das maquinas. Estes serviços são denominados por Load Balancer e Auto Scaling. O Load Balancer encarrega-se de agrupar máquinas e estabelecer um nome de DNS comum e ao receber pedidos HTTP, distribui os pedidos entre as maquinas de uma forma balanceada. O Auto Scaling permite fazer a escalabilidade de máquinas, ou seja, adiciona máquinas ou remove de acordo com as politicas definidas. Usando estes dois serviços da Amazon é possível ter um serviço com uma boa disponibilidade - gastando o mínimo de recursos possíveis. Para implementar estes serviços em uma instancia é necessário: Criação de um Load Balancer, configurada para a zona eu-west-1; Criação de uma Launch Configuration para Auto Scaling, para definir como lançar uma instância nova. Na Lauch Configuration é passada uma AMI que é usada como base a novas instâncias; Criação de um Grupo Auto Scaling para estabelecer os limites, mínimo (1 instância) e máximo (8 instâncias) de máquinas, e realizar a ligação com o Load Balancer; Criação de Políticas de escalabilidade Auto Scaling para definir como se aumenta ou diminui o número de máquinas. Foram criadas duas politicas: uma para adicionar e outra para remover máquinas; Criação de Alarmes CloudWatch que executem as políticas criadas anteriormente: logo foram criados dois alarmes. No Auto Scaling escolhemos a métrica de utilização de processador, associada ao Auto Scaling Group. Quando a utilização de processador ultrapassa os 60% de utilização durante 5 minutos é criada uma nova instancia. Por outro lado, quando a utilização de processador é inferior a 20% de utilização durante 5 minutos é retirada uma instância. Escolhemos os limites de 60% e 20%, máximo e mínimo respectivamente, para permitir uma boa disponibilidade e um serviço eficiente. O valor de 5 minutos evita flutuações constantes no número de Instâncias no grupo aquando a existência de picos de utilização Armazenamento de dados na cloud (DynamoDB) Para armazenar os dados na dynamodb utilizamos um script que assim que acaba de correr o elastic-mapreduce faz download do ficheiro para a nossa máquina e fazemos parse do ficheiro de forma a adiciona-lo á base de dados. Cada tabela é identificada é identificada da seguinte maneira: o nome da tabela: Cidade Hash-Key: dia

7 valor humidade média valor chuva total valor temperatura máxima valor temperatura minima valor tempretura média Cada tabela é criada com 150 unidade de leitura e 100 de escrita pois meter todos os dados do sample input na dynamo demora bastante tempo. Decidimos as unidades de leitura serem superiores às de escrita para que seja possível fazer querys à dynamo mesmo quando estamos a inserir centenas ou milhões de valores novos. Devido a organizarmos os outputs do mapreduce desta maneira a nossa a aplicação do tempo torna-se super escalável pois é muito fácil adicionar novos dias às cidades, adicionar novos parâmetros caso sejam precisos. Para alem disso é tambêm possível mover tabelas de dias que seja menos acedidos para o S3 ou mesmo baixar as velocidades de escrita e leitura e forma a reduzirmos custos. Por exemplo é normal termos mais acessos na área de Lisboa do que em Ponta Delgada e em função disto é possível adaptar velocidades de leitura/escrita. Dias que sejam menos acedidos ou comecem a ficar desactualizados podem ser movidos para o S Armazenamento no Amazon S3 No nosso projecto utilizamos o S3 para guardar os mappers, reducers, logs e output do elastic mapreduce Elastic MapReduce O elastic-mapreduce é controlado por um script Ruby que depois de o mandar executar fica à espera que o job esteja completo e logo de seguida faz download do output do S3 e começa a enviar dados para a dynamodb. Tivemos problemas a utilizar o EMR da Amazon: se corressemos o Hadoop com mais do que uma máquina dava um erro de configurações. Estas configurações não podem ser alteradas devido ao encapsulamento que a Amazon faz das suas ferramentas. 2. Testes 3. Pico de carga Para fazer testes de elasticidade, fizemos subrecarga no sistema de maneira a aumentar a utilização de processador, para isso usamos a ferramenta Siege. Com esta ferramenta foi possível verificar que os alarmes colocados no CloudWatch fazem com que o Auto Scaling Group aumente o numero de instancias dinamicamente.

8 4. Conclusão Fazer analise de big data com Hadoop e utilizar bases de dados não relacionais foi uma experiencia bastante diferente, tal como utilizar servidores virtualizados na Amazon. No entanto grande parte dos problemas que tivemos foram devido à muito fraca documentação e até por vezes errada da parte da Amazon. Os foruns são mais utilizados para se submeter bugs do que para se esclarecer problemas - existe mesmo código metido por funcionários da Amazon que não corre. Isto deve ser devido ao facto dos serviços serem bastante recentes e com o tempo deve melhorar. Outro problema que tivemos foi que grande parte dos devellopers de ruby usam o Heroku para meterem as suas aplicações devido à sua simplicidade e facilidade de escalar, o que fez com que erros que tivemos não fossem fáceis de encontrar na Web: quando os erros não são fáceis de encontrar quer dizer que vamos perder bastante tempo a perceber o que é que se passa de errado. 5. Bibliografia Hadoop - The Definitive Guide, Tom White, O Reilly Programming Amazon EC2, Jurg van Vliet & Flavia Paganielli, O Reilly Programing Ruby 1.0 Dave Thomas O Reilly