Основные тезисы конференции HighLoad++ 2011

    imageВ октябре 2011 года в Москве проходила ежегодная конференция разработчиков высоконагруженных проектов HighLoad++.
    Решил поделиться с читателями основными тезисами с конференции. Поскольку вся информация открыта и доступна на странице конференции, решил что собрать все тезисы вместе будет не такой уж и плохой затеей. Сразу отмечу, что в отчёте не содержится детальной информации о каждом докладе — затронуты лишь ключевые моменты.
    Итак, о чём говорилось на HighLoad++ 2011.

    Проектируем облачный веб-сервис «по-взрослому” / Сергей Рыжиков (1С-Битрикс)

    У 1С три дата-центра, находящиеся в России, США и Европе. Потеря связи между датацентрами может занимать часы. Между серверами БД настроена асинхронная мастер-мастер репликация.
    Вся архитектура строится из сервисов Amazon Web Services.
    Для статического контента используется Amazon S3. Преимуществом, помимо всего прочего, является низкая цена такого решения по сравнению с EBS.
    Используется Elastic Cloud Balancing, CloudWatch и Auto Scaling.
    Машины с БД — на EC2. Каждая с 17.1Gb RAM. Из EBS-дисков строятся software RAID-массивы. Выбран RAID-10, как наиболее быстрый и надёжный.
    Используется InnoDB.
    Бэкапы делаются с помощью snapshots в EC2 с помощью заморозки (freeze) ФС.
    Amazon RBS не используется по следующим причинам:
    • Нет полноценного root в базе
    • Не прозрачно
    • Риск долгого downtime

    Архитектура хранилища бинарных данных на Одноклассниках / Александр Христофоров, Олег Анастасьев (Одноклассники)

    Первоначально оценивалась возможность использования one-db. При этом были следующие ограничения:
    • Плохая производительность
    • Длительные бэкапы (до 17 часов)
    Оценивались также HDFS, Cassandra, Voldemort, Krati.
    В текущем решении реализованы кластер zookeeper и кластер хранилищ.
    На каждом узле кластера хранилищ находятся по N хранилищ. В каждом из них на отдельном диске располагаются сегменты данных (256 Mb) и RAID1 массив логов. Обработкой IO занимается NIO Socket Server (Mina).
    Резервирование происходит с помощью xfs_io.
    Для индекса используется хэш-таблица на основе обычного массива. Хранится прямо в direct memory.
    При старте проверяется целостность данных. Логи синхронизируются и чистятся по мере необходимости.
    Фактор репликации — 3.
    Маршрутизация происходит на основе партиционирования. Вычисляется хэш ID и вычисляется остаток от деления на N хранилищ. Вычисленное значение партиции ищется в таблице маршрутизации и ищется диск с данными.
    Используется концепция регионов. Для расширения не требуется перемещение данных.
    Zookeeper используется для координации. Его преимущество — надёжность и производительность. В Zookeeper хранятся следующие данные:
    • Доступные сервера и их адреса
    • Местоположения и статусы дисков
    • Таблицы маршрутизации
    • Распределённая блокировка
    Система развёрнута на 24 сервера.: 20 — хранилища, 2 — логи, 2 — резервные.

    Почему не стоит использовать MongoDB / Сергей Туленцев

    Основные тезисы доклада:
    • Map/Reduce медленный и однопоточный
    • Каждая операция в map/reduce накладывает read или write lock
    • Проблема Memory Mapped Files — плохое управление памятью в системе
    • Не очень удобно, когда все шарды равноправны. Встроенный автошардинг плохо конфигурируется
    Тем не менее, автор говорит, что по умолчанию MongoDB использовать можно. Пока не станет вопрос о скорости обработки отдельных запросов и нужды в возможности реляционных БД.

    Впервые в рунете: сказ о 100М писем в день / Андрей Сас (Badoo)

    Используется асинхронная отправка. Очередь на отправку реализуется на основе файлов — нативные средства, логирование, простота чтения/записи.
    Вместо sendmail используется SSMTP-клиент.
    In-memory не используется для обеспечения отказоустойчивости (страх потерять письма).
    Реализован локальный кэшер DNS-запросов, увеличено количество DNS и SMTP воркеров.

    Большая книга рецептов или часто задаваемые вопросы по управлению сложными системами / Александр Титов, Игорь Курочкин (Skype)

    Предлагается использовать инструмент Cobbler. Инструмент поддерживает широкий диапазон дистрибутивов linux, имеет удобные механизмы взаимодействия.
    Для управления конфигурацией — Chef.
    Мониторинг — Zabbix API.
    Бэкапы статистики, БД и репозиториев.

    Проектирование крупномасштабных приложений сбора данных / Josh Berkus

    Для сбора статистики о падениях рекомендуется использовать проект Mozilla Soccoro. Для хранения информации используется hbase, как наиболее масштабируемое решение. При этом в hbase хранятся сами данные (40 Тб на 30 узлах). За хранение метаданных (500 Гб) отвечают 2 сервера PostgreSQL. Балансировкой нагрузки занимаются 6 серверов.
    В качестве инструмента для управления конфигурацией — puppet.

    12 вариантов использования Redis — в Tarantool / Александр Календарев, Константин Осипов (Mail.ru)

    Tarantool – NoSQL СУБД для хранения самых “горячих” данных. Tarantool хранит все данные в оперативной памяти и регистрирует все изменения на диске, таким образом, гарантируя надежность данных в случае отказа. Хранение данных в памяти позволяет выполнять запросы с максимальной производительностью – 200-300k запросов в секунду на обычном современном оборудовании.
    Масштабирование предлагается делать на основе tarantool proxy и шардов.
    В скором времени tarantool обзаведётся также следующими возможностями:
    • Поддержка транзакций
    • Мастер-мастер репликация
    • Менеджер кластера
    • Балансировщик нагрузки
    Таким образом, представители mail.ru говорят о Tarantool как о замене Redis. Уступающей по произвоительности ~на 5%.

    Секреты сборки мусора в Java / Алексей Рагозин

    Подсчёт ссылок в памяти — не самое лучшее средство. Не спасает от циклических графов, плохо сочетается с многопоточностью. Также это 15-30% CPU загрузки.
    Согласно гипотезе о поколениях, большинство объектов умирают молодыми. Пока они являются таковыми, на них ссылается небольшое количество других объектов. Таким образом, разделяя хранение “молодых” и “старых” объектов, мы можем добиться увеличения производительности.
    Для таких JVM, как HotSpot, присутствует множество ключей. Информация о возможности использования ключей содержится в блоге Алексея.
    Рекомендуется использовать Concurrent Mark Sweep GC для приложений, чувствительных к паузам при сборке мусора. Включается, в частности: -XX:+ExplicitGCInvokesConcurrent
    CMS зачастую производят сборку мусора прямо во время работы приложения: объекты “нового” поколения собираются в режиме stop-the-world (довольно быстрая операция), при том что “старое” поколение собирается параллельно и за продолжительное время. Соответственно, приложение должно удовлетворять условиям гипотезы о поколениях.
    В результате паузы могут достигать не более 150 мс для 32 Гб кучи.
    Как вариант — использование off-heap memory. Но это уже гораздо более сложная задача.

    Apache Cassandra — еще одно NoSQL хранилище / Владимир Климонтович

    Apache Cassandra = Amazon Dynamo + Google Bigtable.
    Используется технология партиционирования данных на основе топологии Token Ring. Репликация осуществляется также на основе данной топологии. В этом Cassandra схожа с Amazon Dynamo.
    Из Bigtable взята модель данных key/value. Доступны сложные запросы, индексы (вещь бесполезная).
    LIFO механизм кэширования запросов.
    Проще всего масштабироваться в 2 раза. Тогда диапазоны сегментов партиций просто делятся на 2.
    Ноды общаются друг с другом на основе протокола Thrift.

    AJAX Layout / Олег Илларионов (ВКонтакте)

    Страница разбивается на несколько частей-iframe, которые отправляют независимо AJAX-запросы.
    Активно используется HTML5, в частности — local storage.
    Параллельно подключаются статика и контент.
    Кэшируются страницы. Используются свои заглушки для работы с History API браузера. При переходе назад — изымается дерево из DOM, копируются переменные окружения.
    Для быстрого поиска по контенту поиск проходит на клиенте.

    Построение облачного хранилища для хранения и доставки статического контента на основе интеграции Nginx и Openstack Swift / Станислав Богатырев, Николай Двас (Clodo)

    Для использования в облаках правильным решением представляется объектное хранилище, такое как Amazon S3 или Rackspace Cloud Files. Облачное хранилище Clodo построено с использованием технологии Swift (лежащей в основе Rackspace Cloud Files) и нацелено, прежде всего, на хранение и раздачу контента для веб-сайтов — основной акцент при его построении сделан именно на это применение — в отличие от более общих S3 и Cloud Files. Хранилище Swift медленно работает при раздаче контента для большого количества клиентов. Поэтому в качестве фронтенда был выбран nginx, модифицированный в двух аспектах:
    добавлен мультизонный кэш (позволяет экономить 40% дискового пространства на дорогих дисках, используемых для кэширования);
    добавлен механизм управления и пообъектной, и поконтейнерной очистки кэша при использовании кластера фронтендов с независимым nginx на каждом.

    P.S. Надеюсь, что статья не вызовет негативную реакцию из-за своего характера описания (предельно сжатая информация, тезисы из слайдов и речи докладчиков). В статье не описаны все доклады, на официальном сайте можно найти информацию о всех недостающих выступлениях.

    P.P.S. Спасибо Олегу Бунину и представителям Онтико за организацию HighLoad++, ждём следующей конференции в 2012 году!
    • +28
    • 3,7k
    • 2
    Поделиться публикацией

    Комментарии 2

      +1
      Блин, мужики… А как на счёт тура по ехЮССР странам? Ну хотя бы по столицам…
        0
        Parallels про управление памятью и Badoo с pconnect — интересные доклады. Хотя, на слайдах будет поскучнее, докладчики были очень харизматичны.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое