Раздача статического контента при большой нагрузке

Question

[Павел Осипов]

На одном проекте начальство придумало отдавать партнёрским сайтам баннер + небольшой JS файл (при нажатии на баннер скрипт получает текущие координаты юзера и перекидывает на наш сайт с ними в параметрах). Баннер + JS — это BN пакет. Для каждого партнёра могут быть разные или только свои пакеты.
И проблема в том, что первый же партнёр имеет 2.5 миллиона уников в неделю. А в планах ещё несколько таких партнёров найти, т.е. нагрузка будет расти сразу и по многу.

И вот задача, как организовать такую раздачу лучшим образом?
Сам проект написан на РНР.
Как вариант мы рассматривали CDN, но у нас всё же логика присутствует, показывать только определённое количество раз, возможность приостановить показ и т.п.
Поискав в сети, нашёл вот хорошую презентацию www.highload.ru/papers2009/12189.html

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



SS – Сервер статики, хранит и раздаёт статику
LB – Балансировщик нагрузки для начала видимо программный.
MS – (Main server) Сервер основного проекта
CM – (Content manager server). Сервер управления SS`ами, получает команды от MS и отправляет команды к SS.

Типы сообщений

SHOW, HIDE, DELETE

Задачи

SS

1. Хранить, удалять и отдавать контент BN
2. На каждом установлен Nginx, PHP, база MemcacheDB. У всех одинаковая конфигурация софта
3. Также имеет доступ к базе MemcacheDB на CM
4. В собственной базе MemcacheDB хранит текущие счётчики и статусы для всех BN и периодически синхронизирует их с CM
5. Имеет набор скриптов для обработки поступающих сообщений от CM

CM

1. Также хранит мастер-копии всех текущих BN`ов
2. Установлен Nginx, PHP, база MemcacheDB.
3. Может получать сообщения от MS и слать на SS
4. Может синхронизировать SS со своим внутренним набором BN`ов
5. Ведёт общую таблицу для всех BN`ов, со счётчиками, текущими статусами и пр.
6. Также ведёт таблицу доступных (IP ?) адресов всех SS`ов. И в случае добавления/удаления SS`а в принципе должно быть достаточно прописать/удалить его адрес в этой таблице.

Такой расклад. Опыта к сожалению мало в такого рода задачах, очень интересует мнение хабранарода.
Может не парится и перейти на облачный хостинг? Или на таких нагрузках там дюже цена растёт?

Заранее спасибо!

Answer 1

[pwlnw]

Чего-то ты загнался.
Если партнеры, в отличите о ваc, легко выдерживают такую нагрузку — отдай им на хранение баннеры и js-файл.

Comments

[pwlnw]

Разумеется, я имею ввиду, что CTR там не феноменальный и из этих 2.5 млн уников на баннер нажмут дай бог 5 тыс целевых посетителей, что вы нормально выдержите на обычном сервере.

Кстати, как они считают цифру уников в неделю? по дням ведь сложили?

[Павел Осипов]

Ну вот не получается им отдать эту статику, я бы с удовольствием!
А насчёт методики подсчёта посетителей, я не знаю конкретно, для меня это входные данные больше

[pwlnw]

Да как это не получается? Рекламодатель, который платит деньги, все получает обычно на блюдечке.

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

[Павел Осипов]

Ну есть чёткие требования:
1) Партнёры хотят добавлять в свою страницу только пару строк кода и никаких файлов себе заливать не хотят.
2) На нашей стороне нужно контролировать количество показов, из панели управления включать/выключать, смотреть статистику т.е. как раз и придётся каждую открутку в базу писать, хоть и накапливая их в мемкеше, менять вероятности показа для каждого банера в пакете.

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

И спасибо за ответы!

[DorBer]

Писать данные в память (Redis, MemcacheDB) и иногда скидывать на винт.

[Павел Осипов]

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

[pwlnw]

>Придётся каждую открутку в базу писать
А вы напишите простой анализатор лог-файлов — вот вам и запись откруток.
У вас счет ведь не на штуки, а на тысячи? Ну и нормально будет.

[Павел Осипов]

Спасибо за идею, сейчас взялись за идею на основе мыслей equand, но и парсить логи может пригодится. Спасибо!

Answer 2

[equand]

Можно сэкономить на LB переносом нагрузки на ДНС или Роутеры.
Отдавать со статов.
Вообще не вижу проблемы 2.5 млн. (правда не ясно сколько хитов будет) средний дедик без проблем выдержит — это же мелкие баннеры их с памяти напрямую будет отдавать, проблема будет только в настройках ос и ширине канала.
Если это хиты, то это всего лишь 56 хитов в секунду (на два файла) — даже апач справится, я уж не говорю про nginx.
Упираться Вы будете только в ширину канала и производительность ОС и сетевухи.

Comments

[equand]

Для примера: сервер, если считать по ночным часам, обслуживает в среднем 8672344 хитов в день (считал только ответ 200 для зипов и картинок, 304 и т.п. не считал), nginx этого даже не замечает (FreeBSD 8.1 оттюнингованная), нагрузка nginx 0.00%-1.75% процентов максимум (и то в пики). Система конечно IBM. Но процессор и в африке процессор, поэтому E5630 вообще не нагружен. Уверен другие системы тоже не заметят.

[Павел Осипов]

Да, я знаю, что Nginx такой трафик статики перемолотит даже на основном сервере, но это только первый партнёр и не известно сколько их таких будет в будущем и хочется сразу заложить удобство масштабирования.
А насчёт хитов, в принципе ведь не важно сколько народу к нам прийдёт, как я написал выше, есть требования, чтобы всё считать и всем управлять, т.е. каждый раз баннер будет видимо с уникальным URL и не кеширующимся
А операционка к стати у нас CentOS

[equand]

С CentOS мое знакомство было кратким и неблагоприятным, поэтому не могу сказать, во FreeBSD подобные вопросы решаются просто и хоть 1млн онлайн, главное чтобы памяти было достаточно (не помню соотношения для буферов уже к сожалению) и платформа железная крепкая и слаженная (второй или третьей ревизии, у нас для это Sun Fire x4150-4170 стоят, IBM x3550M3 был не лучшим выбором, т.к. сыровато железо, как и у Intel последней архитектуры).
Считать можно по логам, логи писать nginx кастомные умеет. Можно даже в реалтайме считать, если разобраться с модулем сислога nginx и поставить syslog-ng3.
Возможно все. Я думаю Вы врядли с баннерами упретесь во что-нибудь кроме производительности сетевой карты и корректности железа и дров для них.

[Павел Осипов]

ОК. Значит я так понял, Вы рекомендуете не заморачиваться такими разветвлёнными схемами, поставить один дополнительный сервер на FreeBSD + хорошее железо и он без проблем выдержит как текущие 2.5 миллионов в неделю, так и потенциальные 25 в неделю в будущем?
Это конечно многое упрощает и мне очень-бы хотелось, чтобы так всё и было!

[equand]

Да, только внимательно смотрите, что берете. У меня есть факты даже разной работы двух одинаковых сетевых карт, но от Intel и от Sun (чипсет тот же — igb). На Intel они вылетают под большой нагрузкой, на Sun проблем не было ни разу никаких с системами, что я перечислил.
Вам я советую ставить ОС с которой Вы лучше всего знакомы. Для меня просто FreeBSD это инструмент больше, все закавыки которого я знаю очень хорошо. Например с виртуализацией там довольно-таки хреново. Из Linux мне больше импонирует Debian.
И помните, 250 000 000 хитов в день это всего лишь 413 хитов в секунду, что довольно низкая нагрузка на самом деле, если смотреть не на среднюю, то будет что-то вроде 1250 в пики и 200 в 4 утра, что опять же мелочь.
Во FreeBSD придется следить за mbufs,, ошибками на интерфейсе (т.к. железо может быть плохим по качеству и не выдерживать).
И пару настроек ядра в /boot/loader.conf, еще придется добавить кое-что в sysctl.

[equand]

*250 000 000 хитов в неделю, в день это 3000 в секунду, что тоже не рекорд, тем более для баннеров.

[Павел Осипов]

Спасибо большое за столь обстоятельный ответ!!!
Как раз мне не хватало мнения человека в этом разбирающегося. Спасибо хабру и Вам equand.

Теперь я определился, будем делать только один дополнительный сервер для раздачи всей этой статики, это и проще реализовать и задела хватит на 100 раз большие нагрузки чем планируется сейчас. Хотя при проектировке всё же постараемся вложить возможность как можно более простого масштабирования путём добавления сервера.

[equand]

Без проблем, удачи Вам!
Вместо того, чтобы плодить nginx на всех серверах посмотрите в сторону haproxy — он поддерживает tcp splicing на уровне ядра в linux, может и 10 гбит/с раздачей статики забить на Core2 сервере не самой крутой комплекции. Даже на FreeBSD он больше впечатляет нежели nginx, единственное но — haproxy — это PROXY сервер только, но на LB в случае такого масштабирования самое то (он используется и в коммерческих железячных LB). (просто следует использовать правильный инструмент для своего дела haproxy как прокси без ssl незаменим, в случае ssl конечно лучше nginx, т.к. все в одной коробке)
Если будет нужно что-то особенное в Европе, обращайтесь :).

[Павел Осипов]

Всенепременно! Проект растёт, а разобраться в тонкостях хайлоада и нормально всё организовать нужен оыт

Answer 3

[Георгий Хромченко]

Один двухпроцессорный ( 2 Xeon 2.4Ghz, времен Pentium-4 ) Linux Debian 4.0 + SCSI на Nginx выдерживал 100 миллионов отдач статики в сутки. Сейчас и процессоры сильно быстрее, и SSD появился.

Comments

[Павел Осипов]

Ну у нас всё же не совсем просто статика отдаётся. Т.е. в принципе статика, но она ещё и считаться и управляться должна. Более комплексная система, чем просто раздача всё же. Хотя единственный путь приблизить как только можно к виду просто раздачи.
И спасибо за инфу, 100 миллионов в сутки, это обнадёживает!

[Георгий Хромченко]

Логи анализировались и считались не в реальном времени и на другой машине.