Papers
Serverless Computing: One Step Forward, Two Steps Back
Joseph M. Hellerstein, Jose Faleiro, Joseph E. Gonzalez, Johann Schleier-Smith, Vikram Sreekanti, Alexey Tumanov, Chenggang Wu · CIDR 2019 (Conference on Innovative Data Systems Research), 2019
A tese: um passo à frente, dois para trás
O paper analisa as ofertas públicas de Function-as-a-Service (FaaS), como o AWS Lambda, e defende que elas fazem uma coisa certa e duas erradas. O passo à frente é o autoscaling com pagamento por uso: o desenvolvedor não pensa em servidores nem em planejamento de capacidade, e a cobrança acompanha o uso real. Os dois passos atrás, segundo os autores, são que a FaaS atual é ruim para computação intensiva em dados e ruim para computação distribuída de propósito geral. A razão é que o modelo isola o código em funções curtas e sem estado, e deixa os dados e a comunicação para serviços de armazenamento lentos. Os autores não dizem que o serverless é inútil. Eles reconhecem um grande mercado de aplicações estreitas, muitas delas pouco mais que lógica de negócio sobre um banco de dados, e dizem que a FaaS atende bem esses casos. A crítica é que o modelo atual não entrega o potencial da nuvem para quem quer programar sistemas de dados e algoritmos distribuídos. A meta declarada é mudar a pergunta de 'o serverless vai ganhar?' para 'como projetar infraestrutura e modelos de programação que liberem inovação em sistemas ricos em dados em escala de nuvem?'.
As quatro limitações da FaaS atual
O paper identifica quatro limitações das ofertas de FaaS. A primeira são os tempos de vida curtos: uma função do Lambda vive no máximo 15 minutos, o que impede manter estado de longa duração dentro dela. A segunda são os gargalos de E/S: medindo a banda de rede, uma única função alcançou 538 Mbps, mas com 20 funções em paralelo a média por função caiu para 28,7 Mbps. A terceira é a comunicação por armazenamento lento: as funções não são endereçáveis pela rede, então duas funções só conversam passando os dados por um serviço intermediário. A quarta é a ausência de hardware especializado, como GPUs, o que pesa para treinamento de modelos. Em conjunto, essas limitações levam ao padrão que o paper critica: o código é enviado ao dado, em vez de o dado ser aproximado do código, e a máquina que roda a função não guarda cache entre invocações com garantia. Os autores tratam esse arranjo como a causa raiz do mau desempenho que mostram nos estudos de caso seguintes, e não como um detalhe de implementação que um ajuste fino resolveria.
Estudos de caso: treino e predição de modelos
Para tornar as críticas concretas, os autores comparam a FaaS com máquinas EC2 em tarefas de machine learning. No treinamento de um modelo, a versão em funções levou 465 minutos, contra cerca de 22 minutos em uma instância EC2 m4.large. Em custo, foram US$ 0,29 contra US$ 0,04. Isso dá uma versão aproximadamente 21 vezes mais lenta e 7,3 vezes mais cara. No serving de predições, a latência por requisição foi de 559 ms quando o modelo era buscado a cada chamada, 447 ms com o modelo embutido na função e uso de SQS para entrada, 13 ms com EC2 e SQS, e 2,8 ms com EC2 e ZeroMQ. Ou seja, mesmo eliminando a busca do modelo, a função ficou muito atrás de uma máquina que se comunica diretamente. O ponto não é que o hardware da função seja ruim em si, e sim que o modelo de execução (vida curta, sem cache confiável, comunicação via serviço) é caro para esse tipo de carga. Os números ilustram o argumento de que dados e comunicação, e não o cálculo, dominam o custo.
Comunicação, latência e o custo da coordenação
O paper mede latências para mover 1 KB de dados em diferentes caminhos: cerca de 303 ms para invocar uma função, 108 ms de uma função Lambda para o S3, 11 ms do Lambda para o DynamoDB, 106 ms de uma instância EC2 para o S3, 11 ms do EC2 para o DynamoDB e apenas 290 microssegundos entre instâncias EC2 usando ZeroMQ. A diferença de ordens de grandeza mostra o preço de forçar a comunicação a passar por armazenamento. O paper também discute coordenação distribuída. Como funções não se endereçam diretamente, um protocolo como eleição de líder tem de ser feito por meio do armazenamento: cada rodada levou 16,7 segundos, o que equivale a 1,9% do tempo agregado, e para 1000 nós o custo foi de pelo menos US$ 450 por hora. Um exemplo de custo de mensageria: sustentar 1 milhão de mensagens por segundo no SQS custaria US$ 1.584 por hora, contra US$ 27,84 por hora para 290 instâncias EC2 (cerca de 57 vezes menos). Esses números sustentam a tese de que a FaaS, como hoje oferecida, é inadequada para algoritmos que dependem de comunicação frequente.
O que a FaaS faz bem e as objeções iniciais
Os autores listam três casos fáceis, em que a FaaS funciona bem: cargas embaraçosamente paralelas (cada tarefa independe das outras), orquestração de serviços (a função coordena chamadas a outros serviços) e composição de funções. Citam como exemplo de sucesso uma empresa, a Autodesk, cujo fluxo de cadastro de usuários passou a levar cerca de 10 minutos. O paper também antecipa objeções. Uma é que 'serverless' tem sentido mais amplo do que FaaS; os autores respondem que entregar um serviço de autoscaling específico não resolve o problema de habilitar programação de propósito geral na nuvem. Outra é 'espere o próximo anúncio de rede': eles aceitam que redes vão melhorar, mas dizem que a hierarquia de memória continuará existindo e que será preciso poder colocar código e dados do mesmo lado de uma fronteira, o que a FaaS não oferece. A terceira é 'a economia torna o serverless inevitável': eles concordam que há um mercado enorme de aplicações estreitas, mas temem que isso desestimule serviços novos com estado e reforce o domínio dos produtos proprietários dos provedores.
Propostas: o caminho adiante
Na última parte, o paper propõe desafios para uma nuvem programável de verdade. O primeiro é a colocação fluida de código e dados: a infraestrutura deve poder aproximar fisicamente código e dados para ganhar desempenho, mas mantê-los separados logicamente para permitir elasticidade. Linguagens declarativas e centradas em dados, como SQL com UDFs, MapReduce e TensorFlow, facilitam isso. O segundo é o suporte a hardware heterogêneo, com o provedor compilando programas de alto nível para o hardware mais barato que cumpra o objetivo do usuário. O terceiro são agentes virtuais endereçáveis e de longa duração, com identidade conhecida e desempenho de rede comparável ao padrão, mas remapeáveis entre máquinas físicas; atores, tuplespaces, pub/sub e DHTs são exemplos de ideias nessa linha. O quarto é a programação desordenada: linguagens que incentivem unidades pequenas de dados e computação, fáceis de mover no tempo e no espaço. Os autores sugerem ainda uma representação intermediária comum, objetivos de nível de serviço (SLOs) com preço associado, e atenção a segurança. Concluem que o futuro da programação em nuvem é 'fluido', chamando ou não de serverless.
Veja as ideias em ação
Pratique na escola de System Design os desenhos que usam este paper.