Перетащил на второй гравитрон пару старых кластеров.
Результат пока выглядит ок.
Предыдущие дни график был практически идентичен, а тут, при смене типа инстанса, словно и нагрузка на ЦПУ стала ниже.
Посмотрим как дальше будет это работать.
Экономия ~$73 доллара в месяц за один инстанс(в кластере их несколько).

#AWS #CostOptimization

Самая удивительная особенность, которая обнаружилась после перехода RDS(8.0.mysql_aurora.3.08.0) на Gravitron v2, это способность на высокий утилизации CPU не снижать эффективность/производительность.
А я не знаю как это точнее назвать, пусть будет слово эффективность.
Давайте к примерам.

Когда был db.r5.2xlarge, при CPU usage 85-100% длительностью больше 10-15 минут начиналась небольшая, но деградация работы с базой данных.
Из замеченного мной:
- небольшое отставание лага у read реплик
- timeout со стороны приложения к бд(для новых коннекшнов)
- slow query (честно говоря они появлялись примерно после 22-24 минут непрерывного CPU usage 85-100%)
- очереди запросов (самое больное по бизнес аппликейшн, почти везде real-time)
- binary log писался с небольшим лагом(используется для Debezium+Kafka для реалтайма)

Когда переключили на db.r6g.2xlarge при ровно таких же жёстких нагрузках:
- регулярные миграции
- по расписанию какие-то профилактические работы
- онбординг новых очень крупных клиентов (там прям DP-MySQL series в этот момент)
- запуск snowflake
- запуск retool,
база свободно выдерживает 85-100% в течении длительного времени 15-30 минут без снижения эффективности.
Никаких диких таймаутов, никаких слоулогов, даже репликация проходит без лагов.

Какая-то удивительная магия для меня.
Заставляет задуматься и даже скорректировать алёрты на такое поведение.
И да, я не знаю причина тому смена c5->r6 или же невероятная магия ARM у Gravitron.

* К сожалению графики Grafana, графики и логи у NewRelic в качестве доказательств не могу предоставить:
там если замазать, то будет совсем непонятно, а без замазки полный NDA, а потому без картиночек.
Trust me, Neo.

#AWS #CostOptimization

#aws #eks #sqs #CostOptimization
Материал уровня 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"   << - - вот это вот важное нам
...

Отлично. Теперь самая точная и потрясающая настройка.