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

Похоже что сейчас это принято делать путем контейнеризации, с чем у меня нет опыта. Для сокращения времени изучения технологии, хочу проконсультироваться с опытными в этих вопросах товарищами, поэтому хочу получить часовую консультацию по обновлению архитектуры.

Задачи консультации:
- изучить текущую схему архитектуры (по схеме + вопросам, в код залезать не нужно)
- предложить/выработать в ходе обсуждения новую архитектуру сервиса
- составить план перехода на эту архитектуру
- предоставить основные ключевые слова для дальнейшего самостоятельно изучения, ссылки на наиболее полезные ресурсы
- ответить на возникающие по ходу вопросы

Скетч архитектуры на приложенной картинке. Пояснения:
- общение с пользователями проходит через приложение web, общение происходит по http(s)
- администрирование и обновления происходят через ssh
- web по необходимости взаимодействует с БД и некоторыми другими инструментами (tools)
- основная бизнес логика находится в приложении app. Каждый инстанс app запускается со своим ID, читает конфигурацию из файла id.conf, записывает данные в файл id.log
- web переадресует большую часть запросов инстансам приложения app, общение web-app происходит через сокеты. На каждый возможный ID app на сервере регистрируется сервис (systemd) который стартует автоматически при обращении к сокету. Выключаются инстансы app сами по тайм-ауту при отсутствие запросов
- обновления app/web происходят в основном с помощью ansible – код чекаутится с GitHub, собирается на сервере, выполняются нужные команды для перезапусков
- пользователь всегда может скачать дистрибутив свежей версии app себе на компьютер для использования локально

Зачем нужна новая архитектура (в первую очередь):
- запустить отдельный сервер в другом географическом регионе, у другого хостинг провайдера
- поддержать возможность архивирования версии app (для определенных ID запускать конкретную сборку app)
- побороть некоторые порочные зависимости (некоторые tools требуют определенного легаси окружения, что осложняет обновления всего остального)
- поддержать горизонтальное масштабирование производительности (в целом сервер справляется с нагрузкой в 90% случаев, но хотелось бы иметь возможность легко добавлять дополнительные сервера для исполнения app при необходимости)

Какие моменты важно сохранить:
- инстансы app должны продолжать работать с файлами, не надо переносить эти данные в БД
- желательно сохранить скорость обновления версий app (условно сейчас деплой новой версии состоит из "git pull; grunt build"