From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control Recentemente Com o objetivo específico de ajudar potenciais clientes da ScyllaDB a entender o verdadeiro custo de executar o DynamoDB. Agora, se você dar um passo atrás e olhar para o meu objetivo, não faz muito sentido, certo? Cálculo de Custo do DynamoDB Naivamente, isso é o que eu pensei, no início.Mas então, eu comecei a refazer o funcionamento interno dos cálculos de custos do DynamoDB. Naquele momento, eu percebi que há muitas razões pelas quais as equipes acabam pagando centenas de milhares (se não milhões) de dólares para executar o DynamoDB em escala. A principal coisa que encontrei: DynamoDB é fácil de adotar, mas sangrento difícil de controlar os custos. Meu colega Guilherme e eu Mas se você não tem tempo para assistir, continue lendo para descobrir as principais descobertas. Faça um webinar nessas linhas O primeiro equívoco comum é exatamente o que o DynamoDB cobra.Você provavelmente já ouviu termos como Unidades de Capacidade de Leitura e Unidades de Capacidade de Escrita, e tem o gesto de “Você paga pelo que você usa” em termos de número de leituras e escrituras. O DynamoDB é muito caro. Se você olhar para , você verá que uma unidade de solicitação de leitura (RRU) custa US $ 0,125 por milhão de unidades, e uma unidade de solicitação de escrita (WRU) custa US $ 0,625 por milhão de unidades. Então, as escrituras são 5 vezes mais caras do que as leituras. Eu não sei a razão técnica exata, mas não há dúvida de que há algo a ver com o caminho de escrita sendo mais pesado (durabilidade, consistência, indexação, etc.) e talvez algum espaço de cabeça. 5x parece um pouco no lado íngreme para bancos de dados e uma das primeiras armadilhas a partir de uma perspectiva de custo. Você pode facilmente encontrar-se gastando uma ordem de magnitude mais se sua carga de trabalho é escrita-pesada, especialmente no modo on-demand. Preço da capacidade on-demand Falando do que ... há o outro modo: Como o nome sugere, isso significa que você pode especificar quanto você vai usar (mesmo que você não o use), e esperamos pagar um pouco menos. Vamos verificar a proporção, no entanto. Uma Unidade de Capacidade de Leitura (RCU) custa $0.00013 por RCU e uma Unidade de Capacidade de Escrever (WCU) custa $0.00065, então as leituras são surpreendentemente 5 vezes mais caras do que as leituras. Capacidade prevista Você não está fornecendo pedidos, você está fornecendo tarifas... Aqui está a captura: as unidades de capacidade providenciadas são medidas por segundo, não por milhão de solicitações, como em on-demand. Isso me atraiu inicialmente. Por que não apenas fornecer o número total de solicitações? N operações por segundo, quer você use essa capacidade ou não. A capacidade de lidar Então, se o seu tráfego está estourado, ou você está sobre provisão para evitar o throttling de solicitação (mais sobre isso em um pouco), você está basicamente pagando por capacidade vazia. Em termos simples, você está comprando capacidade sustentada, mesmo que você só precise dela ocasionalmente. Capacidade reservada... Então, aqui está o negócio: se você reservar capacidade, você está apostando grande antecipadamente para, esperamos, economizar um pouco mais tarde. Se você tem confiança no seu uso da linha de base, a AWS dá a você a opção de reservar a capacidade do DynamoDB, assim como com o EC2 ou o RDS. É um compromisso pré-pago de 1 ou 3 anos, onde você bloqueia uma taxa fixa de leituras e escritos por segundo. Um gotcha: não há opção antecipada parcial; é pagar na íntegra ou ir embora. Vamos olhar para um caso de uso simples para comparar os modelos de preços... Digamos que sua carga de trabalho seja média de 10.000 leituras/segundo e 10.000 escritas/segundo durante uma hora. Preço On Demand: Escrever: $22.50 / h ... 10,000 * 3600 * 0.625 / 1M Leia: $4.50 / h ... 10.000 * 3600 * 0.125 / 1M (5x mais barato do que escreve, como de costume) Preço provisório (não reservado): Escritos: $6.50 / h ... 10.000 * $0.00065 Leia: $1.30 / h ... 10.000 * $0.00013 Disponível com 1 ano de reserva: Escritos: ~$ 2,99 / h Leituras: ~$ 0.59/hora “Onde está a matemática reservada?”, ouço você. Você toma o preço reservado para 100 WCUs ($ 0,0128 / h) e RCUs ($ 0,0025 / h), divida por 730 horas em um mês, divida por 12 meses em um ano, divida novamente por 100 unidades, multiplique pela taxa necessária ... depois arredondá-lo, chore um pouco e colar no meme "matemata". Meu ponto é: Provisionado é ~3.4x mais barato do que on-demand Reservar é ~7.5x mais barato do que on-demand On-demand é para pessoas que gostam de pagar demais, ou odeiam prever O IVA, Para o: AWS recomenda on-demand Padrões de tráfego que evoluem ao longo do tempo Cargas de trabalho spiky ou batchy Baixa utilização (caídas para zero ou abaixo de 30% do pico) O que é basicamente toda a carga de trabalho da vida real – pelo menos para os clientes do ScyllaDB. Então, sim, espere pagar um prémio por essa flexibilidade, a menos que seu tráfego pareça uma onda de sinônimos e você tenha uma bola de cristal. Não é o tamanho do item, mas é... É uma armadilha que você pode não atingir até usar dados reais de aplicativos ... em que ponto você imediatamente se arrependerá de ignorá-lo. No DynamoDB, você não paga apenas por operação; você paga por pedaço de dados transferidos. Os Writes são faturados por 1KB (Write Request Units ou WRUs) As leituras são cobradas por 4KB (unidades de solicitação de leitura ou RRU) Então, se você escrever um item de 1.1KB, isso é 2 WRUs. Escreva um item de 3KB? Ainda 3 WRUs, cada 1KB (ou parte dele) é contado. As leituras funcionam da mesma forma, apenas nos limites de 4KB. Leia um item de 1KB? 1 RRU. Leia um item de 4.1KB? Isso é 2 RRUs. Não é divertido arredondar? Tenho certeza de que existem fortes razões técnicas para esses limites. Você pode ver a armadilha aqui. Combine isso com o custo de 5x de uma escrita em comparação com uma leitura, e as coisas podem ficar feias rapidamente, especialmente se o tamanho do item atravessar esses limiares sem que você perceba. É provavelmente ok se você tiver um tamanho de item fixo em seu esquema, mas definitivamente não está bem com os tipos de casos de uso que vemos no ScyllaDB. Por exemplo, os clientes podem ter campos de JSON ou blob que podem encolher ou crescer com o uso. E lembre-se, é o tamanho real do item, não apenas o tamanho do esquema lógico. Excesso de providência, porque você tem que... Outro ponto doloroso, e a omissão perversa da própria calculadora da AWS, é a necessidade de sobreprovisionar ao usar capacidade provisória.Parece contraintuitivo, mas você é forçado a sobreprovisionar – não porque você queira, mas porque o DynamoDB o castiga se você não o fizer. Se você deslizar além da capacidade prevista, você atingirá Eu adoro a clareza deste tipo de mensagem de exceção. eu não gosto do que ele realmente faz, embora: pedido throttling. Isso mantém a capacidade de leitura e escrita não usada.Mas além disso, seu aplicativo simplesmente falha. ExceçãoExceçãoExceçãoExceção 300s janela de capacidade de explosão Então, a melhor maneira de combater isso é a sobreprovisão. Por quanto? Isso garante uma resposta “depende”. Mas isso depende do tipo de carga de trabalho. Nós adicionamos essa funcionalidade à nossa calculadora para que você possa dinamicamente sobreprovisão por uma porcentagem, apenas para factorizar os custos adicionais para a sua carga de trabalho. Obviamente, esses custos podem acumular-se rapidamente porque na prática, você está pagando pelo pico, mesmo se você estiver operando na torneira. Antes de nos movimentarmos... Se há um tema recorrente aqui, é este: o preço do DynamoDB não é inerentemente errado. Você paga pelo que você usa. No entanto, é extremamente imperdoável para qualquer carga de trabalho que não pareça uma onda de sinusite perfeita e previsível. Seja o que for: 5x Multiplicador de Custo de Escrita 7.5x multiplicador de custos on-demand Opaque taxas provisionadas por segundo Arredondamento punitivo e limites artificiais de tamanhos de itens Ou apenas a necessidade de sobreprovisionamento para evitar a plantação de rostos durante a carga de pico ...Você está constantemente tendo que adivinhar sua arquitetura apenas para ficar à frente de explosões de custos. A ironia é que o DynamoDB é rotulado como “sem servidor” e “completamente gerenciado”, mas você acaba gerenciando matemática de capacidade, erros de throttling, níveis de preços arcanos e ginástica de transmissão infinita.Tendo observado muitas das previsões de planilhas de nossos clientes (e exportações do AWS Cost Explorer) para o DynamoDB, até equipes maduras que executam sistemas em grande escala não têm ideia do custo... até que seja tarde demais. É por isso que construímos uma calculadora que modela cargas de trabalho reais, não apenas médias.Porque o primeiro passo para fixar custos é entender de onde elas vêm. em , Eu passei por alguns exemplos do mundo real de clientes que mudaram de DynamoDB para ScyllaDB para mostrar o verdadeiro impacto de padrões de tráfego, tamanhos de itens, caches e topologias multi-região. ao . Meu próximo post no blog saltar para a frente e modelar suas próprias cargas de trabalho Avaliação.scylladb.com Modelando suas próprias cargas de trabalho do DynamoDB em nossa nova calculadora de custos Sobre o Tim Koopmans Tim tem suas mãos em todas as formas de engenharia durante as últimas duas décadas com uma inclinação para a confiabilidade e segurança. Em 2013, ele fundou a Flood IO; uma plataforma de teste de desempenho distribuído.Depois que foi adquirido, ele gostou de escalar o produto, negócio e equipe antes de passar para outros esforços relacionados ao desempenho.
