#пятница

Ну почему бы и не поучаствовать в этом нескончаемом челлендже

#aws #costoptimization #devops

А иногда вообще ничего из существующих финансовых алертов не помогает.
Нужен глубокий, живой человеческий анализ.

Был случай: проект, всё на AWS, стартап.
Постепенно рос, изменялся, но изначально у всех всюду был root-доступ (а как иначе в стартапе из 4 человек?). Набирались люди, улучшались процессы, разграничивались доступы, всё заносилось в IaC.
В целом стоимость услуг AWS была сравнительно небольшой, от 2к до 5к долларов, и держалась года полтора-два.
Раунд за раундом, компания выросла, трафика и сервиса стало больше, увеличился и счет.
Затем начали оптимизировать затраты: внедрили RI, SP (Reserved Instances, Savings Plans) и другие методы.
Обвешали обычным алертингом и FinOps-инструментами вроде Cost Anomaly Detection.
Каждые 1-3 месяца проводились Cost Review meetings, на которых обсуждались траты, предстоящий рост и многое другое. Каждая, повторюсь, позиция в биллинге детально разбиралась и для каждого участника команды и руководителя была очевидна, понятна и разумна.

Всё вышенаписанное лишь для того, чтобы подчеркнуть, что ничего нестандартного тут не было, всё как у всех.

Каждый месяц счет всё рос и рос. Где-то разумно за Compute - воркеры в EKS, где увеличилось количество реплик.
Где-то за RDS, потому как и размер БД увеличивается, и инстансы примерно раз в полгода-год увеличивали, да бэкапы (snapshots) также увеличивают стоимость хранения.
Где-то CloudFront, потому как количество клиентов и трафика стало больше.

Приходили и письма от Cost Anomaly Detection: "сервис А увеличился на 20% - теперь 21 доллар", "сервис Б увеличился на 47% и теперь 11 долларов".
И такие письма приходили регулярно.
Визуально - всё разумно и понятно:
- увеличивается количество кастомеров
- увеличивается трафик и нагрузка
- немного растет стоимость услуг

Однако пришел момент, когда счет за услуги CloudFront вырос до умопомрачительной отметки в 1000 долларов в месяц.
На очередном Cost meeting поставили задачу проверить корректность настроек, везде ли правильно включено кэширование, заголовки и так далее.
Триггернулись лишь потому, что на старте компании платили порядка 30 баксов, спустя год 150, затем 400 через два года, а тут сразу $1000 - слишком большой скачок.

Задачу поручили мне, и я начал копать.
Признаюсь - я ничего на тот момент не понял.
Ну ALB, CloudFront да API Gateway.
Много ресурсов, разные.
Поверхностно изучил еще раз - да, вроде очевиден рост как клиентов, так и трафика и биллинга.
Отписался "да всё норм", закрываю таску.

Спустя месяц счет стал уже 1250 долларов, и это напрягло всех.
Руководство попросило сделать анализ: как тут можно сэкономить, ведь ожидали рост клиентов x20, а это значит, что потенциально счет будет невероятно огромным.
Требовалось исследование альтернативных архитектурных решений.

Начал я повторно изучать, уже в процессе расписывая куда какой трафик идет, спрашивая разработчиков, смотря DNS, балансировщик, все файлы веб-страницы и многое другое.
Я это изучал лишь чтобы понять, как сейчас что работает, чтобы понять, как и на что мне надо заменить, чтобы снизить косты.

В процессе анализа для переноса архитектуры мне пришел неожиданный вопрос в голову:
а счет за CloudFront это с одного Distribution или с разных?
Начал включать аналитику и овервью.
Определились, что траты лишь с двух Distribution из 25.
Вопреки тому, что все думали изначально, что с 10-15.

Ок, копаю дальше, стало интересно, ведь именно у этих двух Distribution было несколько источников (Origins) и несколько правил поведения (Behaviors).
Мне же надо их на что-то менять, надо копнуть глубже.

#пятница

Мои прогнозы на re:Invent 2025:
- AI
- GenAI
- MCP agents
- Agentic AI
- Generative AI Workflows
- Serverless-VPC-in-a-Container
Никто не знает, зачем, но звучит очень глубоко.
- Zero-ETL-to-Zero-Code
- The Data Lake House Lakehouse Warehouse Mesh Fabric
Просто потому, что Data Mesh уже недостаточно сложно.
- The Multi-Region-Multi-AZ-Multi-Cloud-Multi-Everything-Architecture
Зарезервировано 100% времени работы, но 1000% затрат.
- AI
Ну, а вдруг вы забыли?

#linux

В эпоху активного использования AI, агентов и автокомплитов я стал чаще допускать ошибки.
Чёртовы AI не глядя могут дропнуть нужные файлы: херак раз - и нет важного файла.

С git‑файлами особых опасений нет, но дополнительные вещи вроде .env в репозитории, которые в гитигноре, или в системе типа ~/.kube/config всё ещё хочется сохранить.

Возвращаюсь к основам и просто запрещаю удаление файла:

sudo chattr +i .env

Проверить, что флаг установлен, можно так:

lsattr .env

Если я сам (а не нейронка) когда‑нибудь захочу удалить файл, сначала придётся снять флаг, а уже потом удалять:

sudo chattr -i .env
sudo rm .env

Флаг immutable защищает от:
- перезаписи файла
- случайного удаления
- случайного переименования
- случайного sudo rm -r по директории, где лежит этот файл*

* Будет ошибка типа Operation not permitted на файле, в то время как остальные файлы в директории будут удалены

Если immutable поставить на саму директорию через chattr +i dir, тогда уже нельзя будет ни создавать, ни удалять, ни переименовывать файлы внутри неё - это ещё более жёсткая защита, но это мне пока не надо.

Иногда очень полезно вернуться к базовым инструментам Linux и защитить важные файлы и от нейросетей, и от себя самого, который запускает команды, не глядя, как макака.

#пятница

Ну почему бы и да

#eks #aks #kubernetes

Апгрейд кластера кубернетис.
С чего начинать?

Начать сперва с проверки совместимости.
Время от времени некоторые ресурсы меняют версию API.
- что-то становится deprecated, например PSP
- что-то меняет версию с alpha, вырастая до v1
- что-то несёт с собой breaking changes

У AWS EKS есть собственные механизмы EKS Upgrade Insights/preflight‑checks, которые дают подсказки по deprecated API и аддонам прямо перед апгрейдом.
https://aws.amazon.com/blogs/containers/accelerate-the-testing-and-verification-of-amazon-eks-upgrades-with-upgrade-insights/

В OpenShift есть свои "pre‑update" проверки и рекомендации, но они более завязаны на платформу.
Значительная часть логики проверки касается операторов, etcd, сети и прочих специфичных для OpenShift компонентов.
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/updating_clusters/preparing-to-update-a-cluster

У Azure есть AKS Upgrade Readiness Check. AKS автоматически блокирует апгрейд, если обнаружены deprecated API. Так же проверяет не только deprecated API, но и всякие PDB, квоты, серты, IP адреса в сабнете​ и так далее.
https://learn.microsoft.com/en-us/azure/aks/upgrade-cluster

Это всё облачные куберы и их вендорлок решения.

Для bare-metal кластеров и для клауд куберов есть более универсальные решения:
- консольные утилиты для проверки всех сущностей куба (локально или в CICD):
- - https://github.com/doitintl/kube-no-trouble
- - https://github.com/kubepug/kubepug
- github action для CI/CD
- - https://github.com/FairwindsOps/pluto
- проверки аутдейт/депрекейтед helm чартов (НЕ связана с API/апгрейд, опциональная проверка)
- - https://github.com/FairwindsOps/Nova

Крайне важно понимать, что AKS проверяет deprecated API в течение 12 часов перед апгрейдом, а EKS использует 30-дневное окно, что важно для планирования процесса upgrade. То есть даже если вы исправили deprecated API, ошибка может оставаться в течении указанного времени. Планируйте заранее.

Всё эти проверки необходимо сделать ДО обновления кластера, иначе у вас будут весёлые часы после апгрейда.

#costoptimization #newrelic

И снова Newrelic.
"Алекс, у нас за последний год возрос биллинг за newrelic.
Можно ли как-то это оптимизировать?"

"Ну удалите его к херам" - думаю я.
Но вслух говорю, конечно же - "Да-да, конечно. ща-ща, сейчас гляну чего там, подождите, пожалуйста".

Зашёл в админ панель, а там и правда по делу меня дёрнули - ведь прайс уже $4200+ в месяц

Вернёмся к базе: за что чарджит newrelic?
- лицензии пользователей
https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-type/
- data ingestion
сколько трафика (любого) отправили от аппликешнов - за сколько и платим

Первым делом иду смотреть за что чарджит сейчас, скачиваем билл за последние 6 месяцев.
https://one.newrelic.com/admin-portal/plan-management/billing

Да, всё так и есть, лицензии и трафик.

Обговорил с боссами, урезал 4 из 10 юзеров.
Этот пункт готов.

Ingestion. Из чего ты состоишь?
https://one.newrelic.com/admin-portal/data-ingestion/home?account=
Top usage в данном случае это
- трейсы
- логирование
- ивенты (транзакции)
- кастом ивенты (кастом транзакции)
Всё остальное ничтожно.

Хорошо, понятно, но какие именно приложения какой именно трафик генерят?
Насколько невероятно крутой интерфейс и удобство у самого newrelic для приложений и насколько он убогий для usage вещей. С ходу понять кто именно и за что сложно.

На помощь мне приходит их встроенная в UI SQL консоль.
- топ апп по трейсингу

SELECT bytecountestimate()/10e8 FROM `Span`, `SpanEvent` WHERE instrumentation.provider != 'pixie' FACET appName OR service.name OR entity.name LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp

- топ ивентов

SELECT bytecountestimate()/10e8 FROM `Transaction`, `TransactionError` FACET appName LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp

- топ метрик

SELECT bytecountestimate()/10e8 FROM `Metric` WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie' FACET CASES (WHERE newrelic.source = 'agent' AS 'Metric Time Slices', WHERE newrelic.source != 'agent' OR newrelic.source IS NULL AS 'Dimensional Metrics') SINCE unixtimestamp UNTIL unixtimestamp

Делаю несколько запросов за последние 30/60/90/180 дней сперва по типу трафика.

Промежуточные итоги:
- апп1 пишет много трейсов
- апп2 и апп3 пишут много транзакций
- апп5 пишет много кастом ивентов
и так далее

В целом понятно, иду в документацию и утопаю в миллиарде информации.
Много терминологий, много названий, ничего не понятно, но очевидно одно:

newrelic выезжает на дефолтах

Дефолт значения высокие/включены по умолчанию и надо это дело вырубать.

Дальше точечно прохожу по всем топам, в разных стеках разное решение.
- в php вырубаем в 10 раз меньше семплирование

newrelic.span_events.max_samples_stored       = 200   # was 2000

- в golang, например

NEW_RELIC_SPAN_EVENTS_MAX_SAMPLES_STORED=200  # was 1000 (default)
NEW_RELIC_TRANSACTION_EVENTS_MAX_SAMPLES_STORED=2000  # was 10000 (default)
NEW_RELIC_APPLICATION_LOGGING_FORWARDING_ENABLED=false # was true (default)

+ обновил агента, так как старая версия не умела работать с этими переменными
Для других стеков были другие решения, в заметках не сохранилось.

Что же я сделал? Я уменьшил количество семплов в минуту.

Давайте поясняю ещё раз:
"Каждую минуту каждый POD каждого приложения отправляет условные 10000 ивентов (транзакций). Это количество ивентов нам не нужно, его слишком много и там по сути мусорная для нас дата. Она не нужна, её можно сократить. Если нам покажется, что её нехватает, но можно добавить. Снижение транзакций/трейсов в 5-10 раз дало снижение Ingestion в 5-10 раз.

Из минусов: результат подобной работы виден не сразу, а лишь спустя 5-7 дней, на графиках и в NewRelic UI SQL.

#costoptimization #newrelic

Итого:
- агенты по умолчанию включают довольно много фич (distributed tracing, logs in context и так далее), что увеличивает ingest
- из коробки агенты New Relic настроены довольно агрессивно с точки зрения объёма собираемых данных. Для продакшн всегда имеет смысл пройтись по дефолтам и подкрутить семплинг под свои бюджеты
- 5-20 строчек конфига/переменных в 3 стеках до снижение трат в .в 18 раз (финально, после всех тюнингов) - с $4200 до $230 в месяц на одной лишь инжестии, без учёта стоимости лицензий
- никто из Ops команды даже не заметил разницу, что 2000/10000 семплов в минуту было, что 200/500. Данных достаточно. Думаю можно было бы снизить и до 100 семплов в минуту, но команда побоялась упустить данные при авариях. С другой стороны, даже 100 событий в минуту на проде часто достаточно для детекции проблем в проде.
- траты выросли за последние месяцы, так как и приложений стало больше и количество реплик POD выше стало
- добавили в readme рекомендации проверять чейнджлог при обновлении агента, так как дефолты могут меняться между версиями (и это ещё одна история)
- golang агент самый мерзкий, чтобы убедиться, что переменные/агент сработал, пришлось поменять гошный код, включить debug левел, посмотреть дефолтные значения, добавить новые, убедится, что применилось в нужном месте, снова ревертнуть код для выключения дебаг левела. Иные способы не помогали узнать какой дефолт и помог ли фикс.

В слова защиты newrelic я скажу, что они сами дают советы как чего тюнить, если счета большие, например:
- https://docs.newrelic.com/docs/apm/agents/php-agent/troubleshooting/agent-overhead-reduction-tips/
- https://docs.newrelic.com/docs/infrastructure/infrastructure-troubleshooting/troubleshoot-infrastructure/reduce-infrastructure-agents-cpu-footprint/

Не знаю кто виноват:
- инженеры, что не тюнят сразу дефолт значения
- newrelic, что из коробки впаривает агрессивный Ingestion и включённые по-умолчанию фичи с высокими дефолтами

Скорее всего, это комбинация обоих: инженеры часто не читают доку по дефолтам, а New Relic заинтересована в высоком ingestion.
Но ясно одно: контролировать затраты нужно с первого дня.

#kubernetes #devops

Последнюю неделю на работе игрался с KRO, AWS ACK и CrossPlane.
- https://github.com/crossplane/crossplane
- https://github.com/aws-controllers-k8s/community
- https://github.com/kubernetes-sigs/kro

Ну что я могу сказать.
Мне одновременно и очень понравилось - инструменты хороши.
Это потрясающие инструменты, выводящие инфраструктурную часть и операционную на совершенно иной уровень.
Не плохой, не хороший, он новый. Не буду приводить аналогий, это просто иной уровень для меня.
Да охрененный, если честно, буду честен.
И одновременно не понравилось - самостоятельно, в одиночку, в одно лицо, без помощи AI ассистентов я разобрался бы в лучшем случае через недели 3-4. Возможно бы и через месяц.

Сложность в том, что эти инструменты создают десятки уровней абстракций - от CRD в Kubernetes до специфических API провайдеров (AWS, GCP). Чтобы отладить ошибку, нужно пройти путь от kubectl describe до логов ACK controller, а потом до настоящего события в облаке. Рисуешь сперва диаграммы, зависимости, порядки деплоя - это колоссальная работа.

Вообще прикольно, конечно, один манифест и фигак, у тебя целые регионы, кластера, роли, рут таблицы, натгейтвеи и миллион сущностей в кубернетисах. Миллионы объектов и сущностей на сотнях уровней абстракций.
Круто. Мне понравилось.

Про KRO/ACK/CrossPlane я ещё напишу не одну глубокую техническую заметку/отзыв, а пока лишь общий отзыв - они хороши.

Зачем? Зачем в наше время вы ещё держитесь за свои ноды и эхи?

Вот так незаметно и тихо прошёл год с основания моего авторского телеграм канала. Поздравляю сам себя и всех, кому это интересно читать.