История одного highload проекта

в 9:00, , рубрики: ruby on rails, SaaS, whois, мониторинг сайта, Песочница, метки: , , , ,

Как написать высоконагруженный, многофункциональный проект вдвоём? Что делать, если нет денег и времени, а открываться нужно? Под катом немного интересной информации из личного опыта.

История одного highload проекта

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

Так как дни веб-мастера тяжелы и неказисты, то на реализацию было заявлено много функционала, а именно:

  • проект должен тянуть каждую неделю whois информацию по всем существующим доменам (планируется более 300 млн.)
  • хранить у себя всю whois информацию по всем доменам вместе с историей изменений;
  • уведомлять об окончании срока регистрации доменов и хостинга;
  • осуществлять мониторинг сайтов минимум раз в 3 минуты и минимум из 6-ти стран (красиво отображать время, коды ответов и графики с этим всем делом по каждой стране);
  • проверять сайт на наличие в чёрных списках, а также на присутствие вредоносной гадости;
  • управлять финансами с добавлением транзакций затрат/прибыли по сайтам (опять же, с графиками);
  • управлять заметками, с возможностью добавления меток и прикрепления файлов;
  • уведомлять клиентов посредством e-mail и sms, согласно пользовательским настройкам;
  • прикрутить интересную партнёрскую программу со скидочными купонами и ссылками;

В общем, надо было написать «Dominder» (от англ. domain + reminder).
Полезный, интересный, перспективный проект, но вот незадача — мало времени и ресурсов. Разработчиков целых два (второй только через 3 месяца после начала разработки подключился).

Заказали за бугром крутой, импортный дизайн. Писать решили на Ruby on Rails, в качестве основной БД выступила PostgreSQL.

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

Решение номер Раз

На качество реализации frontend-а решили забить времени потратили меньше, чем хотелось бы. Будем его потихоньку допиливать — главное, чтобы клиентов ничего не напрягало.

Решение номер Два

Т.к. времени нет, то тот или иной способ реализации выбирается исходя из параметров:

  • временные затраты;
  • scalability;
  • (текущее количество пользователей в системе) реализация должна держать.

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

Решение номер Три

Параллельно с разработкой велся пиар продукта. Как это происходило.
Выстраивается 2 «потока планирования»: разработки и пиара. Они должны наполняться равномерно исходя из текущих потребностей проекта и возможностей на его текущую реализацию. Например, если готов какой-то функциональный кусок проекта — он сразу же тестировался, обкатывался и популяризировался. Либо, если текущее количество пользователей меньше прогнозируемого — то сначала разрабатывались красивые фенечки для клиентов (например, демо аккаунт), а уже второстепенным шла оптимизация текущих алгоритмов. И наоборот, если клиенты начали приходить валом — всё бросали и начинали сурово кодить. Получались своеобразные качели, но по-другому, по-моему, никак.

Решение номер Четыре

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

Решение номер Пять

Ввиду того, что историю пингов нужно хранить бесконечно долго — все записи жмутся в «архивы» согласно алгоритму отображения в графиках.

Решение номер Шесть

Использование собственного самописного прокси-сервера, для вытягивания whois от регистраторов. Некоторые из них поначалу просто банили ip из-за очень частых обращений. В итоге удалось получать информацию для полумиллиона доменов в день. Не предел, но на доработку просто не было времени.

Решение номер Семь

Всё, к чему нужен быстрый, частый доступ, беспощадно пихается в NoSql.

После запуска проекта встал вопрос о привлечении пользователей.
Тот же мониторинг сайтов на Западе уже давно популярен и им пользуются миллионы. А вот объяснить нашему, советскому человеку, что проще, выгоднее и удобнее заплатить несколько долларов в месяц и иметь возможность сразу узнать, что что-то произошло с сайтом, оказалось довольно трудной задачей. Многие так и не поняли, что мониторинг сайтов (да и другие наши услуги) – это как страховка. Хорошо, если ничего не случилось. А если произойдёт?

История одного highload проекта

Для тестов мы добавили 140 белорусских сайтов. В итоге оказалось, что порядка 40% сайтов хотя бы раз в неделю перестаёт быть доступным (на срок от 5 минут до нескольких часов). А некоторые сайты просто дико колбасятся и явно теряют своих клиентов.

Конечно, в России есть такой грозный конкурент, как Яндекс.Метрика (и у меня довольно часто спрашивают, в чём наши отличия). Но Метрика, бывает, не сразу присылает уведомления (бывает, запаздывают на несколько минут), нет возможности проверки доступности сайтов из разных стран, не гарантирует мониторинг в некоторых случаях и необходимо устанавливать дополнительный код на свои сайты.

Имея ограниченные ресурсы после открытия нашего проекта, мы стали действовать своими силами по всем фронтам: e-mail маркетинг, партнёрская программа, партнёры в виде хостинг-компаний и веб-студий и т.д.

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

Автор: YSPRO

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js