Graceful shutdown: откуда берутся пятисотки при каждой выкатке

Что здесь на самом деле спрашивают

Лестница обычно такая:

1. «Что происходит при остановке контейнера?» — разминка, отсылающая к первому уроку линии: SIGTERM, льготный срок, SIGKILL.
2. «Почему при выкатке появляются ошибки?» — здесь начинается содержание.
3. «Что такое graceful shutdown?» — вопрос, на который часто отвечают «дождаться завершения», не уточняя чего именно.
4. «В каком порядке закрывать?» — вопрос, отделяющий тех, кто это делал.
5. «Что делать с долгими запросами, которые не влезают в льготный срок?» — вопрос про границы метода.
6. «А балансировщик?» — вопрос про то, что дренаж начинается раньше сигнала.

Числа получены прогоном bench/shutdown/drain.py и bench/shutdown/practice.py: настоящий сервер на loopback, двадцать одновременных клиентов, обработка 300 мс, сигнал приходит на её середине.

База: остановка — это последовательность, а не мгновение

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

Остановка, устроенная по-человечески, — это четыре действия по порядку:

1. перестать принимать новую работу — новые запросы больше не берутся, они уходят туда, где их обслужат;
2. закончить начатую — те запросы, что уже в руках, доводятся до ответа;
3. закрыть то, чем пользовались — соединения с базой, файлы, соединения с соседними сервисами;
4. выйти.

Процесс, у которого этой последовательности нет, делает только четвёртое действие. И вот главный вопрос урока: что происходит с работой, которая была в руках, если сразу выполнить четвёртый шаг?

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

Отсюда и берутся «немного пятисоток при каждой выкатке». Это не свойство выкаток: это то, что процесс сделал со своей работой в момент, когда его попросили уйти.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования. Всё дальнейшее — про то, как процессу вообще сообщают об остановке, почему порядок первых двух действий важнее, чем кажется, и почему на всю эту вежливость отведён конечный срок.

Механизм 1: что именно обрывается

Первый режим — то, что делает процесс, у которого обработчика нет вовсе (первый урок линии) или у которого он написан как «выйти немедленно»:

1. EXIT ON SIGTERM, THE WAY A PROCESS WITHOUT A HANDLER DOES
------------------------------------------------------------
  requests broken                              20 of 20
  time from SIGTERM to exit, ms                2
  wait status: killed by signal                15
  the same as a shell reports it               143

Двадцать из двадцати. Не «немного пятисоток», а все запросы, которые были в работе в этот момент. Их доля от общего потока мала только потому, что момент короткий: обрываются не проценты запросов, а те, кому не повезло попасть в секунду остановки.

Отсюда первое уточнение, которое стоит делать в разговоре: «0,1 % ошибок при деплое» — это не характеристика надёжности, а произведение длительности обработки на частоту выкаток. Тот же код при вдвое более долгих запросах даст вдвое больше ошибок, ничего не изменив в себе.

Механизм 2: дренаж — это два действия, а не одно

Второй режим отличается обработчиком. Он делает две вещи по очереди:

1. закрывает слушающий сокет — новые соединения больше не принимаются;
2. дожидается, пока закончится работа по уже принятым, и только потом выходит.

2. STOP ACCEPTING, FINISH WHAT IS STARTED, THEN EXIT
----------------------------------------------------
  requests broken                              0 of 20
  time from SIGTERM to exit, ms                164
  exit code                                    0

Ноль из двадцати. И заметьте цену: 164 мс против 2 — это остаток той работы, которая уже шла. Сигнал пришёл на середине трёхсотмиллисекундной обработки, значит дожидаться пришлось около половины.

Здесь важно назвать границу этого нуля, иначе из него получится неверное правило. Ноль оборванных — результат этого прогона: этот сервер, эта нагрузка, обработка в 300 мс и льготный срок, в который вся начатая работа поместилась с запасом. «Дренаж не обрывает ничего» — не свойство дренажа, а описание случая, когда работа успела закончиться. Правило формулируется от границы: дренаж доводит до конца только то, что укладывается в отведённое ему время, и потому он обязан быть ограничен по времени сам. Ниже видно, почему.

Порядок двух действий важен, и в этом суть вопроса на собеседовании. Если сначала «дождаться завершения», а закрывать сокет потом, то за время ожидания придут новые соединения — и дренаж не закончится никогда, пока идёт нагрузка. Если закрыть сокет и сразу выйти, обрываются те же самые запросы, что и в первом режиме.

Почему это вообще возможно, известно из первого урока: SIGTERM перехватывается. Вторая половина того же правила — граница метода:

То есть дренаж работает только внутри льготного срока. Всё, что не успело закончиться, будет оборвано, и никакой обработчик этого не изменит. Отсюда и цена бесконечного ожидания: обработчик, который ждёт «сколько понадобится», не получает больше времени — он получает SIGKILL в конце срока, и тогда обрывается всё, что оставалось в работе. Ноль оборванных запросов держится не на терпении обработчика, а на том, что работа успела закончиться до этого момента.

Механизм 3: почему закрытие сокета — не то же самое, что отказ

Тонкость, которую стоит знать: закрыв слушающий сокет, вы перестаёте принимать новые соединения, но соединения, уже стоящие в очереди ядра, никуда не деваются. Из прошлого урока:

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

• в работе — их доводит дренаж;
• в очереди accept, но ещё не принятые — при закрытии слушающего сокета они будут сброшены; клиент получит разрыв, хотя приложение о них не знало;
• ещё не пришедшие — они пойдут в другую реплику, если балансировщик уже знает, что эта уходит.

Отсюда третье действие, которое к самому процессу не относится: сначала вывести реплику из балансировки, и только потом останавливать. Дренаж внутри процесса не спасает от запросов, которые к нему всё ещё направляют.

Глубже: работа, которая не влезает в льготный срок

Дренаж ограничен льготным сроком, а значит, есть работа, которая в него не поместится: длинные выгрузки, потоковые ответы, большие транзакции. Здесь метод не спасает, и это стоит сказать самому.

Три способа, каждый со своей ценой.

Разрешить прервать. Если операция идемпотентна и клиент повторит её (урок про ретраи), обрыв стоит одного повтора. Это самый дешёвый вариант, и он же самый частый в жизни.

Сделать её возобновляемой. Ответ по частям с указанием позиции — клиент продолжит с того места, где оборвалось. Дороже в коде, дешевле в эксплуатации.

Вынести из запроса. Длинная работа переезжает в фоновую задачу, а запрос только ставит её в очередь. Тогда остановка процесса не обрывает ничего важного — а перезапуск фоновой задачи становится отдельным механизмом со своими свойствами.

Как отвечать на собеседовании

Короткий ответ: graceful shutdown — это два действия по порядку: перестать принимать новые соединения и доработать уже принятые; и работает он только потому, что SIGTERM перехватывается. Измерено на одном и том же сервере под одинаковой нагрузкой: без обработчика оборвано 20 запросов из 20, с дренажем — ноль, а цена дренажа — 164 мс против 2, то есть остаток уже начатой работы.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Хороший ответ отличают три вещи. Первая — вы называете порядок: сокет закрывается первым, иначе дренаж не кончится под нагрузкой. Вторая — вы говорите про балансировщик: реплику выводят из ротации до сигнала, потому что дренаж не отменяет запросы, которые к ней всё ещё направляют. Третья — вы знаете границу: дренаж живёт внутри льготного срока, а SIGKILL не перехватывается, поэтому долгую работу надо либо делать возобновляемой, либо выносить из запроса.

И одна вещь, на которой легко переусердствовать. Сказать «с дренажем обрывов не бывает» — значит выдать один прогон за свойство метода. Ноль из двадцати получен на конкретном сервере, при конкретной нагрузке и при работе, которая уложилась в льготный срок. Точная формулировка звучит так: дренаж доводит до конца ровно то, что успевает уложиться в отведённое ему время, поэтому его самого ограничивают по времени — иначе его завершит SIGKILL, и обрывы вернутся.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

abrupt = run("abrupt")
drained = run("drain")
print(abrupt["broken"])
print(drained["broken"])
print(abrupt["exit"])

20
0
-15

20
0
143

1
0
-15

20
20
-15

Проверка знаний