evnuh
@evnuh
Поиск Гугл помог мне, впусти и ты его в свой дом

Какой стек приложений под высоконагруженный сервис выбрать?

В общем, пилим сервис по сбору статистики и аналитики. Должен будет собирать всякие метрики с сайтов. При этом трекать посетителей, собирать хиты и хранить их сессии. Минимально требуемая нагрузка 2000rps, и чтоб сразу можно было 10k зафигачить в будущем на одном лишь масштабировании :)
Хотелось бы узнать у опытных людей кто какой стек технологий использовал, в частности интересует:
  1. Что выступает фронтом? Очевидно пилить свой веб-сервер не хочется, но по бенчмаркам nginx выдаёт 12000rps. Есть yandex phantom, но не нашёл по бенчмаркам ничего, алсо без документации как таковой. Хотелось бы чтобы сразу и с ssl, load balancing, http/2 :)
  2. Как общаться с c++ воркерами? fcgi? Или может вкорячить в nginx модуль который, например, по zeromq будет общаться с воркерами?

  3. БД. Исходя из текущих условий, ясно что собирать нужно будет информацию всякую разную, потому реляционный подход здесь вписывается не очень удачно. Что есть из NoSQL для быстрой записи и редкого чтения? Накопал Tarantool, вроде как хорошо


В общем, всё что сам нашёл это отрывки без объяснений чем обусловлен такой выбор, поэтому обращаюсь к тем кто реализовывал.
  • Вопрос задан
  • 5015 просмотров
Решения вопроса 1
@hsc
full stack python back-end developer
Для сбора статистики очень логично использовать append only databases, производительность которых на запись часто играет решающую роль в выборе. Скорее всего вы, как и многие другие, не будете выдавать отчеты на лету, а будете генерировать их по запросу некоторое время, и на опережение генерировать несколько самых основных/популярных и для вас время выборки будет не самым важным критерием.

Дисковое пространство сегодня стоит относительно не много, и overhead даже в 20% для проекта с такими нагрузками является допустимым. Тут все зависит от формата сообщений, которые вы хотите принимать и от того, как вы решите их хранить.

В качестве БД можно смотреть на RiakLevelDB в качестве бекенда) или еще один интересный append only key-value storage по типу тарантула: sophia.
Но на самом деле, решающим фактором тут является не столько сама БД, сколько то, как в нее попадает информация и на каких нодах она должна быть доступна. Как по мне, даже вариант с обычными файлами ОС и fsync() тоже отбрасывать не стоит.

По поводу веб.сервера: без балансировки, скорее всего, не удасться обработать такое кол-во запросов, хотя это очень сильно зависит от сущности самих запросов. Интересно что Вы тестировали, что nginx показал вам такие цифры на одной ноде, скорее всего отдачу одной (пары) страниц, каждая из которых попала в файловый cache ОС из-за частого обращения и, соответственно, отдавалась с памяти. Вот вам и намек: чтение и запись в память происходят с приблизительно одинаковой скоростью, а nginx позволяет обрабатывать запросы c помощью Lua. А тут уже много вариантов: redis pub/sub, pipes, shared memory и т.д., может вы даже захотите написать модуль для nginx на С.

Скорее всего вы будете принимать json самых разных вариаций, и тут возможны 2 варианта: или писать сообщения сразу на диск и потом пост-обработка, или парсить данные и потом писать результаты. Тут посоветовать не могу, вам должно быть виднее что на данном этапе логичнее. Но имейте ввиду, что каждая операция на этапе обработки запроса от клиента уменьшает ваш rps.

Еще важный момент здесь учитывать, что 12krps с одного хоста != 12krps с 12k хостов. Каждый из коннектов nginx будет должен мультриплексировать на что тоже будет расходоваться время.
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
OnYourLips
@OnYourLips
Начните с малого. С сервисно-ориентированной распределенной архитектуры.
О железе рано думать.
Ответ написан
DigitalSmile
@DigitalSmile
http://brainstorage.me/digitalsmile
Если проект с серьезным бюджетом, то кусочек дата-центра, балансировщик нагрузки в виде железки от f5 (https://f5.com/products/platforms/appliances). В программной части nginx - проверенное решение (если распределить его на 20 нодах с балансировкой, то нагрузка вытекает 12000 * 20). Что будет за фронтендом полностью зависит от архитектуры Вашего приложения (там может быть шардинг, еще один балансировщик и т.п.).
Если бюджет не позволяет, можете забыть о 10000rps (Вам в любом случае надо либо нанимать очень крутых программистов-спецов по высокой нагрузке, либо см. вариант выше). Берете любой облачный сервис (Amazon, Jelastic, etc) и разворачиваете виртуальную структуру там. Тамошняя производительность будет целиком зависеть от облака и вашего кода.

По поводу БД, не торопитесь, выбрасывать реляционные базы. Ознакомьтесь с опытом, например здесь www.sarahmei.com/blog/2013/11/11/why-you-should-ne... Не для каждой архитектуры подходят NoSQL.
Ответ написан
begemot_sun
@begemot_sun
Программист в душе.
Поюзайте Erlang.

www.ostinelli.net/a-comparison-between-misultin-mo...

Если что нужно могу и помочь.
Ваша основная проблема будет это создание на основе лога событий аггрегатов в различных разрезах.
Ответ написан
@Moxa
Пишите на java, у меня на ноуте jetty с томкатом выдают 55k rps, netty - 90k, undertow - 130k, я сейчас пилю свой веб сервер, до 210k rps дотянул
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы