Взгляд изнутри или инфраструктура проекта Likeastore

в 15:49, , рубрики: cloud, iaas, likeastore, paas, Блог компании Likeastore, ит-инфраструктура, разработка, метки: , , ,

За относительно небольшое время, мы успели попробовать и поменять много решений, прямо или косвенно влияющих на продукт. Сегодня, я бы хотел сделать обзор инфаструктуры вокруг проекта Likeastore. Это может быть интересно многими разработчикам думающим о своем запуске.

Я пойду от железа к софту, от низких инфрастуктурных уровней к более высоким. Для всех сервисов, которые мы используем по подписке, я укажу цены. Для каждого из пункта будет небольшой комментарий, но в перспективе каждый из них может быть открыт более глубоко, в последующих постах. Поехали…

Небольшая история..

С самого начала, мы начали ориентироватся на облака, потому что это удобно. Основное требование было к тому, чтобы это был именно PaaS (AppFog, Nodejitsu, Heroku, Azure), а не IaaS (EC2, DigitalOcean, Rackspace). Поддерживать собственную инфаструктуру серверов слишком «большое удовольствие» для стартапа.

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

Наш первый опыт был именно с AppFog. На момент первых эксперементов они выглядели действительно привлекательно — 8 инстансов, 256 МБ памяти на каждый. Самое главное, «деплоймеймент одной командой» через руби клиент и все это за 20 баксов. Поначалу все было окей, но позже начали открываться негативные моменты: довольно долгий деплоймент (30 — 40 сек), неудобный дешборд, но самое неприятное, из-за неполадки в их load balancing системы, AppFog постоянно «терял» серверные куки, что делало невозможность использовать приложение.

Мы вынуждены были уйти на Nodejitsu. 3 инстанса за 33$, дорого по сравнению с AppFog, но зато на Nodejitsu приложение работало, деплойменты шли быстро, дешборд удобный и поддержка на высоте. Пришлось немного пересмотреть нашу архитектуру, чтобы умещаться в 3 инстанса, но это было даже к лучшему. Никаких особых нареканий на Nodejitsu у нас небыло, кроме того, что их сервера размещены в зоне us-east-1 и для Европы это создавало заметный ping latency.

Счастье закончилось, когда мы выходили в публичную бета фазу (лето 2013). Мы четко понимали, что работаем с личными данными пользователя, поэтому использование http, было не приемлемо. Nodejitsu не дает возможности использовать SSL для Personal Plan c кастомным доменом. Переход на Business Plan, стоил 120$ месяц.

Это был «облом»… Необходимо было арендовать сервера и все делать самостоятельно, т.е. по сути вернутся к IaaS решениям.

Хостинг и железо

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

К моменту нашего перехода на DigitalOcean они запустили поддержку в зоне AMS1 (Amsterdam) и мы были одним из первых дроплетов в этой зоне. Нельзя сказать. что все было идеально гладко с самого начала, но после перемещение машины в европейскую зону отзывчивость приложения поменялась радикально (в лучшую строну). Особенно это было заметно с мобильных устройств.

Начали с самого дешевого варианта: 512MB, 1CPU, 20GB SSD всего за 5 баксов. Этого было более чем достаточно для старта. В такой конфигурации, мы просущестовали вплоть до тысячного пользователя. Node.js не самая «расточительная» платформа в плане ресурсов и 512MB дает возможность для нормальной работы, но до некоторой нагрузки. Со временем самая ресурсоемкая компонента сollector (сбор лайков) стала потреблять много памяти и банально падать.

Мы взяли дроплет побольше — 1GB, 1CPU, 30GB SDD за 10 баксов, а прошлую оставили для нашего «стежинг» окружения. Тем самым весь хостинг нам обходился в 15 баксов, с поддержкой SSL. Почти в 10 раз выгоднее любого PaaS решения. Буквально совсем недавно, мы перешли на дроплеты с 2GB RAM/2 CPU, и такой конфигурации нам хватит на долго.

«Но DigitalOcean, это не PaaS», возразите Вы, и будете правы. Но мы смогли приблизить его к таковому. Как?

После того как «вкусил» перелести PaaS, отказатся от них крайне сложно. Я с трудом мог представить себе деплоймент через ftp или ssh, «ручной» запуск и остановка ноды, конфигурирование nginx и т.д. Но волею случая, мне на глаза попался проект под названием dokku, который сильно повлиял на развитие Likeastore.

Dokku позволяет превратить Ubuntu сервер в mini-Heroku сервер, с возможность развертования любого (Node.js, Ruby, PHP, Static etc.) приложения через git push. Dokku очень просто установить и он требует минимальной конфигурации.

Процесс деплоймента

Dokku использует git как транспорт исходников в машины А (машина разработичка или интерграционный сервер) на машину Б (машина в производстве) и docker для изоляции исполняемых процессов и окружения запуска. dokku дает возможность развернуть приложение одной командой:


git push production master

Каждый раз приложение развертся с «чистой» среды, на этой среде будет устновлен nodejs нужной версии, происталируются все необходимые зависимости и т.д. dokku использует nginx, выступающий прокси для запущенных контейнеров, при необходимости SSL соединение настраивается путем копирования ключей в определенную папку на сервере.

Мы депоим примерно 5-10 раз в день на тестовое и 1-2 раза в рабочее окружение, начиная использование dokku с версии 0.1 мы не испытывали каких либо значительных сложностей, а вот пользы проект принес очень много. При этом, и он сам и технологии лежащие в его основе, крайне интересны!

Хранение данных

В самом начале проекта мы использовали CouchDB, но очень быстро перешли на MongoDB.

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

Переспективы конфигурации MongoDB в производстве меня радовали еще меньше чем ручной деплоймент. Начинали с MongoLab, но позже перешли на MongoHQ, прежде всего потому что получили хорошие рекомендации от коллег по поводу их службы поддержки, а второе, что MongoHQ позволяет развернуть сервер в Европе.

Для прототипа взяли тестовое подключение, 512MB (тогда казавшийся нам недостижимым объемом) все работало на ура. Но помню как я радовался с переходом на AWS Small:EU, кредит на который нам дал MongoHQ, после того как у нас возникла некоторая проблема и мы обратились в поддержку — приложение стало просто «летать», время отклика было близко к тому, что мы имеем на окружении разработчика. Кроме того у них довольно неплохая админка, отслеживание медленных запросов и рекомендованные индексы.

Логгирование и мониторинг

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

Решение, на котором мы мы остановились, это Logentries. С нашим текущим объемом лог траффика мы остаемся на бесплатном аккаунте. «Кардиограммы» всех наших приложений всегда перед глазами, поэтому мы быстро видим, когда что-то начинает идти не так.

Также важно следить за состоянием ваших серверов. По началу это был ssh к серверу и ручной мониторинг, сейчас по совету коллег поробывали New Relic. Мне очень понравился процесс установки, хорошая документация и поддержка. Премиум фича New Relic, это мониторинг приложений, совсем недавно у них появилась поддержка Node.js.

Метрики и связь с пользователями

Если логи это приоритет номер один для приложения, то метрики это приоритет номер для продукта.

Естественно, что у нас есть Google Analytics. Может в меня кинут камнем, но GA для меня это не более чем отслеживание общего траффика и рефералов. Шаг вправо, шаг влево — начинаются проблемы, которые сложно заметить, так как данные в репортах появляются только на следующий день. Сложный в тонкой настройке и требует много времени, чтобы в нем разобраться.

Мы используем свое решение Seismo (оч раннее и простое) и совсем недавно, для построения «воронок» (funnels) мы взяли MixPanel. MixPanel очень порадовал своей интеграцией и испугал своей ценой. Так что мы будем развивать свое решение, в зависимости от текущих нужд.

Для связи с пользователями используем 2 решения: для транзакционных писем Mandrill, а для поддержки, пригласительных и ретеншн писем Intercom. Оба продукта очень классные, ценовая политика Mandrill (12,000 писем бесплатно) позволяет нам использовать его без затрат, но с Intercom у нас совсем недавно закончился триал, а ценник у них довольно высокий — базовая цена 49$ + 11$ за каждые 250 активных пользователей. Мы подключили Intercom в конце декабря и наш инвойс составил 82$. Это пока что самый дорогой сервис (при этом удобный), но я бы рассмотрел альтернативы.

Суммарные инфраструктурые затраты

Итак, подсуммируем затраты стартапа на инфрастуктуру: 40$ (DigitalOcean) + 20$(MongoHQ) + 82$ (Intercom) = 152$. Это довольно много, как для начинающей компании, мы еще будем искать пути оптимизации. Тем не менее, это не такие большие деньги, которые должны вас удерживать от попытки запустить свой сервис. Более того, к этим расходам мы пришли примерно за пол года существования продукта, а начальные были на уровне 10-20$ в месяц.

Сейчас наиболее благоприятная среда и много чего делается в помощь разработчикам, прочь сомнения — запускайтесь сегодня!

Автор: alexbeletsky

Источник

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


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