AWS Notes
5.59K subscribers
452 photos
42 videos
10 files
2.81K links
AWS Notes — Amazon Web Services Educational and Information Channel

Chat: https://xn--r1a.website/aws_notes_chat

Contacts: @apple_rom, https://www.linkedin.com/in/roman-siewko/
Download Telegram
— А давайте придумаем новое название для Aurora Serverless v2?
— А давайте!

🆕 Aurora DSQL = multi-region Aurora Serverless v2

https://aws.amazon.com/blogs/database/introducing-amazon-aurora-dsql/

#Aurora
Aurora DSQLмечта разработчика

Главным событием re:Invent 2024 определённо является появление Aurora DSQL — новой инкарнации Aurora, как результат её 10 лет разработки.

С появления революционной DynamoDB в 2012-м каждый первый разработчик спрашивал — а можно нам такое же, с этими фичами, только Relational и лучше Postgres?

Теперь можно: Aurora DSQL = multi-region + active-active + serverless + strong-consistency.

Под капотом Aurora DSQL в реальности целый комбайн сервисов. Представьте, что каждый ваш запрос обрабатывается отдельной Лямбдой. С великолепными возможностями скейлинга, причём крайне эффективного и отдельным сервисом для хранилища, отделяя таким образом compute от storage.

А самое офигительное, что практически удалив кэширование (сделав его динамическим) и с использованием принципиально ускорившейся за последние годы сети, удалось сделать Aurora DSQL волшебным strongly consistent даже в контексте мульти-регион конфигурации.

Ещё не до конца разобрался, как AWS удалось победить проблему скорости света. 😀 Ведь при использовании регионов на разных сторонах Земли задержка будет в секунду просто на прохождение таких расстояний. Подожду Aurora DSQL Deep Dive видео с re:Invent 2024.

Вот хорошие статьи с подкапотными деталями Aurora DSQL:

🔸 https://blog.datachef.co/aurora-dsql-a-new-boring-aws-serverless-postgres-compatible-database

🔹 https://brooker.co.za/blog/2024/12/04/inside-dsql.html

Добавляйте свои мысли/ссылки по Aurora DSQL в комментариях.

P.S. Aurora DSQL заявлена как "serverless", но не подразумевает скейла в 0. Как минимум это справедливо для текущей версии.

#Aurora
👍152🔥2😱2
#aws #aurora #terraform #finops
Материал уровня senior

Мы умеем определять тип инстанса - по нагрузке на CPU/Memory и другим факторам.
Но насколько эффективно мы выбрали Cluster storage configuration Авроры вашего проекта?
Эффективно ли это спустя год или два?
А никто не знает, давайте разбираться.

- сперва пилим Dashboard к нашему существующему кластеру
https://gist.github.com/kruchkov-alexandr/d9335d7927e58d06557b994dc9f194de
- применяем, видим панель в CloudWatch
Сверху у нас панель чтения/записи хранилища, снизу размер базы данных (+снепшоты?).
Разделение нужно из-за разницы масштабов и удобства экспорта.
- выбираем период три месяца и кликаем на трех точках у обоих панелей и выбираем Download as .csv и качаем оба файла
- заходим в cost explorer и экспортируем дату за три месяца по кластеру
- заходим в вашу любимую AI(я спрашивал у клаудии, перплексити и грок3, все платные) и пилим промт нечто типа(можете писать свой, если мой вам кажется тупым):
"Help me decide if we should switch to Amazon Aurora I/O-Optimized. Use the attached billing screenshot/csv, three-month IOPS data from the CSV, and the IOPS/storage graphs to analyze our costs. Calculate our current I/O expenses, compare them to I/O-Optimized costs and check if our I/O costs exceed AWS’s 25% threshold for switching. Look at IOPS and storage trends, then recommend whether to switch, including specific cost figures. I’ve attached all files (billing, CSV, graphs).
based on this article
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/"

- ждём ответа и все 4 нейронки мне выдали на 95% одинаковый подробнейший расчёт ответ. Вкратце "Переходить пока рано".
- пишем менеджеру/боссу
I've analyzed our infrastructure costs over the last three months billing and IOPS data, to see if switching to Amazon Aurora I/O-Optimized makes sense. Right now, it's not cost-effective. Our I/O costs an average of $******* monthly (************ I/Os at $**** per million). Moving to I/O-Optimized would increase instance costs by ***%, from $******* to $******* - a $******* jump, which is $415.21 more than our current I/O expenses.
Our IOPS trends show peaks up to *** but no major growth, averaging ~** Write and ~**** Read IOPS hourly in February. Storage usage is growing at *** GB/month, but that doesn't impact the I/O-Optimized cost comparison. AWS suggests I/O-Optimized when I/O costs exceed **% of total
Aurora spend, but ours ($******) are only **% of the $******* total, so we're below that threshold.
I recommend sticking with our standard configuration for now. We should keep monitoring I/O activity -if it exceeds **** I/Os monthly or I/O costs reach **% of our
Aurora spend, we can revisit I/O-Optimized.
Прикладываем все файлы,скрины,расчёты.
- закрываем таску и трекаем время

Всё вышеописанное заняло у меня минут 15, а вот подготовительные работы(чтение про фичу, особенности, лимиты, как считать, написание борды, особенности биллинга и тп) почти половину дня.
* Если не верите ИИ, можете пересчитать вручную🐒

Дополнительные полезные ссылки(а вдруг вы мне не верите):
- анонс фичи
https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-aurora-i-o-optimized/
- обзор менеджер уровня
https://aws.amazon.com/awstv/watch/b9bfc040ac5/
- пример расчётов (там руками считают, без ИИ)
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍3🤔21👏1