1. Introdução Redes de Distribuição de Conteúdos (RDCs) Felipe Uderman 1 1 uderman@ic.uff.br Universidade Federal Fluminense O aumento crescente da popularidade dos serviços oferecidos através da Internet tende a impulsionar de forma significativa a demanda por conteúdos, por parte dos usuários. Novos desafios estão associados a este aumento na demanda por conteúdos, já que serviços atualmente populares na Internet frequentemente experimentam problemas de congestionamento e consequente indisponibilidade. Estes momentos de indisponibilidade são geralmente associados à problemas do tipo flash crowds [Arlitt and Jin 1999], que consistem em um aumento repentino e significativo da demanda de um determinado conteúdo. Estes eventos devem ser evitados para aumentar a Qualidade de Serviço experimentada pelos cada vez mais exigentes clientes destes conteúdos. Uma Rede de Distribuição de Conteúdos (RDC) pode ser definida como uma rede sobreposta de servidores colaborativos, que são utilizados para posicionar réplicas de conteúdos a serem acessados de forma transparente pelos clientes [Rajkumar Buyya 2008]. Devido ao crescimento do número de requisições por conteúdos na Internet, as redes de distribuição de conteúdos estão cada vez mais sendo utilizadas pelos provedores de serviços. Esta afirmação é especialmente verdadeira para conteúdos multimídia, que normalmente possuem requisitos de qualidade de serviço mais restritos. Uma RDC é capaz de posicionar os servidores de conteúdo mais próximos aos clientes, replicar conteúdos para estes servidores e atender às requisições dos clientes, indicando qual servidor deve ser utilizado. Estas funcionalidades produzem efeitos positivos no desempenho do serviço tanto sob o ponto de vista do usuário, que irá experimentar um menor atraso de rede, maior banda de transmissão disponível e maior disponibilidade do conteúdo, quanto sob o ponto de vista dos provedores de RDCs, que podem otimizar o atendimento das requisições, reduzindo seus custos operacionais e consequentemente aumentando a sua lucratividade. O objetivo deste trabalho é prover informações gerais sobre as tecnologias e desafios associados às RDCs. Por se tratar de um tema muito amplo, somente alguns dos muitos tópicos relevantes às RDCs são tratados. O restante deste trabalho está organizado da seguinte maneira: a Seção 2 aborda o tema de uma maneira generalizada, elucidando os principais conceitos referentes às RDCs. Exemplos de implementações comerciais e acadêmicas de RDCs são descritos. A Seção 3 trata de um importante problema, abordando mecanismos de replicação de conteúdos em RDCs. Além de conceitos sobre mecanismos de replicação tradicionais, é apresentado o mecanismo SCAN (Scalable Content Access Network), que resolve este problema a partir de uma formulação dinâmica e e um sistema de localização de recursos distribuído. A Seção 4 aborda conceito relacionados com a entrega de conteúdos em ambientes Web, destacando as peculiaridades relativas às arquiteturas de RDCs otimizadas para este ambiente. Por fim, a Seção 5 contém comentários finais sobre o tema e perspectivas para trabalhos futuros.
2. Visão geral sobre as RDCs Primeiramente, alguns conceitos relacionados às RDCs devem ser definidos, para melhorar a compreensão do restante do texto: Entrega de conteúdos: A ação de servir conteúdos aos clientes, a partir de suas requisições. Conteúdo: Dados ou recursos digitalizados, divididos em duas partes principais: mídia codificada e metadados. Mídia codificada: Dados estáticos, dinâmicos ou contínuos, como áudio, vídeo, imagens, documentos e páginas Web. Metadados: Descrição do conteúdo, que permite a sua identificação, interpretação e gerenciamento. Provedor de Conteúdos: Entidade que delega a um provedor de RDC a tarefa de entregar os seus conteúdos para os clientes. Provedor de RDC: Organização ou empresa que provê a infraestrutura necessária para entregar conteúdos a clientes de maneira satisfatória. Usuários finais: São os usuários da RDC que acessam os conteúdos disponibilizados na RDC. Servidores substitutos: Também chamados de caches ou servidores de borda, são distribuídos em diferentes localizações geográficas desntro da abrangência da RDC e preenchidos com conteúdos que são entregues aos clientes, a partir de suas requisições. O objetivo principal das RDCs é entregar os conteúdos aos clientes, atendendo às restrições de qualidade de serviço impostas. Para cumprir este objetivo, as RDCs irão posicionar servidores de conteúdos próximos aos clientes e implementar mecanismos diversos de gerenciamento e operação. A figura 2.1 exemplifica um modelo básico de uma RDC, onde cada servidor substituto realiza a entrega de conteúdos para clientes geograficamente relacionados: Figura 2.1. Modelo básico de uma RDC [Rajkumar Buyya 2008].
Um provedor de RDC deve oferecer serviços tanto aos clientes da RDC, que buscam conteúdos diversos, quanto aos contratantes do provedor de RDC, representados pelos provedores de conteúdo. Os principais serviços oferecidos por um provedor de RDCs sãs os seguintes: Serviço de redirecionamento de requisições e entrega de conteúdos, para realizar o atendimento da maneira menos custosa possível para o provedor de RDC. Serviços de distribuição, para replicar conteúdos entre seus servidores originais e os demais servidores da RDC. Serviço de negociação do atendimento, para atender aos requisitos de Qualidade de Serviço heterogêneos. Serviço de gerenciamento, para gerenciar os componentes da RDC, lidar com a contabilidade do serviço e gerar relatórios sobre o uso da rede e popularidade dos conteúdos. 2.1. Componentes de uma RDC A figura 2.2 mostra componentes gerais de uma RDC. Diferentes técnicas e algoritmos podem ser utilizados para implementar estes serviços. É imprescindível que estes serviços sejam implementados de forma eficiente, para garantir a viabilidade técnica e econômica das RDCs: Figura 2.2. Componentes de uma RDC [Rajkumar Buyya 2008]. Componente de entrega de conteúdos, que consiste de um servidor original e uma série de servidores substitutos que entregam cópias dos conteúdos aos clientes. Componente de redirecionamento de requisições, responsável por redirecionar as requisições dos clientes aos servidores substitutos apropriados. Componente de distribuição, que replica os conteúdos do servidor original para os servidores substitutos, garantindo a consistência dos conteúdos na rede.
Componente de contabilidade, responsável por manter registro das atividades dos clientes e estatísticas de uso da RDC. Estas informações podem ser utilizadas para cobrança dos serviços prestados. Diversos tipos de conteúdos podem ser disponibilizados pelas RDCs, tais como conteúdos estáticos (páginas HTML, imagens, documentos), transmissão de mídia (áudio e vídeo em tempo real) e conteúdos diversos (transferência de arquivos, serviços de diretório), ilustrados na figura 2.3. Como diferentes conteúdos possuem requisitos de qualidade distintos, é natural que as RDCs apliquem preços diferenciados para a entrega dos conteúdos, baseados principalmente nos seguintes fatores: Figura 2.3. Exemplos de conteúdos disponibilizados em RDCs [Rajkumar Buyya 2008]. Taxa de transmissão experimentadas pelos clientes. Quanto maior a taxa utilizada, maior o valor cobrado. Variação da distribuição de tráfego ao longo do tempo. Em períodos de maior congestionamento na rede, a entrega de conteúdos será mais cara. Tamanho dos conteúdos replicados entre os servidores originais e substitutos na rede. Número de servidores substitutos, que representam a habilidade da RDC em manter a qualidade do serviço oferecido em situações adversas. Confiabilidade, estabilidade e segurança da RDC. 2.2. Evolução das RDCs A evolução das RDCs se deu a partir de outros tipos de tecnologias que, apesar de não possuírem os mesmos objetivos das RDCs, possuem características desejáveis para aumentar o desempelho de serviços de entrega de conteúdos. Algumas destas técnicas são: Melhoria de hardware nos servidores de conteúdo: Apesar destas melhorias aumentarem a capacidade dos servidores em prover conteúdos para os clientes, elas não são flexíveis e escaláveis o suficiente, já que pequenas melhorias nem sempre são possíveis, e eventualmente todo o sistema dos servidores teria que ser substituído para acomodar o crescente número de requisições.
Posicionamento de servidores do tipo Proxy Caching pelos Provedores de Serviço de Internet em locais próximos aos clientes: Esta técnica melhora o desempenho da entrega de conteúdos para clientes com banda de acesso limitada, além de reduzir o tráfego total na Internet. Os Proxy Caching irão guardar uma cópia dos conteúdos previamente solicitados, para que novas requisições para estes mesmos conteúdos possam ser atendidas diretamente pelo Proxy Caching, sem necessidade de acionar o servidor original do conteúdo. Posicionamento de diferentes níveis hierárquicos de servidores Cache locais, regionais e internacionais: Esta técnica, conhecida como Hierarchical Caching, é capaz de prover um aumento adicional no desempenho da entrega de conteúdos, assim como na economia de banda. Além disto, a utilização de Server Farms, que consiste em múltiplos servidores que compartilham a responsabilidade de entregar o conteúdo requisitado, tem se mostrado uma solução mais escalável, além de prover uma redundância natural ao sistema. Ainda que estas técnicas produzam bons resultados, elas são insuficientes para garantir a qualidade do serviço de entrega de conteúdos em situações adversas, já que atuam sem uma infraestrutura dedicada, dinâmica e colaborativa para a entrega dos conteúdos. A primeiras gerações de RDCs foram criadas para proteger a entrega de documentos Web de eventos do tipo Flash Crowd. Já a geração atual mudou o foco para entrega de vídeo sob demanda e transmissão de áudio e vídeo. É possível antecipar que a terceira geração de RDCs será voltada para a disseminação de conteúdos gerados por pessoas comuns, a chamada Community-based CDNs. A figura 2.4 ilustra este cenário. Figura 2.4. Evolução das RDCs [Rajkumar Buyya 2008]. As RDCs modernas evoluíram a partir de outros tipos de sistemas distribuídos para compartilhamento de recursos ou acesso a conteúdos digitais. Estes sistemas possuem características e mecanismos de operação relevantes para a composição das arquiteturas de RDC modernas. Data Grids são ambientes de computação intensiva que provêem serviços de processamento de grandes conjuntos de dados para usuários em diferentes localizações geográficas. Existem duas funcionalidades dos Data Grids que são especialmente relevantes no contexto das RDCs: transferência confiável de dados e mecanismos
de busca e replicação de objetos. Além disto, a segurança e a integridade dos dados são fatores relevantes para os Data Grids. Apesar disto, as RDCs se diferem dos Data Grids principalmente pelo fato do objetivo principal dos Data Grids ser fazer com que uma grande massa de dados seja transferida para um sítio de alta concentração de poder computacional para serem processados, enquanto que o objetivo principal das RDCs é fazer com que clientes geograficamente espalhados possam ter acesso a dados que originalmente se encontram em ambientes com alta capacidade de armazenamento. Outros sistemas relacionados são os Bancos de Dados Distribuídos (BDD), que consistem em uma coleção de dados logicamente organizados em nós com diferentes localizações geográficas. Neste tipo de sistema, cada nó pode agir como cliente, servidor ou ambos, a depender da situação. Os BDDs surgiram para suprir a necessidade de grandes corporações que desejavam substituir bancos de dados centralizados por um sistema distribuído capaz de integrar os bancos de dados existentes a novos bancos de dados, que surgem a partir de novas unidades corporativas. A principal diferença entre os BDDs e as RDCs é o fato de que os diversos sítios que compõem os BDDs possuem um grau de independência de operação e gerenciamento elevados, enquanto que nas RDCs os servidores que compõem o sistema têm sua operação regida por um sistema integrado. Além disto, as RDCs possuem o objetivo de entregar conteúdos aos seus clientes, enquanto que os BDDs fazem parte de sistemas de consulta e processamento de dados. Por fim, as redes Peer-to-Peer (P2P), projetadas para o compartilhamento direto dos recursos computacionais dos clientes, sem o intermédio de uma entidade intermediária com uma infraestrutura dedicada, também possuem características compatíveis com as RDCs modernas. Em redes P2P, cada cliente, ou peer, possui total autonomia para se juntar ou deixar a rede, e adicionar ou remover conteúdos em seu espaço de armazenamento. As redes P2P são mais indicadas para o compartilhamento de conteúdos estáticos, já que características da sua arquitetura não conseguem acomodar de forma eficiente conteúdos dinâmicos. Estes sistemas possuem um alto grau de escalabilidade, e idealmente não possuem um ponto único de falha. Entretanto, em contraste com as RDCs, as redes P2P têm seu desempenho altamente afetados pela número de clientes participantes na rede. Além disto, o principal objetivo das redes P2P é prover um mecanismo eficiente para busca e transferência de arquivos em meio aos clientes participantes, enquanto que as RDCs possuem o principal objetivo de atender às requisições dos clientes observando os seus requisitos de desempenho. 2.3. Desafios das RDCs O principal objetivo das RDCs é atender provedores de conteúdos ou clientes que desejam ter seus requisitos de desempenho atendidos, em um ambiente seguro e confiável. Portanto, algumas regras de negócio devem nortear o desenvolvimento das arquiteturas de RDCs: Escalabilidade: A RDC precisa lidar com grandes volumes de dados e requisições por conteúdos, sem que os usuários e clientes experimentem uma queda de desempenho. É muito importante que uma RDC seja capaz de se adequar dinamicamente a variações abruptas na demanda por determinados conteúdos, alocando espaço de armazenamento quando houver necessidade, e consequentemente reduzindo os custos operacionais da RDC.
Segurança: Prover soluções de segurança para conteúdos confidenciais e de alto valor é um grande desafio para as RDCs. Sem um forte esquema de segurança, as RDCs estão sujeitas a fraudes, ataques de negação de serviço distribuído( Distributed Denial-of-Service - DDOS), vírus e outros incidentes indesejáveis. Desta forma, uma arquitetura de RDC, em um cenário ideal, deve incorporar diversos níveis de segurança( física, de rede, de dados e de procedimentos), para que soluções de segurança de terceiros, que geralmente possuem um custo elevado, não precisem ser contratadas. Confiabilidade, correspondência e desempenho: Confiabilidade se refere à uma alta disponibilidade esperada para determinado serviço. Uma maneira de se prover confiabilidade a uma RDC é alocar diversos servidores, em diferentes regiões geográficas diferentes, para reduzir ao máximo as chances do cliente não ser atendido devido à indisponibilidade da RDC. Correspondência está relacionado com o tempo necessário para que a RDC consiga restabelecer o seu padrão original de qualidade no funcionamento, em caso de possíveis indisponibilidades do serviço ou redução da qualidade no atendimento. Por fim, o desempenho de uma RDC está altamente relacionado com a localização do conteúdo distribuído, mecanismos de roteamento empregados e com as estratégias de replicação de dados e caching empregados. 2.4. Arquiteturas Existentes Para RDCs Atualmente, diversas arquiteturas de RDC estão em operação, tanto no âmbito comercial quanto no acadêmico. Dentre as RDCs comerciais, algumas merecem destaque por estarem em operação estável a alguns anos: Akamai, EdgeStream, Limelight Networks e Mirror Image. 2.4.1. RDCs Comerciais A Akamai [aka 2010] foi fundada em 1998 em Massachusetts, a partir de um esforço do MIT para resolver o problema de flash crowd. Atualmente, a Akamai é considerada a empresa líder no mercado de RDCs. A abordagem da Akamai é baseada na premissa de quer prover conteúdos a partir de uma única fonte centralizada representa um grande problema de escalabilidade. Desta forma, seu sistema é projetado para para atender às requisições por conteúdos a partir de diversos servidores substitutos na borda da rede. A Akamai distribui conteúdos estáticos (páginas HTML, arquivos e documentos), conteúdos dinâmicos (animações, scripts e DHTML), assim como transmissões de áudio e vídeo. A Akamai implementa um mecanismo de alocação dinâmica de servidores para amenizar ocorrências de flash crowds. Através de um balanceamento de carga via DNS, a Akamai mapeia as requisições aos servidores baseado no serviço requisitado, localização do usuário e condições da rede. Além disto, agentes que simulam o comportamento dos usuário finais são utilizados para realizar medições de qualidade que também alimentam o sistema de balanceamento de carga, protegendo servidores que se encontram congestionados. Outras técnica utilizada é a fragmentação de conteúdos, que são tratados como objetos independentes. A EdgeStream [edg 2010] foi fundada em 2000 na Califórnia como um provedor
de transmissões de vídeo pela Internet. Provê serviços de vídeo sob demanda e transmissões IPTV para possibilitar o transporte de vídeos de alta qualidade pela Internet. Para atingir métricas de latência de rede, perda de pacotes e evitar caminhos congestionados, a EdgeStream desenvolveu técnicas de Continuous Route Optimization Software (CROS), Internet Congestion Tunnel Through (ICTT) e Real Time Performance Monitoring Service (RPMS). A Limelight [lim 2010] Networks foi fundada em 2001 no Arizona. Seu foco é a distribuição de conteúdos via plataforma Web, incluindo vídeos, muúsica, jogos e aplicativos. Além disto, também provê serviços de transmissão de áudio e vídeo. Empresas carregam seus conteúdos nos servidores da Limelight, que são distribuídos sob demanda, para seus diversos clusters de servidores espalhados pelo mundo. Também utiliza DNS para redirecionar as requisições dos clientes para servidores locais. Este sistema de redirecionamento é alimentado por mapas detalhados da topologia da Internet, construídos através de medições próprias e informações do protocolo BGP. A Mirror Image [mir 2010] foi fundada em 1999 em Massachusetts como um provedor de conteúdo online, transmissões de áudio e vídeo e computação via Web. A sua arquitetura é baseada na alocação de grandes clusters de servidores Web, localizados em regiões geográficas densamente povoadas. A Mirror Image utiliza uma infraestrutura sobreposta à Internet denominada Content Access Point (CAP), para prover conteúdos aos seus usuários. Através de um balanceamento de carga via DNS, as requisições são enviadas para a localização CAP com o tempo de resposta mais rápido. Caso o conteúdo requisitado esteja presente na localização CAP escolhida, o atendimento é realizado. Caso contrário, o atendimento é realizado a partir do servidor de origem do conteúdo, e uma cópia é realizada para a localização CAP para futuras requisições. 2.4.2. RDCs Acadêmicas Em oposição às RDCs comerciais, o uso de tecnologias P2P é muito comum nas RDCs acadêmicas. Desta forma, as requisições são atendidas de forma distribuída por todos os participantes da rede. Estas RDCs baseadas em tecnologias P2P são eficientes apenas para conteúdos estáticos, sendo incapazes de lidar com conteúdos que podem ser dinamicamente modificados. Alguns exemplos de RDCs acadêmicas são: CoDeeN, Coral e Globule. CoDeeN [Wang et al. 2004] é um sistema de servidores proxy baseado em P2P, implementada sob a rede PlanetLab que possibilita aos seus usuários um dempenho melhor ao acessar a maioria das páginas Web da Internet. O princípio de funcionamento do CoDeeN consiste em configurar os navegadores Web dos usuários participantes para utilizarem um dos caches do CoDeeN como proxy. Para cada requisição dos clientes, o servidor proxy selecionado irá tentar entregar o conteúdo solicitado. Caso ocorra a falta deste conteúdo no cache, os algoritmos de redirecionamento implementados pelo CoDeeN irão para qual cache esta requisição deve ser enviada. Os algoritmos de redirecionamento levam em consideração a localização da requisição, a carga e confiabilidade do sistema e informações de proximidade. Caso a requisição não possa ser atendida por nenhum dos servidores cache do CoDeeN, a requisição é redirecionada para o servidor de origem.
Coral [Freedman et al. 2004] é uma RDC gratuita, baseada em tecnologia P2P e implementada sob a rede PlanetLab. Seu objetivo é prover à maioria dos seus usuários um desempenho melhor ao acessar páginas Web participantes. Coral utiliza a banda de transmissão de voluntários para evitar eventos do tipo flash crowd e reduzir a carga nos servidores originais dos Web sites participantes. As requisições dos clientes são redirecionadas para servidores caches do Coral próximos de forma transparente, através de redirecionamento via DNS. Sempre que possível, dados são transmitidos entre servidores cache adjacentes, para reduzir tanto a carga no servidor Web original quanto a latência de rede experimentada pelos clientes. Globule [Pierre and Steen 2006] é uma RDC colaborativa com implementação em código aberto. Seu objetivo é permitir que provedores de conteúdo Web possam se organizar e operar sua própria plataforma de armazenamento de escala global. Os usuários participantes constituem nós das rede Globule e oferecem recursos de armazenamento, banda de transmissão e poder de processamento. Globule provê mecanismos de replicação de conteúdos, monitoramento de servidores e redirecionamento de requisições para as réplicas próximas disponíveis. 3. Técnicas de replicação de Conteúdos Devido aos grandes avanços nas áreas de desempenho de processadores, capacidade de armazenamento e disponibilidade de recursos de rede, é cada vez mais frequente a implantação de sistemas computacionais distribuídos, compostos de milhares de elementos auto-organizáveis posicionados em diferentes localizações geográficas. Apesar disto, estes tipos de sistemas estão frequentemente sujeitos a falhas em seus componentes e indisponibilidades na rede, ou até mesmo uma redução temporária do desempenho, que podem isolar as diversas partes destes sistemas distribuídos. Desta forma, no contexto das RDCs, o uso eficiente de recursos locais, através de uma política eficiente de posicionamento de réplicas de conteúdos é extremamente importante, tanto para o desempenho quanto para a disponibilidade do sistema. Uma abordagem comum para uma política de replicação de conteúdos eficiente é particionar o sistema em duas camadas de réplicas: uma primeira camada (primarytier) que deve ser pequena e durável e uma segunda camada (second-tier) que deve ser grande, porém volátil. O primary-tier pode ser representado por um servidor Web que contém a cópia mais atualizada do conteúdo, e pode ser abstraído como a localização de origem, ou fonte do conteúdo. Já o second-tier pode ser representado por uma RDC, com seu conjunto de servidores armazenando réplicas do conteúdo com origem no primarytier. Requisitos de qualidade de serviço (Quality of Service - QoS) podem ser utilizados para determinar o número e posição das réplicas de conteúdos na RDC, ou second-tier da rede. Como o posicionamento de uma réplica em um servidor da RDC consome recursos, é desejável que os requisitos de QoS sejam satisfeitos com o mínimo de réplicas possíveis distribuídas na RDC. Desta forma, a depender da popularidade dos conteúdos, requisitos de QoS das requisições e outros fatores, o número de réplicas de cada conteúdo na RDC pode variar significativamente. 3.1. Localização de Conteúdos Um importante problema relacionado com a replicação de objetos em RDCs é o da determinação da localização dos conteúdos entre os diversos servidores ou caches que
compõem a RDC. Diversos trabalhos abordaram ente problema, em diferentes contextos. Estas abordagens podem ser classificadas em três grandes grupos: Serviços de Diretório Centralizados (SDC), Serviços de Diretórios Replicados (SDR) e Serviços de Diretórios Distribuídos (SDD). A abordagem SDC consiste em um único servidor de diretórios que provê informações sobre a localização de cada objeto presente na rede. Por ser constituída de apenas um servidor, esta abordagem é bastante vulnerável a ataques de negação de serviço (Denial of Service - DoS). A abordagem SDR, ilustrada na figura 3.1 pode ser considerada uma variante da abordagem SDC, e consiste na existência de diversos servidores de diretórios, nos quais a base de dados que mapeia a localização dos conteúdos é replicada. Esta abordagem provê uma maior disponibilidade, porém acrescenta um overhead adicional no sistema, relativo à replicação e manutenção de consistência da base de dados. Figura 3.1. Sistema de Diretórios Replicados: O diretório centralizado pode ser replicado para pontos remotos da rede [Rajkumar Buyya 2008]. Em contraste com as demais abordagens, SDDs são implementados a partir de uma infra-estrutura descentralizada, normalmente baseadas em P2P, para localizar objetos de maneira rápida e com sucesso garantido. Nesta abordagem, os pedidos de localização de objetos são passados para os diversos servidores de diretórios da rede, até que algum destes servidores possua a informação requisitada. Devido à sua característica distribuída, esta abordagem provê uma alta disponibilidade, mesmo sob ataque. 3.2. Disseminação de atualizações Um outro problema está relacionado com a disseminação de mensagens de atualizações de conteúdos na RDC. Uma abordagem tradicional utiliza IP Multicasting para realizar esta tarefa. Entretanto, IP Multicasting possui características incompatíveis com a sua utilização em uma arquitetura de distribuição de conteúdos na Internet. Essencialmente, IP Multicasting funciona somente através do espaço, e não através do tempo [Francis 2001]. Isto significa que, apesar dos nós de um grupo multicast serem organizados de maneira hierárquica para facilitar a disseminação de informações, não existe nenhuma garantia de que todos os nós estarão prontos para receber atualizações no momento em que esta seja disseminada via IP Multicasting, o que geraria a necessidade de novas mensagens IP Multicasting, até que todos os nós recebessem as atualizações. Como alternativa ao IP Multicasting, diversos sistemas multicast em nível de aplicação (Application Level Multicast - ALM) foram propostos, sendo alguns focados em aplicações de pequena escala e múltiplas fontes, como vídeo-conferências, e outros
focados em aplicações de grande escala e uma única fonte, como transmissão multicast de mídia. Entretanto, estes sistemas geralmente são suscetíveis a problemas de escalabilidade, já que um único nó central deve manter informações sobre o estado de todos os outros nós da rede. 3.3. Estratégias Para Replicação de Conteúdos O principal desafio da replicação de conteúdos nas RDCs é prover um atendimento com bons níveis de QoS para os clientes, enquanto os recursos da RDC são consumidos de maneira eficiente e balanceada. A banda disponível em rede e o espaço de armazenamento disponíveis nos servidores são os principais recursos da RDC que precisam ser preservados, e normalmente os esquemas de replicação aplicam uma relação de compromisso entre estes dois parâmetros. Já os requisitos de QoS, tipicamente, dizem respeito à banda de rede mínima e atraso de comunicação máximos aceitos pela requisição. Os principais modelos de arquitetura para replicação de conteúdos em second-tier são os seguintes: Web Caching, un-cooperative pull-based CDN e cooperative push-based CDN. 3.3.1. Web Caching Existem dois tipos de arquitetura de servidores Cache Web: iniciada pelo cliente e iniciada pelo servidor. Na arquitetura iniciada pelo cliente, cópias de conteúdos são armazenadas nas máquinas dos clientes ou em caches locais. Ambas estas abordagens possuem limitações devido à falta de cooperação entre os nós de armazenamento, já que o armazenamento de conteúdo na máquina de um cliente em nada ajuda o desempenho em um cliente vizinho. De maneira similar, o armazenamento de conteúdo em um determinado cache local em nada ajuda um outro cache local vizinho. As arquiteturas de Cache iniciadas pelos servidores constituem uma possível solução para os problemas inerentes às arquiteturas de cache iniciadas pelos clientes, já que é permitido ao servidor de origem determinar em quais caches o seu conteúdo deve ser replicado. De forma geral, as RDCs podem ser consideradas arquiteturas de Cache iniciadas pelos servidores, com servidores de borda dedicados. Arquiteturas pushcaching replicam automaticamente dados entre os servidores cache participantes, baseados na topologia da rede e nos padrões de acesso dos usuários. Mais recentemente, esquemas de Web caching adaptativos foram propostos para permitir o compartilhamento de servidores cache entre diferentes servidores proxies. Ainda que esta abordagem represente uma melhoria significativa quando comparado com arquiteturas de Caches iniciadas pelo cliente, existe uma grande limitação no que diz respeito a sua escalabilidade. Esta limitação ocorre pela necessidade de cada cache participante ter que, periodicamente, informar todos os demais caches participantes sobre quais conteúdos então sendo armazenados. Além disto, sem uma infraestrutura de RDC dedicada, estas soluções não podem se adaptar a momentos de congestionamentos ou falhas na rede ou prover esquemas de balanceamento de carga distribuídos de forma eficiente.
3.3.2. Un-Cooperative Pull-Based CDN Uma outra solução em replicação de conteúdos, que é bastante utilizada pelos provedores comerciais de RDC, é chamada de un-cooperative pull-based CDN. Basicamente, os conteúdo são copiados para os servidores de borda da RDC, a partir de uma requisição por parte dos clientes. Apesar de existirem diversas técnicas disponíveis para direcionar as requisições dos clientes para os conteúdos solicitados, o redirecionamento baseado em DNS é o mais utilizado, devido ao alto nível de transparência disponibilizado ao usuário. Desta forma, cada requisição DNS por conteúdos é direcionada para um servidor de nomes local da RDC, que irá redirecionar a requisição para um dos servidores de conteúdo da RDC. A figura 3.2 ilustra este mecanismo de replicação: Figura 3.2. Un-Cooperative Pull-Based CDN: Servidor de nomes local informa ao cliente qual servidor de conteúdos deve ser acessado [Rajkumar Buyya 2008]. Entretanto, o servidor de nomes local da RDC que atende um grupo de clientes nem sempre é capaz de armazenar registros de quais conteúdos estão presentes em todos os servidores de conteúdo, o que faz com que a escolha do servidor de conteúdos seja baseada somente na proximidade de rede, disponibilidade de banda e carga do servidor. Desta forma, existe a possibilidade do servidor de conteúdos escolhido não possuir uma réplica do conteúdo requisitado. Neste caso, o servidor de conteúdo irá requisitar uma cópia do conteúdo do servidor original ( ou de algum outro servidor que possua uma cópia deste conteúdo), antes de atender à requisição. Devido às características não cooperativas desta abordagem, para manter níveis de qualidade de serviço aceitáveis, geralmente existem mais réplicas na rede de cada conteúdo do que realmente seria necessário, caso uma abordagem cooperativa fosse utilizada. 3.3.3. Cooperative Push-Based CDN Recentemente, diversos trabalhos propuseram mecanismos pró-ativos de replicação de conteúdos que posicionam replicas dos conteúdos nos servidores da RDC baseado em padrões de acesso dos clientes e na topologia global da rede. A principal vantagem desta
técnica, denominada cooperative push-based CDN, não reside do fato da replicação ocorrer de forma pró-ativa ao invés de mecanismos reativos, mas sim no compartilhamento colaborativo das réplicas nos servidores. Este compartilhamento colaborativo das réplicas, gerenciado por uma entidade centralizada, permite a redução do número de réplicas de conteúdos existentes na RDC, que consequentemente reduz o custo de replicação. Este mecanismo de replicação é ilustrado na figura 3.3. Figura 3.3. Cooperative Push-Based CDN: Servidor de nomes deve manter registros sobre as réplicas distribuídas na RDC [Rajkumar Buyya 2008] Para cada replicação realizada, é necessário informar ao servidor de nomes local este fato, para que os registros que mapeiam qual conteúdo está localizado sejam atualizados. A depender das características da RDC, manter tal registro em cada servidor de nomes local pode ser uma tarefa muito custosa. Entretanto, para reduzir a complexidade desta tarefa, pode-se agrupar diversos conteúdos em apenas um registro ou limitar o número de servidores que cada servidor de nomes local é capaz de gerenciar. 3.3.4. SCAN: Scalable Content Access Network SCAN é um sistema de replicação de conteúdos auto-organizável e soft-state, como pode ser observado na figura 3.4. SCAN utiliza o Tapestry como seu SDD, que provê um ambiente de gerência de conteúdos colaborativo e descentralizado. Através do Tepestry, SCAN posiciona réplicas dinamicamente entre os servidores de borda e as auto organiza em uma árvore multicast em nível de aplicação para disseminar as atualizações. SCAN calcula as decisões referentes às replicações de conteúdos de maneira dinâmica, o que permite a adaptação da rede perante eventos adversos. Tapestry é um serviço de localização de P2P descentralizado que expõe informações de localidade de objetos em mensagens de roteamento. Devido a sua abordagem descentralizada, Tapestry foi utilizado como um sistema base para o desenvolvimento de SCAN. Seus principais componentes são:
Figura 3.4. Sistema de Diretórios Replicados: O diretório centralizado pode ser replicado para pontos remotos da rede [Rajkumar Buyya 2008]. Tapestry Routing Mesh: Gerência o descobrimento de rotas dentro da rede Tapestry. Cada novo nó, ao se juntar à rede, deve se conectar a um novo nó existente, formando um link de vizinhança. O nó existente provê ao novo nó rotas para todos os nós da rede, através da computação de algoritmos baseados em DHT ( Distributed Hash Table). Tapestry Distributed Location Service: Implementa o serviço de localização do Tapestry. Um GUID (Globally Unique ID ou Identificador Único Global) é associado a cada objeto, e para cada GUID é associado um único servidor raiz. Os servidores de armazenamanto anunciam seus conteúdos em direção ao servidor raiz, e depositam mensagens de localização, que apontam para a localização do objeto, em cada nó intermediário. Os clientes, quando necessitam conhecer a localização de algum conteúdo, enviam requisições para seus vizinhos, até encontrar um registro correspondente. A distância média percorrida ao se localizar objetos é proporcional à distância do objeto. O problema de replicação dinâmica de conteúdos pode ser modelada como um problema de otimização. Pode-se, por exemplo, modelar um problema que visa minimizar o tráfego total na RDC durante o atendimento às requisições dos clientes, enquanto as restrições de QoS e limitações de desempenho da infraestrutura da RDC são respeitadas. Outra abordagem seria minimizar o tempo de reposta total, experimentado por todos os clientes da RDC. SCAN tenta minimizar o número total de réplicas de cada conteúdo posicionadas na RDC, enquanto mantém aderência aos requisitos de QoS impostos. A formulação matemática adotada para nortear o desenvolvimento de SCAN foi a seguinte: Dada uma rede G com C clientes e S servidores, cada cliente c i com sua restrição de latência d i e cada servidor s j com um conjunto de restrições de carga/banda/armazenamento l j. O problema consiste em encontrar um valor mínimo para K, tal que um conjunto S S, com S = K e c C, s c S tal que distancia(c, s c ) d c. Os clientes C e os servidores S devem se auto-organizar em uma árvore ALM tendo C como suas folhas e s i S, o número de clientes conectados satisfaçam a relação f(s i ) l i.
O posicionamento dinâmico das réplicas tenta satisfazer às restrições de latência dos clientes e às restrições de carga dos servidores. O objetivo é satisfazer estas restrições minimizando o número de réplicas posicionadas, mantendo as árvores ALM balanceadas e gerando o mínimo de tráfego de atualizações possíveis. SCAN implementa algoritmos heurísticos para solucionar este problema. Quando comparado com mecanismos implementados em arquiteturas tradicionais de RDCs, SCAN posiciona cerca de 6-8% do número de réplicas na rede. 4. Gerenciamento e Entrega de Conteúdos em Ambientes Web A Internet e os sistemas Web, nos últimos anos, evoluíram de um meio de distribuir conteúdos estáticos de interesse marginal para a principal plataforma de comunicação mundial, onde conteúdos e serviços críticos são entregues aos seus usuários. Esta evolução foi acompanhada por uma preocupação dos provedores de conteúdos com relação o desempenho da entrega dos conteúdos percebida pelos usuários, que por muitas vezes contrataram serviços dos provedores de RDC, para manter este desempenho em níveis aceitáveis. As primeiras gerações de RDCs para entrega de conteúdos Web se concentravam na distribuição de conteúdos estáticos e possuíam o objetivo de amenizar eventos de congestionamento em páginas Web com alta demanda. Entretanto, o cenário Web atual sofreu modificações marcantes no que diz respeito à sofisticação e complexidade dos serviços oferecidos, evidenciadas principalmente pela presença maciça de conteúdos gerados dinamicamente e personalizáveis. Desta forma, as arquiteturas de RDC sofreram diversas modificações e aprimoramentos ao longo dos anos para serem capazes de lidar de forma eficiente com esta nova realidade dos ambientes Web, que possuem serviços mais complexos, usuários mais exigentes e uma grande quantidade de conteúdos gerados dinamicamente e personalizáveis por seus usuários. 4.1. Camadas Lógicas dos Sistemas Web De forma geral, pode-se dizer que os sistemas Web são baseados numa arquitetura lógia multi-camada que separa em diferentes componentes a interface HTTP, a lógica da aplicação, um repositório ou banco de dados e um banco de informações relacionadas com os usuários que acessam o sistema. Estes diferentes componentes ou camadas podem ser referenciadas, respectivamente, como front-end, application, back-end e user profile. A figura 4.1 ilustra estes componentes: Front-end layer: Esta camada funciona como uma interface entre os usuários do sistema e a camada application. A partir das requisições HTTP dos clientes, conteúdos estáticos são buscados em um sistema de arquivos e entregue aos clientes de maneira simplificada. Alguns exemplos de conteúdos estáticos que podem ser manipulados pelo front-end são os seguintes: objetos embutidos em páginas Web como imagens, style sheets e animações em flash e conteúdos multimídia como áudio e vídeo, que geralmente são entregues via HTTP Streaming. Application layer: Esta pode ser considerada a principal camada dos sistemas Web, já que é responsável por toda a lógica de processamento do serviço implementado no sistema Web. Uma funcionalidade interessante desta camada é realizar o processamento necessário para geração de conteúdos dinâmicos ou personalizáveis, a partir das informações fornecidas pelos usuário via o front-end
Figura 4.1. Camadas lógicas de um sistema Web [Rajkumar Buyya 2008] layer e dados armazenados no back-end layer e no user profile layer. Alguns exemplos de conteúdos dinâmicos que podem ser gerados por esta camada são os seguintes: respostas obtidas a partir de fontes de informações como carrinhos de compras e formulários de busca e conteúdos gerados a partir do comportamento social dos usuários, como páginas de fóruns ou blogs. Back-end layer: Esta camada gerencia o principal repositório de informações do sistema Web e, tipicamente, é constituído de um servidor de banco de dados e armazenamento. Os conteúdos armazenados neste sistema podem ser utilizados para a geração de conteúdos dinâmicos. Listas de produtos de uma loja virtual e páginas ou artigos de blogs ou fórum são exemplos de informações que podem ser armazenadas nesta camada. User profile layer: Esta camada armazena dados de preferências dos usuários, que podem ser utilizadas na geração de conteúdos dinâmicos personalizáveis. Informações fornecidas pelos usuários através de formulários, para adicionar ou editar suas preferências e informações inferidas por sistemas de análise de comportamento dos usuários, para geração de anúncios de publicidade direcionados, são exemplos de informações que podem ser armazenadas nesta camada. 4.2. Arquiteturas de RDC Para Entrega de Conteúdos Web Uma abordagem simplificada de uma RDC para conteúdos Web, ilustrada na figura 4.2 se baseia no princípio da replicação dos recursos do sistema, ou seja, dos servidores Web, para melhorar o desempenho percebido pelos usuários ao acessarem a enorme quantidade de conteúdos, que geralmente estão presentes nestes sistemas. Esta replicação de recursos pode se dar de forma local ou distribuída. Na replicação local, diversos servidores localizados na mesma rede local (Local Area Network - LAN) compartilham a mesma conexão para o restante da Internet, e funcionam como um cluster de servidores. Desta forma, este cluster de servidores se comporta como um único sistema computacional de alto desempenho, o que de certa forma aumenta a escalabilidade do sistema e a sua tolerância a falhas. Entretanto, quando as páginas Web armazenadas neste cluster de servidores possuem uma alta popularidade, problemas graves de escalabilidade podem surgir, principalmente
no que diz respeito à conexão Internet compartilhada pelos servidores que compõem o cluster, que pode funcionar como um gargalo no desempenho do sistema, além de representar um ponto único de falha. Desta forma, um alto tráfego de rede na zona em que o cluster está localizado, falhas em roteadores e componentes externos ou ataques do tipo DoS podem tornar o sistema indisponível, independente do poder computacional alocado no cluster. Figura 4.2. Arquitetura de RDC simplificada [Rajkumar Buyya 2008]. Já em abordagens de replicação distribuídas, dois tipos de servidores existem na RDC: servidores de borda e servidores de núcleo. Os servidores de borda devem ser posicionados o mais próximo possível dos clientes, e geralmente estão localizados em pontos de presença (Points of Presence - POP) de diversos provedores de serviço de Internet (Internet Service Providers - ISP). Estes servidores são responsáveis principalmente pela interações com os clientes, já que as requisições lhes são encaminhadas, geralmente por meio de redirecionamento via DNS. Os servidores de núcleo são entidades lógicas que geralmente realizam funções relativas ao gerenciamento da RDC, coordenação das políticas de distribuição de requisições e contabilidade. Os servidores de núcleo podem ser implementados como um multi-cluster, que pode ser definido como um grupo de cluster que trabalham de forma colaborativa para se comportarem como um único sistema computacional virtual com alta disponibilidade e poder computacional. Além destes dois tipos de servidores, o chamado servidor de origem do conteúdo também deve existir, de forma integrada à RDC. O servidor original deve sempre conter uma cópia atualizada de determinados conteúdos e é acessado sempre que necessário, ou seja, quando os servidores de borda não possuem, ou não podem entregar uma determinada réplica aos clientes. 4.3. Replicação das Camadas Lógicas de Sistemas Web De forma geral, o objetivo principal em se utilizar uma RDC para entrega de conteúdos Web é o de acelerar a entrega dos conteúdos aos clientes, com aderência aos requisitos de QoS impostos e minimizando os custos operacionas de se manter réplicas destes conteúdos e de transmiti-los. Dentro deste contexto, os servidores de borda da RDC e o servidor de origem de cada conteúdo são os mais relevantes, já que são estes os responsáveis pela entrega dos conteúdos e relacionamento direto com o cliente. Desta forma, como pode ser obsevado na figura 4.3 as quatro camadas lógicas que compõem os servidores Web (Front-end, Application, Back-end e User profile) podem ser replicados dos servidores de origem para os servidores de borda da RDC, para permitir a
aceleração da geração e entrega de diferentes tipos de conteúdos (estáticos, dinâmicos e personalizáveis). Figura 4.3. Replicação das camadas lógicas dos sistemas Web [Rajkumar Buyya 2008]. 4.3.1. Replicação do Front-end Layer Na replicação do Front-end, ilustrada na figura 4.4 os servidores de borda são responsáveis apenas pelo gerenciamento e entrega de conteúdos estáticos, com o objetivo de melhorar o desempenho e a escalabilidade deste serviço. Neste caso, os servidores de borda se comportam como proxies reversos ou caches para acelerar a entrega de conteúdos que podem ser armazenados em sistemas de arquivos. Este tipo de replicação ajuda a aumentar a disponibilidade, desempenho e a escalabilidade deste serviço, já que ao trazer os conteúdos estáticos para os servidores de borda, que estão mais próximos aos clientes, problemas de indisponibilidade, desempenho e limitações de capacidade em links de longa distância não mais afetarão a qualidade de serviço experimentada pelo cliente. Figura 4.4. Replicação do Front-end Layer [Rajkumar Buyya 2008] A utilização de um provedor de RDC para entrega de conteúdos estáticos na Web é uma abordagem bastante comum, e remete às primeiras gerações de RDCs. Entretanto, a entrega de conteúdos estáticos ainda é uma tarefa crítica, devido principalmente ao
continuado aumento da quantidade de conteúdos multimídias na Web. Mover a responsabilidade de entrega deste tipo de conteúdo para os servidores de borda de uma RDC gera grandes benefícios para os clientes, devido a dois motivos. Primeiramente, dado que estes tipos de conteúdos normalmente possuem um tamanho relativamente grande, atrasos de rede impactam significativamente a performance do serviço percebida pelos usuários. Além disto, devido à disseminação de técnicas de streaming via HTTP na entrega destes conteúdos, a redução da variância do atraso de rede resulta em uma execução ou exibição mais suave e estável. Entretanto, nem sempre é possível replicar todo o conteúdo multimídia para os servidores de borda, devido a restrições de espaço de armazenamento. Neste caso, apenas partes dos conteúdos devem ser replicados, técnica esta chamada de segment caching. Segment chaching pode ser implementada de duas maneiras: sequential caching e interleaved caching. A técnica de sequential caching é aplicada em conteúdos com uma forte semântica temporal, e neste caso apenas as partes inciais do conteúdo são replicadas, para evitar o tempo de buferização. Já para conteúdos que são acessados a partir de uma quantidade significativa de operações de busca por suas partes, técnicas de interleaved caching são aplicadas, em que segmentos mais populares dos conteúdos são replicados. O conceito de segment caching pode ser estendido para páginas Web formadas por diferentes fragmentos ou objetos independentes. Neste caso, existe um aumento de complexidade nas funções desempenhadas pelo Front-end que foi replicado para um servidor de borda da RDC, já que este precisa gerenciar o armazenamento e a entrega destes diferentes fragmentos, ao invés de uma página Web como um único objeto. Entretanto, os servidores de borda também se beneficiam desta técnica, já que sua utilização implica num uso mais otimizado do espaço em disco utilizado para armazenar os objetos replicados, pois objetos compartilhados por diferentes páginas Web só precisariam de uma cópia armazenada. Além disto, caso ocorra uma atualização nos conteúdos de alguma página Web, somente os fragmentos modificados precisam ser atualizados, e não toda a página. Já para os servidores de origem, duas vantagens podem ser observadas: este servidor não mais precisará montar a página Web e apenas uma frações dos conteúdos armazenados precisarão ser entregues ao cliente. Esta geração dinâmica de páginas Web pelos Frontend replicados nos servidores de borda tende a melhorar o tempo de resposta de entrega de conteúdos, melhorando a desempenho do serviço observado pelo usuário final. 4.3.2. Replicação do Application Layer Um gargalo de desempenho na replicação do front-end layer é que o application layer do sistema, responsável pela lógica de geração de conteúdos dinâmicos no sistema Web, continua centralizado no servidor de origem. A replicação do application layer para servidores de borda de uma RDC, chamada de computação de borda ou edge computing, tem o objetivo de reduzir a carga do servidor de origem, o que implica em um maior desempenho, disponibilidade e escalabilidade dos sistemas Web. O back-end layer e user profile layer ainda permanecem como uma base de dadaos centralizada no servidor de origem, compartilhada entre os servidores de borda, como pode ser observado na figura 4.5. Duas soluções de arquitetura para replicação do application layer podem ser
Figura 4.5. Replicação do Application Layer [Rajkumar Buyya 2008] definidas, baseadas na capacidade dos servidores de borda em diferenciar requisições transacionais e não transacionais. Uma requisição transacional é um conjunto atômico de operações de banco de dados que geralmente envolve o travamento de uma parte do banco de dados e atualizações em seus registros. Já uma requisição não transacional realiza apenas operações de leitura no banco de dados. Se os servidores de borda da RDC não são capazes de fazer esta distinção, todas as requisições são encaminhadas para seus respectivos application layers, onde são processadas. A lógica do application layer irá então realizar chamadas no banco de dados centralizado do sistema. Já se os servidores de borda são capazes de realizar esta distinção, apenas as requisições não transacionais são processadas pelo application layer local, enquanto que as requisições transacionais são encaminhadas diretamente para o application layer do servidor de origem, que irá processar a requisição acessando o seu banco de dados centralizado. 4.3.3. Replicação do Back-end Layer A computação de borda não resolve todos problemas de desempenho em ambientes Web, já que em alguns sistemas o gargalo da performance reside no back-end layer, ou seja, no acesso aos registros do banco de dados. Ao replicar o back-end layer para os servidores de borda de uma RDC, como pode ser observado na figura 4.6 um provedor de conteúdos delega à RDC a função de gerenciar os dados da sua aplicação e responder às requisições por dados a partir da borda da rede. A replicação do back-end layer pode ser encarada como um complemento à replicação do application layer, já que, para que se alcance uma melhoria de desempenho com esta estratégia, é preciso que os dados do back-end layer sejam acessados pela aplicação do application layer localmente. Dentro do contexto dos sistemas Web, a replicação do back-end layer pode se dar de de forma parcial ou integral. As replicações parciais podem se basear em estratégias de caching para melhorar o seu desempenho. Com o mecanismo de Content-Blind Caching, os dados mais populares são replicados para os servidores de borda. Já com o mecanismo de Content-Aware Caching, porções do back-end Layer são replicadas ativamente para os servidores de borda baseado em padrões de acesso dos clientes e condições da rede e da infraestrutura de servidores. Dentre estes dois mecanismos, não existe um vencedor