Канареечная выкладка и зеркало трафика

Знаешь оба инструмента - листай до второго разбора: там замер, опровергающий совет «медленное зеркало тормозит клиента».

Зеркало проксирует копию запроса в новую версию, а та отвечает десять секунд. На сколько это задержит основной запрос?

основной запрос: код=200 время=0.001611
счётчики бэкенда сразу после ответа: {"main": 1, "slow-mirror-start": 1}
счётчики через 12 секунд:            {"main": 1, "slow-mirror-start": 1, "slow-mirror-done": 1}

Полторы миллисекунды. Клиент ушёл давно, а копия ещё выполнялась - и это не означает, что медленное зеркало ничего не стоит.

На что это похоже

split_clients - это очередь, которую разделили лентой: часть людей идёт к новому окну. Человек, попавший в новую очередь, идёт в неё и завтра - иначе он получал бы то новую услугу, то старую, и жаловался бы на обе.

mirror - это второй кассир, который повторяет все операции для тренировки, но чеки не выдаёт. Клиенту его работа не видна вовсе. Зато он занимает место в зале, и если он медленный, зал постепенно забивается.

Механизм: две схемы деления трафика

Правило

split_clients "$remote_addr$http_user_agent" $backend_pool {
    5%      app_canary;
    *       app_stable;
}

upstream app_stable { server app-1:8000; server app-2:8000; }
upstream app_canary { server app-new:8000; }

proxy_pass http://$backend_pool;

Модуль считает хеш от строки и раскидывает по долям. Долю меняют в конфиге и применяют reload-ом: 5% на час, 25% на день, 100% - и старую группу можно гасить. Откат такой же быстрый, в этом вся ценность.

location /api/ {
    mirror     /mirror;
    mirror_request_body on;
    proxy_pass http://app_stable;
}

location = /mirror {
    internal;
    proxy_pass http://app-new:8000$request_uri;
}

Разбор: постоянство ключа в цифрах

Ключ должен быть стабилен для человека и разным у разных людей. Что бывает, когда это правило нарушено, видно на замере: один и тот же клиент, 200 запросов, доля канарейки 5%.

Первая строка - то, ради чего инструмент и берут: человек не прыгает между версиями. Третья - что получается с неудачным ключом: тот же клиент попал в новую версию семь раз из двухсот, то есть корзина у него собиралась то там, то здесь. Вторая строка доказывает, что доли настоящие, а не декоративные.

Годятся $remote_addr, cookie приложения, идентификатор сессии. Не годится ничего, что меняется от запроса к запросу.

Разбор: что на самом деле стоит медленное зеркало

Совет «держи зеркало быстрым, иначе оно тормозит основной запрос» встречается часто. Замер из крючка его не подтверждает: основной ответ ушёл за 0,0016 секунды, пока копия ещё работала. Ответ подзапроса не участвует в ответе клиенту, и ждать его nginx не обязан.

Цена другая, и она обнаруживается под нагрузкой. Каждая незавершённая копия - это открытое соединение к бэкенду, то есть занятый слот worker_connections из прошлого урока. Тот же стенд, worker_connections 4, тридцать параллельных запросов с десятисекундным зеркалом:

server accepts handled requests
 38 31 30

Семь соединений отброшено. То есть медленное зеркало бьёт не по времени ответа, а по ёмкости: слоты кончаются, и страдают запросы, к зеркалу отношения не имеющие. Отсюда правильные меры - короткий proxy_read_timeout у подзапроса и запас по worker_connections, а не «главное, чтобы клиент не ждал».

Что зеркало действительно делает, проверяется счётчиками на бэкенде:

mirror_request_body on действительно передаёт тело - новая версия получает настоящие запросы, а не их очертания.

Что ломается без этого

Забытый internal. Замер: с ним прямой запрос к /mirror снаружи даёт 404, без него - 204, то есть служебный адрес открыт всему интернету и через него можно дёргать новую версию напрямую, минуя лимиты и авторизацию основного маршрута. Это тот же internal из двенадцатого раздела и та же цена забывчивости.

Удвоенные побочные эффекты. Зеркало - настоящий запрос: если новая версия пишет в ту же базу, шлёт письма или списывает деньги, всё это произойдёт дважды. Зеркалить можно туда, где побочных эффектов нет: своя база, своя очередь, режим только для чтения. Проверять это надо до включения, а не после.

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

log_format canary '$status $request_time $backend_pool "$request"';

Зачем это в работе

Порядок выкатки, который стоит держать в голове: сначала зеркало на день - оно ловит несовместимость и падения на настоящих данных; потом пять процентов на час; потом четверть; потом все. На каждом шаге смотрят три метрики из прошлого урока, и на каждом шаге откат - это правка одной строки и reload.

Теперь сам

Канареечная выкладка идёт вторые сутки. В мониторинге доля 5xx выросла с 0,1% до 0,4%, но по какой версии - непонятно. Ключ карты - $remote_addr, метка группы в лог не пишется. Что сделать сейчас, чтобы понять, виновата ли новая версия, и что стоило сделать заранее?