Если вы используете PostgreSQL в облаке, существует очень большая вероятность того, что вы тратите больше, чем нужно для того, чтобы покрыть все необходимости вашего бизнеса.

Давайте же разберемся, как выжать из Postgre максимум, потратив при этом минимму. В основу этой статьи легли рекомендации Дани Гусмана Бургоса (Dani Guzmán Burgos), нашего технического руководителя по мониторингу и управлению Percona (PMM).

Сокращение расходов: на что стоит обратить внимание, чтобы снизить затраты на PostgreSQL в облаке

Первый шаг на пути к снижению затрат — использовать только то, что вам действительно нужно. Не платите за ресурсы, которые вам не нужны.

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

Если вы видите на главном дашборде PMM низкую нагруженность процессора в какой-либо из отслеживаемых служб базы данных, это скорее всего означает, что сервер неактивен или ресурсы для него были выделены с избытком (over-provisioned). На рисунке 1 красным отмечен сервер, на котором процессор загружен менее чем на 30% своей допустимой мощности. PMM также может отображать исторические данные, которые помогут вам определить, как долго служба находилась в этом состоянии. На дашборде даже можно изменить конфигурацию метрик процессора. Представленная ниже цветовая индикация состояний доступна в дашбордах PMM 2.32.0 и более поздних версиях.

Согласно документации Amazon Web Services (AWS), инстанс считается выделенным с избытком ресурсов (over-provisioned), если по крайней мере один из таких показателей, как нагрузка на процессор, сеть или потребление памяти, может быть уменьшен при сохранении соответствия требованиям к производительности вашей рабочей нагрузки, и ни один из этих ресурсов не выделен в недостаточном объеме (under-provisioned). Over-provisioned инстансы являются одной из основных причин излишних затрат на инфраструктуру.

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

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

В качестве примера можно представить игровую студию, создавшую игру, которая становится популярной, поэтому количество ресурсов, необходимых для поддержки большего числа пользователей, значительно возрастет. Но если игра начнет терять популярность, сервер неизбежно будет переходить over-provisioned состояние – нужно будет корректировать выделение ресурсов, чтобы лучше соответствовать реальным потребностям приложения.

Определение адекватного масштаба с целью экономии

Есть три подхода к сокращению расходов:

• Сокращение переплаты (cloud waste)

• Переработка архитектуры

• Снижение выделенных ресурсов до необходимого масштаба

Независимо от метода, который вы используете для развертывания своего инстанса PostgreSQL, вот показатели, по которым определяется необходимость изменения масштаба:

• Загрузка процессора

• Использование памяти

• Пропускная способность сети

• Использование хранилища

Помните, что целью оптимизации вашей инфраструктуры является не одна лишь минимизация затрат. Вы должны быть уверены, что ваши решения, основанные на анализе метрик, не повлияют на операции. Самая главная задача заключается в том, чтобы гарантировать, что сервисы не потеряют производительность, исчерпав доступные ресурсы.

PostgreSQL в облаке

Процессор

Допустим, вы выбрали качестве облачной платформы AWS – конфигурация, подобранная для вашей инфраструктуры, будет очень сильно влиять на производительность вашего приложения и ежемесячные расходы. Например, инстанс Amazon Elastic Compute Cloud (EC2) на процессорах Graviton2 будет лучшим выбором, нежели варианты без ARM, потому что он дешевле, и вы получите более быстрые ядра, так как это будут реальные физические ядра процессора, а не hyper-threading потоки. Процессоры Graviton2 предназначены для работы с зарезервированными инстансами для экономии затрат в долгосрочной перспективе.

Преимущества процессоров Graviton2:

• Лучшее соотношение цены и качества для широкого спектра рабочих нагрузок.

• Всесторонняя поддержка программным обеспечением.

• Повышенная безопасность для облачных приложений.

• Доступны с управляемыми сервисами AWS.

• Лучшая производительность на ватт энергии, при использовании в Amazon EC2.

Хранилище данных

Развивая пример с AWS, выбор правильного варианта хранения данных также будет иметь ключевое значение для производительности. Amazon Elastic Block Store (EBS) — это отличный вариант дискового пространства.

Согласно документации AWS, Amazon EBS — это простой в использовании, масштабируемый и высокопроизводительный сервис блочного хранилища, разработанный под Amazon EC2.

Работа с реляционными или NoSQL базами данных — это один из юзкейсов, для которых рекомендуется использовать EBS. Вы можете развертывать и масштабировать с его помощью ряд баз данных, среди которых можно выделить SAP HANA, Oracle, Microsoft SQL Server, PostgreSQL, MySQL, Cassandra и MongoDB.

EBS позволят вам задействовать тома на основе жестких дисков (HDD), оптимизированные для больших потоковых рабочих нагрузок, и тома на основе твердотельных накопителей (рекомендуется для рабочих нагрузок баз данных), оптимизированные для транзакционных рабочих нагрузок.

Твердотельный том (SSD) может быть любым из следующих типов:

• io1

• io2

• io2 Block Express

• gp2

• gp3

Что именно из всего этого многообразия лучше выбрать в качестве хранилища данных? Это будет зависеть от требований конкретно вашей рабочей нагрузки: дискового пространства, количества операций ввода-вывода в секунду (IOPS) и пропускной способности (МБ/с). А также ваша конфигурация также должна быть оптимальной с точки зрения стоимости.

По этому вопросу я рекомендую вам почитать блогпост Ави Драбкина (Avi Drabkin), в котором он анализирует конфигурации для каждого типа тома, чтобы которые будут наилучшим образом удовлетворять требованиям конкретных юзкейсов. Больше информации о типах томов EBS вы можете найти на странице Типы томов Amazon EBS.

Развертывание в нескольких зонах доступности и read-реплики

Развертывание в нескольких зонах доступности (Multi-AZ deployment)

В рамках развертывания в нескольких зонах доступности Amazon RDS автоматически создает первичный (primary) инстанс базы данных и синхронно реплицирует данные в инстанс в другой зоне доступности. При обнаружении сбоя Amazon RDS автоматически переключается на резервный инстанс без ручного вмешательства.

Read-реплика (Read replica)

Amazon RDS создает второй инстанс базы данных, используя снапшот исходного инстанса. Затем он использует встроенную в движок асинхронную репликацию для обновления read-реплики при каждом изменении исходного инстанса базы данных. Read-реплика работает как инстанс базы данных, который разрешает соединения только для чтения; приложения могут подключаться к read-реплике точно так же, как и к любому другому инстансу базы данных. Amazon RDS реплицирует все базы данных в исходный инстанс.

Какой вариант лучше?

Развертывание в нескольких зонах доступности имеет ряд преимуществ, особенно в обеспечении высокой доступности и аварийного восстановления. Минус заключается в том, что этот вариант стоит дорого.

Самым лучшим вариантом было бы развернуть reader-инстансы и использовать их с обратным прокси-сервером, например, pgpool-II или pgbouncer. Reader-инстансы тоже стоят дороже, чем стандартный сетап, но вы можете использовать их для обработки повседневного трафика баз данных в продакшене.

Pgpool-II можно использовать не только с целью сокращения использования соединений (connection usage), что конечно поможет снизить нагрузку на процессор и память, но также и для балансировки нагрузки. Благодаря балансировке нагрузки вы можете перераспределять трафик, автоматически отправляя запросы на чтение данных вашим read-репликам, а запросы на запись в ваш основной инстанс базы данных.

Что касается read-реплик, в AWS нельзя продвигать RDS PostgreSQL read-реплику, что означает, что read-реплика не может стать основным инстансом. Всякий раз, когда вы будете пытаться сделать это, read-реплика будет отсоединяться от первичного инстанса и становиться своим собственным первичным инстансом, в результате чего вы получите два разных кластера.

Одним из возможных решений является использование расширения pglogical для создания реплик вне RDS. При сочетании pglogical-репликации с обратным прокси-сервером вы сохраните все преимущества управляемой базы данных, а именно резервное копирование, обслуживание незначительных обновлений, поддержку восстановления и привязку к конфигурации в нескольких зонах доступности, что дает вам полный контроль над запланированными переключениями на другой ресурс.

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

Больше информации о том, как использовать pglogical для обновления ваших инстансов базы данных, вы можете найти в этом блогпосте.

Очистка

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

Как избавиться от раздувания? Именно для этого и предназначен процесс очистки с помощью Autovacuum и vacuumdb.

Autovacuum это демон, который автоматизирует выполнение команд VACUUM и ANALYZE (для сбора статистики). Autovacuum проверяет наличие раздутых таблиц в базе данных и освобождает место для повторного использования.

vacuumdb – утилита для очистки базы данных PostgreSQL. vacuumdb также будет генерировать внутреннюю статистику, используемую оптимизатором запросов PostgreSQL. vacuumdb — это оболочка для SQL-команды VACUUM.

Запуск Autovacuum в базе данных с таблицами, в которых хранятся десятки терабайт данных, может привести к большим накладным расходам не только из-за объема данных, но и из-за “мертвых” строк (dead tuples), генерируемых при каждой транзакции. Обойти это можно с помощью изменения типа тома с EBS на io1, который способен поддерживать эту рабочую нагрузку, но ваш ежемесячный счет также увеличится.

Лучшим решением для этого сценария будет запуск процесса очистки по запросу. Отключение Autovacuum не означает, что его вообще нельзя запускать. Вы просто запускаете его по запросу в часы с низким трафиком, когда накладные расходы на производительность диска не влияют на общую работу. В этом случае накладные расходы на работу с высоким процентом мертвых строк обходятся дешевле.

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

Является ли это решение лучшим для каждого сценария? Конечно нет, все будет зависеть от требований вашей конкретной базы данных.

Также рекомендуется самостоятельно мониторить вашу базу данных на наличие мертвых строк / раздувания. Для этого вы можете использовать экспериментальный мониторинг для очистки PostgreSQL. Этот экспериментальный дашборд не является частью PMM, но ничто не мешает вам попробовать его (и оставить свой отзыв).

А как насчет бессерверных решений?

При использовании бессерверных (serverless) технологий вы действительно платите только за то, что активно используете, и о неиспользуемых ресурсах придется беспокоиться гораздо меньше, но переход на бессерверные решения не обходится без дополнительных затрат. Сложность построения любого плана миграции на бессерверные решения заключается в его реализации, которая на практике является антонимом экономии средств. Существует совершенно другая призма, через которую вы можете рассматривать целесообразность бессерверных решений: совокупная стоимость владения (TCO).

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

Обязанности, которые обычно выполняют DevOps-инженеры (управление сервером, масштабирование, выделение ресурсов, установка исправлений и т.д.), ложатся на плечи AWS, GCP или Azure. Это дает командам разработки больше времени на то, чтобы сосредоточиться на более быстрой доставке более проработанных фич.

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

Возвращаясь к оценке преимуществ по сравнению с требуемыми усилиями, вы должны учитывать общую стоимость перепроектирования сервиса на бессерверные решения и возможность снижения затрат.

Заключение

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

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

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

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

Материал подготовлен в преддверии старта курса "PostgreSQL Cloud Solutions".