Во время rolling update в проде одновременно работают старая и новая версии сервиса. Какое требование из этого следует?
- Что учитывать при rolling update?
- Почему миграцию схемы и код выкатывают отдельно?
Во время выкатки работают обе версии, поэтому совместимость нужна в обе стороны: старая переживает данные и запросы новой, новая — старой.
- Миграция схемы и изменение кода — разными релизами
- Новая колонка — nullable или с умолчанием; удаление старого — поздним отдельным релизом
- Форматы сообщений и кэша тоже: старая версия прочитает то, что записала новая
А ещё Blue-green сокращает окно сосуществования, но база всё равно общая
Подробно
При rolling update экземпляры заменяются по одному. Несколько минут (а при откате — снова) старая и новая версии обслуживают трафик одновременно и работают с одними данными:
- запрос пользователя попадает на любой экземпляр;
- строку, записанную новой версией, тут же читает старая;
- сообщение в брокере, опубликованное новой, обрабатывает старый потребитель;
- значение в общем кэше, сериализованное новой версией, читает старая.
Требования:
- изменения схемы совместимы с обеими версиями кода: добавлять nullable-колонки и таблицы можно, удалять и переименовывать — только через expand–contract;
- миграция и код — разные релизы: сначала расширение схемы, потом код, потом (позже) сужение;
- старая версия должна игнорировать незнакомые поля и значения (толерантный читатель), новая — работать с данными без новых полей;
- откат — тоже переход между версиями: новая версия не должна оставить данных, которые старая не прочитает.
Blue-green переключает трафик целиком, окно сосуществования короче, но схема базы и брокер общие — требования те же.
Что хотят услышать
- Сосуществование версий и обмен данными между ними.
- Двусторонняя совместимость схемы, сообщений, кэша.
- Миграция и код разными релизами, expand–contract.
- Откат как такой же переход.
Частые ошибки
- Выкатывать миграцию, ломающую старый код, вместе с новым кодом.
- Думать, что blue-green снимает проблему совместимости схемы.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Соседние версии обязаны быть взаимно совместимы по API и по схеме данных
- ✗Достаточно, чтобы новая версия умела читать данные старой
- ✗Требований нет: балансировщик направляет пользователя всегда в одну и ту же версию
- ✗Нужно останавливать приём трафика на время выкатки
Что спросят дальше
- Как выкатить переименование колонки без простоя?
- Чем canary отличается от rolling по радиусу поражения?
Разбор темы
- Выкатка без простоя и миграции схемы
Rolling, blue-green и canary с их ценой, отделение деплоя от релиза через feature flags, expand–contract для схемы БД, совместимость соседних версий и стратегия отката.
Связанные вопросы
- Нужно переименовать колонку name в full_name без простоя при rolling-выкатке. Какая последовательность верна? Middle
- Как вы спланируете выкатку изменения, затрагивающего и код, и схему базы, чтобы её можно было безопасно откатить? Middle
- Что такое rolling update при выкатке новой версии? Junior
- Какие изменения REST API обратно совместимы для существующих клиентов? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.