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

Введение 

Когда мы пишем сервисы у которых есть свое состояние нам рано или поздно необходимо начинать задумываться о том, что же будет когда нагрузка на наше приложение вырастет. Ответ - масштабироваться. При горизонтальном масштабировании мы увеличиваем количество реплик сервиса, однако такой подход в stateful приложениях не подходит, так как каждый инстанс имеет свое состояние, и все они в своем роде уникальны. В таком случае нам - как разработчикам нужно искать способы делать систему одновременно и согласованной и масштабируемой.

Термины:

Stateful — имеющий состояние

Инстанс — экземпляр

Консистентность — согласованность, актуальное состояние

Сервер — потребитель ©

Клиент — поставщик (B)

Сервис — приложение‑посредник между клиентом и сервером (A)

Пример

Давайте например возьмем сервис A к которому по gRPC стримам будут подключаться клиенты B0, B1 .. Bn,  и , сервера C0, C1 .. Cn, а он в свою очередь будет как-то обрабатывать эти сообщения.  Клиенты должны стримить сообщения одному и тому же серверу, то есть, если сервер Cn подключен к An, то и клиент Bn должен как-то доставлять сообщения до An чтобы сервер мог их забрать.

При одном инстансе никаких проблем тут не возникает, сервер подключился к сервису A, клиенты также подключаются к нему и спокойно отсылают сообщения. Но при количестве экземпляров сервиса A > 1 возникают трудности.

Решения

1. Использование хранилища/очереди 

Самое наверное простое решение - использовать какое-то хранилище. К примеру: создать топик в Kafka куда сервис А будет кидать все сообщения из стрима клиента B0, которые подходят по условию что сервер C0 не подключен к этому инстансу (если сервер C ждет сообщения в другом инстансе A). Тогда достаточно реализовать функционал, что на каждом A должен работать воркер который будет консьюмить этот топик, если у него подключен этот сервер C0 и форвардить сообщения ему.

Минусы:

• Внешняя зависимость

Плюсы:

• Простота

Но что если мы не хотим использовать внешнее хранилище и реализовать все подручными средствами?

2. Hash-Ring

Идея простая - присваиваем каждому серверу С свой айди, также необходима реализация некой хэш функции, которая будет трансформировать этот айди в число <= кол-ву реплик. Ну и каждому экземпляру А необходимо знать о всех своих репликах. Тогда если необходимый нам сервер не подключен к текущему инстансу A, то достаточно открыть стрим с нужным нам экзмепляром А и форвардить сообщения ему.

См. примеры реализации: Amazon DynamoDB, Apache Cassandra

Минусы:

• Если изменяется кол-во реплик, то необходимо делать перерасчет ключа  и переподключаться к нужной реплике, часть ключей перераспределяется, что может вызвать временную несогласованность.

• Плохая балансировка (могут возникнуть хот-споты, при равномерном хэшировании нагрузка может неравномерно распределяться)

Плюсы:

• Относительная простота

• Отсутствие внешних зависимостей

А если мы хотим убрать лишние переподключения и сделать балансировку?

3. Gossip

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

См. примеры реализации: SWIM, Epidemic Broadcast Trees, HashiCorp Consul

Минусы:

• Сложная реализация

• Возможны задержки для согласования состояний, eventual consistency

Плюсы:

• Высокая отказоустойчивость и динамическая балансировка

4. Broadcasting

Чем-то похоже на первое решение. Также можно использовать очередь, но немного другим образом, ну или открыть стримы все со всеми и раскидывать сообщения всем, и, тот кто нужно, его обязательно получит. Говоря про очередь, тут наверняка неплохо справится Redis PUB/SUB, а впрочем, можно выбрать и любую другую, главное чтобы была возможность реализовать связь many-to-many. 

Минусы:

• Излишнее потребление ресурсов (можно открыть стрим и не использовать или слишком часто открывать/закрывать его)

Плюсы:

• Простота

Выводы

Так, ну на этом, мне кажется, все :-) Стоит помнить что выбор решения строго зависит от вашего юзкейса, может быть такое что самый неоптимальный на первый взгляд способ лучше всего подойдет вашей системе, а может и наоборот, тут необходимо отталкиваться от многих условий. Поэтому, эта статья ни в коем случае не панацея, моей задачей было осведомление читателя с такой проблемой и возможными путями ее решения.