Архитектура Яндекс.Поиска v 1.04 Анатолий Орлов Сентябрь 2007 – Май 2008

Disclaimer Это все про поиск и его надежность и производительность -это не про робот и его нагрузки -не про ранжирование и релевантность в поиске. Описано реальное, а не идеальное решение -Можно и нужно сделать лучше -Часть решений объясняется термином legacy (читай: руки еще не дошли переделать) Совсем интимных данных не будет

Оглавление Что такое поиск и на чем все это работает Архитектура поиска и взаимодействие серверов Архитектура поискового кластера Методики анализа производительности кластера Пример проблемы и её решений.

Что такое Яндекс.Поиск ~40M показов SERP людям в день (+5M на xml поиски). База ~4 миллиардов документов. несколько тысяч серверов + сетевое оборудование в нескольких серверных в разных местах Москвы соединенных собственной оптикой.

На чем все это работает Поиски – FreeBSD 6,7 64 бита - кое где есть еще FreeBSD4-32 Языки разработки C++ и Perl - Примерно 52Mb кода на C++ и 3Mb Perl SLB – Linux, IPVS. - раньше была Cisco Роутеры – FreeBSD6. - с подпаченными сетевыми драйверами Коммутаторы – Cisco.

(Часть 2) Архитектура Яндекс.Поиска и взаимодействие серверов

Сферический поиск в Вакууме.

Кэширование Нужно кэшировать. На метапоисках. В нарисованной схеме кэши работают плохо

Правильное кэширование Каждый запрос кэшируется на одном сервере

Метапоиски более подробно

Программные решения Верхний метапоиск – Подхаченный apache(1.x) – FreeBSD4-32. fork()+kthreads – ModPerl Средний метапоиск – Свой http сервер. – FreeBSD6-64. Native Threads. – переходим на FreeBSD7 Базовый поиск – Свой http сервер. – FreeBSD6-64. Native Threads. – переходим на FreeBSD7

Взаимодействие Верхний –> средний, параллельные. – http (с установлением соединения) Средний -> базовый – keep-alive http. Обработка соединений – kevent/kqueue. – был FSM, перешли на CoRoutines. Хотим UDP

(Часть 3) Архитектура поискового кластера Яндекса

Поисковые кластера

Балансировка внутри кластера Linux, IPVS – проверяет живость серверов – раздает запросы примерно поровну Sticky – клиент по IP приклеивается к морде на N минут. Где я? az, buki, vedi, glagol.. sfront99

Сеть Машины одного кластера в одной подсети*

(Часть 4) Методики анализа производительности больших систем

Время ответа? Банально знать время ответа – среднее время ответа(бесполезно) – классы ответов – медианы Мониторим в RRD постоянно – знаем для всего сервиса – знаем для кластера отдельно – для каждого сервера отдельно – не только общее, но и базовых/средних Более сложные – время от времени

Классы ответов (абс).

Классы ответов (относит)

Медианы

Методы интенсивной терапии Запрос на входе метим reqid, и таcкаем его везде. Пишем в логи - всё. 2 раза. Сверяем показания в разных логах. В конечном итоге не верим никому, кроме tcpdump-а. – и ему тоже до конца не верим

(Часть 5) Пример проблемы и ее возможных решений. (проблема старая)

C чего все началось

Сетевые потери

Причины 1.2s и 3s это сетевые ретрансмиты. Нашли по разнице в логах и tcpdump-у. Причина потерь объективная – т.е. это не ошибка. Сетевое оборудование не держит наши нагрузки.

Возможные решения Переткнуть. Крутить настройки циски. Уменьшить количество пакетов. – packet rate vs. traffic. Ввести еще один уровень метапоиска Посылать информацию 2 раза. Маленько задержать ответы. Крутить таймауты.

Вопросы? Комментарии? Так же можно потом на Всё