По redis’у - он действительно был без авторизации, это наш тех долг. То что в редис можно сходить по IP - это возможно сделать только из внутренней сети, из внешки не пробиться, всё будет пресечено сетевыми политиками доступа. Да и на сколько мне известно в slaveof redis запись невозможна.
XProxy - там генерировался конфигурации с haproxy + twemproxy на не одну сотню нижестоящие железные сервера, которые они должны были health-check-ать, а помимо всего этого еще и обрабатывать запросы всё это возлагалось на один единственный контейнер. Он не успевал этого делать и часть запросов отваливались с дефолтным тайм-аутом в 300мс или имели задержку на выполнение запроса.
PgBouncer - для управления соединениями и контроля чтобы бекенд не злоупотреблял ресурсами. PgBouncer в составе XProxy у нас не полетел в силу следующих пунктов: 1) конструкция получилась тяжеловесная для задачи database service discovery и менее надежная, чем альтернативный вариант; 2) альтернативный вариант - захардкоженный виртуальный хост (DNS или k8s service) в конфигурации и отдельностоящая система по актуализации этого хоста. XProxy же для redis в первую очередь решает задачу прозрачного для приложения шардирования, а у же потом database service discovery. Для PostgreSQL задача с шардированием не стояла (и не могла быть в рамках текущих инструментов), а database service discovery решается гораздо лучшими способами (см. выше).
Blue-Green на LXC - у нас была система с подменом symlink-ов и релоадом процессов. Это происходило достаточно быстро, что можно было считать такой процесс как blue-green. После разъезда по 3дц емкость кластера высвободилась и ресурсов стало хватать без проблем.
Тут политика такая же, как и для прода. Нужно делать компенсирующую миграцию, если это возможно конечно.
Перераскатка ресурсов довольно дорогая операция: так как внесёт много не согласованностей в других сервисах, и будет порождать кучу проблем вида: у пользователя есть несуществующие объявления, или объявления от несуществующего пользователя и много похожих проблем, так как у большинства сервисов свои сэмплы с базами данных. Поэтому к такой операции прибегаем крайне редко.
А так у нас очень хорошо уже всё распилено по микросервисам, так что миграции делаются крайне редко.
По redis’у - он действительно был без авторизации, это наш тех долг. То что в редис можно сходить по IP - это возможно сделать только из внутренней сети, из внешки не пробиться, всё будет пресечено сетевыми политиками доступа. Да и на сколько мне известно в slaveof redis запись невозможна.
XProxy - там генерировался конфигурации с haproxy + twemproxy на не одну сотню нижестоящие железные сервера, которые они должны были health-check-ать, а помимо всего этого еще и обрабатывать запросы всё это возлагалось на один единственный контейнер. Он не успевал этого делать и часть запросов отваливались с дефолтным тайм-аутом в 300мс или имели задержку на выполнение запроса.
PgBouncer - для управления соединениями и контроля чтобы бекенд не злоупотреблял ресурсами. PgBouncer в составе XProxy у нас не полетел в силу следующих пунктов: 1) конструкция получилась тяжеловесная для задачи database service discovery и менее надежная, чем альтернативный вариант; 2) альтернативный вариант - захардкоженный виртуальный хост (DNS или k8s service) в конфигурации и отдельностоящая система по актуализации этого хоста. XProxy же для redis в первую очередь решает задачу прозрачного для приложения шардирования, а у же потом database service discovery. Для PostgreSQL задача с шардированием не стояла (и не могла быть в рамках текущих инструментов), а database service discovery решается гораздо лучшими способами (см. выше).
Blue-Green на LXC - у нас была система с подменом symlink-ов и релоадом процессов. Это происходило достаточно быстро, что можно было считать такой процесс как blue-green. После разъезда по 3дц емкость кластера высвободилась и ресурсов стало хватать без проблем.
Перераскатка ресурсов довольно дорогая операция: так как внесёт много не согласованностей в других сервисах, и будет порождать кучу проблем вида: у пользователя есть несуществующие объявления, или объявления от несуществующего пользователя и много похожих проблем, так как у большинства сервисов свои сэмплы с базами данных. Поэтому к такой операции прибегаем крайне редко.
А так у нас очень хорошо уже всё распилено по микросервисам, так что миграции делаются крайне редко.