VCStart: как мы создавали платформу
Разработка нашей платформы началась еще в 2013 году, когда наша команда, полная вдохновения и энтузиазма, взялась за этот амбициозный и интересный проект, который позволил бы объединить средства тысяч мелких частных инвесторов и стартаперов-энтузиастов для воплощения бизнес-идей.
ИнструментыДля разработки платформы инвестирования был выбран старый добрый PHP и очень быстрый и хорошо себя зарекомендовавший в прошлых проектах PHP-фреймворк Yii первой версии.База данных Разрабатывая новую систему, в первую очередь задумываешься об объемах и формате денных, которые необходимо будет хранить.Заглядывая далеко вперед, мы основательно подошли к разработке архитектуры платформы.Подход к ее расширяемости и масштабируемости был продиктован максимальными показателями (на тот момент) Кикстартера.А именно:
3.000.000 юзеров 100.000 проектов каждый юзер в среднем инвестирует в 3–10 проектов, но бывают и исключения по 500–700 проектов каждый юзер подписывается на 20–50 проектов, а вот в каждом проекте может быть 2000–5000 инвесторов и 5000–20000 подписчиков Следовательно пришлось бы делать запросы к таблицам с миллиардами записей. Дабы этого избежать, было решено реализовать горизонтальный шардинг таблиц базы данных.Особенности горизонтального шардинга:
Части одной и той же таблицы могут находиться на разных физических серверах В web-приложении нужное соединение с каждой из бд выбирается по заранее определенному алгоритму Перед каждым обращением к таблице выбирается нужное соединение В основе всех сущностей данных платформы лежит стартап, поэтому он и лег в основу алгоритма выбора соединения. Был написан класс работы с базой данных, который сам в зависимости от ID стартапа выбирет требуемое подключение и таблицу, не требуя где-либо в коде явных указаний.Работает это так: необходимо получить количество подписчиков для определенного проекта, допустим с id 600. При построении запроса класс доступа к базе данных определяет, что необходимо использовать спот номер 2. Из конфигурационного файла извлекается соединение db и название таблицы subscriber2, и автоматически подставляется в запрос.
Конфигурационный файл связи спотов, серверов и таблиц БД очень упрощенно выглядит приблизительно так:
В качестве СУБД был выбран надежный и производительный PostgreSql. Пока что наши web-серверы используют всего один сервер баз данных, поскольку тщательное кэширование запросов, страниц и фрагментов страниц практически лишило его нагрузки.Еще один сервер БД отдан под реплики.
Web-серверы Как известно, вертикальное масштабирование (докупить оперативку, более производительное железо) дорого стоит и имеет быстро достижимый предел наращивания ресурсов, поэтому мы выбрали горизонтальное масштабирование web-серверов, которое обеспечивает больший прирост производительности за меньшие средства.Для обработки запросов от пользователей было решено построить следующую схему:
Наружу в интернет выглядывает только один сервер — балансировщик nginx, к которому непосредственно обращаются пользователи, заходя на сайт. В конфигурации балансировщика прописаны все доступные backend-сервера, на которые будут перенаправляться запросы пользователей, и которые будут отдавать им контент.
В данный момент у нас запросы от пользователей обрабатывают 5 backend-серверов, которые не испытывают практически никакой нагрузки, но при необходимости выдерживают тысячу и более соединения в секунду.
Для того, чтоб не было расхождения между версиями контента, отображаемого пользователям, backend«ы используют единый кэш и сессии, которые хранятся в высокопроизводительном key-value хранилище Redis.Помимо кеша и сессий в Redis хранятся все счетчики, некоторые списки данных и статистика по посещениям пользователей, проектам и т.д.
Так же балансировщик позволяет задавать веса (приоритет) каждого из backend-серверов, количество неудачных попыток соединения с backend-сервером, после которого он будет считаться вышедшим из эксплуатации, и запросы будут перенаправляться на оставшиеся сервера.
При резком увеличении нагрузки на сервера, мы можем очень легко добавить любое количество backend-серверов, разворачивание нового сервера из snapshot’а занимает около трех минут.
Amazon В ходе разработки встал вопрос о том, где же хранить файлы и картинки проектов, да так, чтоб каждый из серверов имел к ним доступ, например, когда пользователь хочет обрезать уже загруженную картинку. На помощь пришел Amazon Simple Storage Service (S3).К слову, Амазон выручил нас дважды, для отправки писем пользователям мы подключили Amazon Simple Email Service (SES), который позволил нам делать массовые рассылки и обеспечил высокий процент попадание писем к пользователям, минуя спам-фильтры.
Последний штрих
После множества этапов функционального тестирования мы выполнили ряд нагрузочных тестов. Помог нам в этом, в первую очередь, сервис нагрузочного тестирования loaddy.com.Тестировали в основном 4 страницы — главную страницу платформы, доступную всем неавторизованным пользователям, страницу с проектами, которая является главной для авторизованных пользователей, главную страницу отдельного проекта и промо страницу VCStart.com/start/, на которой миловидные девушки держат счетчик времени, оставшийся до финального запуска платформы.
Некоторое время заняла тщательная работа над кэшированием, после чего результаты нагрузочных тестов стали более чем удовлетворительными — платформа выдерживала нагрузку до 1000 соединений в секунду, при этом среднее время ответа на запрос составляло менее двух секунд.
Такая тщательная подготовка к запуску проекта дала нам огромный запас возможностей расширения аудитории, благодаря чему ожидаемая цунами хабраэффекта показалась нам лишь легким ветерком.
Ждем вас, инвесторы, и вас, авторы стартапов, на нашей первой в России краудинвестиционной платформе VCStart.com! Если интересуют какие-то подробности, буду рад ответить на них в комментариях
