LINUX.ORG.RU
ФорумAdmin

Нужны советы по отказоустойчивой инфраструктуре трекинг системы

 , , ,


0

1

Всем привет! Нужна помошь и подсказки по создании инфраструктуры трекинг системы.

Будет создаватся на основе облака хецнера. Входящих данных примерно 2-10млн/мес. Структуру накидали примерно такую:

  • На входе 2 балансировщика хецнера (решили остановится на них, а не разворачивать свои) в разных локациях, которые распределяют запросы между одними и теми же виртуалками в разных локациях. 2 балансировщика для 2 ip. Приложения на них дергают инфу из запроса и пишут в PostgreSQL (тут чисто инсерты). Тут важна высокая доступность.
  • PostgreSQL в виде нескольких виртуалок в разных локациях с мастерами за виртуалкой с PgBouncer. Дополнительно еще одна виртуалка с репликой базы для тяжелых селектов для админок. Тут важна высокая доступность.
  • Отдельно еще 2 виртуалки в разных локациях за 1 балансировщиком хецнера для апдейтов и записи в базу (нагрузки на базу тут будет в 10-15 раз меньше). Тут важна почти высокая доступность.
  • И еще 1 виртуалка для API и админок. В основном будет стучатся за данными в реплику PostgreSQL.

Нужно чтобы это все стабильно работало без отвалов и без проблем масштабировалось при росте нагрузки.

Вопросы:

  1. PgBouncer только один на одной виртуалке. Как можно обезопасится при его отвале?
  2. Насколько быстро синхронизируются мастера PostgreSQL и как часто? При каждом запросе синхронизируются или через какое-то время? Узкого места тут не будет? (мультимастер рассматривали в pro enterprise, но дорого)
  3. Как-то можно на вскидку прикинуть, сколько ресурсов нужно будет для виртуалок под 10млн инсертов в месяц (примерно 15 колонок в базе, данные будут хранится примерно за последний год)? Или тут только тестить?
  4. Может есть еще какие рекомендации? Или где есть явные грабли и узкие места?

P.S.: с PgBouncer не работал, с PostgreSQL на уровне поставил, настроил и забыл. Других хостеров и всякие куберы не предлагать. MongoDB рассматривали, но разрабы отказались из-за хреновой работы с джоинами.

★★★

О господи.

Входящих данных примерно 2-10млн/мес.

Миллиона чего, запросов? Какое совпадение, в месяце как раз примерно 2.5 миллиона секунд. То есть 1-4 запроса в секунду.

[кроме этого очешуительного числа инсертов в секунду требований так и не сформулировал]

Значит так. Берёшь два VPS чуть мощнее raspberry pi zero, и пишешь хоть в sqlite, хоть в текстовый файл на microsd. Избыточность реализуешь тем, что клиент шлёт в оба.

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

t184256 ★★★★★
()

Ты так привязываешься к виртуалкам от дяди Пети забывая о том, что в случае проблем у хостера, недоступны окажутся все. Я бы так не строил инфраструктуру. ИМХО, лучше взять по 2 железки у каждого провайдера и на них нарезать виртуалки под все нужды. И дублировать не только по виртуалкам но еще и железякам и локациям.

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

iron ★★★★★
()
Ответ на: комментарий от zevilz

Ещё скажи

ну ты же не сказал.

Это только стартовые цифры.

число секунд в месяце планируют уменьшить? О_о

для тяжелых селектов

любопытно, каких это.. хоть в общих чертах. И почему если заранее известно, что они «тяжёлые», их не оптимизировать?

mrjaggers
()
Ответ на: комментарий от iron

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

Уже давно на хецнере сижу. Если и отваливается сеть, то только определенной ноде. А так неприпомню, чтобы он весь упал.

два PgBouncer на разных виртуалках

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

от мультимастера поимеешь больше проблем чем пользы

а есть конкретные примеры проблем?

zevilz ★★★
() автор топика
Ответ на: комментарий от mrjaggers

число секунд в месяце планируют уменьшить?

число запросов

любопытно, каких это.. хоть в общих чертах. И почему если заранее известно, что они «тяжёлые», их не оптимизировать?

это без понятия, я не разраб

zevilz ★★★
() автор топика

инфраструктуры трекинг системы

Постгрес так се в этом случае. Есть же всякие influxdb и TimescaleDB (которая под капотом та же самая постгрес).

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

Ну и с выборкой тоже быстро не очень-то и получится.

Берите решение заточенное под задачу, к написанному выше я бы добавил и скорее всего выбрал бы clickhouse.

разрабы отказались из-за хреновой работы с джоинами

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

vvn_black ★★★★★
()

Чтобы обсуждать отказоустойчивость надо понимать места отказа для начала. Тут они не очевидны.

Не очень понятно зачем сразу городить кластер из СУБД, предполагается что постгрес первым падет в бою в неравной схватке с данными чтоли? Это далеко не всегда так.

Ну и потом кластер это сознательное замедление системы ради масштабирования, в твоем случае каких-то адских миллионов пользователей не придвидится, разработка очевидно in-house.

Дальше сами данные, как правильно уже заметили - озвученные «примерно 2-10млн/мес» это не что-то невероятное, даже если это XML по мегабайту, который еще нужно распарсить и разложить в сотню связанных таблиц.

В трекинг системе (кстати было бы неплохо уточнить специфику) самих поступаемых данных не может быть много, это же просто какие-то числовые коэффициенты, координаты, максимум - строки. Плюс они достаточно быстро устаревают, те хранить все в одной базе особого смысла и нет.

Вообщем сплошные загадки во тьме )

alex0x08 ★★★
()
Ответ на: комментарий от zevilz

аналитика, даже самая замудреная, на таких объемах за сутки уж всяко построится, даже на приблизительно никаком железе

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

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

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

olelookoe ★★★
()