aws, затем поёду в часик девопсру если это тема для там.
Вот представьте есть некий проект.
Ну прям всё как обычно: Mysql/Postgresql(RDS), EKS, ALB, S3, Elasticache и короче вот все эти сервисы облаков.
Всё как в сказке.
Есть большая вероятность, что проект может вырасти и вылезть за пределы стартапа.
Условно говоря к нам придёт условный Pepsi co и нам надо будет многое изолировать для них отдельно.
Потенциальная задача - разделить все по разным регионам/базам.
Если со всякими s3/alb/EKS у меня вопросов нет, то как "делить" БД я не знаю.
Ну может там какие-то тенанты делать(?)
Или миграцию структуры и содержимого БД из одного существующего кластера в несколько БД по клиентам/регионам и разносить это руками/скриптом по разным регионам/БД.
Надеюсь донёс свою мысль).
Вопрос:
а где бы вот почитать о неком таком опыте внезапного роста с разделением по регионам/клиентам и самое главное - даёт ли сам амазон нечто подобное из фичей?
Хочется сперва задействовать от самой экосистемы, чтобы не выдумывать костыли.
Я нашёл лишь пару статей в интернетах, но это не совсем то, что надо.
Если кто что знает/видел/читал - буду рад ссылкам.
Что значит "делить бд"? А кто и как этой базой пользуется то?
ну сейчас есть backend который живёт в кубере и подключается к бд клиенты сидят на фронте, который подключается к беку. если придёт большой крупны клиент надо это как то полностью отделить
Добро пожаловать! SaaS Tenant Isolation Strategies
Это делается же на уровне приложений. Как ты хочешь данные делить между клиентами?
я пока не понимаю, по мне так проще поднять всю инфру отдельно по терраформу и поменяь url для эдпойнта у нового клиента, но может быть это оверхед
А как данные синкать потом? Или я не понимаю основной задачи
Весьма любопытно. Похоже это часть того что мне надо. Благодарю.
Пока не знаю, потому пришёл сюда, почитать то, что накидают 🙂
В обе стороны?
Так первоначально не ясна вся задача целиком. И вводных данных не хватает
Ну я соглашусь с тобой. Вот выше коллега скинул документ, который меня пока на данный момент устроил. Пойду с ним с руководству, когда спросят меня про мои мысли. Я сейчас про нему пробежался по диагонали, и это похоже на то, что мне надо. Даже в условиях текущих невнятных тз.
У клиента должна быть базовая модель базы с миграциями на отдельном инстансе, с новыми миграциями приходящими с релизами кмк По крайней мере для SaaS мы так проектировали
Подозреваю, что они инфру клиентам дают и ему надо продумать как клиентов ограничить друг от друга
Все базы очень разные. И для каждой куча бест практик) Если брать ваш пример с RDS (MySQl & Postgress) то можно изолировать клиентов на вскидку: 1) RDS кластер per client 2) database внутри кластера per client 3) schema внутри database per client 4) поле tenantId в каждой табличке 5) etc. В каждом случае будет отличаться способ работы с данными, уровень изоляции, механизм миграций и т.д. Разделение по регионам для чего именно? Для изоляции? Или для повышения отказоустойчивости? Или чтобы снизить летенси для клентов из разных стран? Вобщем лучше всего начать с формулировки конкретных требований к решению.
Часто сталкивался с тем, что под крупных клиентов пилится свой о дельный акк и не один. Они скорее всего сами это запросят, если энтерпрайз
Спасибо, записал, буду думать.
Ну тебя хорошо навык телепатии развит)
Я админом начинал))))
Обсуждают сегодня