После Спамтеста я очень зауважал Microsoft

После Спамтеста я очень зауважал Microsoft

У меня в гостях Алексей Тутубалин — заядлый исследователь всевозможных вещей. Самое нашумевшее его исследование это обзор русскоязычного рынка ссылок. Существующий по сей день и знакомый каждому — рейтинг Rambler’s Top100 является разработкой Алексея. Он тот кто дал миру Russian Apache.

Он является для Ашманова тем, кем был Леня Голубков для МММ…Партнером конечно!

Алексей Тутубалин — один из лучших в России специалистов по интернет-технологиям, высоким нагрузкам, большим объемам данных. С вопросов о высоких нагрузках на сервера и начинается интервью. Что вы можете посоветовать для оптимизации работы сервера, чтобы он смог держать высокие нагрузки?

Я тут весной читал обзорную лекцию на эту тему. По-моему, уложился в два часа. Потом осенью была конференция Highload-2007, где все было более детально, но на два дня. Но у нас формат интервью, поэтому нужно покороче.

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

Таким образом, основных приемов два: замена длинных запросов к базе на короткие (помимо оптимизации структуры базы это может быть, например, расчет нужных отчетов заранее) и кэширование всего, чего только можно, в памяти.

Впрочем, в ряде случаев от дисковых запросов деваться некуда. Эта проблема у поисковиков, эта проблема у больших файловых архивов. Решают ее единственным способом: увеличивают количество дисков и стараются расположить там данные так, чтобы одновременные запросы от разных пользователей размазывались бы по всем дискам и, по возможности, не конкурировали между собой.

Какие меры можно применить для стабилизации системы при максимальных нагрузках?

Если нагрузка уже максимальная (больше выдать вы не можете, насыщение), то вы уже приплыли. Если мы говорим не о DoS, а о штатной нагрузке, то все что вам осталось — это обнаружить самые тяжелые для обработки участки и их оптимизировать (либо убрать). Но общего ответа тут нет.

Алексей, почему вы отдаете предпочтение движку Movable Type? Только из-за возможности делать статические публикации?

На статическую публикацию мне как раз наплевать, посетителей мало, динамика была бы даже удобнее, кнопка «перегенерировать все страницы» изрядно надоела.

MT выбран из «соображений второго порядка»: функциональность меня полностью устраивала, но движок на Perl, а не на PHP, а в качестве базы данных подходит PostgreSQL и ставить MySQL необязательно.

Это все личные предпочтения: в mainstream любят LAMP (Linux-Apache-MySQL-PHP), а я люблю FAPP (FreeBSD-Apache-PostgreSQL-Perl). Эти предпочтения сложились лет 7-10-12 назад, тогда я их мог даже обосновать, а сейчас все дело больше в привычке.

Конечно, полностью от Linux избавиться не получилось. Пользователи наших тиражных продуктов его используют, поэтому приходится и немножко разрабатывать и тестироваться под Linux.

Какими особенностями должно обладать веб-приложение, чтобы оно не создавало сверх-нагрузку на сервер?

Идеальное приложение все делает в памяти, а все тяжелые задачи делает асинхронно (уже после обработки запроса). Это дает удивительные результаты, скажем показ 100 млн. динамических баннеров в сутки с одного дохлого (по сегодняшним меркам) сервера — абсолютно не проблема.

Какие основные проблемы вы видите в традиционных конфигурациях современных систем?

Если говорить про оборудование, то оно такое, какое есть. Довольно сильно несбалансированное: процессорная мощность растет, объемы памяти (и RAM и внешней) растут, а скорость памяти и дисков растет очень медленно. Но этот дисбаланс не сегодня начался, ему лет 15-20 минимум.

Если говорить про софт, то это не столько проблема, сколько дело привычки. Действительно, почти все, что мы используем, уже довольно старое, история уходит в 90-е годы, а то и раньше. И стандартные лимиты в операционных системах или базах данных рассчитаны на «те» компьютеры. Примеров можно очень много привести: количество открытых файлов в системе, объем shared memory, стандартный размер кэша в базе данных, настройки оптимизатора БД (отношение стоимости вычислений к стоимости дисковой операции). Получается, что после установки свежей системы нужно поправить около десятка настроек. Но это рутинная операция.

Вторая крупная проблема — это файловые системы. Тут есть некоторый прогресс в последние годы, но пока не очень убедительный.

Вот то, что нас ожидает в ближайшие 5-10 лет — это гораздо интереснее. По всей видимости, производительность будут наращивать увеличением числа процессоров (ядер) в одном ящике. Ну и память перестанет быть симметричной (впрочем, на AMD Opteron она уже NUMA). А программировать под такое еще не научились толком, причем это касается и операционных систем и прикладных задач. Разве только у вычислителей проблем нет, они кластеры неплохо освоили.

Порекомендуйте, как эффективно организовать хранение файлов, как работать с быстро меняющимися данными?

Это два разных вопроса. Давайте начнем с конца.

По счастью, «очень много, очень быстро меняющихся данных» не бывает. Либо их немного, либо меняется небольшой «свежий» кусок, правда он обычно самый нужный. Какого-то общего решения тут нет, есть типичные рекомендации: отказаться от жесткого реалтайма, обрабатывать и хранить свежие данные в памяти. Но у меня нет общего ответа, каждое такое приложение нужно индивидуально проектировать, отдельно разбираясь, где можно пожертвовать синхронностью, а где нужно обязательно все в реалтайме.

С файлами же технологии уже неплохо отработаны: много дисков, stripe или RAID10, размер страйпа подбирается по месту. Наливаем туда файлов. Если хватает денег, то берем быстрые диски. Файловые архивы легко параллелятся, железо дешевое, вопроса как бы и нет.

Если перед вами поставить выбор, что использовать на сервере — Apache или nginx, что вы выберите?

Они же для разного. Nginx — прекрасный frontend (и для Apache и для FastCGI) и прекрасный раздатчик статических файлов. А динамический контент удобнее отлаживать на Apache, а не на FastCGI. Конечно, при больших требованиях по нагрузке динамику придется вынести на FastCGI, но не нагрузочные куски останутся на Apache.

Итого: выберу обоих.

Вы разрабатывали рейтинг Rambler’s Top100. Что из себя представлял этот рейтинг до вашей работы над ним и какие задачи были поставлены перед вами?

Если вернуться в начало 2000-го года, то все выглядело очень просто. Топ-100 катастрофически не справлялся с нагрузкой, нужно было в первую очередь вылечить эту проблему, а потом заниматься остальным. Остальное формулировалось довольно обще «руководить проектом», там довольно быстро наняли людей, в пике их было 5 человек при мне.

Топ-100 в технологическом смысле — это определенно моя удача. За почти 6 лет (с сентября 2001 по май 2007) в Рамблере к нему подходили два раза, один раз перевели на 64 бита, один раз распараллелили обсчет на две машины вместо одной (если не задумываться о мелочах, вроде синхронизации паролей, а в Рамблере не задумывались, то это не очень сложное действие). А исходная логическая структура осталась без изменений. Там, на самом деле, довольно легко можно все распараллелить на любое число машин и на раздаче счетчиков и на обсчете.

С чем вы можете сравнить сложность разработки рейтинга Rambler’s Top100? И например, сложность разработки Новотеки?

Я в оба проекта пришел не с самого старта, поэтому там сложность была одинаковой: было некоторое понимание, как оно должно работать, а был реальный код, который работал несколько иначе. И надо было разобраться, где правда — в описании или же в реальной программе. При том, что доставшийся мне по наследству код был далек от идеала.

А все остальное — это обычная работа. Спроектировать, спрограммировать, протестировать, запустить в бой, увидеть проблему, решить, оттестировать, запустить.

С Топ-100 ответственность была выше: проект работал, проект был гигантским трафикогенератором (да и сейчас им остается), уложить его отдыхать даже на полчаса было нельзя. Соответственно, основная сложность была в том, чтобы даже незапланированная остановка с гарантией не теряла данные.

С Новотекой другая история. Сама по себе Новотека всегда была демонстрационной площадкой для технологий «Ашманов и Партнеры»: поиска, кластеризации текстов, поиска нечетких дубликатов, определения тематики, автоматических дайджестов новостных сюжетов и так далее (у нас много интересных технологий). Все проблемы там связаны с тем, что база данных довольно большая, а нужно обеспечить выполнение тяжелых запросов («покажите мне новостную ленту по Хоккею-С-Мячом начиная с 17 марта 2002?). Потом развитие повернулось в сторону сервисов для интернет-СМИ (поиск, «гиперпоиск», обмен трафиком), это уже вполне обычные вебовские высоко-нагрузочные задачи с мягким стартом, я там сложных проблем вообще не помню. Но, конечно, когда вы обслуживаете десяток крупных новостных сайтов, от Комсомолки и МК до Известий и Регнума, ответственность высокая.

Какую вашу разработку вы можете назвать самой сложной, в техническом плане?

Сложно отделить технические проблемы и остальные. Поэтому я лучше просто о «самой сложной».

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

После Спамтеста я очень зауважал Microsoft и ее продукты: при их тиражах обеспечить работоспособность почти в 100% случаев с программами и драйверами третьих сторон — это очень сильное техническое достижение.

Помимо розничного продукта, мы еще поддерживали инсталляцию Спамтеста на Mail. ru, а там свои приключения, связанные с огромной нагрузкой.

Какое свое исследование в интернет-сфере вы можете назвать самым интересным?

Интереснее всего по содержанию было про рынок ссылок. Судя по бурной реакции, я с ним попал в точку.

Были ли такие случаи, когда начинали что-то исследовать, а через некоторое время интерес пропадал?

Традиционное уже мартовское исследование «Рунет в таком-то году» делается, конечно, больше по традиции и механически. Основная задача — это выдать тот же набор параметров, что и в прошлом году. Но оно все автоматизированное, запускаются несколько скриптов, получается результат. Но это продолжение того RU-Survey, который я начал делать 10 лет назад (а первые публичные результаты были в марте 98 года), нельзя останавливаться.

В связи с чем вы решили перейти с Windows на Mac OS?

Почему это «перейти»? Это еще один зверь в зоопарке. Мне была нужна Mac OS X для запуска ровно одной программы. Мне был нужен ноутбук, чтобы можно было работать где угодно. Складываем два желания, получаем MacBook Pro.

Но при этом никуда не делась Windows с десктопной машины (и замена не рассматривается, Mac Pro чудовищно дорог, а iMac для меня слабоват), FreeBSD с серверов, та же FreeBSD и Linux с виртуальных машин, которые я для разработки использую.

Опять же, если сравнивать эти системы, то что можете выделить из их преимуществ и недостатков?

По мне, так и Windows и Mac работают как предписано. Я не вижу никакой принципиальной разницы с точки зрения пользователя, ну кроме списка приложений и устройств расширения. Apple, конечно, здорово упростила себе задачу — у них закрытый список платформ и не очень большой.

С точки зрения программиста, Mac OS X — это ЮНИКС, разработка Web-приложений не будет отличаться от Linux, например.

А если копаться в потрохах, то что у Windows, что у Mac OS, что у Linux можно найти такой ужас….

Напоследок, пожелайте что-нибудь российским исследователям, благо их в нашей стране не мало.

Исследователи! Исследуйте!

Кроме шуток, желаю исследователям драки вокруг их результатов. Ведь если драки нет, значит никому не интересно.


Карта сайта


Информационный сайт Webavtocat.ru