Size: a a a

Архитектура данных

2020 September 19

MV

Mitya Volodin in Архитектура данных
Я не про свой код, но и не только про мажорное обновление. И я писал про особые случаи - smp это и есть особый случай. Oltp в кластере обновлять так же сложно. Совместимость даже минорных обновлений ни разу официального не видел. Да и я бы не рисковал.
источник

PD

Phil Delgyado in Архитектура данных
Mitya Volodin
Я не про свой код, но и не только про мажорное обновление. И я писал про особые случаи - smp это и есть особый случай. Oltp в кластере обновлять так же сложно. Совместимость даже минорных обновлений ни разу официального не видел. Да и я бы не рисковал.
Ну, вообще все промышленные СУБД обещают совместимость между репликами в минорных обновлениях.
В мажорных иногда тоже, но это уже сильно зависит (например, в Pg начали думать про совместимость между мажорными версиями после 10ки, насколько я помню).
А обновление oltp в кластере - это вполне себе обыденность, нет там ничего сверхсложного при нормальной архитектуре и нормальных специалистах, у меня в проектах такое делалось и не раз.
Вот между мажорными версиями без совместимости - там сложнее, иногда приходится просить у бизнеса 15минутную паузу и вписываться в нее.
источник

MV

Mitya Volodin in Архитектура данных
Phil Delgyado
Ну, вообще все промышленные СУБД обещают совместимость между репликами в минорных обновлениях.
В мажорных иногда тоже, но это уже сильно зависит (например, в Pg начали думать про совместимость между мажорными версиями после 10ки, насколько я помню).
А обновление oltp в кластере - это вполне себе обыденность, нет там ничего сверхсложного при нормальной архитектуре и нормальных специалистах, у меня в проектах такое делалось и не раз.
Вот между мажорными версиями без совместимости - там сложнее, иногда приходится просить у бизнеса 15минутную паузу и вписываться в нее.
Все - это слишком смелое замыкание. Было бы крайне сложно это подтвердить 😁
Ну я не настолько смел, возможно у вас больше опыта в этом вопросе, но некоторые базы я бы не решился без остановки обновлять. Но я и не могу сказать, что я большой специалист
источник

PD

Phil Delgyado in Архитектура данных
Так обновление тоже нужно тестировать, конечно, особенно для ответственных систем.
Но вообще весь финтех старается жить в обновлении без останова (или с остановом порядка минут).
Вообще, при наличии нормальных практик HA (локальный резерв, ближний георезерв, дальний георезерв) задачи обновления - это частный случай задач "переключения при сбоях". А так как датацентров с 99.999 не бывает, то переключение при сбое - это достаточно частая реальность, с которой нужно жить.
источник

PD

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

MV

Mitya Volodin in Архитектура данных
Phil Delgyado
Так обновление тоже нужно тестировать, конечно, особенно для ответственных систем.
Но вообще весь финтех старается жить в обновлении без останова (или с остановом порядка минут).
Вообще, при наличии нормальных практик HA (локальный резерв, ближний георезерв, дальний георезерв) задачи обновления - это частный случай задач "переключения при сбоях". А так как датацентров с 99.999 не бывает, то переключение при сбое - это достаточно частая реальность, с которой нужно жить.
Но вот именно с этим тезисом о том, что это частный случай переключения, я и не согласен. Обновление часто безвозвратно меняет инстанс, тогда как переключение предполагает временную рассинхронизацию, но возвращение всех зеркал/реплик в один инстанс. То есть это похожая задача, но все-таки (на мой взгляд) не частный случай.

Да, конечно, это чисто практическая задача, уверен, что в большинстве вендоров, поставляющих энтерпрайз решения, светлые головы придумали способ смягчения, который, как вы и отметили, требует отказа в обслуживании или перевода в read-only на какой-то очень маленький интервал времени. И для этого даже не надо придумывать велосипед.

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

VS

Vladislav 👻 Shishkov... in Архитектура данных
Phil Delgyado
Нормальное обновление без останова сложной системы - это итеративный многостадийны процесс с кучей сценариев вида:
"развернуть сервис версии n+1, настроить меш по переводу на него тестовых пользователей, прогнать тесты на тестовых пользователях, проверить логи, запросить у админа разрешение продолжить, настроить меш на перевод 1% пользователей, подождать час, проверить логи, запросить у админа разрешения продолжить, перевести 10% пользователей, подождать день" и т.п.
Плюс еще параллельные миграции (в том числе долгосрочные), совместимость разных сервисов, переключения фичафлагов по факту окончания выкладки и так далее.
Рулить этим из ансибла (который сделан в идеологии "привести целевые сервера в соответствие с описанным декларативно идеалом") очень неудобно (хотя, конечно, реально  - но очень не выгодно).
Впрочем, удобных инструментов для сложной выкладки на рынке нет. Что-то можно сделать на грэдле, что-то можно сделать груви-сценариями в Jenkins (с кучей плагинов), но удобной платформы - нет.
Основные проблемы - это "долгосрочные операции" (подождать час, а потом анализировать статистику), событийные модули (а если сработал алерт на прометеусе - откатить выкладку), взаимодействие с оператором (после 10% пользователей такая-то статистика - продолжать или нет).
Я сразу вижу проблемы с АБ-тестированием, почему у вас не реализовали это ввиде отдельной платформы?
источник

PD

Phil Delgyado in Архитектура данных
Vladislav 👻 Shishkov
Я сразу вижу проблемы с АБ-тестированием, почему у вас не реализовали это ввиде отдельной платформы?
АБ тестирование сильно отличается от выкладки, это скорее просто управление фичафлагами.
Если же его делать через разные версии отдельных сервисов, то это становится частным случаем процессы выкладки с канарейкой.
И что значит "отдельная платформа", зачем для AB-тестирования отдельная платформа?
источник

VS

Vladislav 👻 Shishkov... in Архитектура данных
Потому что канарейка тесно связана с АБ-тестированием
источник

VS

Vladislav 👻 Shishkov... in Архитектура данных
Идеологически
источник

VS

Vladislav 👻 Shishkov... in Архитектура данных
Все ваши проблемы, которые вы описали, у нас, например, не считаются проблемами априори...
источник

PD

Phil Delgyado in Архитектура данных
Эээ, в каком месте она связана? Там даже распределение пользователей обычно идет другим способом (если вообще идет).
источник

PD

Phil Delgyado in Архитектура данных
При выкладке новых версий на новые сервисы нужно отправлять всех пользователей, вне зависимости от включенных настроек для AB-тестирования.
источник

VS

Vladislav 👻 Shishkov... in Архитектура данных
Phil Delgyado
При выкладке новых версий на новые сервисы нужно отправлять всех пользователей, вне зависимости от включенных настроек для AB-тестирования.
Вы писали про 1 и 10 процентов...
источник

PD

Phil Delgyado in Архитектура данных
Или тестовых (по тегам).
источник

VS

Vladislav 👻 Shishkov... in Архитектура данных
Именно платформа это все решает, конечно, если вы об этом заботились на платформе
источник

VS

Vladislav 👻 Shishkov... in Архитектура данных
Кажется я вас понял и услышал, думаю, финтех очень интересный...
источник

PD

Phil Delgyado in Архитектура данных
Хм, что подразумеваете под платформой?
источник

PD

Phil Delgyado in Архитектура данных
Распределение пользователей - это или задача внешней прокси или сервис-меша (зависит от архитектуры). Но это не платформа, это просто решение.
AB-testing уже нельзя сделать на меше или проксе, так как обычно есть мобильные приложение (и хорошо, если не еще какие-нибудь десктоп-клиенты).
источник

PD

Phil Delgyado in Архитектура данных
Архитектура поддержки безопасного обновления системы без останова предполагает использование множества отдельных решений (меш, конфигурация, дашборды обновления, сложный скриптинг и т.п.) и в рамках этой архитектуры на ансибле удобно делать, разве что, инициацию новых серверов под развертывание и, иногда, развертывание third-party компонент (типа баз данных или кафки). Остальное, увы, приходится делать другими инструментами, в основном, на данный момент, самодельными.
источник