— А давайте придумаем новое название для Aurora Serverless v2?
— А давайте!
🆕 Aurora DSQL = multi-region Aurora Serverless v2
https://aws.amazon.com/blogs/database/introducing-amazon-aurora-dsql/
#Aurora
— А давайте!
🆕 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
Главным событием 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
DataChef's Blog
Aurora DSQL - A NEW boring(?) AWS Serverless Postgres compatible database
Aurora DSQL is a serverless, distributed database with PostgreSQL compatibility. Serverless and relational databases don't usually mix, but AWS has modernized this traditional classic car(PostgresSQL), with a brand-new interior powered by a Formula 1...
👍15❤2🔥2😱2
Forwarded from Make. Build. Break. Reflect.
#aws #aurora #terraform #finops
Материал уровня senior
Мы умеем определять тип инстанса - по нагрузке на CPU/Memory и другим факторам.
Но насколько эффективно мы выбрали
Эффективно ли это спустя год или два?
А никто не знает, давайте разбираться.
- сперва пилим Dashboard к нашему существующему кластеру
https://gist.github.com/kruchkov-alexandr/d9335d7927e58d06557b994dc9f194de
- применяем, видим панель в CloudWatch
Сверху у нас панель чтения/записи хранилища, снизу размер базы данных (+снепшоты?).
Разделение нужно из-за разницы масштабов и удобства экспорта.
- выбираем период три месяца и кликаем на трех точках у обоих панелей и выбираем
- заходим в 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/
Материал уровня 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🤔2❤1👏1
Миграция 4 миллионов баз на 3000 RDS в 13 регионах на Aurora:
https://www.atlassian.com/blog/atlassian-engineering/migrating-jira-database-platform-to-aws-aurora
#RDS #Aurora
https://www.atlassian.com/blog/atlassian-engineering/migrating-jira-database-platform-to-aws-aurora
#RDS #Aurora
Work Life by Atlassian
Migrating the Jira Database Platform to AWS Aurora
Explore how Atlassian successfully migrated four million Jira databases to AWS Aurora, overcoming unique technical and operational challenges at massive scale. Learn how the team balanced reliability, performance, and ambitious cost-saving goals—while minimizing…
🔥15👍9❤1😱1