From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control Recientemente con el objetivo específico de ayudar a los clientes potenciales de ScyllaDB a comprender el verdadero coste de ejecutar DynamoDB. Ahora, si usted hace un paso atrás y mira a mi objetivo, no tiene mucho sentido, ¿verdad? Cálculo de costes de DynamoDB En ese momento, me di cuenta de que hay muchas razones por las que los equipos terminan pagando cientos de miles (si no millones) de dólares para ejecutar DynamoDB a escala. Lo principal que encontré: DynamoDB es fácil de adoptar, pero sangriento difícil de controlar. Mi compañero de trabajo Guilherme y yo , pero si no tienes tiempo para mirar, continúa leyendo para descubrir los principales hallazgos. Hemos realizado un webinar en estas líneas El primer malentendido común es exactamente lo que DynamoDB te cobra. probablemente ya hayas escuchado términos como Unidades de Capacidad de Lectura y Unidades de Capacidad de Escritura, y obtendrás el gesto de “Pagas por lo que usas” en términos de número de lecturas y escrituras. Los escritos de DynamoDB son caros... Si miras a , verá que una unidad de solicitud de lectura (RRU) cuesta $0.125 por millón de unidades, y una unidad de solicitud de escritura (WRU) cuesta $0.625 por millón de unidades. Así que, las escrituras son 5 veces más caras que las lecturas. No conozco la razón técnica exacta, pero no hay duda de que tiene algo que ver con el camino de escritura siendo más pesado (durabilidad, consistencia, indexación, etc.) y quizás algo de cabecera. 5x parece un poco en el lado abrupto para las bases de datos y una de las primeras trampas desde una perspectiva de costo. Puede encontrarse fácilmente gastando una orden de magnitud más si su carga de trabajo es de escritura pesada, especialmente en el modo on-demand. Precio de la capacidad on-demand Hablando de lo que... hay el otro modo: Como su nombre sugiere, esto significa que puede especificar cuánto va a usar (incluso si no lo usa), y esperemos que pague un poco menos. Vamos a comprobar la proporción, sin embargo. Una Unidad de Capacidad de Lectura (RCU) cuesta $0.00013 por RCU y una Unidad de Capacidad de Escritura (WCU) cuesta $0.00065, por lo que escribir es sorprendentemente 5 veces más caro que leer. Así que incluso en modo provisionado, todavía está pagando una multa de 5x por escribir. Así, es significativo, especialmente para cargas de trabajo de escritura de alto volumen. ¡No hay descuento previsto en escribir para usted! Capacidad prevista Usted no está proporcionando solicitudes, usted está proporcionando tarifas... Aquí está la captura: las unidades de capacidad proporcionadas se miden por segundo, no por millón de solicitudes, como en el caso de la demanda. Eso me impactó inicialmente. ¿Por qué no solo proporcionar el número total de solicitudes? Pero desde la perspectiva de AWS, tiene un sentido de negocio perfecto. N operaciones por segundo, ya sea que utilice esa capacidad o no. La capacidad de manejar Así que si tu tráfico está estallado, o estás sobreprovisionando para evitar que la solicitud caiga (más sobre eso en un poco), básicamente estás pagando por la capacidad vacía. En pocas palabras, estás comprando capacidad sostenida, incluso si solo lo necesitas ocasionalmente. Capacidad reservada... Así que aquí está el acuerdo: si reserva capacidad, está apostando por adelantado para, esperemos, ahorrar un poco más tarde. Si está seguro de su uso de la línea de base, AWS le da la opción de reservar la capacidad de DynamoDB, al igual que con EC2 o RDS. Es un compromiso de 1 o 3 años prepagado, donde bloquea una tasa fija de lecturas y escrituras por segundo. Un gotcha: no hay opción anticipada parcial; se paga en su totalidad o se va. Veamos un caso de uso simple para comparar los modelos de precios... Supongamos que su carga de trabajo promedio 10,000 lectas/sec y 10,000 escritas/sec durante una hora. Precios en demanda: Escrito: $22.50 / h ... 10,000 * 3600 * 0.625 / 1M Listas: $4.50 / h ... 10,000 * 3600 * 0.125 / 1M (5x más barato que escribir, como de costumbre) Precios provisionales (no reservados): Escrito: $6.50 / h ... 10.000 * $0.00065 Lecturas: $1.30 / h ... 10.000 * $0.00013 Disponible con 1 año de reserva: Escrito: ~ $ 2.99 / h Lecturas: ~$0.59/hora “¿Dónde está la matemática reservada?” te oigo. Usted toma el precio reservado para 100 WCUs ($0.0128 / h) y RCUs ($0.0025 / h), dividir por 730 horas en un mes, dividir por 12 meses en un año, dividir de nuevo por 100 unidades, multiplicar por su tasa necesaria ... luego redondearlo, llorar un poco, y pegar en el meme de "matcha dama". Mi punto es: Provisionado es ~3.4x más barato que en demanda Reservar es ~7.5x más barato que en demanda On-demand es para personas que aman pagar demasiado, o odian predecir El IVA, por : AWS recomienda on-demand Los patrones de tráfico que evolucionan con el tiempo Cargas de trabajo Spiky o Batchy Bajo aprovechamiento (caídas a cero o por debajo del 30% del pico) Lo que es básicamente cada carga de trabajo en la vida real, al menos para los clientes de ScyllaDB. Así que sí, espera pagar un premio por esa flexibilidad a menos que su tráfico se vea como una onda sináptica de libros de texto y tenga una bola de cristal. No es el tamaño del artículo, pero es... Es una trampa que puede no golpear hasta que utilice datos de aplicaciones reales... en cuyo punto te arrepentirás inmediatamente de ignorarlo. En DynamoDB, no solo pagas por operación; pagas por trozo de datos transferidos. Los Writes son facturados por 1KB (Write Request Units o WRUs) Las lecturas se facturan por 4KB (unidades de solicitud de lectura o RRUs) Así que si escribes un elemento de 1.1KB, eso es 2 WRUs. ¿Escribe un elemento de 3KB? Aún 3 WRUs, cada 1KB (o parte de él) se cuenta. Las lecturas funcionan de la misma manera, sólo en los límites de 4KB. Leer un elemento de 1KB? 1 RRU. Leer un elemento de 4.1KB? Eso es 2 RRUs. ¿No es divertido redondear? Estoy seguro de que hay fuertes razones técnicas para estos límites. Puedes ver la trampa aquí. Combine esto con el costo de 5x de una escritura en comparación con una lectura, y las cosas pueden llegar desagradables rápidamente, especialmente si el tamaño de tu artículo cruza esos umbrales sin que te das cuenta. Probablemente esté bien si tienes un tamaño de elemento fijo en tu esquema, pero definitivamente no está bien con los tipos de casos de uso que vemos en ScyllaDB. Por ejemplo, los clientes podrían haber anidado campos de JSON o blob que pueden disminuir o crecer con el uso. Y recuerda, es el tamaño real del artículo, no sólo el tamaño del esquema lógico. Excesivo, porque tienes que... Otro punto doloroso, y la omisión errónea de la propia calculadora de AWS, es la necesidad de sobreprovisionar cuando se utiliza la capacidad provisionada. Suena contraintuitivo, pero se ve obligado a sobreprovisionar - no porque lo desee, sino porque DynamoDB le castiga si no lo hace. En el modo provisionado, cada solicitud está sujeta a estrictos límites de rendimiento porque, si se acuerda antes, una tasa fija es lo que está pagando. Si desliza por encima de la capacidad prevista, golpeará Me encanta la claridad de este tipo de mensaje de excepción. no me gusta lo que realmente hace, sin embargo: solicitud throttling. que mantiene la capacidad de lectura y escritura no utilizada. pero más allá de eso, su aplicación simplemente falla. ProvisionalExcepcionalExcepcional Capacidad de ventana de 300s Así que la mejor manera de contrarrestar esto es la sobreprovisionamiento. ¿Por cuánto? Eso garantiza una respuesta "depende". Pero depende de su tipo de carga de trabajo. Hemos añadido esta funcionalidad a nuestra calculadora para que pueda sobreprovisionar dinámicamente por un porcentaje, solo para factorizar los costes adicionales a su carga de trabajo. Obviamente, estos costes pueden sumarse rápidamente porque en la práctica, estás pagando por el pico incluso si operas en la trampa. Si no proporcionas suficiente capacidad, tus picos corren el riesgo de ser arrastrados, dándote fallos frente al cliente en el peor momento posible. Antes de movernos... Si hay un tema recurrente aquí, es este: el precio de DynamoDB no es inherentemente equivocado. usted paga por lo que usa. Sin embargo, es extremadamente imperdonable para cualquier carga de trabajo que no se vea como una onda de síntomas perfecta y predecible. Ya sea que sea: 5x multiplicador de costes de escritura Multiplicador de costo 7.5x on-demand Opaque por segundo tasas provisionales Redondeo punitivo y límites artificiales de los tamaños de los artículos O simplemente la necesidad de sobreprovisionar para evitar la plantación de cara durante la carga de pico ...Está constantemente teniendo que adivinar su arquitectura en segundo lugar solo para mantenerse por delante de los brotes de costes. La ironía es que DynamoDB se marca como “sin servidor” y “completamente gestionado”, pero usted acaba gestionando las matemáticas de capacidad, los errores de throttling, las capas de precios arcanas y la gimnasia de rendimiento sin fin. Después de observar muchas de las previsiones de la hoja de cálculo de nuestros clientes (y las exportaciones de AWS Cost Explorer) para DynamoDB, incluso los equipos maduros que ejecutan sistemas a gran escala no tienen idea de cuál es el coste... hasta que sea demasiado tarde. Es por eso que construimos una calculadora que modela las cargas de trabajo reales, no sólo las medias.Porque el primer paso para fijar los costes es comprender de dónde vienen. en , Pasé por algunos ejemplos del mundo real de clientes que cambiaron de DynamoDB a ScyllaDB para mostrar el verdadero impacto de los patrones de tráfico, tamaños de artículos, cachés y topologías multi-región. en . Nuestro próximo blog saltar adelante y modelar sus propias cargas de trabajo Cálculo.scylladb.com Modela tus propias cargas de trabajo de DynamoDB en nuestra nueva calculadora de costes Más sobre Tim Koopmans Tim ha tenido sus manos en todas las formas de ingeniería durante las últimas dos décadas con una inclinación por la fiabilidad y la seguridad. En 2013 fundó Flood IO; una plataforma de prueba de rendimiento distribuido. Después de que fue adquirida, disfrutó de escalar el producto, el negocio y el equipo antes de pasar a otros esfuerzos relacionados con el rendimiento.
