Архитектура Яндекс.Поиска v 1.04

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

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

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

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

5. На чем все это работает Поиски –FreeBSD6,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 минут. Где я?www.yandex.ru/cgi-bin/hostname 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. Всё Вопросы? Комментарии? Так же можно потом на anatolix@yandex-team.ru