В октябре 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 часов)
В текущем решении реализованы кластер zookeeper и кластер хранилищ.
На каждом узле кластера хранилищ находятся по N хранилищ. В каждом из них на отдельном диске располагаются сегменты данных (256 Mb) и RAID1 массив логов. Обработкой IO занимается NIO Socket Server (Mina).
Резервирование происходит с помощью xfs_io.
Для индекса используется хэш-таблица на основе обычного массива. Хранится прямо в direct memory.
При старте проверяется целостность данных. Логи синхронизируются и чистятся по мере необходимости.
Фактор репликации — 3.
Маршрутизация происходит на основе партиционирования. Вычисляется хэш ID и вычисляется остаток от деления на N хранилищ. Вычисленное значение партиции ищется в таблице маршрутизации и ищется диск с данными.
Используется концепция регионов. Для расширения не требуется перемещение данных.
Zookeeper используется для координации. Его преимущество — надёжность и производительность. В Zookeeper хранятся следующие данные:
- Доступные сервера и их адреса
- Местоположения и статусы дисков
- Таблицы маршрутизации
- Распределённая блокировка
Почему не стоит использовать MongoDB / Сергей Туленцев
Основные тезисы доклада:
- Map/Reduce медленный и однопоточный
- Каждая операция в map/reduce накладывает read или write lock
- Проблема Memory Mapped Files — плохое управление памятью в системе
- Не очень удобно, когда все шарды равноправны. Встроенный автошардинг плохо конфигурируется
Впервые в рунете: сказ о 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 обзаведётся также следующими возможностями:
- Поддержка транзакций
- Мастер-мастер репликация
- Менеджер кластера
- Балансировщик нагрузки
Секреты сборки мусора в 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 году!
