Русский
Русский
English
Статистика
Реклама

Ec2

Перевод Расширение кластера PostgreSQL размером 5,7ТБ и переход с версии 9.6 на 12.4

26.01.2021 16:05:52 | Автор: admin

Фото Ричарда Джекобса на Unsplash

В ноябре 2020 года мы начали крупную миграцию для обновления кластера PostgreSQL с версии 9.6 на 12.4. В этом посте я вкратце расскажу про нашу архитектуру в компании Coffee Meets Bagel, объясню, как даунтайм апгрейда удалось снизить ниже 30 минут, и расскажу про то, что мы узнали в процессе.

Архитектура


Для справки: Coffee Meets Bagel это приложение для романтических знакомств с системой курирования. Каждый день наши пользователи получают в полдень по их часовому поясу ограниченную партию высококачественных кандидатов. Это приводит к хорошо предсказуемым закономерностям нагрузки. Если посмотреть данные за последнюю неделю от момента написания статьи, у нас в среднем получается 30 тысяч транзакций в секунду, в пике до 65 тысяч.



До обновления у нас работали 6 серверов Postgres на инстансах i3.8xlarge в AWS. Они содержали одну главную ноду, три реплики для раздачи веб-трафика только для чтения, балансируемые с помощью HAProxy, один сервер для асинхронных воркеров и один сервер для ETL [Extract, Transform, Load] и Business Intelligence.

Для поддержания парка реплик в актуальном состоянии мы полагаемся на встроенную в Postgres потоковую репликацию.



Причины для апгрейда


Последние несколько лет мы заметно игнорировали наш уровень данных, и как результат, он слегка устарел. Особенно много костылей поднабрал в себя наш основной сервер он находится в онлайне уже 3,5 года. Различные системные библиотеки и службы мы патчим без остановок сервера.


Мой кандидат для подреддита r/uptimeporn

Как итог, накопилось множество странностей, которые заставляют понервничать. К примеру, новые сервисы в systemd не запускаются. Пришлось настраивать запуск агента datadog в сессии screen. Иногда SSH переставал отвечать при загрузке процессора выше50%, а сам сервер исправно отдавал запросы базы данных.

А ещё свободное место на диске начало подходить к опасным значениям. Как я упоминал выше, Postgres работал на инстансах i3.8xlarge в EC2, у которых 7,6ТБ хранилища NVMe. В отличие от EBS, здесь размер диска динамически менять нельзя что заложено изначально, то и будет. И мы заполнили примерно 75% диска. Стало понятно, что для поддержания будущего роста размер инстанса придётся менять.

Наши требования


  1. Минимальный даунтайм. Мы поставили целью ограничение в 4 часа суммарного даунтайма, включая незапланированные отключения, вызванные ошибками при обновлении.
  2. Собрать новый кластер баз данных на новых инстансах для замены текущего парка стареющих серверов.
  3. Перейти на i3.16xlarge, чтобы был простор для роста.

Нам известны три способа выполнить обновление Postgres: создание резервной копии и восстановление из неё, pg_upgrade и логическая репликация pglogical.

От первого способа, восстановления из резервной копии, мы отказались сразу: для нашего датасета на 5,7ТБ он занял бы слишком много времени. При своей скорости приложение pg_upgrade не удовлетворяло требованиям 2 и 3: это инструмент для миграции на той же машине. Поэтому мы выбрали логическую репликацию.

Наш процесс


Про ключевые особенности работы pglogical написано уже достаточно. Поэтому вместо повторения прописных истин я просто приведу статьи, которые оказались полезными для меня:


Мы создали новый primary-сервер Postgres 12 и с помощью pglogical синхронизировали все наши данные. Когда он синхронизировался и перешёл к репликации входящих изменений, мы начали добавлять за него потоковые реплики. После настройки новой потоковой реплики мы включали её в HAProxy, а одну из старых версии 9.6 удаляли.

Этот процесс продолжался до полного отключения серверов Postgres 9.6, кроме мастера. Конфигурация приняла следующий вид.



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

  1. Перевод сайта в режим технических работ;
  2. Смена записей DNS мастера на новый сервер;
  3. Принудительная синхронизация всех последовательностей (sequences) первичных ключей (primary key);
  4. Ручной запуск контрольной точки (CHECKPOINT) на старом мастере.
  5. На новом мастере выполнение некоторых процедур валидации данных и тестов;
  6. Включение сайта.

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

Извлечённые уроки


При общем успехе операции пара проблем по пути всё же встретилась. Самая страшная из них чуть не убила наш мастер Postgres 9.6

Урок 1: медленная синхронизация может быть опасной


Обозначим для начала контекст: как работает pglogical? Процесс передачи (sender) на поставщике (provider, в данном случае наш старый мастер 9.6) декодирует упреждающий журнал WAL [write-ahead log], извлекает логические изменения и посылает их на подписчика (subscriber).

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

При первом добавлении таблицы в поток репликации приложению pglogical сначала нужно синхронизировать данные таблицы. Это выполняется с помощью команды Postgres COPY. После этого сегменты WAL начинают копиться на поставщике, чтобы изменения за время работы COPY получилось передать на подписчика после изначальной синхронизации, гарантируя отсутствие потери данных.

На практике это означает, что при синхронизации большой таблицы на системе с большой нагрузкой по записям/изменениям нужно тщательно следить за использованием диска. При первой попытке синхронизации нашей самой крупной (4ТБ) таблицы команда с оператором COPY работала больше суток. За это время на ноде поставщика набралось больше одного терабайта упреждающих журналов WAL.

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


Доступное дисковое пространство на старом мастере при первой попытке синхронизации

Чтобы ускорить процесс синхронизации, мы внесли следующие изменения в базу данных подписчика:

  • Удалили все индексы в синхронизируемой таблице;
  • fsynch переключили на off;
  • Поменяли max_wal_size на 50GB;
  • Поменяли checkpoint_timeout на 1h.

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

Урок 2: каждое изменение строк журналируется как конфликт


Когда pglogical обнаруживает конфликт, приложение оставляет в логах запись вида CONFLICT: remote UPDATE on relation PUBLIC.foo. Resolution: apply_remote.

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

Эту проблему удалось решить заданием параметра pglogical.conflict_log_level = DEBUG в файле postgresql.conf.

Об авторе


Томми Ли старший инженер программного обеспечения в компании Coffee Meets Bagel. До этого он работал в Microsoft и канадском производителе систем автоматизирования бухгалтерского учёта Wave HQ.
Подробнее..

ARM сервера более производительные и более дешёвые

31.12.2020 14:09:18 | Автор: admin

В этом году Apple потрясла рынок десктопных процессоров чипом Apple M1 и устройствами на нём. Похожее событие произошло в мире облачных вычислений в прошлом году. AWS выпустили новый тип сервера на собственных ARM процессорах Graviton2. По заявлениям Amazon, соотношение производительности к цене у новых процессоров на 40% выше, чем у аналогов на x86. Ещё одно недавнее обновление - сервера Amazon RDS (облачный сервис, предоставляющий сервера баз данных) на Graviton2. Я запустил несколько бенчмарков и нагрузочный тест реального бэкенд приложения, чтобы проверить настолько ли хороши сервера на ARM процессорах и узнать какие проблемы совместимости могут возникнуть.

Производительность

Я сравнивал сервера типов t4g.small (ARM) и t3.small (x86) на AWS. На момент написания статьи цена за 1 час на ARM сервер составляет $0.0208, а на x86 сервер - $0.0168. Сервер на ARM на 20% дешевле.

Сперва я провёл нагрузочный тест при помощи wrk, запустив на серверах свежую установку recap.dev

Это шаблон docker-compose с 4 процессами. Веб-сервер, принимающий запросы и сохраняющий их в RabbitMQ и отдельный фоновый процесс, сохраняющий запросы группами по 1000 в PostgreSQL.

Я запускал wrk на сервере t3.2xlarge, находящемся в том же регионе, используя следующую команду:

wrk -t24 -c1000 -d300s -s ./post.lua <hostname>

Она непрерывно посылает запросы в течение 5 минут, используя 24 потока и 1000 HTTP соединений.

Результат для сервера t4g.small (ARM):

  24 threads and 1000 connections  Thread Stats   Avg      Stdev     Max   +/- Stdev    Latency   473.53ms   53.06ms   1.96s    81.33%    Req/Sec   115.83     96.65   494.00     71.32%  620751 requests in 5.00m, 85.84MB read  Socket errors: connect 0, read 0, write 0, timeout 225Requests/sec:   2068.48Transfer/sec:    292.90KB

Для сервера t3.small (x86):

 24 threads and 1000 connections  Thread Stats   Avg      Stdev     Max   +/- Stdev    Latency   600.28ms   70.23ms   2.00s    72.53%    Req/Sec    92.77     82.25   404.00     70.26%  488218 requests in 5.00m, 67.51MB read  Socket errors: connect 0, read 0, write 0, timeout 348Requests/sec:   1626.87Transfer/sec:    230.37KB

Сервер на ARM обслужил на 27% больше запросов в секунду в среднем на 26% быстрее.

Затем я запустил несколько бенчмарков из набора тестов Phoronix.

В тесте pts/compress-7zip-1.7.1t4g.small (ARM) выдал 6833 MIPS, а сервер t3.small (x86) - 5029 MIPS. ARM сервер был производительнее на 35%.

Сервер на ARM процессоре также завершил бенчмарк pts/c-ray быстрее более чем в 2 раза. 958 секунд ушло у сервера на x86 процессоре против 458 секунд у сервера с ARM процессором.

Я также запустил несколько тестов pts/ramspeed, измеряющих пропускную способность ОЗУ при выполнении различных операций.

Тип бенчмарка

t4g.small (ARM)

t3.small (x86)

Add/Integer

50000 МБ/c

13008 МБ/c

Copy/Integer

58650 МБ/c

11772 МБ/c

Scale/Integer

31753 МБ/c

11989 МБ/c

Triad/Integer

36869 МБ/c

12818 МБ/c

Average/Integer

44280 МБ/c

12314 МБ/c

Add/Floating Point

49775 МБ/c

12750 МБ/c

Copy/Floating Point

58749 МБ/c

11694 МБ/c

Scale/Floating Point

58721 МБ/c

11765 МБ/c

Triad/Floating Point

49667 МБ/c

12809 МБ/c

Average/Floating Point

54716 МБ/c

12260 МБ/c

Вкратце, ОЗУ на сервере t4g.small с процессором Graviton2 была быстрее от 3 до 5 раз.

Если смотреть только на производительность, переход на ARM сервера это одни преимущества. Больше производительности за меньшие деньги.

Совместимость

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

Некоторая часть ПО уже перекомпилирована для ARM процессоров. Например, Docker был доступен в форматах .rpm и .deb, как и большая часть образов (да, образы Docker требуют пересборки для разных архитектур). Однако, docker-compose не был скомпилирован для ARM процессоров, что вылилось в несколько часов сборки различных зависимостей из исходного кода. Скорее всего, ситуация улучшится в будущем, когда сервера на ARM станут более распространены. Сейчас, однако, в некоторых случаях, переход на ARM может принести больше затрат, чем преимуществ.

Зато сервера Amazon RDS на Graviton2 не требуют никакой настройки и позволяют получить все преимущества серверов на ARM процессорах без проблем с совместимостью.

Ввиду преимуществ ARM процессоров мы также собрали Docker образы recap.dev для архитектур arm/v7 и arm64.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru