Введение

В моей статье Amazon DevOps Guru для бессерверных приложений. Часть 10. Обнаружение аномалий в Aurora Serverless v2 мы узнали, что DevOps Guru смог успешно обнаружить аномалии с помощью базы данных Aurora (Serverless v2) PostgreSQL в случае функции Lambda с управлением Java 21. среда выполнения была подключена к нему через JDBC. Мы масштабировали нашу базу данных всего с 0,5 до 1 ACU и создали очень высокую нагрузку на базу данных, вызывая функцию Lambda для извлечения продукта по идентификатору несколько сотен раз одновременно в течение нескольких минут. Мы увидели, что DevOps Guru правильно указал на возросшую сумму подключений к базе данных и постоянно высокую нагрузку на базу данных (ЦП). В этой статье я хотел бы выяснить, обнаружит ли DevOps Guru аномалию, проведя тот же эксперимент, но используя Data API для Aurora Serverless v2 с AWS SDK для Java вместо JDBC.

Обнаружение аномалий в Aurora Serverless v2 с помощью Data API

Давайте рассмотрим наш пример приложения и воспользуемся шаблоном SAM для создания инфраструктуры и развертывания приложения, описанного на следующем рисунке:

Приложение создает продукты, хранящиеся в базе данных PostgreSQL Aurora Serverless v2, и извлекает их по идентификатору с помощью Data API. Соответствующая функция Lambda, которую мы будем использовать для получения продукта по его идентификатору, — это GetProductByIdViaAuroraServerlessV2DataApi, а ее реализация обработчика — GetProductByIdViaAuroraServerlessV2DataApiHandler.

Как и в предыдущей статье, мы используем инструмент «hey» для проведения такого стресс-теста

hey -z 15m -c 300 -H "X-API-Key: XXXa6XXXX" https://XXX.execute-api.eu-central-1.amazonaws.com/prod/productsWithDataApi/1   

В этом примере мы вызываем конечную точку шлюза API с 300 одновременными контейнерами на 15 минут. За конечной точкой prod/productsWithoutDataApi будет вызвана лямбда-функция GetProductByIdViaAuroraServerlessV2WithoutDataApi, которая получит продукт по идентификатору 1 из базы данных PostgreSQL Aurora Serverless v2.

Мы настроили в нашем [шаблоне SAM]((https://github.com/Vadym79/AWSLambdaJavaAuroraServerlessV2DataApi/blob/master/template.yaml) кластер базы данных Aurora для масштабирования от минимальной емкости 0,5 до максимальной емкости 1 ACU (что составляет очень маленький размер базы данных) в случае повышенной нагрузки в целях экономии.

  AuroraServerlessV2Cluster:
    Type: 'AWS::RDS::DBCluster'
...
      ServerlessV2ScalingConfiguration:
        MinCapacity: 0.5
        MaxCapacity: 1

База данных Aurora (Serverless v2) управляет максимальным количеством доступных подключений к базе данных пропорционально размеру базы данных (в нашем случае настройка ACU), а также с помощью Data API для Aurora Serverless v2 (что является огромным отличием от версии 1, которая станет поддержка прекращена в конце 2024 года, когда была жесткая квота в 1000 подключений к базе данных в секунду). Для получения дополнительной информации прочтите документацию о максимальном количестве подключений для Aurora Serverless v2. Таким образом, с увеличением количества вызовов мы ожидаем вскоре достичь максимального количества доступных подключений к базе данных и высокой загрузки базы данных (ЦП), так что база данных не сможет отвечать на запросы новых функций Lambda для получения продукта по id (тогда тоже столкнется с Lambda). Тем самым мы спровоцируем аномалию и хотим выяснить, сможет ли DevOps Guru ее обнаружить. И это удалось, вроде.... Возникло следующее понимание:

И были выявлены следующие совокупные аномальные показатели:

По сравнению с агрегированными аномальными метриками, выявленными в случае использования JDBC вместо Data API, описанными в моей статье Amazon DevOps Guru для бессерверных приложений. Часть 10. Обнаружение аномалий в Aurora Serverless v2, мы полностью запутались в аномальных метриках базы данных Aurora: подключение к базе данных сумма и загрузка базы данных (ЦП), но правильно увидеть ошибку в Lambda, которая произошла в течение определенного времени из 15 секунд, поскольку база данных не могла ответить.

.

Так в чем же разница? Давайте рассмотрим оба инцидента, которые мы воспроизвели в кластере PostgreSQL Aurora Serverless v2 с JDBC (Non Data API) и Data API:

С точки зрения использования/масштабирования ACU они оба выглядят одинаково:

Что касается других показателей базы данных, таких как загрузка ЦП, DatabaseConnection DBLoad(CPU), существуют огромные различия:

• Загрузка ЦП выглядит одинаково для случаев JDBC (API без данных) и API данных. Но DevOps Guru, похоже, не учитывает эту метрику, поскольку мы не видели ее даже в эксперименте JDBC
• DBLoad(CPU), что очень мало для использования Data API. Похоже, что для Dat API перед базой данных Aurora Serverless v2 есть некий балансировщик нагрузки, который отслеживает использование соединения и защищает базу данных от перегрузки.
• Метрика DatabaseConnection не отображается (или отображается как 0) для использования Data API. Причина в том, что мы не управляем подключением к базе данных для Data API, это делается за нас с другой стороны. Конечно, они по-прежнему играют важную роль, которую мы узнали в разделе «Максимальное количество подключений для Aurora Serverless v2», но эта метрика, похоже, доступна извне в метриках CloudWatch, и даже DevOps Guru не имеет доступа к реальным цифрам.

При этом и очень низком уровне DBLoad (ЦП) не было получено никакой информации DevOps Guru для кластера Aurora Serverless v2 с использованием Data API по сравнению со сценарием использования JDBC.

Я провел второй эксперимент, подключившись к кластеру Aurora Serverless v2 напрямую, и написал сценарий для создания нагрузочного теста, написав сценарий, который извлекает продукт по идентификатору несколько сотен раз, используя стандартный способ (не-Data API). Аналогично тому, как мы это делали с инструментом «hey», но обращаемся напрямую к базе данных вместо вызова Api Gateway. После того, как я подверг базу данных нагрузке, я начал тот же эксперимент с инструментом «эй», как описано выше, и хотел посмотреть, что произойдет. Была получена такая же информация, но на этот раз со следующими аномальными показателями:

Теперь мы видим как минимум дополнительную аномальную метрику суммы подключений к базе данных Aurora Serverless v2, но метрики DBLoad(CPU) по-прежнему отсутствуют.

Аномалии на графике выглядят следующим образом:

Конечно, эксперимент не был чистым, так как я выполнил 2 нагрузочных теста друг за другом и частично параллельно: первый с подключением к базе данных напрямую без использования API Gateway, а второй с использованием Data API. Это подтвердило мое первоначальное предположение о том, что метрики суммы подключений к базе данных являются очень важным критерием для получения информации DevOps Guru для Aurora Serverless v2 (и для RDS в целом) и в целом не раскрываются в случае использования Data API.
Я уже связался с командой Devops Guru и поделился с ними своими мыслями, ожидая, что они улучшат сервис. Или, прежде всего, будет исправлено предоставление подключения к базе данных в качестве метрики CloudWatch для использования Aurora Serverless v2 с API данных.

Заключение

В этой статье мы узнали, что DevOps Guru может успешно обнаруживать аномалии с базой данных Aurora (Serverless v2) PostgreSQL в случае функции Lambda с управляемой средой выполнения Java 21, подключенной к ней через API данных, но может показывать только аномальные метрики, связанные с функцией Lambda. время ожидания истекло, поскольку база данных не ответила. Основная причина этого, по-видимому, заключается в том, что подключение к базе данных в качестве метрики CloudWatch не отображается (или всегда отображается как 0) в случае использования Aurora Serverless v2 с Data API. Метрики базы данных Aurora Serverless v2 (сумма подключений к базе данных) были показаны только во время второго искусственного эксперимента.