Amvera Cloud — облако для ботов
Уже 1 год мы разрабатываем облако, в котором проекты можно развертывать и обновлять через PUSH в мастер-ветку GIT. Это проще, чем использование VPS (виртуальных машин).
Что у нас было:
- максимально сырой прототип, позволяющий запускать проекты в контейнерах через отправку кода в выделенный или привязанный Git-репозиторий.
Чего у нас не было:
- Документации — я искренне удивляюсь, как наши пользователи справлялись с развертыванием, используя лишь несколько абзацев краткой инструкции. Приношу извинения за ваши страдания! Но многие справились.
- Отображения логов. Но и без логов были пользователи, которые успешно разворачивали проект.
- Поддержки баз данных, за исключением SQLite.
- Возможности добавлять свой домен.
- Возможности скачивать загруженные данные.
- Возможности добавлять переменные и секреты.
- Возможности ставить проект на паузу
- Возможности развертывать проекты из графического интерфейса
- CLI
Правильно ли мы сделали, что запустились со столь сырым продуктом? Мы в команде до сих пор спорим на этот счет, но я считаю, что да. Это позволило поймать момент перехода пользователей от Heroku и получить обратную связь, чтобы понять как развивать сервис.
Первые сложности
Первое, с чем мы столкнулись, — это тот факт, что без документации и логов пользователи испытывают некоторые сложности с развертыванием (мягко говоря). Но это было не так сложно исправить: мы написали на коленке за несколько дней свой стриминг логов и пару страниц документации. Правда, логи работали нестабильно, с ужасными задержками (задержка отображения остается по сей день, но уже минимальная), да и документация была самая базовая. Но это лучше чем ничего.
Пока у нас были только единичные пользователи, мы еще не осознавали проблем, возникающих с ростом нагрузки. И тут наступил день Х: 29 ноября Heroku закрыл бесплатные тарифы, и мы запустили рекламу по этому поводу. В итоге, к нам пришло больше пользователей, чем мы могли “вывезти”.
Сначала мы уперлись в лимит по выписке SSL-сертификатов Let’s Encrypt. Проблема решилась достаточно просто: купили Wildcard и немного переделали логику генерации внутренних доменов.
Далее наши сервисы начали по очереди отказывать. Отваливалось буквально все. Пришлось в экстренном порядке все переписывать. Ближе к концу декабря мы поправили почти все и даже успели выпустить функционал переменных и секретов.
Нокаут
На новогодние праздники мы ушли с почти чистой совестью. Сервис работал, и первые пользователи разместили свои проекты. Но 3 января 2022 утром я увидел, что ничего не работает.
Попробовали восстановить работоспособность разными способами, но ничего не получалось. Уже постфактум можно сказать, что наложилось сразу несколько серьезных проблем, основной из которых было потеря нами etcd.
Почему это произошло?
Мы развернули сервис на bare-metal, а именно, на арендованных серверах у одного известного провайдера. Сделано это было из-за того, что, как показывали расчеты, при использовании managed-инфраструктуры (kubernetes в облаке и т.д.) могла не сойтись экономика проекта. Согласитесь, странно делать бизнес, отдавая всю выручку облачному провайдеру.
Однако на этих арендованных серверах были более медленные диски, чем требуется, из-за чего возникла критическая ошибка. Но главная ошибка была в том, что не стоит все делать на собственной инфраструктуре, если у вас нет человеческого ресурса ее качественно администрировать и сразу правильно настроить. А с этим ресурсом у нас была проблема: после запуска почти все силы были брошены на “тушение пожаров”, а все, что осталось, мы направили на доработку функционала.
Мы почти сразу поняли, что если мы просто заново развернем сервис, то получим ту же проблему с потерей данных и пользователей в самое ближайшее время. Стали пробовать переписать сервис так, чтобы новая архитектура была более устойчива к подобным инцидентам и содержала меньше “узких” мест. Но по самым разным причинам что-то не получалось. Время шло, а мы так и не могли запуститься. Особенно мучительно было оттого, что некоторые пользователи успели запустить у нас свои проекты, и теперь они не работали.
В итоге было принято волевое решение запустить наш сервис поверх managed-облака одного из провайдеров и править архитектуру уже после этого.
Результат метаний — большой даунтайм в несколько недель, что неприемлемо даже для бета-теста. Мы сохранили данные проектов пользователей, но за время даунтайма большинство первых клиентов ушли, и мы их понимаем. Это было самое тяжелое время для нас.
Но мы решили “вернуться в игру”, перезапуститься, и продолжить бета-тест. И, на удивление, обнаружили, что экономика проекта может сходиться даже при использовании мощностей облачного провайдера, хотя и не так хорошо, как на своих серверах.
Жаркие майские
За месяцы после перезапуска мы повысили стабильность работы и немного улучшили функционал. А затем наступили майские праздники. Ночью и утром 9 мая стали поступать сообщения от пользователей, что не работает развертывание новых проектов. Данные мониторинга тоже указывали на катастрофу.
Оказывается, наш облачный провайдер (не буду его называть) ночью произвел обновление. И несмотря на то, что у нас были установлены все галочки о запрете любых обновлений на некоторых виртуальных машинах, он их обновил, параллельно стерев все данные с дисков. Особенно чувствительно было то, что мы использовали не только сетевые, но и локальные диски для снижения latency запросов к базам данных. Нам помогло только то, что, наученные горьким опытом, мы заранее провели ряд работ, которые защитили проекты и данные текущих пользователей. Но работоспособность собственных сервисов нам пришлось восстанавливать, так как не все было покрыто бэкапами и не везде мы их могли применить из-за риска нарушить консистентность данных работающих проектов пользователей.
И хотя большинство пользователей не заметили даунтайма и их проекты продолжали работать, нам пришлось все майские внепланово все поднимать и восстанавливать.
Из этого мы извлекли два урока. Урок первый: даже на облачных провайдеров с громким именем нельзя полагаться на 100%. Урок второй: все нужно хранить на сетевых дисках с репликацией, полным покрытием бэкапами и так, чтобы восстановление не затрагивало работающие проекты.
Повышение качества работы и новый функционал
После инцидента нам пришлось еще раз пересмотреть архитектуру проекта. Теперь мы понимали: необходимо минимизировать риски коллапса от независящих от нас причин. Доработка архитектуры заняла время, и только летом мы вернулись к разработке нового функционала. Добавили поддержку баз данных, отображение файлов, поддержку своих доменов и генерацию конфигурационных файлов, переписали стриминг логов, чтобы он нормально работал, и сделали ряд других работ.
Помните, как один облачный провайдер стер нам прод? Мы тоже помнили, и мигрировали на другого провайдера через несколько месяцев. Не буду говорить, что новый провайдер работает без нареканий. Бывают проблемы с сетью, есть подозрения на избыточную переподписку по CPU и другие шероховатости, но, в целом, все работает.
Активация биллинга
Ближе к концу лета мы убедились, что наш сервис работает стабильно несколько месяцев. Оставались небольшие шероховатости, например, нестабильная работа стриминга логов, но в целом сервис работал и все было многократно покрыто бэкапами.
Мы доработали некоторый функционал, закончили режим бета-теста, начислили пользователям обещанный стартовый баланс и включили биллинг.
Финансовые показатели раскрывать не буду, только отмечу, что пока выручка не очень большая, но показывает планомерный рост.
Работа над ошибками
Даже когда мы перешли на платный режим для пользователей, было понятно, что сервис еще очень “сырой”. Было много мелких багов, которые затрудняли развертывание проектов и делали неудобным процесс эксплуатации.
Где-то не загружались все файлы, где-то не удалялись артефакты, где-то сам интерфейс вводил в заблуждение.
И основная работа в сентябре-декабре была как раз посвящена борьбе с ошибками, мешающими пользователям. Работа еще не закончена, но уже сейчас мы видим, что в два раза сократился отток и в два раза выросла конверсия в развертывания.
Вывод — качество продукта важно, и часто качество кроется в мелочах.
Про поиски венчурных инвесторов
Сразу скажу, что от внешних инвестиций наш проект зависит не сильно. Изначально был расчет на то, что мы будем тратить не больше, чем получается зарабатывать на прошлых проектах. Это хоть и скромный ресурс, но достаточно устойчивая стратегия.
Но быстро стало понятно, что если мы хотим не просто выживать, но и активно развиваться, дополнительный капитал будет полезен.
Про венчурных инвесторов из России и опыт общения с ними можно писать отдельную статью, в которой будут забавные истории. Главный вывод: венчурного капитала в России практически нет, но ключевое слово тут — практически.
Пару раз были просто смешные (я бы даже сказал, немного оскорбительные) предложения, сводящиеся к следующей фразе: “Давайте вы нам отдадите компанию, а мы команде будем зарплаты платить…”. Даже интересно, людям не кажется, что если бы основатели хотели получать зарплату, они бы … устроились на работу? Логика таких инвесторов заключается в принципе “а вдруг прокатит”.
Но это скорее исключения. Чаще встречается примерно такая постановка вопроса: “Покажите нам выручку и ее динамику, которая гарантирует возврат наших инвестиций через N лет дивидендами”. И тут я понимаю, что люди ищут дивидендный бизнес, и в этом нет ничего плохого. Но это никак нельзя назвать венчурными инвестициями. И если есть “гарантии” возврата через дивиденды, то в таком случае основателю выгоднее брать обычный банковский кредит, чем отдавать кому-либо долю в бизнесе. Еще раз повторю, что в такой модели нет ничего плохого, только не нужно при этом называть себя венчурным фондом.
При этом на рынке есть профессионалы, с которыми приятно и полезно общаться. Они понимают бизнес и технологии и грамотно подходят к стратегии.
В итоге мы получили три независимых (и взаимоисключающих) предложения от действительно компетентных инвесторов, и с одним из них, в итоге, вышли на сделку буквально на днях. Новость с деталями скоро опубликуем.
Вывод: если поставить себе такую цель, то даже в текущих условиях “венчурной зимы” инвестиции найти можно.
Текущий статус
Сервис уже полгода работает в штатном режиме без глобальных сбоев. Случаются лишь небольшие неполадки, например, неработающий биллинг или временные проблемы с сетью на одной ноде. Добавили поддержку баз данных, возможность загружать проект прямо из интерфейса, поддержку доменов и другой полезный функционал.
Для стабильности работы мы сделали следующее. И возможно, вам это может пригодиться в ваших проектах.
- Разнесли ноды с нашими сервисами и с проектами пользователей в отдельные группы. Это повысило безопасность и позволило избежать случаев, когда из-за проблем на одной пользовательской ноде, вызванных проектом конкретного пользователя, страдает весь сервис.
- Допустимая нагрузка по CPU на ноде должна быть, в среднем, не выше 50%, с редкими небольшими превышениями. Если у вас процессор будет почти полностью загружен, его производительность будет ухудшаться не прямо пропорционально уровню загрузки. И все проекты, размещенные на ноде, будут очень медленно работать.
- Стали использовать сетевые диски везде, где это возможно. Да, присутствует небольшая latency, но для наших задач задержка оказалась некритичной. При этом сетевые диски проще реплицировать, масштабировать и покрывать бэкапами.
- Использование постоянного мониторинга. Для себя мы выбрали стек продуктов Grafana + OpenSearch.
- Перевели все на очень быстрые SSD диски. Диск может быть узким местом, и практика показывает, что тут лучше не экономить.
- Изменили архитектуру, чтобы такие процессы, как стриминг логов и т.д. не перегружали систему.
- Добавили удаление неиспользуемых ингресс-контроллеров, что важно для разгрузки Kubernetes.
- Помимо реплицирования дисков, покрыли все бэкапами, так как потеря данных — более серьезная проблема, чем кратковременная недоступность сервиса. И реализовали сохранение копии самых ценных данных у независимого провайдера в другом ЦОДе.
Наши ошибки, и что сделать вам, чтобы их не повторить
- Попытка реализации сложного проекта полностью на своей инфраструктуре. Если вы развиваете проект на свои деньги и у вас нет отдельной команды опытных инфраструктурных инженеров, воспользуйтесь услугами одного из публичных облаков. Это будет дешевле, чем отвлекать всю команду разработки на администрирование и восстановление сервиса.
- Полное доверие облачному провайдеру, когда вы решили отказаться от части своей инфраструктуры по п.1. Надо помнить, что проблемы облачного провайдера — это ваши проблемы, а ваши проблемы — это ваши проблемы. Даже самые именитые компании не гарантируют вам почти ничего, даже при SLA. Выход — полное многократное покрытие бэкапами, которые хранятся в разных ЦОДах и у разных провайдеров, резервирование и продуманная архитектура проекта, рассчитанная на самое худшее. Детали того, как мы повышали надежность архитектуры, достойны отдельной технической статьи, и мы ее обязательно напишем в ближайшее время.
- Планирование бюджета. Изначально мы хотели закончить бета-тест и включить монетизацию в январе 2022, но продлили тестовый режим почти до августа. Если бы не строгий контроль расходов, я бы писал не эту статью, а про “полученный бесценный опыт закрытого бизнеса”. И нужно учитывать, что в России венчурных денег почти нет. Большинство тех, кто называет себя венчурными инвесторами, требуют гарантий дивидендов, которые за N времени отобьют вложения. Это противоречит самой сути высокорисковых инвестиций. Поэтому надо сразу считать деньги так, чтобы вам хватило до точки безубыточности. Но если получится привлечь инвестиции, будет только лучше.
- Неполное покрытие бэкапами. Либо невозможность их применения из-за нарушения согласованности пользовательских данных, когда часть системы продолжила работать и генерировать новые данные. Мало все покрыть бэкапами, нужно еще иметь возможность их применить.
- Старт с маленьким бюджетом. Если у вас сложный продукт, он будет ломаться, а первое время — ломаться часто. И если у вас маленькая команда, то команда будет заниматься не разработкой функционала, а “тушением пожаров”, администрированием инфраструктуры и написанием извинений недовольным пользователям в поддержке. И тут совет простой — либо переплачивать за сторонние managed-решения, либо расширять команду.
Планы на будущее
Нам еще предстоит большой путь для того, чтобы сделать такое облако, которое мы задумали. Это и новые продукты в рамках текущего сервиса (тестовые среды, мониторинг, кластеры баз данных и т.д.), и B2B версия, и, главное, дальнейшее повышение уровня стабильности и удобства сервиса.
Мы планируем расширять команду и достаточно оптимистично смотрим в будущее. Если вам нужно облако с функционалом простого развертывания, регистрируйтесь в нашем сервисе, а если есть вопросы, пишите мне на почту kkosolapov@amvera.ru
amvera.ru/cloud
https://id.amvera.ru/auth/