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

29 Ноя
2011

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

Впервые в рунете: сказ о 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.

Проектируем облачный веб-сервис «по-взрослому” / Сергей Рыжиков (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

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

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

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

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

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

Подсчёт ссылок в памяти — не самое лучшее средство. Не спасает от циклических графов, плохо сочетается с многопоточностью. Также это 15-30% CPU загрузки.
Согласно гипотезе о поколениях, большинство объектов умирают молодыми. Пока они являются таковыми, на них ссылается небольшое количество других объектов. Таким образом, разделяя хранение “молодых” и “старых” объектов, мы можем добиться увеличения производительности.
Для таких JVM, как HotSpot, присутствует множество ключей: aragozin.blogspot.com/2011/07/hotspot-jvm-garbage-collection-options.html
Рекомендуется использовать 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, копируются переменные окружения.
Для быстрого поиска по контенту поиск проходит на клиенте.

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

Первоначально оценивалась возможность использования 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 — резервные.

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

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

P.S. Спасибо Олегу Бунину и представителям Онтико за организацию HighLoad++, ждём следующей конференции.
По материалам Хабрахабр.



загрузка...

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

Наверх