ℹ️ Оптимизация расходов на AWS SQS

Если вы используете AWS SQS с дефолтными настройками и у вас более миллиона сообщений в день, обратите внимание на параметр receive_wait_time_seconds.
По умолчанию его значение равно 0, что означает использование Short Polling.
При таком подходе AWS будет брать с вас плату за каждый API-запрос, даже если очередь пуста.
Что можно сделать:
Установите receive_wait_time_seconds = 20 в вашем Terraform-конфиге, чтобы включить Long Polling.
При этом режиме AWS будет удерживать соединение до 20 секунд в ожидании сообщений, что существенно сократит количество API-вызовов.
Результат:
В моём случае это снизило расходы примерно в 3 раза! Ваша экономия может отличаться в зависимости от паттерна использования очереди и частоты появления сообщений.
⚠️Важно:
Подходит для случаев, когда вам не критична минимальная задержка в получении сообщений.
Если ваш сценарий требует мгновенной обработки - оставьте Short Polling и платите больше.

#AWS #Terraform #CostOptimization

ℹ️Оптимизация расходов на AWS RDS Proxy и CloudWatch

Если у вас есть RDS MySQL с read replica и RDS proxy, то вы можете сильно сэкономить на CloudWatch логах.
Проблема:
- RDS Proxy по умолчанию отправляет ВСЕ логи уровня INFO в CloudWatch
- Это нельзя отключить через консоль или API
- Вы платите за:
1. Каждый входящий лог-ивент (PutLogEvent)
2. Хранение этих логов
- Большинство этих логов - просто информационные, не критичные для мониторинга
Решение:
1. Написать в AWS Support
2. Попросить изменить log level для RDS Proxy с INFO на ERROR
3. Profit!
Результат:
- Количество логов уменьшается в миллионы раз
- В нашем случае счёт за CloudWatch снизился на 170$ в месяц
Бонус-совет:
Даже если вам нужны некоторые логи, можно дополнительно уменьшить retention time в CloudWatch до 1 дня для экономии на хранении.

Да, это может показаться мелочью, но:
- Занимает 5 минут времени
- Требует только написать письмо
- Экономит реальные деньги, в моем случае аж $170 ежемесячно

#AWS #CostOptimization

На выходных впервые пересмотрел всю классическую серию фильмов Звёздные Войны с 1 по 6 эпизод.
Очень понравилось, потрясающе. Как жаль, что я раньше не видел эти фильмы.

Так же понравился Чубакка. Его внешний вид и особенно звуки мне напомнили самого себя, когда в будний день меня внезапно без приглашения и записи в календаре инвайтят на встречу в зум/слак/тимс. Один в один это я.

Random Teams call? Full Chewbacca mood.

Больше стал внедрять оптимизацию по ресурсам.
Понравилась утилита krr от робусты. Хотя саму робусту я, мягко говоря, недолюбливаю.
https://github.com/robusta-dev/krr
Использование простое, например вот так:

>./krr simple --history_duration=120

Оно показывает все рекомендации, как поправить CPU/Memory request/limits.
Исправляешь везде и скедулер куба работает точнее.
Не выделяются лишние ноды или наоборот не ощущается нехватка ресурсов с медленным скейлом нод.
Раз в квартал сделать оптимизации руками и всё ок.
У меня это встроено в скедулед пайплайн, который срабатывает раз в месяц, я прост смотрю отчёт.
В конечном итоге это нужно для оптимизации костов.

#kubernetes #CostOptimization

Комментарии стоит писать так, чтобы любой участник команды понимал что в конфиге, что это за код и почему такие цифры (с)

# Node: 32Gi RAM total (100%)
#
# Memory allocation and thresholds visualization:
#
# Memory (Gi)     % of total
# 32.00 (100%) ┌──────────────────────────────────────────────┐
#              │                                              │
# 30.13 (94.2%)│               Safe working zone              │ ← Allocatable: 30.13Gi (32 - 1 - 0.87)
#              │                 (26.93Gi)                    │
#              │                 (84.2%)                      │
# 20.00 (62.5%)│                                              │
#              │                                              │
#              │                                              │
# 10.00 (31.3%)│                                              │
#              │                                              │
#  3.20 (10.0%)│- - - - - - - - - - - - - - - - - - - - - - │ ← Soft eviction starts (10% of total)
#              │           Soft eviction zone                 │ ← 30s grace period
#  1.00 (3.1%) │━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━│ ← Hard eviction starts
#              │           Hard eviction zone                 │
# 0.00 (0%)    └──────────────────────────────────────────────┘ ← Node is "not ready" and "dead" (memory pressure)
#
# Reserved (total 1.87Gi, 5.8%):
# - system-reserved: 1Gi (3.1%) - OS & system daemons
# - kube-reserved: 893Mi ≈ 0.87Gi (2.7%) - k8s components
#
# Working ranges:
# - 30.13Gi - 3.2Gi:  Safe working zone (26.93Gi, 84.2% usable)
# - 3.2Gi - 1Gi:      Soft eviction zone (2.2Gi, 6.9%)
# - <1Gi (3.1%):      Hard eviction zone (immediate pod killing)

# https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md#description-of-settings
[settings.kubernetes]
api-server = "${endpoint}"
cluster-certificate = "${cluster_auth_base64}"
cluster-name = "${cluster_name}"
pod-pids-limit = 1024
image-gc-high-threshold-percent = 85
image-gc-low-threshold-percent = 80
container-log-max-files = 50
container-log-max-size = "100Mi"

[settings.kubernetes.system-reserved]
cpu = "200m"
ephemeral-storage = "1Gi"
memory = "1Gi"

[settings.kubernetes.kube-reserved]
# memory_to_reserve = max_num_pods * 11 + 255
# memory_to_reserve = 58 * 11 + 255 = 638 + 255 = 893 MiB
memory = "893Mi"

[settings.kernel]
lockdown = "integrity"

[settings.host-containers.admin]
enabled = ${enable_admin_container}

[settings.host-containers.control]
enabled = ${enable_control_container}

[settings.kubernetes.eviction-hard]
"memory.available" = "1Gi"
"nodefs.available" = "20%"
"nodefs.inodesFree" = "5%"
"imagefs.available" = "15%"

[settings.kubernetes.eviction-soft]
"memory.available" = "10%"

[settings.kubernetes.eviction-soft-grace-period]
"memory.available" = "30s"

Тут, конечно же с телефона полная херня, но с ПК клиента все отлично.

#kubernetes

Столкнулся с интересной проблемой в Kubernetes кластере с Bottlerocket AMI и хочу поделиться находкой.

Изначально ситуация выглядела как классическая проблема с памятью:
1. Растет нагрузка на сервис (новые прожорливые поды)
2. Приложения начинают потреблять больше памяти
3. Происходят OOM киллд шторм, сжирается вся память нод.
4. Ноды падают в not ready, сервис деградирует

Первый этап решения был очевидным - настроить kubelet так, чтобы защитить ноды от падения(выше пример).
Внес изменения, и теперь:
1. Растет нагрузка
2. Приложения едят память
3. Происходят OOM шторм
4. Ноды теперь живы, поды умирают по оомкиллед не убивая ноду - поды убивает кублет.

Вроде бы лучше, но проблемы с сервисом все равно есть.
Включил расширенное логирование, собрал данные за несколько дней и обнаружил реальную причину:
1. Растет нагрузка
2. Приложения едят память
3. OOM киллы убивают поды, ноды живы.
4. Автоскейлер поднимает новые ноды (около 15 секунд)
5. НО! Новые ноды не могут сразу принять поды, потому что сетевой драйвер (CNI) еще инициализируется
"NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized"

И вот эта временная яма между "старые поды умерли от ООМкиллд шторма" и "новые ноды еще не готовы из-за долгой инициализации сетевого драйвера" создает провал в работе сервиса. Сраные 11 секунд.

Сейчас исследую два направления решения:
1. Ускорение инициализации сетевого драйвера на новых нодах
2. Упреждающее масштабирование - чтобы новые ноды поднимались заранее, до достижения критической нагрузки

Забавно, как иногда решение одной проблемы просто показывает следующую, более глубокую.
И насколько важно копать глубже очевидных симптомов.

Ниже можно найти окончание истории, проблема была не в этом