Делимся опытом с теми, кто начинает развивать свои B2B SaaS продукты и может столкнуться с вопросом переноса своего решения на внутренние ИТ мощности корпоративных заказчиков. Статья будет полезна проектам с SaaS моделью.
В статье затронем технические, организационные и архитектурные нюансы. Будем акцентировать внимание на объеме дополнительных работ, которые необходимо учитывать при продаже внедрения Enterprise клиенту.
Краткое содержание:
О проекте
Основной вызов — кратное масштабирование
Задача №1. Понять реальный объем бедствия.
Задача №2. Провести нагрузочные тестирования.
Задача №3. Проектирование новой архитектуры, балансировка.
Задача №4. Соответствие системы нефункциональным требованиям.
Задача №5. Адаптация платформы под программные решения заказчика.
Задача №6. Перенос на IT мощности заказчика.
Задача №7. Внутреннее тестирование.
Задача №8. Настройка отказоустойчивости.
Задача №9. Подготовка документации.
Задача №10. Настройка логгирования и 9
Мы занимаемся развитием российской платформы по управлению контентом дополненной реальности ARGUMENT: в web-редакторе совмещается digital контент и маркер (как привило это фотография реального объекта), а с помощью мобильного приложения, в режиме камеры digital контент накладывается на маркер.
В базовой модели платформа ARGUMENT работает как SaaS сервис: редактор в он-лайне и чтобы им пользоваться необходимо самостоятельно зарегистрировать аккаунт и начать создание AR контента. У нас B2B модель, которая дает компаниям возможность использовать AR в первую очередь, для обучения персонала. Однако, ряд компаний по соображениям ИТ безопасности не хотят или не могут использовать облачные решения. Все сервисы должны быть On-Premise расположены на внутренних ИТ мощностях.
Мы не первый и не последний SaaS сервис, который сталкивается с вопросом, внедрять ли решение заказчику или отказаться от возможности заработать и спать спокойно )). Технически и организационно гораздо проще развивать решение, размещенное в одном месте, нежели поддерживать работоспособность и обновления у всех клиентов. Да, для решения таких задач придуманы специальные технологии: и докеры и Kubernetes, но мы на момент разворачивания первых внутренних инсталляций контейнеризацией не владели. А когда клиент пришел – решили внедрять.
С чем же мы столкнулись.
Кратное масштабирование. Это практически основная задача из который вытекает все остальное. На момент внедрения наш SaaS обслуживал 2000-3000 активных пользователей мобильного приложения, которое по API забирает данные с сервера. Соответственно, вся архитектура была развёрнута под такие нужды: на одной виртуальной машине (под управлением Debian) в крупном ЦОД у нас была развернута и БД (MySQL) и Web-интерфейс редактора (PHPFpm +Phalcon), и API (PHPFpm) обработки запросов и файл-сервер и все прочие мелочи.
Потенциальный размер аудитории у заказчика, кто может использовать наше приложение – 200 000 сотрудников. А такие масштабы — это совсем другая архитектура.
Задача №1. Понять реальный объем бедствия. Нам цифра 200 000 ни о чем особо не говорит, для оценки данных для ИТ- инфраструктуры и проектирования новой архитектуры работы системы, необходимо понять количество обращений к серверам в единицу времени, желательно в секунду.
Опыта использования таких систем в компании не было, поэтому, решили прогнозировать. Сколько сотрудников в день может сканировать маркеры и сколько раз за день. Чтобы это понять, расписывали по мелочам бизнес-кейс использования AR на рабочем месте: если это обучение нового сотрудника, сколько раз в день новый сотрудник будет что сканировать и как долго после принятия на работу; а если это работа с ассортиментом и нужно сканировать ассортимент в процессе работы; а если это сканирование стеллажей для работы с панорамами или склад и т.д.
Задача №2. Провести нагрузочные тестирования. Когда определились с количеством возможных запросов к серверам в секунду, необходимо было организовать нагрузочные тестирования, чтобы понять требования определения требований к архитектуре и инфраструктуре.
Увы, у начинающего стартапа в штате специалиста по нагрузочным тестированиям не нашлось, пришлось обращаться к внешним специалистам. Эксперта нашли довольно быстро, развернули тестовый стенд (сначала один, скопировав нашу базовую архитектуру), развернули сервер нагрузочного тестирования, установили на него набор ПО для организации нагрузки и логгирования: influxdb, grafana, mavenz и пр. И начали нагрузку и тестирование.
Задача №3. Проектирование новой архитектуры, балансировка.
Сразу стало понятно, что архитектура «всё в одном» это «не серьёзно и так далеко не уедешь. Шагом первым мы выделили на отдельные сервера: СУБД, Web-редактор, Файл-сервер и сервер API.
Плавно увеличивали количество обращений (запросов в секунду) к серверу до запланированный значений. Делали это помощью специального ПО и отмечали, когда и в каком месте начинает сбоить: не хватает процессорных мощностей – не беда, увеличиваем в облаке мощности; оперативка – тоже самое; БД – правили SQL запросы. В определённый момент времени уткнулиcь в возможности веб-обработки API запросов, за которые отвечал nginx, тут стало понятно — на одном API сервере далеко не уедешь, нужно распределять запросы.
Подключили второй сервер для обработки входящих от мобильного приложения обращений, а для распределения запросов подняли сервер балансировки с установленным на него haproxy.Он помог нам раскидывать входящие обращения то на один, то на другой сервер, равномерно распределяя нагрузку. В итоге, казалось, что двух API серверов нам вполне достаточно.
Точно также определили, что файл-сервер — тоже узкое место при большом количестве запросов в секунду, пришлось продублировать и его.
Подкрутили там (настройки nginx и php), подкрутили здесь (sql запросы и haproxy) и пришли к такой упрощенной схеме:
На этом этапе стало понятно, какие мощности у заказчика нужны для поддержки такого решения: сколько серверов, сколько процессорных мощностей, сколько памяти и жестких дисков.
Подготовили схемку в ArchiMate (пришлось попутно освоить), согласовали, пошли дальше.
Задача №4. Соответствие системы нефункциональным требованиям. Помимо того, что именно делает наша система и как она будет работать на 200 000 сотрудниках, она во внутреннем IT контуре компании должна соответствовать серии нефункциональных требований.
Нам прислали эксельку в 142 строки с таким же количество требований. Часть из них — общие технические требования, часть — касающаяся интеграции, часть по безопасности. При этом, некоторые требования отсекающие, не выполнив которые, нельзя запускать систему в эксплуатацию, некоторые – критические, некоторые рабочие. Для каждого критерия определен вес и эталонные значения, при наборе определенного количества несоответствий опять же систему запускать нельзя.
Но оказалось все не так страшно. Основному количеству критериев мы соответствовали, там где нет – пришлось перенастраивать или дорабатывать компоненты системы.
Задача №5. Адаптация платформы под программные решения заказчика. Эта часть проекта была не самой сложной, но всё же пришлось повозиться. Она же имела отношение к вышеупомянутым НФТ.
В базовом варианте у нас сервера были на Debian, а unix заказчика это только лицензируемое ПО — Linux CentOS, Red Hat Enterprise Linux (RHEL). Ок, сделали адаптацию, переписали некоторые компоненты системы, под специфичные версии пакетов этой системы.
СУБД. Изначально мы использовали MySQL, у заказчика — много всякого другого, но корпоративного. Путём переговоров договорились на использование СУБД Percona, так как это форк от MySQL и переехать на нее было вполне реалистично.
Задача №6. Перенос на IT мощности заказчика. Вот вроде то самое, с чего мы и хотели начать ). Но и тут не все просто. Как правило во внутренний IT контур компании по сети просто так не попадешь, это специальные доступы по VPN, внутренние виртуальные рабочие столы с протоколированием совершаемых действий и т.д. Потом внутри системы подключение по ssh к развернутым виртуальным серверам и т.д.
По соображения безопасности, в крупных компаниях сервера не имеют доступа в интернет, а кто знает, установка unix окружения для серверного ПО тянет за собой необходимость установки множества различных пакетов из внешних репозиториев и заранее описать связи всех пакетов не представляется возможным, какие файлы понадобятся для работы компонент системы предугадать сложно.
Так и получилось, зашли мы на голые сервера, а установить туда ничего не можем. Даже просто пробросить файлы на сервер нет возможности, всё через корпоративный файлообменник через специального сотрудника. Мы тут приуныли немного, но заказчику нужно было решение и нам выделили грамотного unix специалиста из внутренних кадров компании, мы быстро нашли общий язык и потихоньку все нужные компоненты окружения были установлены.
Дело оставалось за малым – перетащить все компоненты нашей системы, настроить структуру БД и всего нужного окружения.
Задача №7. Внутреннее тестирование. Когда перенесли все компоненты системы и настроили доступы к балансировщикам и API через интернет (если помните, у нас приложение на смартфоне в мобильной сети оператора связи считывает данные с внутренних серверов) то только тут приступили к внутреннему тестированию. На данном этапе выявили ряд багов, что-то по работе приложения, что-то по нагрузкам, а что-то по отказоустойчивости. Ничего из ряда вон выходящего.
Задача №8. Настройка отказоустойчивости. Тут все для нас было просто, так как практически вся данная задача легла на плечи внутренних специалистов заказчика.
- Настроена система регулярного бекапирования.
- Почти все сервера из схемы выше были продублированы с целью сохранности данных (БД и файл-сервера) и стабильности работы.
- Была настроена система автоматического разворачивания резервных серверов по мере загрузки мощностей существующих серверов
Задача №9. Подготовка документации. Тут, наверное, все по стандарту, но всё же чтобы не было сюрпризом. В нашем случае комплект документации был таким:
- Соответствие нефункциональным требованиям
- Описание архитектурного решения
- Схема компонент системы, в формате ArchiMate
- Расчет нагрузочного тестирования с учетом горизонтального масштабирования
- Инструкция пользователя (он же редактор контента)
- Инструкция конечного пользователя (владелец смартфона)
- Инструкция администратора
И это мы еще легко отделались
Задача №10. Настройка логгирования и системы мониторинга.
Когда система была передана на внутреннее ИТ сопровождение, то понадобились дополнительные телодвижения для настройки мониторинга и оповещений. Система должна сигнализировать в нужных случаях – у меня сбой: место заканчивается, запросы не правильно обрабатываются, данные не считываются и т.д. Всё автоматизировать и предусмотреть не возможно, но сделали, что могли. Настроили систему логов и передачу данных в систему мониторинга при критичных значениях работы компонент платформы.
Вот вроде и всё. Хочу отдельно отметить, что весь объем работ занял у нас около полугода. Система функционирует стабильно, находится под нашим наблюдением м техническим сопровождением и приносит прибыль заказчику, чего и всем желаем.
Хоть статья получилась и большая, но рассмотрены тут только основные моменты, так как весь объем работ в статью не засунешь: обошли стороной вопросы интеграции с внутренней LMS и ActiveDirectory, разворачивание тестового стенда во внутреннем контуре и пр
Надеюсь, не усыпил и кому-то было полезно.
