Введение

Объем данных многих популярных сайтов быстро растет. Кроме проблемы резервного копирования возникает и проблема быстрой раздачи контента клиентам, чтобы все могли его, контент, качать на высокой скорости. Для системного администратора задача даже редкого, ежедневного резервного копирования такого объема файлов крайне сложна, а менеджер веб-проекта просыпается в холодном поту от мысли о предстоящей профилактике дата-центра на 6 часов.

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

Двухуровневая конфигурация Front-End и Back-End

NGINX или аналогичный обратный прокси в режиме двухуровневой конфигурации позволяет эффективно раздавать файлы, особенно по медленным каналам. При этом серьезно снижается нагрузка на сервер и повышается в целом производительность веб-приложения: NGINX раздает кучу файлов, Apache или PHP-fpm обрабатывают запросы к серверу приложений. Такие веб-приложения живут хорошо, пока объем файлов не увеличивается до, скажем десятков гигабайт. Когда несколько сотен клиентов начинают одновременно скачивать файлы с сервера, а памяти для кэширования файлов в ОЗУ недостаточно: диск, а потом и RAID просто умрёт.

Сервер статики

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

Чтобы более эффективно раздавать статику с разных доменов, ее выносят на отдельный сервер(а) статики. Полезно на этом сервере использовать режим кэширования NGINX и "быстрый" RAID (чтобы побольше клиентов требовалось для постановки диска «на колени»).

Делают домены что-то типа:
www.mysite.ru
img.mysite.ru
js.mysite.ru
css.mysite.ru
download.mysite.ru
и т.п.

CDN

При дальнейшей работе веб-проекта организаторы начинают понимать, что раздавать из своего дата-центра даже с очень быстрых дисков или даже SAN - не всегда эффективно:

• Ценный клиент начал качать файл с московского сервера из Владивостока по узкому каналу.
• Случилась беда, обрыв питания прервал связь 10000 клиентов, качающих новый дистрибутив.
• Наоборот, мог случиться такой наплыв клиентов, что стало не хватать серверной мощности раздавать одновременно столько статики, либо уже каналы загружены до предела.

Становится понятно, что нужно быть как можно ближе к клиенту и отдавать клиенту столько статики, сколько он хочет, на максимально возможной быстрой скорости, а не сколько мы можем отдавать со своего сервера(ов). Эти задачи в последнее время начала эффективно решать технология CDN.

"Вертикальное" масштабирование раздачи статики

Веб-проект постепенно распухает. Копится все больше и больше файлов для раздачи. Они хранятся централизованно в одном ДЦ на одном или группе серверов. Делать резервную копию такого количества файлов становится все дороже, дольше и сложнее. Полный бэкап делается неделю, приходится делать снепшоты, инкременты и прочие вещи, увеличивающие риск потери данных.

Что будет, если:

• Рассыпятся диски на файловом хранилище (рейд10 может умереть, забрав с собой сразу пару зеркальных дисков и это - случается не очень редко) и придется доставать файлы из резервной копии в течении двух-трех недель.
• В дата-центре вас с утра обрадовали сообщением, что диски рассыпались, а ваши бэкапы в результате ошибки софта - безвозвратно повреждены (такое в Амазоне с "1С-Битрикс" один раз произошло).
• Пройдет рекламная акция и начнется наплыв клиентов из Дальнего Востока или из Европы - и вы не справитесь с эффективной раздачей такого количества статики.

В инфраструктуру вложено уже столько денег, а риски, причем немалые, всё ещё остаются.

Распределенная файловая система

Для проекта с большим бюджетом есть вариант развернуть в нескольких дата-центрах свою распределенную файловую систему. Вариант достаточно сложный для реализации и администрирования, но если есть профессионалы, то вполне реализуем.

Виртуальная файловая система

Одним из наиболее эффективных решений является использование возможностей известных облачных провайдеров. Они дают возможность хранить неограниченный объем ваших файлов в облаке с очень высокой надежностью по очень привлекательным, особенно при большом объеме данных, ценам. Провайдеры организовали на своих мощностях описанные выше распределенные файловые системы. Эти системы - высоконадежные и размещенные в нескольких дата-центрах, разделенных территориально. Более того, эти сервисы, как правило, тесно интегрированы в сеть CDN данного провайдера. Т.е. вы будете не просто удобно и дешево хранить свои файлы, но и их максимально удобно для клиента раздавать.

Для этого нужно настроить на своем веб-проекте прослойку или виртуальную файловую систему (или аналог облачного диска). Среди бесплатных решений можно выделить FUSE-инструменты (для linux) типа s3fs.

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

Модуль "Облачные хранилища"

Последний вариант реализован "из коробки" в модуле Облачные хранилища, который позволяет перенести хранение файлов вместо локального сервера веб-сайта в "облака". Модуль позволяет хранить данные отдельных модулей системы в разных облачных хранилищах. Это реально диверсифицирует файловое хранилище. Можно распределить файлы в зависимости от адреса или типа клиента. Можно распределить файлы в зависимости от типа информации: кто-то эффективно отдает легкую статику, кто-то тяжелый контент.