С 2022 года я задаю индустрии один и тот же вопрос: насколько мелко нарезать? Сначала про микросервисы, потом про модули монолита и даже про команды и отделы. Теперь настало время приложить вопрос и принципы ответа на него к большим объёмам данных и поиску по ним. Здесь он звучит так: какого размера должен быть шард индекса.

Повод задуматься дал Яндекс. На конференции «Я про бэкенд» есть активность «2718» — system design наоборот. Задачи присылают зрители, жюри отбирает самую заковыристую, а решает её в прямом эфире инженер Яндекса: условие видит впервые, детали выспрашивает сам. Я не удержался и отправил свою.

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

Кому-то наверняка знакомо? :) Нарежешь мелко — утонешь в сетевых вызовах и накладных расходах. Нарежешь крупно — пара сервисов заберёт всю нагрузку, а любая переделка растянется на недели. Тот же баланс, что с микросервисами, только искать его надо на трёх уровнях сразу: размер шарда, размер сегмента внутри шарда и размер виртуального шарда (chunk'а или таблетки) — куска, которым данные переезжают с сервера на сервер, когда база выросла и её пора перераспределять. Переносить по целому шарду долго, по одному документу — бесконечно, так что и здесь нужен свой размер.

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

1. Чем сервис пожертвует первым, если нагрузка окажется выше расчётной — частью результатов, скоростью появления новых документов или временем ответа. Запроектировать этот порядок нужно заранее, до первой аварии.
2. По каким признакам архитектор поймёт, что нарезал неправильно. У микросервисов это могут быть повторы в трассировках, у шардов — например, доля запросов, в которых один шард не ответил вовремя.
3. При каких значениях этих признаков пора принимать решение о перепроектировании и перенарезке шардов.

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


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

3 октября, Москва и онлайн, бесплатно: регистрация