22 января 2014 в 19:49

Взгляд изнутри или инфраструктура проекта 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
Likeastore
рейтинг 28,50
Похожие публикации

Комментарии (20)

  • +3
    У меня вопрос не по теме, если можно.
    Почему вы не сделали русскоязычную версию системы, если способны были сделать?
    • +1
      способны мы действительно на многое :) но до недавнего времени соотношение русскоговорящей и англоговорящей аудитории было примерно 1 к 5. на текущий момент момент вопрос более актуален, так что со временем появится.
      • +1
        Я, конечно, не маркетолог, но повангую, что малый процент русскоговорящей аудитории из-за отсутствия локализованного интерфейса :)
        • 0
          сервис не ориентирован на конкретный рынок/страну, поэтому выпуск первой версии на англ. языке давало нам большие возможности охвата аудитории и соответсвенно более быстро тестировать наши гипотезы… вот собственно основная причина :)
  • +2
    Для тестового периода можно использовать OpenShift.
    А вообще вы молодцы, что так бережливо относитесь к расходам. Для начинающего стартапа это важно.
    Удачи вам!
    • 0
      спасибо большое! OpenShift классная штука, но я оч позно о нем узнал… Red Hat сейчас тесно сотрудничают с Docker, и OpenShift использует Docker у себя. в каком-то смысле, мы близки :)
  • 0
    Кстати, для стартапов у Microsoft есть программа BizSpark, Вы подавали заявку на участие в ней?
    • +2
      программа BizSpark предусматривает использование технологий Microsoft. в перспективе, решения построенные на опен соурс технологиях (как у нас) все равно будет дешевле.
      • –2
        Ну почему? в Azure может работать тот же oracle, 1c, и много популярных бесплатных cms, не говорю уже о виртуальных машинах Linux.
        • +4
          вы правы, Microsoft сейчас делает оч много в плане поддержки open source, *nix серверов на Azure, node.js на Windows и т.д. но как говорится «осадочек остался» :) если серьезно, что я отчасти разделяю позицию роба коннери, по этому вопросу.
          • 0
            Спасибо, интересное чтиво
  • 0
    Подскажи, вы пользуетесь какими-либо сборщиками, вроде: gulp, grunt, может bower? Сложностей при деплое в dokku не было?
    • 0
      используем grunt & bower. для bower сделал специальный плагин, который установит все зависимости… а grunt запускаем при старте приложения, такой се bootstrap (раньше часто забывали запускать билд перед пушем в продакшн, так стало гораздо лучше).
      • 0
        Можно использовать yeoman.io, а на git push повесить хук. Ну или, что еще лучше, на сервере автоматически все билдить.
        • 0
          Есть в докку/докере своя специфика — мы билдим апп, внутри своего контейнера.
  • +1
    +1 расскажите про dokku подробнее? какие подводные камни были?
    • +3
      наверно это будет тема следующего поста :) stay tuned
  • 0
    Ппц, возможно я отстал от жизни, но для меня пост читался как «Мы решили сделать стартап, для этого мы взяли НЕНУЖНО, совместили его с НЕНУЖНО и задеплоили на НЕНУЖНО. В процессе выяснили, что НЕНУЖНО нам не совсем подходит и переехали на альтернативное НЕНУЖНО.»
    Может я зря для разворачивания сервера вбиваю в консоль sudo aptitude install postgresql-server erlang nginx git logrotate postfix и после 20-30 минут редактирую конфиги.
    Мне почему то кажется, что время, потраченное на изучение API и библиотек всех этих сервисов сравнимо со временем, которое нужно потратить на то, чтобы плюс-минус эквивалентное окружение научиться настраивать самому (или нагуглить подходящие HOWTO).
    Особенно комично смотрится изначальное утверждение «поддерживать собственную инфраструктуру слишком дорогое удовольствие» и последующие переезды с сервиса на сервис.
    Хоть скажите, не пожалели что с PaaS-ами связывались?
    • +1
      > Может я зря для разворачивания сервера вбиваю в консоль sudo aptitude…
      > Поддерживать собственную инфраструктуру слишком дорогое удовольствие…
      Возможно в этом всё и дело? Развернуть один раз достаточно легко, но поддерживать всё-время наверное сложнее: обновление, уязвимости, падение оборудования, контроль беккапа.
    • 0
      Мне казалось, что тема PaaS настолько широко открыта, во многих источниках, что даже не стал на этом особо фокусировать внимание. Поэтому, ответ на Ваш вопрос — не только не пожалели, а без их бурного развития и достуности, многим стартапам, было бы гораздо сложнее начинать. Преимуществ оч много. Один из основных для меня — считайте, мы арендуем работу, которую нам теперь не надо делать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка