Много лет ты читаешь отчёты с HighLoad++, следишь за докладами и обсуждениями в кулуарах, но все это обычно воспринимается как что-то, наблюдаемое со стороны. Момент же, когда твоя собственная заявка попадает в программу,   становится переломным и воспринимается совсем иначе.

HighLoad++ давно стал местом концентрации лучших технарей со всей страны –   самого смузи индустрии – и площадкой обсуждения сложных инженерных задач. Поэтому приглашение на конференцию с докладом для нас – это не про "ещё один слот в очередном мероприятии", а про возможность поделиться практическим опытом нескольких лет разработки с аудиторией, которую сложно удивить красивыми слайдами без реальных технических результатов.

Выбор темы был довольно рискованным и не самым очевидным, но тем и интереснее. Вокруг HighLoad обычно много разговоров про микросервисы, безопасность, Kubernetes, AI. Ну а мы (команда Avanpost DS) позволим себе выйти с докладом о разработке собственной службы каталогов enterprise-уровня.

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

Именно об этом мы и хотим поговорить на Saint HighLoad++ 2026.

Краткий экскурс: эволюция хайлоада (версия ChatGPT)

Для объективности я попросил нейросеть сгруппировать тематику докладов HighLoad последних лет по характерным эпохам. Вот что вышло:

  • 2015-2018: Эпоха «Монолит — зло, нарезаем всё в 100500 микросервисов». Главные боли — сеть и сериализация.

  • 2019-2022: Эпоха «Реактивщина и асинхронность». Гонка за нулевым оверхедом. Vert.x, Akka, Project Loom (который тогда был мифом).

  • 2023-2025: Эпоха «Data Intensive». Все вдруг поняли, что микросервисы — это легко, а вот данные… данные больно. Дебаты вокруг NewSQL, векторных БД и шардирования как искусства.

А теперь внимание вопрос: Где во всей этой картине место для службы каталогов, которая хранит оргструктуру по типу «Организация → Подразделение → Отдел → Сотрудник» и напоминает картотеку из старых детективных фильмов? 

Замена Active Directory в энтерпрайзе – не так просто, как кажется

Здесь, наверное, излишним будет напоминать зачем вообще понадобилось менять MS AD, который просто работал все эти годы, на что-то другое. Я искренне удивлюсь, если на Хабре найдется хоть один человек, который не в курсе процесса импортозамещения в России. Однако задача импортозамещения MS AD далеко не так тривиальна, как могло показаться на первый взгляд.

Проблема в том, что за 20+ лет эволюции AD оброс множеством неочевидных оптимизаций, к которым привыкли и разработчики приложений, и сами администраторы. Например,AD умеет выполнять сложные поиски с транзитивным членством в группах за десятки миллисекунд на миллионах объектов. Open-source аналоги в таких запросах либо падают в линейный обход дерева, либо требуют предрасчета всех замыканий, что взрывает объём хранимых данных. Или взять репликацию: AD использует устаревший, но феноменально живучий протокол с семантикой «последний победил» и восстановлением после длительного отсутствия связи. Классические LDAP-движки просто не проектировались для таких нагрузок и масштабов.

Опенсорсная боль: почему «бесплатно» оказалось слишком дорого?

Мы не гонимся за хайпом. Наша ЦА — это серьезная корпоративная инфраструктура с legacy в 20 лет и нагрузкой в сотни тысяч операций в секунду. Мы честно пытались не изобретать велосипед и взять готовые опенсорсные каталоги.

Что мы увидели на нагрузочном тестировании (сценарий: каталог на 50K  пользователей, глубокая вложенность групп, имитация «logon storm»):

SambaDC: С чего ещё начинать, как не с проекта, построенного на реверс инжиниринге MS AD. Увы Самба не только не справляется с нагрузкой, выдавая жалкие 5% пропускной способности MS AD, но и просто падает на бок и больше не встает.

389 DS(FreeIPA) : Неплохая производительность на поиск (если сравнивать с самбой), но ужасная работа с массовыми изменениями, тяжеловесная ACL и вечные проблемы с репликацией. Не помогает даже миграция на LMDB, пропускная способность все равно на порядок уступает MS AD.

OpenLDAP(режим back-mdb): На 20-30K rps начиналась жуткая фрагментация памяти. Поиск по индексу работал отлично, пока вы не добавляли атрибут с подстановочными знаками (*). Тогда движок падал в sequential scan. Да и подсистема репликации существует в OpenLDAP как некий afterthought.

Мы поняли главное: ни один Open-Source LDAP каталог не способен заменитьMS AD на масштабах крупного предприятия, единственно-верное решение – это писать свой каталог с нуля, сразу закладывая масштабирование и производительность в архитектуру.

Как мы это сделали (коротко, подробности — на докладе)

Оглядываясь на пройденный нами путь, можно с уверенностью утверждать, что львиная доля работ по созданию Avanpost DS – это R&D в том или ином виде. Конечно, основные протоколы взаимодействия с инфраструктурой –LDAP и Kerberos – открытые и хорошо задокументированы в документации IETF, однако целый пласт задач ещё требовал исследований:

Производительность: Обеспечить производительность на уровне AD оказалось не так просто, за 20+ лет развития команда MS выжала из JET Blue все, что было можно, результатом стала единственная служба каталогов в мире, способная предоставлять аутентификацию и авторизацию в инфраструктурах на сотни тысяч пользователей без прерывания обслуживания. Одной из основных задач для нас стало добиться производительности на уровнеMS AD – здесь R&D исчисляется годами. Небольшой спойлер – добились мы таких результатов за счет использования хранилища LSM-tree с кастомными индексами на базе BadgerDB, но подробнее об этом в своем докладе на HL расскажет мой коллега, Собир Абдуллаев.

Горизонтальная масштабируемость: Ещё одна область, практически не охваченная документацией на базовые протоколы – это репликация данных. Стандартное решение CAP теоремы, к которому рано или поздно приходили все каталоги, начиная от MS AD и заканчивая Open LDAP – это мультимастер репликация. Однако несмотря на большое количество примеров тут тоже было много почвы для исследований, начиная с пограничных кейсов конфликтов репликации, заканчивая тем, что репликация это в общем то тоже нагрузка (и нагрузку на запись она нисколько не снижает, даже скорее наоборот).

Совместимость: MS AD за время своего существования оброс огромным количеством расширений, с которыми теперь оказались плотно завязаны многие инфраструктурные и прикладные сервисы (ага, то самое легаси 20-летней давности, опирающееся на функционал, который уже лет 10 как deprecated). Тема обеспечения совместимости как с существующей инфраструктурой заказчика, так и с самой MS AD (доверительные отношения и миграция), стала основным поставщиком задач по реверс инжинирингу в нашем продукте. 

Как видите скучная на первый взгляд задача по созданию службы каталогов на замену MS AD оказалась весьма нетривиальной и обросла кучей приключений по дороге. Но, результат того стоил, посмотреть хотя бы даже на графики пропускной способности по результатам сравнительного нагрузочного тестирования – здесь нам действительно есть чем гордиться:

Так с чем мы идём на HighLoad?

С первой службой каталогов enterprise уровня за последние 20 лет, с рассказом о том, как решили задачи производительности и масштабируемости, с историей реверс инжиниринга и реальными цифрами из боевой инфраструктуры.

На нашем докладе мы расскажем:

  • Как выбирали базу данных и почему остановились на BadgerDB;

  • Как мы строили индексы для поиска по поддереву и по связанным атрибутам;

  • Каких показателей производительности нам удалось добиться (и чего это стоило).

Надеюсь, удалось вас заинтересовать, будем рады вас видеть на конференции)

Тема доклада: Реализация высокопроизводительной распределенной службы каталогов на Go и Badger DB
Где и когда: HighLoad.ru, 23 июня, 10:00, «Зал Розовый»