SSO на пять миллионов пользователей

https://www.youtube-nocookie.com/embed/g20bvH5LdEQ

Авторы: Ирина Блажина и Николай Зайцев · HighLoad Channel

---

В X5 Tech несколько продуктов использовали собственные системы аутентификации. Пользователям приходилось заново входить в разные сервисы и получать дополнительные SMS, а команды независимо поддерживали код, связанный с безопасностью. Единый SSO должен был решить обе проблемы.

Основой системы стал Keycloak. Его возможностей хватало для обработки входов, но при росте аудитории команда столкнулась с другим ограничением: время запуска зависело от количества сохранённых сессий. Так задача масштабирования SSO превратилась в разбор кэшей, rolling updates, PostgreSQL и устройства самого Keycloak.

Кому смотреть: командам, которые внедряют централизованную аутентификацию, расширяют Keycloak собственными providers или готовят SSO к большой аудитории.

Из этого можно взять в работу: проверять identity-сервис не только под потоком входов, но и при полном перезапуске кластера с реальным объёмом пользовательских сессий.

---

X5 Tech выбрала Keycloak, чтобы не разрабатывать собственный identity server вместе с поддержкой протоколов, сессий, адаптеров и механизмов безопасности. Систему планировали масштабировать до пяти миллионов пользователей.

Проблема обнаружилась в Keycloak 10. Перед тем как начать принимать запросы, нода загружала пользовательские сессии из PostgreSQL в Infinispan. Чем больше становилось сессий, тем дольше продолжался запуск. По расчётам команды, при 300 тысячах пользователей полный перезапуск мог занять больше 40 минут.

Rolling update не устранил проблему. Когда обновлённая нода возвращалась в кластер, начиналась синхронизация кэшей, во время которой сервис мог работать нестабильно. Попытка вынести Infinispan в отдельный кластер тоже не дала простого решения и добавила новые компоненты в инфраструктуру.

Команда настраивала PostgreSQL, индексы, репликацию, количество сегментов и число узлов. Эти меры помогли стабилизировать пилот, но не устранили главную зависимость: перед запуском Keycloak по-прежнему требовалось загрузить большое количество сессий.

В итоге инженеры перенесли в свой форк Keycloak 10 механизм из более новой версии. Вместо массовой загрузки всех сессий нода сначала обращалась к кэшу, а при промахе читала нужную запись из базы. Запуск перестал зависеть от общего количества пользователей.

Срочная техническая проблема была решена, но у команды появился собственный форк критически важного компонента. Его нужно было сопровождать, проверять вместе с внутренними providers и совмещать с последующими обновлениями Keycloak.

Важно для 2026 года: описанная архитектура относится прежде всего к Keycloak 10–20. В Keycloak 26 persistent user sessions включены по умолчанию: база хранит состояние, а ограниченный кэш заполняется по требованию. Повторять доработку X5 Tech на современной версии не следует.

Сегодня этот доклад стоит смотреть не как инструкцию по настройке Keycloak, а как честный production-кейс. Он показывает, как рост аудитории меняет требования не только к рабочей нагрузке, но и к перезапускам, обновлениям и стоимости собственных изменений в коробочном SSO.