Техническая архитектура Connect.ua
Копирую статью - "".
Connect.ua - это первый украинский социальный сервис. За два года проект вырос в достаточно крупный, а следовательно имеет свою собственную историю и роста.
Во время роста мы перепробовали большое количество технологий и подходов, которыми я и хочу поделиться в этой статье.
Наши показатели и цифры
Некоторые цифры проекта
- 720 тыс. пользователей
- 2 миллиона фотографий
- 400 тысяч видео роликов
- 20 миллионов личных сообщений
- 50 миллионов оценок в ЖЖОТ
- 25 миллионов событий в ленте новостей
- 40 миллионов отправленных “Подмигнуть”
Технические показатели
- 500 запросов в секунду на MySQL
- 300 активных соединений на фронте + 200 активных соединений на медиа серверах (HTTP)
- 1.5 тысячи запросов в секунду на каждом из бекендов
- 8 миллионов запросов к бекендам в день
- 7 Тб медиа (видео + аудио + фото)
- 3 сервера баз данных
- 4 бекенд сервера
- 1 фротенд
- 4 медиа сервера
- 2 сервера транскодирования
- 20 Гб памяти под
Технологии
Технологий используется огромное множество, причем динамика использования новых технологий очень высокая. За год на проекте появилось множество улучшений, связанных с новыми техническими решениями.
- MySQL
- Sphinxsearch
- PHP
- PHP-FPM
- Eaccelerator
- Imagemagick
- FFmpeg
- Mencoder
- Flvtools
- GFS
- Munin
- Nagios
- Xhprof
- Minify (библиотека сжатия статики)
- Linux shell
Далее наш опыт, архитектура, решения, ошибки и выводы:
Мониторинг и статистика
Как только появляются первые признаки тормозов или отказов на сайте, первым делом устанавливайте систему статистики. Мы поставили Munin и очень довольны. Множество плагинов, практически для любых технических решений. Очень просто писать свои плагины на любом интерпретируемом языке (мы пишем на PHP).
Для мониторинга используем Nagios.
Система статистики не только помагает обнаруживать проблемы, но и прогнозировать расширение.
Оборудование
Мы используем подход горизонтального расширения, а не вертикального. Поэтому мы делаем выбор в сторону недорого оборудования. Что это дает:
- Избавляет от SPOF (единых узлов падения)
- Покупая дорогое и мощное оборудование, Вам нужно больше платить и за все остальное (коммутаторы, сеть, поддержка и т.п.)
- Стоимость вертикального роста имеет экспоненциальный характер
- В любом случае вертикальный рост ограничен
СУБД: не в MySQL проблема, проблема в эффективности
Для начала, мы отказались от использования классической схемы репликации “запись на мастер” + “чтение с реплики”. При асинхронной репликации время отставания реплики неконтролируемо, что очень усложняет логику приложения. На реплику идут только агрегатные запросы, которые не чувствительны к небольшим задержкам (лучшее видео и т.п.).
В качестве архитектурного решения мы используем федерацию (вертикальное разделение СУБД по таблицам). Часть таблиц работает на одном сервере, часть на другом. Необходимость федерации появилась, когда некоторые особо большие таблицы препятствовали эффективной работе буфера MySQL.
Движки таблиц - InnoDB для всех таблиц, кроме случаев с полностью статическими таблицами (города, страны и т.п.) - для них MyISAM.
Для полнотекстового поиска используем Sphinx. Работает по схеме дельта индексации. Самая тяжелая часть - полная переиндексация, поэтому запускаем ее раз в неделю. Планируем внедрить объединения индексов (index merging).
Наиболее тяжелые функциональные части для СУБД - это личные сообщения и лента новостей. Ленту новостей недавно перевели на . Стратегию выбрали масштабируемую, у каждого пользователя есть свой личный список событий, который обновляется, когда генерируется новое событие. Это позволит очень легко масштабировать этот функционал.
Что мы делали для оптимизации нагрузки
- Кеширование (подробнее - ниже)
- Тюнинг настроек сервера MySQL - никогда не используйте настройки по умолчанию
- Оптимизировали (и все еще продолжаем) запросы. EXPLAIN + maatkit - это наш набор оптимизатора.
- Тяжелые запросы зачастую можно упростить на порядки выкинув малозначимые части логики
- Для особо тяжелых и не поддающихся ускорению запросов есть слейв
- Денормализация + индексация - постоянные задачи
Кеширование: кешируйте все и еще немножко
Кеширование - первое, что мы начали делать для приложения. выбрали по нескольким причинам: простой и эффективный, поддержка распределенного кеширования, встроенный алгоритм консистентного хеширования (необходимо при добавлении новых серверов), поддержка сессий PHP.
Сейчас хитрейт доходит до 95%, показатели вынужденного вытеснения из памяти стремятся к нулю.
Стратегию кеширования используем довольно простую. Для списков кешируем только первичные ключи. Для тяжелых запросов используем дубликаты с разным временем жизни. Ввиду большого количества персональных выборок, пришлось реализовать собственный механизм пространств имен для того, чтобы иметь возможность обновлять несколько объектов одновременно.
Система кеширования носит двухслойных характер: кеш приложения => .
Клиентская оптимизация
Клиентская - это второе, что мы начали делать для . Клиентская позволила увеличить скорость загрузки страниц в несколько раз. После базовой клиентской части, удалось повысить показатель просмотров страниц в полтора раза. Кроме всего прочего клиентская позволяет сэкономить канал.
Что мы делали:
- Gzip всего
- Склеивание и сжатие статики
- Вынос статики на другой домен
- Установка необходимых заголовков для кеширования на клиентах
Сейчас наиболее медленное место в клиентской части - это система управления банерными показами.
Медиа
Наиболее ресурсоемкой частью проекта является то, что относится к медиа. Поэтому все медиа ресурсы изолированы от основной части системы. В качестве стратегии роста используем разделение по серверам. Каждый сервер работает независимо от других, что делает всю систему устойчивой к сбоям.
PHP
С PHP было меньше всего проблем. Единственным шагом, который привел к ощутимому росту скорости работы, стала установка eAccelerator’a. Большинство изменений в коде были связаны с архитектурными изменениями.
Для профилирования используем XhProf - хорошо подходит для работы в продуктивных условиях.
Что мы планируем
- Переводить часть логики с MySQL на key=value базы данных
- Внедрить систему очередей сообщений
- Оптимизировать клиентскую часть дальше
- Искать затычки и исправлять их
В качестве итога
После проделанной работы мы пришли к нескольким простым правилами, которыми пользуемся и сейчас:
- Если решение работает у кого-то, это еще не значит, что оно будет работать для Вас
- Во многих случаях приходиться экспериментировать. Нужно позаботиться о том, чтобы небольшие изменения в системе не вызывали огромных трудностей
- Думайте о росте заранее, но не решайте не существующих проблем
- Многие технологии умеют гораздо больше, чем кажется - гораздо больше
- Творчество Ваш самый необходимый инструмент
- Не делайте того, о чем ничего не знаете
Надеюсь будет полезно!