Архитектура Яндекс.Поиска v 1.04 Анатолий Орлов anatolix@yandex-team.ru Сентябрь 2007 – Май 2008. - презентация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

21 Медианы

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

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

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

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

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

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

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