Как избавиться от лавины S3 запросов в CloudNativePG

При использовании оператора CloudNativePG для управления PostgreSQL в Kubernetes можно столкнуться с неприятной проблемой: хранилище S3 начинает получать огромное количество запросов на список объектов (GET и LIST операций). Это приводит к росту расходов и лишней нагрузке на инфраструктуру.

Проблема часто остается незамеченной до тех пор, пока не начнут расти счета за API-операции. Разберемся, откуда она берется и как её решить одной строкой в конфигурации.

Откуда берутся эти запросы

CloudNativePG использует плагин Barman Cloud для создания резервных копий в S3-совместимые хранилища. Плагин работает отлично: создает снимки базы, архивирует журналы операций (WAL) и удаляет старые копии по заданной политике.

Для того чтобы система знала, какие файлы нужно удалить, а какие оставить, специальный контейнер (сайдкар) должен регулярно проверять содержимое в S3. При стандартных настройках сайдкар просыпается часто — примерно каждые несколько минут. Если кластер работает непрерывно, то за день набегает огромное число запросов.

В объектных хранилищах, где каждый запрос тарифицируется, это быстро становится заметным в бюджете.

Что не помогло

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

Отключение WAL архивирования. Как оказалось, это основа плагина, он не умеет работать без WAL архивации. И это только усугубило ситуацию: плагин продолжал накапливать файлы WAL, но не очищал их и не отправлял в S3. За пару дней может накопиться более 100Гб данных.

Оптимизация параметров WAL. Логично, что если увеличить размер журналов и указать больший период отправки, то данных станет меньше, что должно сократить количество запросов. Но количество операций изменилось несущественно, стало чуть меньше GET запросов.

Переключение на WAL-G. Есть альтернативный плагин от Yandex — WAL-G, который поддерживает CNPG-I интерфейс и реализует инкрементальные резервные копии. Плагин решает некоторые проблемы на больших объемах данных, но совершенно не решает проблему избыточного чтения объектов в S3.

Ничего из всего этого не помогло. GET и LIST операции так и продолжали идти в том же объеме.

Простое решение

В конфигурации CloudNativePG есть параметр instanceSidecarConfiguration с настройкой retentionPolicyIntervalSeconds. Это число определяет, через сколько секунд сайдкар должен просыпаться и проверять, какие файлы нужно удалить по политике хранения.

Вместо того чтобы проверять это каждые несколько минут, можно указать контейнеру проверять раз в несколько часов:

spec:
 instanceSidecarConfiguration:
  retentionPolicyIntervalSeconds: 21600 # 6 hours

После этого количество запросов падает радикально. В метриках хранилища шума становится в несколько раз меньше, расходы по API-операциям приходят в норму.

Что при этом меняется

После такого изменения система продолжает работать ровно так же:

• Резервные копии создаются по расписанию
• Восстановление из резервной копии работает без проблем
• Возможность восстановления на конкретный момент времени (PITR) остается
• Журналы операций архивируются в S3 как раньше

Единственное, что меняется — старые файлы удаляются не в режиме реального времени, а с опозданием на несколько часов. На практике это никак не сказывается на функциональности. Размер архивов может быть чуть больше, но ненамного и ненадолго.

Как подобрать правильный интервал

Значение retentionPolicyIntervalSeconds — это баланс между тем, как часто очищается архив, и тем, как сильно нагружается хранилище запросами.

Для большинства кластеров хорошо работают значения от одного до шести часов. Если система создает снимки не более чем раз в час и не нужна супер-оперативная очистка архива, то можно спокойно ставить 6 часов. Если требуется более частое обновление политики, то 1-3 часа будут разумным компромиссом.

Главное — не ставить слишком маленькие значения, иначе теряется смысл оптимизации. И не ставить огромные значения, иначе хранилище будет забиваться старыми архивами.

Если вы видите в логах своего хранилища много GET и LIST-операций от CloudNativePG, или счета за S3 растут без видимых причин — проверьте эту настройку. Часто этого хватает, чтобы вернуть всё в норму.