Hice que AWS perdiera dinero: ¡así es como!

Esta es una serie corta que quería compartir desde hace mucho tiempo sobre los conceptos básicos de "Optimización de costos" en AWS. ¡Comencemos este viaje con ! DocumentDB No dudes en 👏 si te ha gustado este post ;) De acuerdo, para ser realmente honesto, este título es *.* clickbait Definitivamente podría escribir algo como ", pero es mucho menos atractivo, ¿no? "cómo realicé la optimización de costos en nuestra infraestructura de AWS al respetar algunas pautas comunes proporcionadas en la documentación Quizás algunos de ustedes ya conozcan estos trucos y buenas prácticas. Si está buscando directamente la lista de verificación que sugiero, desplácese aquí. Comprenda el complicado costo de E/S del servicio DocumentDB Si observa su página de precios, está dividida por 4 dimensiones de costos, lo resumo aquí: : bueno, este costo es comprensible rápidamente: paga por una instancia, y el precio dependerá de sus recursos (CPU, RAM, etc.) El precio de la instancia : igual que el anterior, es bastante comprensible, y podemos rastrear y estimar fácilmente los costos de los mismos, la factura de AWS por GB almacenado. Legal. Costos de almacenamiento y almacenamiento de respaldo : ¡AWS facturará entre y (según la región de la instancia) La parte más complicada es la E/S de la base de datos 0,20 $ 0,30 $ por 1 millón de E/S! Entonces, ¿qué hay detrás de las E/S? AWS explica que con el servicio DocumentDB, no tiene que aprovisionar recursos de E/S por adelantado, lo cual es bastante interesante, porque no tiene limitaciones de almacenamiento y puede manejar fácilmente una selección de operaciones de E/S. Parece justo, ya que se le factura por el uso. AWS describe en su documentación lo que cubre las operaciones de E/S, principalmente todas las operaciones como buscar, insertar, actualizar y eliminar o algunas características como flujos de cambios e índices TTL (tiempo de vida). Bueno, todo lo que afecte el volumen de almacenamiento se te facturará. Espera, ¿qué, 0,20 $ por millón de E/S? ¡Hagamos que AWS pierda dinero, ahora mismo! Hay una frase en la documentación de AWS DocumentDB que llamará su atención (y billetera 💸): Una vez, una vez que los datos se han leído del volumen de almacenamiento y continúan residiendo en la memoria, las lecturas posteriores de los mismos datos no incurren en E/S adicionales. Esta frase es clave para entender qué hay detrás de las E/S. ¿Qué operaciones utilizan menos E/S? probablemente usarán menos E/S ya que no está escaneando todo el almacenamiento de su colección. Ciertamente consumirá E/S, pero mucho menos que escanear una colección completa. Las consultas que usan un índice Además, la RAM de su instancia debe cubrir el tamaño de su índice, lo que le permitirá no incurrir en operaciones de E/S adicionales. Tenga en cuenta que debe respetar algunos principios con el uso de índices. Lista de verificación ✅ Este es mi consejo/lista de verificación cuando desee optimizar su uso de E/S y reducir sus costos y mejorar el rendimiento. Verá que no soy un genio, ya que solo agrego información de la página de documentación de AWS DocumentDB con algunas mejores prácticas comunes que no son estrictamente aplicables a DocumentDB. Siempre es bueno refrescar nuestras mentes con principios. 🧠 : menos E/S = más barato = mejor rendimiento, aquí no se trata solo de costos ni de rendimiento, pero las dos cosas están vinculadas. Primero, recuerda esto ❌ : no sabes lo caro que es un índice sin usar para una colección ocupada. fácil 🤌, eliminando los índices no utilizados. Y es muy fácil rastrear índices no utilizados con esta consulta: Eliminar índices sin usar Hice que mi empresa ahorrara 2000 $/mes así de Consulta de estadísticas de índice La consulta generará las de campo que corresponden a la cantidad de veces que se alcanza su índice. Dependiendo de la carga de su aplicación, considere eliminar el índice no utilizado. ops 🧐 : si usa RDS, es posible que esté al tanto de , le brinda algunas métricas e información muy útiles sobre las consultas que están afectando su rendimiento de DocumentDB, y puede ver rápidamente las consultas que consumen I /Os operaciones (y la cantidad de ellas), por lo que es muy bueno para rastrear fácilmente un cuello de botella. Otra forma de monitorear consultas lentas o consultas collscan es activando de generación de perfiles, como su nombre indica, está generando perfiles para usted de algunas operaciones (aquí hay un enlace para obtener más información:), puede establecer un umbral que colocará en CloudWatch un registro de un operación que está tomando más de . Muy útil para rastrear el número de consultas que están realizando COLLSCAN por ejemplo. ¡Active ambas opciones ya que son muy valiosas! Active y la información de rendimiento las operaciones de generación de perfiles la información de rendimiento las operaciones n ms 💾 : deberá identificar el mejor campo de cardinalidad alta que desea indexar, si no está acostumbrado al concepto de cardinalidad de índice, la documentación de AWS DocumentDB está bien explicada :) Mire siempre primero sus datos 🫠 : si planea tener una colección que tendrá tres campos con uno de ellos con una clave única, y si planea realizar muchas actualizaciones/inserciones, considere la modelización de su colección, porque sus operaciones de E/S se verán afectadas y, por lo tanto, su uso de E/S. Evite colecciones pequeñas y complicadas ⏱️ : (la mayoría de las veces) puede manejarlo sin establecer un índice de tiempo de salida, así que verifique que el parámetro TTL no esté habilitado en la instancia o el clúster. Evite TTL, también conocido como índices de tiempo de salida 💡 Una forma muy sencilla de verificar la selectividad del índice del planificador de consultas cuando está realizando una nueva consulta (o no) es realizar una operación de con el parámetro . Se sorprenderá de que algunas consultas que está pensando en índice de éxito, simplemente no lleguen a ningún índice... ¡Explica! explicación executionStats ☯️ . Simplemente no lo hagas. Recuerda la cardinalidad. No cree un índice para un campo booleano ⚖️ para cada colección que tenga con este comando: Un tamaño promedio extremo puede crear rápidamente un bloqueo en sus consultas y aumentar las operaciones de E/S porque la RAM de tu instancia no es suficiente. Supervise de cerca los objetos y no almacene campos innecesarios. Si necesita almacenar muchos campos, considere optimizar las consultas al no seleccionar todos los campos. Supervise el tamaño promedio de un objeto db. .stats(1024) ⚠️ Es principalmente compatible con MongoDB pero no es MongoDB ya que hay algunos comportamientos específicos de mierda. Por ejemplo, si desea realizar una consulta con el operador , deberá indicar su indexación, ya que es obligatorio. Los operadores de exclusión nunca usarán ningún índice, así que tenga en cuenta estos comportamientos al crear u optimizar sus índices. Tenga en cuenta que DocumentDB no es MongoDB. $regex 👉Nunca . A excepción de los casos de uso muy específicos mencionados anteriormente, debe evitar el uso de la , tenga en cuenta que si el planificador de consultas no elige su índice, es por una buena razón. La mayoría de las veces es porque es más largo o equivalente a escanear el índice en lugar de todos los documentos de la colección. insinuar hint Espero que aprecie estos trucos que aprendí mientras trabajaba en AWS Cost Optimization para mi empresa. ¡Estén atentos para otra publicación! No dudes en 👏 si te ha gustado este post ;) PD: si algo parece mal o un malentendido, no dudes en enviarme un mensaje privado. También publicado aquí