Forwarded from Make. Build. Break. Reflect.
Есть база данных AWS RDS(
К базе подключено N клиентов-приложений. Допустим их 10. Все подключены через прокси.
Появилась задача понять "кто из приложений кушает больше всего коннекшнов и отобразить это на графике".
Большее обсервабилити, большая детализация. Больше SRE👏
Однако штатно таких метрик не существует(ну или же я просто не нашёл).
Вариант с лямбдой и
Мне показался туповатым.
❕Я не знаю как это делают правильные инженеры, опишу свой вариант решения, который сделал в выходные.
- создаем в базе данных 10 новых пользователей с нужными правами
- добавляем креды новых юзеров в secret manager
- добавляем аксесс этих юзеров на RDS proxy кредами из secret manager
- создаем новые rds proxy endpoint для каждого из приложений/юзера
- переключаем каждое из приложение на свой собственный RDS proxy endpoint через переменные окружения
Отлично, теперь у нас каждый микросервис подключен к отдельному RDS proxy endpoint с отдельными кредами.
Теперь идём в AWS CloudWatch в Dashboards.
У нас есть метрики и мы их можем смело раскинуть по каждому из RDS proxy Endpoint
Смело строим графики и видим все интересующие параметры по каждому пользователю/приложению.
Итог:
На выходе у нас дашборд, который показывает массу деталей по конкретно каждому юзеру/приложению, что очень важно понять например кто больше делает нагрузки на БД.
Дополнительно:
- перед реализацией не забывайте про ограничения:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html
- всё тоже самое можно сделать создав несколько RDS proxy для каждого приложения, но и платить придётся сильно больше
- есть вы подключили в своей Grafana datasource=CloudWatch, то он пока не умеет выводить метрики дименшна по endpoint, только по отдельным RDS proxy. Пока красивые графики только в CloudWatch Dashboard.
#AWS #observability #cloudwatch
8.0.mysql_aurora.3.08.0) + RDS Proxy.К базе подключено N клиентов-приложений. Допустим их 10. Все подключены через прокси.
Появилась задача понять "кто из приложений кушает больше всего коннекшнов и отобразить это на графике".
Большее обсервабилити, большая детализация. Больше SRE
Однако штатно таких метрик не существует(ну или же я просто не нашёл).
Вариант с лямбдой и
SELECT usename, count(*)
FROM pg_stat_activity
GROUP BY usename;
Мне показался туповатым.
❕Я не знаю как это делают правильные инженеры, опишу свой вариант решения, который сделал в выходные.
- создаем в базе данных 10 новых пользователей с нужными правами
- добавляем креды новых юзеров в secret manager
- добавляем аксесс этих юзеров на RDS proxy кредами из secret manager
resource "aws_db_proxy" "this" {
...
auth {
auth_scheme = "SECRETS"
iam_auth = "DISABLED"
client_password_auth_type = "MYSQL_NATIVE_PASSWORD"
secret_arn = aws_secretsmanager_secret.user1_credentials.arn
}
auth {
auth_scheme = "SECRETS"
iam_auth = "DISABLED"
client_password_auth_type = "MYSQL_NATIVE_PASSWORD"
secret_arn = aws_secretsmanager_secret.user2_credentials.arn
}
...
}- создаем новые rds proxy endpoint для каждого из приложений/юзера
resource "aws_db_proxy_endpoint" "this" {
...
db_proxy_endpoint_name = "${var.project}-${var.environment}-user1"
target_role = "READ_WRITE"
...
}resource "aws_db_proxy_endpoint" "this" {
...
db_proxy_endpoint_name = "${var.project}-${var.environment}-user2"
target_role = "READ_WRITE"
...
}- переключаем каждое из приложение на свой собственный RDS proxy endpoint через переменные окружения
Отлично, теперь у нас каждый микросервис подключен к отдельному RDS proxy endpoint с отдельными кредами.
Теперь идём в AWS CloudWatch в Dashboards.
У нас есть метрики и мы их можем смело раскинуть по каждому из RDS proxy Endpoint
- ClientConnections
- DatabaseConnections
- AvailableConnectionPercent
- ConnectionAttempts
- QueryRequests
- QueryRequestsPerSec
Смело строим графики и видим все интересующие параметры по каждому пользователю/приложению.
Итог:
На выходе у нас дашборд, который показывает массу деталей по конкретно каждому юзеру/приложению, что очень важно понять например кто больше делает нагрузки на БД.
Дополнительно:
- перед реализацией не забывайте про ограничения:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html
- всё тоже самое можно сделать создав несколько RDS proxy для каждого приложения, но и платить придётся сильно больше
- есть вы подключили в своей Grafana datasource=CloudWatch, то он пока не умеет выводить метрики дименшна по endpoint, только по отдельным RDS proxy. Пока красивые графики только в CloudWatch Dashboard.
#AWS #observability #cloudwatch
Please open Telegram to view this post
VIEW IN TELEGRAM
👍26❤2
Forwarded from Make. Build. Break. Reflect.
"хей Алекс, у нас закончилась демо версия Backup radar, теперь они хотят денег. Сможешь сделать аналог на AWS? Но денег и часов на задачу на один час. Нам просто надо ежедневно получать уведомления, что у нас успешно создаются бекапы. Сами снепшоты/бекапы создаются".
Ну один час, так один час.
1) Используем популярный модуль ИЛИ пилим те же ресурсы в чистом терраформе.
Выбор каждого.
- пример с модулем
- пример без модуля будет нечто типа того (в попытке обезличить мог чушь написать, но на то он и пример).
https://gist.github.com/kruchkov-alexandr/e9139d60658175a5a91c186bd7e0f6b3
Ок теперь у нас есть лямбда, роли, пермишны, SNS топик.
При отправке мессаджа в SNS лямбда отправляет сообщение с метаданными в Slack.
2) Теперь нам надо научиться подписываться на события:
Если нам надо ещё и по Redis, то в существующих ресурсах добавить
Ок, делаем вручную снепшот, видим мессаджи в Slack - задача выполнена.
4) Так, сообщение от Redis(ElastiCache) короткое и удобно читать в слаке, а вот через лямбду некрасивое и много лишней метаданных, давайте порежем лямбду...
oh wait, а час и закончился, сдаём как есть🤣 .
Кому хочется красоты и лаконичности, тот знает прайс.
5) Не забываем напомнить заказчику не мьютить сразу новый слак канал😁
#aws
Ну один час, так один час.
EventBridge в чистом виде неудобен, я дольше буду читать про типы сорсов и полей, занимаясь фильтрацией.1) Используем популярный модуль ИЛИ пилим те же ресурсы в чистом терраформе.
Выбор каждого.
- пример с модулем
module "aws-backup-notifications" {
source = "terraform-aws-modules/notify-slack/aws"
version = "6.5.1"
sns_topic_name = "aws-backup-notifications"
recreate_missing_package = false
slack_webhook_url = data.sops_file.sops_file.data.slack-webhook-aws-backup-notifications.url"]
slack_channel = "aws-backup-daily-notifications"
lambda_function_name = "aws-backup-notifications"
slack_username = "AWS Health Event"
}- пример без модуля будет нечто типа того (в попытке обезличить мог чушь написать, но на то он и пример).
https://gist.github.com/kruchkov-alexandr/e9139d60658175a5a91c186bd7e0f6b3
Ок теперь у нас есть лямбда, роли, пермишны, SNS топик.
При отправке мессаджа в SNS лямбда отправляет сообщение с метаданными в Slack.
2) Теперь нам надо научиться подписываться на события:
# RDS and DocumentDB cluster snapshot events
resource "aws_db_event_subscription" "db_snapshot_events" {
name = "aws-backup-notifications"
sns_topic = "arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-backup-notifications"
source_type = "db-cluster-snapshot"
event_categories = []
source_ids = []
enabled = true
}
Если нам надо ещё и по Redis, то в существующих ресурсах добавить
resource "aws_elasticache_replication_group" "this" {
...
notification_topic_arn = "arn:aws:sns:us-east-1:${data.aws_caller_identity.this.account_id}:aws-backup-notifications"
...
}Ок, делаем вручную снепшот, видим мессаджи в Slack - задача выполнена.
4) Так, сообщение от Redis(ElastiCache) короткое и удобно читать в слаке, а вот через лямбду некрасивое и много лишней метаданных, давайте порежем лямбду...
oh wait, а час и закончился, сдаём как есть
Кому хочется красоты и лаконичности, тот знает прайс.
5) Не забываем напомнить заказчику не мьютить сразу новый слак канал
#aws-backup-daily-notifications #aws
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤3
Forwarded from Make. Build. Break. Reflect.
* для этой задачи для этих условий
Плюсы с модулем:
- 18 строчек кода
Минусы с модулем:
- мессадж гигантский, занимает половину экрана
Плюсы без модуля:
- можно сделать лямбду с минимальным мессаджем в слак
Минусы без модуля:
- ну в час не успеть
- много кода, либо пилить свой модуль
Не забывайте, что тут данная подписка на снепшоты кластера, на снепшоты инстансов это не распространяется.
Зачем замазывал event id я не знаю 🤣
#aws
Плюсы с модулем:
- 18 строчек кода
Минусы с модулем:
- мессадж гигантский, занимает половину экрана
Плюсы без модуля:
- можно сделать лямбду с минимальным мессаджем в слак
Минусы без модуля:
- ну в час не успеть
- много кода, либо пилить свой модуль
Не забывайте, что тут данная подписка на снепшоты кластера, на снепшоты инстансов это не распространяется.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
Forwarded from Make. Build. Break. Reflect.
#aws #eks #sqs #CostOptimization
Материал уровня middle.
Снова про экономию.
У нас есть AWS SQS.
В него прилетает миллион вебхуков с полезным и важным payload.
Бывают пики, бывают нет.
У нас есть AWS EKS и приложение в POD-e, который вычитывает SQS, процессит и всё ок.
Нам надо настроить масштабирование не за счёт CPU/memory usage, а за счёт количества сообщений.
В этом нам помогает KEDA. Опустим этапы установки/настройки/прав и авторизации.
У нас есть готовый манифест
Всё работает, всё скейлится, всё ок.
В HPA некрасиво выглядят цифры, хочется видеть точное количество мессаджем. Добавляем
И теперь в
Этого нам мало, нужна точная подстройка.
Читаем дальше доку, у нас есть адвансед настройки.
Теперь у нас всё динамически скейлится, прописаны все триггеры, трешхолды.
Всё отлично и бизнес ликует(не вру, прям ликует, сильно помогло).
Однако меня, как рьяного и верного пса девопс церкви, напрягает, что в период высокой нагрузки всё упирается в максимум реплик. Да, можно поставить не 50, а 100, но я думаю, что настройка неверная.
Углубляемся дальше в доку(вру, я ничо не понял и просто спросил ребят-гуру-AWS-технологий в телеге) и вспоминаем про визибл/анвизибл настройки у sqs.
https://keda.sh/docs/2.14/scalers/aws-sqs/
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
Окончательно пилим манифест.
Отлично. Теперь самая точная и потрясающая настройка.
Материал уровня middle.
Снова про экономию.
У нас есть AWS SQS.
В него прилетает миллион вебхуков с полезным и важным payload.
Бывают пики, бывают нет.
У нас есть AWS EKS и приложение в POD-e, который вычитывает SQS, процессит и всё ок.
Нам надо настроить масштабирование не за счёт CPU/memory usage, а за счёт количества сообщений.
В этом нам помогает KEDA. Опустим этапы установки/настройки/прав и авторизации.
У нас есть готовый манифест
scaledobject.---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
cooldownPeriod: 300
maxReplicaCount: 50
minReplicaCount: 2
pollingInterval: 30
scaleTargetRef:
name: application
triggers:
- authenticationRef:
name: keda-aws-credentials
metadata:
awsRegion: us-east-1
identityOwner: operator
queueLength: "500"
queueURL: https://sqs.us-east-1.amazonaws.com/123456789/sqsname
type: aws-sqs-queue
Всё работает, всё скейлится, всё ок.
В HPA некрасиво выглядят цифры, хочется видеть точное количество мессаджем. Добавляем
metricType---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
...
metricType: Value
И теперь в
kubectl get hpa blablabla видим точное количество мессаджей в TARGETS(а не системы счисления инопланетян).Этого нам мало, нужна точная подстройка.
Читаем дальше доку, у нас есть адвансед настройки.
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
advanced:
horizontalPodAutoscalerConfig:
behavior:
scaleDown:
policies:
- periodSeconds: 15
type: Pods
value: 1
stabilizationWindowSeconds: 300
scaleUp:
policies:
- periodSeconds: 15
type: Pods
value: 1
selectPolicy: Max
stabilizationWindowSeconds: 60
... (остальное так же)
Теперь у нас всё динамически скейлится, прописаны все триггеры, трешхолды.
Всё отлично и бизнес ликует(не вру, прям ликует, сильно помогло).
Однако меня, как рьяного и верного пса девопс церкви, напрягает, что в период высокой нагрузки всё упирается в максимум реплик. Да, можно поставить не 50, а 100, но я думаю, что настройка неверная.
Углубляемся дальше в доку(вру, я ничо не понял и просто спросил ребят-гуру-AWS-технологий в телеге) и вспоминаем про визибл/анвизибл настройки у sqs.
https://keda.sh/docs/2.14/scalers/aws-sqs/
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
Окончательно пилим манифест.
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
...
spec:
advanced:
...(тут тоже самое)
metadata:
...
scaleOnInFlight: "false" << - - вот это вот важное нам
...
Отлично. Теперь самая точная и потрясающая настройка.
👍14
Forwarded from Make. Build. Break. Reflect.
#aws #eks #sqs #CostOptimization
Благодаря точной настройке мы неслабо экономим:
- во время нагрузки мы не скейлим так много реплик
- нет большого лишнего скейла реплик - нет и скейла нод кластера AWS EKS
- нет скейла нод - платим серьёзно меньше
Всего один параметр и в разы снижаем нагрузку и косты.
❕Прежде чем делать подобное, уточните у девелоперов и бизнеса - подойдёт ли это вам и продукту.
Не все процессинги можно переключить только на инфлайт режим.
Полный пример манифеста(код в телеге неудобно читать).
https://gist.github.com/kruchkov-alexandr/e6328137107e49c6a5e7c05c40851680
scaleOnInFlight - Indication of whether or not to include in-flight messages when calculating the number of SQS messages. (default: true, Optional)Благодаря точной настройке мы неслабо экономим:
- во время нагрузки мы не скейлим так много реплик
- нет большого лишнего скейла реплик - нет и скейла нод кластера AWS EKS
- нет скейла нод - платим серьёзно меньше
Всего один параметр и в разы снижаем нагрузку и косты.
❕Прежде чем делать подобное, уточните у девелоперов и бизнеса - подойдёт ли это вам и продукту.
Не все процессинги можно переключить только на инфлайт режим.
Полный пример манифеста(код в телеге неудобно читать).
https://gist.github.com/kruchkov-alexandr/e6328137107e49c6a5e7c05c40851680
👍14🔥1
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
Forwarded from Make. Build. Break. Reflect.
#aws #rds
Короткий материал на уровне senior+
Нырни на самое дно. Без страховки.
Иногда, когда проект достиг своего максимума на данный момент, приходится оптимизировать уже не софт и не пайплайны, а саму инфраструктуру.
Например параметры движка или базу.
Так и вышло в этот раз.
Традиционные параметры типа CPU/memory usage, connections, memory usage, latency, IOPS, lags, cache, CRUD throughput, slow logs и прочее мы научились мониторить и алёртить, что заставило нас оптимизировать запросы к бд и серьёзно снизило нагрузку.
Совсем недавно мы нырнули глубже и поменяли пару параметров в ущерб потери 1 секунды данных в случае аутейджа со стороны Амазон.
Данный проект не использует критически важные операции для транзакций типа финансовых операций, так что мы имеем право это включить. Если у вас финансовые операции или любые критичные операции вам НЕЛЬЗЯ это включать. Нельзя и запомните это.
Значение 2 означает, что журнал транзакций (redo log) записывается в буфер операционной системы при каждой фиксации (commit), но сброс на диск происходит только раз в секунду
- Улучшает производительность, так как уменьшает операции ввода-вывода диска
- Снижает надежность: возможна потеря транзакций последней секунды при сбое сервера/ОС
- Компромисс между производительностью (выше) и надежностью (ниже) по сравнению со значением 1
Значение 1 означает, что система разрешает возможную потерю данных для увеличения производительности
- Значительно ускоряет операции фиксации транзакций
- Снижает гарантии сохранности данных
- Может привести к потере транзакций при сбоях
Результат дал о себе знать почти сразу, но нам явно придётся ещё несколько раз нырять для более точного тюнинга. Будем наблюдать и изменять под себя.
DevOps это не всегда общение, ямлоделие, пайплайны и кубер.
Иногда это тюнинг БД, когда все остальные элементы уже исчерпаны или нет на это бюджета(выше тип инстанса, gravitron v4, больше read реплик, RDS proxy, queries tuning etc).
Ну и код для примера:
Короткий материал на уровне senior+
Нырни на самое дно. Без страховки.
Иногда, когда проект достиг своего максимума на данный момент, приходится оптимизировать уже не софт и не пайплайны, а саму инфраструктуру.
Например параметры движка или базу.
Так и вышло в этот раз.
Традиционные параметры типа CPU/memory usage, connections, memory usage, latency, IOPS, lags, cache, CRUD throughput, slow logs и прочее мы научились мониторить и алёртить, что заставило нас оптимизировать запросы к бд и серьёзно снизило нагрузку.
Совсем недавно мы нырнули глубже и поменяли пару параметров в ущерб потери 1 секунды данных в случае аутейджа со стороны Амазон.
Данный проект не использует критически важные операции для транзакций типа финансовых операций, так что мы имеем право это включить. Если у вас финансовые операции или любые критичные операции вам НЕЛЬЗЯ это включать. Нельзя и запомните это.
innodb_flush_log_at_trx_commitЗначение 2 означает, что журнал транзакций (redo log) записывается в буфер операционной системы при каждой фиксации (commit), но сброс на диск происходит только раз в секунду
- Улучшает производительность, так как уменьшает операции ввода-вывода диска
- Снижает надежность: возможна потеря транзакций последней секунды при сбое сервера/ОС
- Компромисс между производительностью (выше) и надежностью (ниже) по сравнению со значением 1
innodb_trx_commit_allow_data_lossЗначение 1 означает, что система разрешает возможную потерю данных для увеличения производительности
- Значительно ускоряет операции фиксации транзакций
- Снижает гарантии сохранности данных
- Может привести к потере транзакций при сбоях
Результат дал о себе знать почти сразу, но нам явно придётся ещё несколько раз нырять для более точного тюнинга. Будем наблюдать и изменять под себя.
DevOps это не всегда общение, ямлоделие, пайплайны и кубер.
Иногда это тюнинг БД, когда все остальные элементы уже исчерпаны или нет на это бюджета(выше тип инстанса, gravitron v4, больше read реплик, RDS proxy, queries tuning etc).
Ну и код для примера:
resource "aws_rds_cluster_parameter_group" "this" {
...
parameter {
apply_method = "immediate"
name = "innodb_flush_log_at_trx_commit"
value = "2"
}
parameter {
apply_method = "immediate"
name = "innodb_trx_commit_allow_data_loss"
value = "1"
}
}🔥20👍4❤3
Новый будущий AWS Region — Чили:
https://aws.amazon.com/blogs/aws/coming-soon-aws-south-america-chile-region/
Регион планируется к открытию в конце 2026-го года.
На момент официального анонса AWS строит следующие новые регионы:
▫️ Германия (AWS European Sovereign Cloud)
▫️ Новая Зеландия (обещали в 2024-м)
▫️ Саудовская Аравия (в 2026-м)
▫️ Тайвань (обещали в начале 2025-го)
▫️ Чили
#AWS_Regions
https://aws.amazon.com/blogs/aws/coming-soon-aws-south-america-chile-region/
Регион планируется к открытию в конце 2026-го года.
На момент официального анонса AWS строит следующие новые регионы:
▫️ Германия (AWS European Sovereign Cloud)
▫️ Новая Зеландия (обещали в 2024-м)
▫️ Саудовская Аравия (в 2026-м)
▫️ Тайвань (обещали в начале 2025-го)
▫️ Чили
#AWS_Regions
👍15🔥4❤2
Новый AWS Region — Тайвань: 🎉
https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-taipei-region/
Идентификатор
✅ Итого на теперь всего — 37 регионов.
#AWS_Regions
https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-taipei-region/
Идентификатор
ap-east-2, имеет 3 AZ.✅ Итого на теперь всего — 37 регионов.
#AWS_Regions
Amazon
Now open – AWS Asia Pacific (Taipei) Region | Amazon Web Services
Today, Amazon Web Services (AWS) announced that AWS Asia Pacific (Taipei) Region is generally available with three Availability Zones and Region code ap-east-2. The new Region brings AWS infrastructure and services closer to customers in Taiwan. Skyline of…
🔥19❤7😁1👌1
Forwarded from Make. Build. Break. Reflect.
#aws #tampermonkey
Мне очень нравятся shortcuts сервисов AWS.
Однако очень бесит, что они стали длинные и мне не очень удобно "листать" вправо/влево в избранном или вводить в строке поиска.
Хочется короткий текст для линков для быстрого перемещения.
Мог поправить через динамику, но у AWS очень строгий CSP.
Давайте попробуем фиксануть без CSP.
Я уже не в первый писал про плагин для браузера
- ставим, если ещё нет https://www.tampermonkey.net/
- добавляем и включаем новый скрипт
- код крадём у меня и кастомизируйте под себя https://gist.github.com/kruchkov-alexandr/525a5166b7a55e2982b1015ba77a3456 (строчки 12-47)
- сохраняем скрипт
- обновляем страницу с AWS console
- радуемся мелким приятностям (скрин)
Переименование только в шапке и только на https://*.console.aws.amazon.com/*.
Всё остальное это не аффектит.
Мне очень нравятся shortcuts сервисов AWS.
Однако очень бесит, что они стали длинные и мне не очень удобно "листать" вправо/влево в избранном или вводить в строке поиска.
Хочется короткий текст для линков для быстрого перемещения.
Мог поправить через динамику, но у AWS очень строгий CSP.
Давайте попробуем фиксануть без CSP.
Я уже не в первый писал про плагин для браузера
tampermonkey.- ставим, если ещё нет https://www.tampermonkey.net/
- добавляем и включаем новый скрипт
- код крадём у меня и кастомизируйте под себя https://gist.github.com/kruchkov-alexandr/525a5166b7a55e2982b1015ba77a3456 (строчки 12-47)
- сохраняем скрипт
- обновляем страницу с AWS console
- радуемся мелким приятностям (скрин)
Переименование только в шапке и только на https://*.console.aws.amazon.com/*.
Всё остальное это не аффектит.
👍15❤5👎2🔥2
AWS Notes
AWS-EU — новая будущая отдельная часть AWS European Sovereign Cloud и новый будущий AWS-EU регион в Германии: https://aws.amazon.com/blogs/aws/in-the-works-aws-european-sovereign-cloud/ AWS-EU будет физически располагаться только на территории Евросоюза…
AWS European Sovereign Cloud
https://aws.eu/
Европейский AWS будет иметь свой отдельный IAM, Route 53, CloudFront и другие привычно глобальные ресурсы, которые обычно живут в единственном регионе
По реализации повторит вариант китайского AWS и AWS GovCloud.
Пока всё ещё в планах сдать первый регион в Германии до конца 2025 года.
#AWS_Regions #AWS_EU_Regions
https://aws.eu/
Европейский AWS будет иметь свой отдельный IAM, Route 53, CloudFront и другие привычно глобальные ресурсы, которые обычно живут в единственном регионе
N.Virginia.По реализации повторит вариант китайского AWS и AWS GovCloud.
Пока всё ещё в планах сдать первый регион в Германии до конца 2025 года.
#AWS_Regions #AWS_EU_Regions
Amazon
AWS GovCloud (US) - Amazon Web Services
Amazon's cloud regions designed to host sensitive data, regulated workloads, and address the most stringent U.S. government security and compliance requirements. AWS GovCloud (US) is available to vetted government customers and organizations in government…
🔥17😁2
Новый AWS Region — Новая Зеландия: 🎉
https://aws.amazon.com/pt/blogs/aws/now-open-aws-asia-pacific-new-zealand-region/
Идентификатор
✅ Итого на теперь всего — 38 регионов.
#AWS_Regions
https://aws.amazon.com/pt/blogs/aws/now-open-aws-asia-pacific-new-zealand-region/
Идентификатор
ap-southeast-6, имеет 3 AZ.✅ Итого на теперь всего — 38 регионов.
#AWS_Regions
Amazon
Now Open — AWS Asia Pacific (New Zealand) Region | Amazon Web Services
AWS has launched its first New Zealand Region with three Availability Zones, marking its 16th Region in Asia Pacific and enabling local data residency for New Zealand organizations.
🔥22😱3🐳3❤1
Начиная с версии AWS CLI v2.30.3 можно генерить/обновлять креды для IAM юзеров с MFA без сторонних утилит с помощью команды:
aws configure mfa-login
Для удобства лучше сразу добавить имя генерируемого профиля с помощью
#
#
p.s. IAM юзеры зло — используйте SSO (IAM Identity Center).
#aws_cli
aws configure mfa-login
Для удобства лучше сразу добавить имя генерируемого профиля с помощью
--update-profile , иначе сгенерит автоматически, а также --duration-seconds , максимум на 36 часов и ARN устройства --serial-number, чтобы не вводить отдельно:#
aws --profile=aws-notes-s3-user configure mfa-login --update-profile=mfa-aws-notes-s3-user --duration-seconds=129600 --serial-number=arn:aws:iam::984475386489:mfa/My-iPhoneMFA token code: 969969
Temporary credentials written to profile 'mfa-aws-notes-s3-user'
Credentials will expire at 2025-09-18T19:50:40+00:00
To use these credentials, specify --profile mfa-aws-notes-s3-user when running AWS CLI commands
#
aws --profile mfa-aws-notes-s3-user s3 ls2018-11-18 16:17:32 aws-notes-test
p.s. IAM юзеры зло — используйте SSO (IAM Identity Center).
#aws_cli
GitHub
aws-cli/CHANGELOG.rst at v2 · aws/aws-cli
Universal Command Line Interface for Amazon Web Services - aws/aws-cli
👍14💯2
Roman Siewko
AWS European Sovereign Cloud https://aws.eu/ Европейский AWS будет иметь свой отдельный IAM, Route 53, CloudFront и другие привычно глобальные ресурсы, которые обычно живут в единственном регионе N.Virginia. По реализации повторит вариант китайского AWS…
Вышел официальный документ, описывающий AWS European Sovereign Cloud:
https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/introduction.html
Значит можно предположить, что откроют ещё до re:Invent 2025.
#AWS_EU_Regions
https://docs.aws.amazon.com/whitepapers/latest/overview-aws-european-sovereign-cloud/introduction.html
Значит можно предположить, что откроют ещё до re:Invent 2025.
#AWS_EU_Regions
Amazon
Introduction - Overview of the AWS European Sovereign Cloud
In November 2022, AWS introduced the AWS Digital Sovereignty Pledge, our commitment to offering all AWS customers the most advanced set of sovereignty controls and features available in the cloud. The AWS European Sovereign Cloud is a direct result of that…
🔥3👏1
Поздравляем Виктора Ведмича с новой должностью! 🎉
Теперь он ,больше не Developer Advocate, аDeveloper Prosecutor Senior Solutions Architect (AWS).
Теперь он ,больше не Developer Advocate, а
Linkedin
#dayone #aws #solutionsarchitect #cloud #kubernetes #generativeai #awscommunity | Viktor Vedmich | 246 comments
I’m happy to share that I’m starting a new position as Senior Solutions Architect at Amazon Web Services (AWS)! Day One (again). New role. New chapter.
Today I’m starting as a Senior Solutions Architect at AWS.
For the past four years I was building and…
Today I’m starting as a Senior Solutions Architect at AWS.
For the past four years I was building and…
👍46🔥24🍾8❤5💩5🎉3🦄3😁2
Вы хотите как было 20 октября 2025-го?
Нет?
Тогда срочно мигрируйте на AWS European Sovereign Cloud — полностью независимый от остального AWS, новый
#реклама #AWS_EU_Regions
Нет?
Тогда срочно мигрируйте на AWS European Sovereign Cloud — полностью независимый от остального AWS, новый
eusc регион!#реклама #AWS_EU_Regions
🤣45😁15🤡5❤3