Давненько не бывал на конференциях, наконец-то удалось совместить наличие хорошей конференции с возможностью на нее пойти. И так, 13 и 14-го апреля в г. Ульяновск проходила конференция "Стачка!" на которой я имел удовольствие поприсутствовать. Сразу отмечу, что несмотря на то, что конференция была бесплатной, уровень организации и качество докладов были на уровне вполне известных платных конференций. Выбрали отличное живописное место, организовали онлайн трансляцию (на сайте выложены архивы с видео докладов). Спасибо организаторам, постарались на славу!
Теперь расскажу о докладах (в общем-то краткий пересказ докладов, много букв! Если нужны подробности - смотрите видео на сайте).
Илья Космодемьянский. "Теория и практика распределенных баз данных".
Свой доклад посвятил следующим темам:
- Области применения репликаций
- Транзакции, локальные и распределенные
- Очереди сообщений
- Materialized View
Довольно общий доклад, обзорный. Если кто-то планирует начать работать с распределенными БД (или неожиданно столкнулся с необходимостью с ними работать) будет полезен. Опять же, отличия подходов к работе с БД в локальном и распределенном случаях.
Роман Павлушко, avito.ru "Нагруженный поиск на Sphinx".
Доклад о том, как создавался и как поддерживается поиск на крупнейшем сайте объявлений в рунете Avito.ru. Докладчик в начале нервничал, но потом разошелся)
Изначальная архитектура сайта была завязана на базу данных. Использовались различные хранимые процедуры, кеш так же укладывался в базу, поиск был реализован на встроенном в PostgreSQL полнотекстовом индексе (tsearch). Когда же столкнулись с серьезными нагрузками, то начали максимально разгружать БД, упростили схему, вынесли кеш в In-memory базу а поиск перенесли в Sphinx.
На сайте Sphinx используется для 2-х вещей: непосредственно поиск и "похожие объявления" и эти 2 части генерируют большую часть траффика на сайте. Поиск обрабатывает около 140 млн запросов в сутки, размер индекса - 3Гб. В кластере 16 серверов и на всех серверах одинаковые индексы.
Каждые 20 минут запускается ПОЛНАЯ переиндексация, которая длится 20 минут. Есть несколько различных индексов для разных целей + главный индекс. В качестве источника данных для индексации используют отдельную реплику базы данных, в которую реплицируют только нужные таблицы и Matreialized Views - ы только с активными объявлениями. При этом индексы строятся параллельно - просто через bash запускаются несколько экземпляров Sphinx indexer, каждый на свой индекс. После окончания процесса новые индексы разносятся по поисковым серверам с помощью uftp + rsync где запускается процедура ротации индексов.
Помимо фронтенда, Sphinx используют в бэкофисе, где успешно используют распределенный индекс.
Лайфхаки:
- не используют MVA ибо работает медленнее, для каждого параметра отдельный атрибут.
- при пагинации если offset > total_matches / 2 то сортируют результат в обратном порядке
- Индексы хранят в tmpfs (фактически в памяти).
- В качестве протокола общения используют SphinxQL.
- Не используют Live Update индексов, т.к. когда пробовали, получили быстрое снижение производительности, ну и нет необходимости.
- Стараются использовать Multi Query, ибо быстрее.
- Не один индекс! Разбивают индекс по категориям на кусочки.
Меня впечатлило в этом докладе то, что использовали простые и, в каком-то смысле, наколенные решения. Ну и здорово, что реальный опыт, конкретные примеры, success story) Люблю такие доклады.
Макс Лапшин. "erlyvideo. Использование эрланг в видеостриминговом сервере".
Я сам уже достаточно давно интересуюсь этим языком и OTP платформой, почитываю книжечку, пишу HelloWorld-ы и думаю даже в будущем начать разрабатывать на нем. Python уже поднадоел, а другие языки не имеют принципиально ничего особенного.
Так вот, про доклад. В Java-подобных языках имеются проблемы с параллельным программированием: Stop The World сборщик мусора, проблемы с обработкой ошибок (утечка ресурсов, слишком много кода посвящено обработке ошибок). Ну и всякие синхронизации/дедлоки само собой.
В отличие от них, у Erlang совершенно другой подход. Для параллелизма и изоляции ошибок используются легковесные процессы, существующие только внутри Erlang VM и дающие очень маленький оверхед (можно запускать миллионы таких процессов на одной машине). Ссылки отсутствуют как таковые, все данные немутабельны. Ошибки не обрабатываются программистом, описывается только HappyPath, в случае возникновения ошибки падает только процесс-обработчик (освобождая свои ресурсы) и тут-же перезапускается процессом - супервизором. У каждого микропотока собственный сборщик мусора, который работает независимо от остальных (т.е. нет моментов, когда вся система целиком встает колом из за активации GC). Дополнительные плюшки:
- Обновление кода сервисов без перезапуска и без даунтайма
- Прозрачная работа в кластере (можно запустить микропроцесс и общаться с ним на удаленной машине точно так же как и на локальной)
- Встроенный в VM асинхронный IO с синхронным API (нет лапши из коллбеков).
- Удобная интроспекция работающей системы (можно удаленно подключиться к работающей системе и посмотреть где что происходит, какой процесс потребляет ресурсы и чем он именно занимается).
- Удобная работа с бинарными данными.
- Автоматическое распараллеливание по ядрам процессора.
Ну и конечно же упомянул проблемы Node.JS, спасибо, это всегда полезно)
Рассказал немного про удобство работы с видео-потоками в Erlang (долгоживущие соединения, неустойчивая внешняя среда, битые данные. ошибки). Легко поддерживать старый код, т.к. кода мало)
От себя - т.к. эрлангом сам интересуюсь, ничего нового для себя не узнал, но все равно было интересно и приятно послушать.
Александр Титов, skype. "Инженерный дзен. Непрерывные изменения"
Долгие релиз-циклы это потеря денег для компании и увеличение числа ошибок в продакшне. Нельзя допускать долгих релиз-циклов. Каждая новая фича - релиз, но с возможностью быстро откатиться в случае необходимости.
Инструментарий:
- Chef - основной инструмент. Управление конфигурацией серверов, инфраструктурой, одновременно и живая документация на инфраструктуру, версионирование.
- vagrant - удобная оболочка для virtualbox + DSL для эмуляции различных инфраструктур
- Юнит-тесты само собой
- Jenkins
"Проповедует" devops - т.е. когда разработчики являются одновременно и админами: "Уметь и софт написать и конфиг Nginx подправить".
Доклад понравился, нужно обдумать и посмотреть как сейчас в нашей организации это устроено. Возникла идея пригласить докладчика к нам на консультацию... еще посоветуюсь с руководством.
Лев Валкин в кулуарах.
Успел поспрашивать как в Echo используются фичи Erlang, так вот:
- Активно используют живое обновление кода
- Активно используют Erlang-кластеризацию (межнодное взаимодействие). В кластер объединены не все сервера, а разбиты по группам.
- Используют message-passing без хаков
- Используют юнит-тесты и какую-то библиотеку для "фаззинга" (кажется QuickCheck)
- Часто тестируют код "на живую"-прямо на продакшне: "У нас 50 000 запросов в секунду, если и есть ошибка, то это проявляется сразу".
- Не используют dialyzer, но собираются начать.
- Для тяжелой математики используют OCaml
Лев Валкин, echo. "Ульяновск как яйцо силиконовой долины. Инкубация".
Единственный доклад не по программированию, который я посетил. Для начала предистория. Лев Валкин - основатель стартапа Echo родом из Ульяновска. Сейчас живет в USA, а команда разработки находится в Ульяновске. Ну и он всячески, не безуспешно, старается развивать и поддерживать IT движуху в этом городе. В докладе рассказал о том, в чем, по его мнению, заключается секрет развития силиконовой долины и чего не хватает Ульяновску для того чтобы стать "Российской силиконовой долиной".
Успешному развитию силиконовой долины (для краткости далее - СД) поспособствовали:
- удаленность от крупных городов бизнес-центров, в которых существовали крупные агрессивные компании
- Хороший климат) Упрощает коммуникацию.
- Взаимодействие с университетами
- Отсутствие государства и политиков
- Кажется, упоминалась небольшая территория (все рядом)
Так же пояснил важный момент: в СД развиваются и всячески поощряются горизонтальные связи между компаниями между специалистами из одной области. Т.е. программисты одной компании обмениваются знаниями с программистами другой, менеджеры - с менеджерами, техподдержка с техподдержкой и т.п. И это очень важно в ситуациях, когда знания специалиста бывают не до конца востребованы в его компании, но могут пригодиться кому то еще. Не менее важен и "обмен" специалистами.
Про Ульяновск: плюсы это то, что он удален от Москвы (мало сильных конкурентов, спецы не сбегают в Москву), довольно большая концентрация IT компаний,
погода, небольшая территория. Минусы - не развиты горизонтальные связи и обмен опытом.
Порекомендовал для удержания и повышения мотивации сотрудников использовать profit-sharing (опционы и т.п.).
От себя - давно наблюдаю, не особо в курсе как развиваются IT бизнесы, появляются ли новые компании в Ульяновске, но какая-то IT движуха там явно есть. Тот - же UlCamp например, присутствие Echo с вакансиями на которые люди из Москвы приезжают...
Аня Степанян, Undev. "Как мы делали webvybory2012"
Доклад о том, с какими трудностями пришлось столкнуться команде UnDev при разработке такого масштабного проекта в столь сжатые сроки и о том, как они героически с ними боролись.
Трудно выбрать хорошие камеры. Медленный интернет на многих участках (до 128кбит/с), часть компьютеров за NAT. Есть специальные требования к компьютерам. Заказы в огромных количествах. В итоге имелось 10 различных комбинаций оборудования. На тестирование очередного релиза на всех конфигурациях уходят сутки. Были проблемы связанные с тем, что официально адреса участков публикуются за месяц до выборов, поэтому пришлось составлять свою базу адресов, с которой были проблемы и неточности - корректировали вручную.
Сам сайт был практически статическим (JSON дампы), база данных - PostgreSQL. Языки программирования: Ruby,Python, CoffeeScript, работа с видео на ObjC.
На этом первый день конференции закончился, народ довольно быстро разошелся, да и я тоже пошел погулять по городу. Впереди еще один день конференции, продолжение следует...