В данной статье хочу поделиться опытом с теми, кто начинает развивать свои B2B SaaS продукты и может столкнуться с вопросом переноса своего решения на внутренние ИТ мощности корпоративных заказчиков. Опишу, не столько технические нюансы, сколько организационные и архитектурные. Хочу акцентировать внимание на объеме дополнительных работ, которые необходимо учитывать при продаже внедрения Enterprise клиенту. Тем, кто работает изначально по модели внедрения ПО, читать будет не особо интересно, а проектам с SaaS моделью надеюсь, что будет полезно.
Заказчика не называю.
Статья вышла не очень маленькая, по этому привожу краткое содержание
О проекте
Основной вызов - кратное масштабирование
Задача №1. Понять реальный объем бедствия.
Задача №2. Провести нагрузочные тестирования.
Задача №3. Проектирование новой архитектуры, балансировка.
Задача №4. Соответствие системы нефункциональным требованиям.
Задача №5. Адаптация платформы под программные решения заказчика.
Задача №6. Перенос на IT мощности заказчика.
Задача №7. Внутреннее тестирование.
Задача №8. Настройка отказоустойчивости.
Задача №9. Подготовка документации.
Задача №10. Настройка логгирования и 9
Мы развиваем российскую платформу по управлению контентом дополненной реальности: в 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, разворачивание тестового стенда во внутреннем контуре и пр
Надеюсь, не усыпил и кому-то было полезно.
