Денис Гордиенко, руководитель Bright Mobile, о нагрузке на примере приложения для оптовых покупателей цветов.
Решил рассказать про опыт разработки приложения для оптового дистрибьютора цветов в Краснодаре и вопросе нагрузки на БД. Отличие от большинства «цветочных» приложений в том, что оно сделано не для конечных покупателей, а для розничных продавцов, которые оформляют заказ удалённо, либо приезжая на базу.
Идея приложения
Проблема заключается в том, что цветы — это очень сезонный товар, ценники меняются постоянно, а переклеивать цены на огромном складе — это большие затраты на зарплату сотрудников. Вместо этого, товары обклеели штрихкодами и приложение выполняет сразу две функции: во-первых, это каталог, во-вторых, сканер штрих-кодов, который подтягивает цену из 1С.
Каталог отображает все цветы сразу или группирует их по типу. В каждой из лент можно добавить выбранные позиции в корзину и указать их количество (цена указана за определённую партию), отметить, что заказывается сейчас, отложить остальное на потом – и отправить заказ менеджеру на обработку.
Физически около каждого товара на базе размещён штрих-код, чтобы не нужно было постоянно переклеивать ценники. С помощью сканера приложения можно отсканировать нужный товар, после чего он автоматически добавляется в виш-лист.
Для рассылок, акций, предложений и новостей предусмотрена новостная лента. Также в приложении имеются история сканирования, где можно посмотреть предыдущие заказы, и меню с прочей информацией о компании: адрес, телефон, ссылки на социальные сети и т.д.
В случае, если у покупателя возникнут трудности с заказом или менеджером, он всегда может перейти в раздел рекламаций и написать жалобу. Все жалобы направляются прямиком на почту директора.
Багфикс ленты товаров
История могла бы быть очень сладенькой и не интересной, как одна из тысяч, описывающих очередное портфолио в стиле «была проблема, сделали вот так, проблемы нет, клиент доволен». Поэтому решил рассказать об одном из багов, который появился в процессе.
Программисты достаточно часто заморачиваются на оптимизацию нагрузок, идеализацию кода и прочее. Выдался хороший пример, чтобы посчитать в цифрах.
Технологии
Для начала приведу список технологий, на которых делалось приложение:
- Сборка Ionic.Framework
- БД FireStore
- Push — FCM
- Обмен данных с 1C — Node.JS
- Авторизация — Firebase Authentication
Кроссплатформенная сборка дала плюсы в скорости и цене разработки. Требования к телефону у бизнес-приложения низкие и переплачивать за натив смысла нет. БД выбрана для работы в режиме реального времени — приложение держит соединение с базой по сокету и моментально получает обновления. Авторизация от Firebase даёт 10 тыс бесплатных СМС, что более чем достаточно для планируемой клиентской базы.
Пропадание списка товаров
При прямом получении списка товаров стали вываливаться из 50 тыс чтений в сутки бесплатного тарифа. Собственно, багом это назвать сложно, т.к. решается переводом на платный тариф.
К слову, у программистов всегда чешутся руки пооптимизировать запросы. Это хорошо, но важно понимать экономическую целесообразность. К примеру, при плановой нагрузке в 200 тыс чтений оплата составит $0,06 за 100 тыс чтений. То есть в сутки $0,09, это $2,7 в месяц.
Выгоднее платить по 167р в мес на платном тарифе, чем дополнительно заложить 40 часов разработчика на кеширование и пакетные запросы. Если ориентироваться на стандартную ставку в 1200р в час, то это добавило бы лишние 48 000р в бюджет.
Когда делать оптимизацию?
Разворачивая идею в обратную сторону давайте попробуем понять, когда же владельцу приложения имеет смысл реально задуматься над оптимизацией запросов.
Предположим, что бизнес пошёл резко в гору и ежемесячно количество пользователей приложения увеличивается. Соответственно, незначительные 167р на текущем этапе будут постоянно расти. Обычно, сравнивая облачный FireStore коллеги приводят как альтернативу собственный сервер. Мол там нет аналогичной тарификации и можно не париться по количеству запросов.
Оставляю за скобками стоимость создания и развёртывания серверной архитектуры. Самый минимальный VDS можно взять примерно за 400р ($6,67) в мес, «нормальный» сервер — в районе 4000р ($66,67) в мес.
Адекватно задумываться об оптимизации было бы на этапе, когда эта самая оптимизация давала значительную выгоду перед арендой собственного сервера. То есть когда количество запросов к БД будет от минимальных 100 000 х $6,67 / $0,06 = 11 111 111 до «нормальных» 100 000 х $66,67 / $0,06 = 111 111 111.
111 миллионов запросов это достаточно абстрактная для бизнеса цифра. Поэтому переведём на заказы. В среднем, на одного пользователя, в этом приложении, чтоб он вдумчиво посидел и оформил корзину нужно 200 запросов к БД. То есть дойдя до платежа в 4000р в мес, клиент получит 10%(средняя конверсия в оплату) х 555 555 = ±55 555 заказов.
Получается за 50 тыс заказов нужно заплатить 4000р. Думаю, что загорая на Бали от такого количества денег, владелец приложения найдёт эту сумму.
Комментарий недоступен
налететь на деньги проснувшись утром после "хорошего" трафика
Интересно, почему многие боятся и не понимают облаков?
Много трафика? Возросшая нагрузка?
Так это же замечательно. Много клиентов, которые несут деньги. И сервисы отработали как надо переварив пиковую нагрузку.
А используй вы неклауд, у вас были бы фиксированные расходы на серверы, да, но под нагрузкой сервер вряд-ли выжил, компания не получила бы клиентов, а админов поднимали бы ночью, что бы что-то сделать. Чем оно лучше?
Бояться облаков действительно не стоит, но и важно понимать, что облако не может в хорошей архитектуре являться единственным хранилищем данных, единственным сервисом и т.д.
По поводу "хорошего трафика", это да, но ситуации бывают разные.
Приведу конкретный пример (см. скриншот), один клиент в прошлом году получил списание в пользу гугла за использование облачных сервисов в размере 14000 долларов США за один календарный месяц. Да, это не опечатка.
Там было списание за несколько картографических сервисов, сумма накапала за месяц, списана единовременно по окончании отчётного периода.
У человека была привязана бизнесовая карта, это та, которая напрямую к расчётному счёту привязана, плюс деньги были списаны в минус, банк это позволяет вполне.
Этот пример конечно не относится конкретно к FireBase, это просто иллюстрация того, как бывает иногда в реальности.
И в чем проблема?
Вы не пользовались этими сервисами? Или хотели бы их бесплатно?
Тем более, основная претензия к картографическим сервисам? За них бы пришлось платить даже на своем железе.
Я работал в компании, средний счёт которой был на уровне 100 тысяч долларов месяц. И никто не жаловался.
Николай, а атаку идти не стоит. Я с Вами не дискутирую. Прочитайте внимательно мой комментарий, и найдите в нём желания бесплатного, или что-то в этом роде. Написано же, это пример, иллюстрация того как иногда бывает проснувшись утром, и когда к этому не готов. Всё. Ничего больше.
Ещё раз, в хорошей архитектуре не может быть такого узкого места, каким является облако когда оно одно и всё, ничего больше. Это исключительно моё мнение, и я его не навязываю.
Я работал в компании, средний счёт которой был на уровне 100 тысяч долларов месяц. И никто не жаловался.Так работайте на здоровье, вопрос то в чём?
Он имеет в виду, что официант (гугл) принес то, что вы заказывали. Счет принесли согласно прайса. И вопрос к вам: хотелось бы уточнить, что вы имели в виду про "неожиданное списание" за облака. Мое предположение, что вы имели в виду, что стоимость заранее не фиксируется и это плохо, да?