Блог - Linux, программирование, Я!

ОбщекомпьютерноеНа стачку! Впечатления и обзор конференции. День 1.

Давненько не бывал на конференциях, наконец-то удалось совместить наличие хорошей конференции с возможностью на нее пойти. И так, 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
Что-ж, меня это сильно успокоило, ибо рассказы про ErlyVideo и Ejabberd заставляли усомниться в том, что горячая замена кода, кластеризация и чистый message-passing совместимы с суровой реальностью. Просто в ErlyVideo очень специфические задачи.

Лев Валкин, echo. "Ульяновск как яйцо силиконовой долины. Инкубация".

Единственный доклад не по программированию, который я посетил. Для начала предистория. Лев Валкин - основатель стартапа Echo родом из Ульяновска. Сейчас живет в USA, а команда разработки находится в Ульяновске. Ну и он всячески, не безуспешно, старается развивать и поддерживать IT движуху в этом городе. В докладе рассказал о том, в чем, по его мнению, заключается секрет развития силиконовой долины и чего не хватает Ульяновску для того чтобы стать "Российской силиконовой долиной".

Успешному развитию силиконовой долины (для краткости далее - СД) поспособствовали:

  • удаленность от крупных городов бизнес-центров, в которых существовали крупные агрессивные компании
  • Хороший климат) Упрощает коммуникацию.
  • Взаимодействие с университетами
  • Отсутствие государства и политиков
  • Кажется, упоминалась небольшая территория (все рядом)

Так же пояснил важный момент: в СД развиваются и всячески поощряются горизонтальные связи между компаниями между специалистами из одной области. Т.е. программисты одной компании обмениваются знаниями с программистами другой, менеджеры - с менеджерами, техподдержка с техподдержкой и т.п. И это очень важно в ситуациях, когда знания специалиста бывают не до конца востребованы в его компании, но могут пригодиться кому то еще. Не менее важен и "обмен" специалистами.

Про Ульяновск: плюсы это то, что он удален от Москвы (мало сильных конкурентов, спецы не сбегают в Москву), довольно большая концентрация IT компаний, погода, небольшая территория. Минусы - не развиты горизонтальные связи и обмен опытом.

Порекомендовал для удержания и повышения мотивации сотрудников использовать profit-sharing (опционы и т.п.).

От себя - давно наблюдаю, не особо в курсе как развиваются IT бизнесы, появляются ли новые компании в Ульяновске, но какая-то IT движуха там явно есть. Тот - же UlCamp например, присутствие Echo с вакансиями на которые люди из Москвы приезжают...

Аня Степанян, Undev. "Как мы делали webvybory2012"

Доклад о том, с какими трудностями пришлось столкнуться команде UnDev при разработке такого масштабного проекта в столь сжатые сроки и о том, как они героически с ними боролись.

Трудно выбрать хорошие камеры. Медленный интернет на многих участках (до 128кбит/с), часть компьютеров за NAT. Есть специальные требования к компьютерам. Заказы в огромных количествах. В итоге имелось 10 различных комбинаций оборудования. На тестирование очередного релиза на всех конфигурациях уходят сутки. Были проблемы связанные с тем, что официально адреса участков публикуются за месяц до выборов, поэтому пришлось составлять свою базу адресов, с которой были проблемы и неточности - корректировали вручную.

Сам сайт был практически статическим (JSON дампы), база данных - PostgreSQL. Языки программирования: Ruby,Python, CoffeeScript, работа с видео на ObjC.

На этом первый день конференции закончился, народ довольно быстро разошелся, да и я тоже пошел погулять по городу. Впереди еще один день конференции, продолжение следует...

  1. 2020-05-15 22:10:29 | #

    Прекрасная была пора. Фантастично звучит, видел подобное только в новых сериалах онлайн про путешествия. Команда отважных астронавтов отправляется на поиски пропавшего коллеги. Так же они перед полетом смотрели фильмы с субтитрами онлайн русскими в хорошем качестве. Они словно герои скандинавских многосерийных фильмов сражаются за матушку Землю.