Как работает система раздачи картинок на TJournal

Я хочу рассказать, как мы отдаём статику (картинки) всем посетителям TJournal. И заодно протестировать новый редактор в «боевом» режиме.

С самого начала все загружаемые на TJ картинки были вынесены отдельно, чему мы много раз радовались при переезде с сервера на сервер, потому что копировать по сети гигабайты и гигабайты картинок, каждая из которых весом максимум пара сотня килобайт — то ещё мучение.

Сначала мы использовали Amazon S3 (старые статьи до сих пор хранят ссылки на амазоновское облако) и до сих продолжаем платить примерно $10 в месяц за хранение и трафик оставшихся там картинок. Затем, как только у Selectel появился аналогичный сервис, перешли на него, чтобы сократить стоимость и увеличить скорость загрузки.

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

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

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

А вот чтобы загружать файлы на сервер, пришлось поднимать apache и настраивать там webdav. Это классический API, им пользуются, например, в Яндекс.Диске.

К сожалению, пропускная способность сервера ограничена 100 мегабитами в секунду, и в моменты пиковой нагрузки, нам стало не хватать выделенной полосы, чтобы раздать картинки всем посетителям.

Можно было докупить ещё 100 мегабит, но выгоднее оказалось арендовать сервер на распродаже (и ещё 100 мегабит в комплекте). Теперь проблема заключалась в том, чтобы загружать картинки надо было только на один сервер, а раздавать сразу с двух.

Также надо было распределить раздачу картинок равномерно между двумя серверами. В этот момент мы уже понимали, что серверов может быть и два, и три и пять. Классическим решением этой задачи является Round Robin DNS — каждому домену для статики присваивается несколько ip-адресов, каждый из которых готов обслужить запрос. DNS-сервер отдаёт клиентам эти адреса в случайном порядке, обеспечивая равномерное распределение (на каждый сервер трафик льётся пропорционально).

На помощь пришёл lsyncd и этот пост на Хабре. Lsyncd — это такая программа, которая мгновенно синхронизирует файлы между серверами. На самом деле всем понятно, что не мгновенно, поэтому надо что-то отдавать в тот момент, когда пользователь запросил картинку с сервера, который её ещё не получил. В таком случае мы заставляем этот сервер пойти и самому забрать картинку с главного.

Ещё один важный момент — количество одновременных запросов к одному домену — многие браузеры ограничиваются максимум восемью, то есть если использовать один домен для всех картинок, они будут загружаться пачками по несколько штук. Не круто.

Поэтому мы научили nginx отвечать на любой запрос к доменам типа static34.cmtt.ru, где 34 — случайное число, генерируемое при загрузке картинки. Таким образом мы заставляем браузер загружать все картинки на странице одновременно.

Сейчас посетителей TJ обслуживают три маломощных сервера (Intel Core2Duo E8400 3.0 ГГц, 6 ГБ DDR3) под кодовыми именами Джиф-1, Джиф-2 и Джиф-3.

Третий нам пришлось поднимать в авральном режиме во время одной из трансляций презентации Apple, когда хлынувший поток желающих следить за фотографиями новых айфонов превысил 300-400 мегабит.

Несколько раз к нам обращались представители различных CDN-сервисов, но услышав, что трафик в 150-250 мегабит в секунду мы обслуживаем за 8 000 рублей в месяц, они разворачивались и уходили.

#tjdev