Как мы создали глобально масштабируемую платформу SAAS
Обо мне
Я бегу и управляю Корабль, мы являемся платформой SAAS, предлагающей полный набор программных услуг для экспедиторских и логистических компаний. Мы очень маленькая компания (2 разработчика).
Создание глобально масштабируемой платформы SAAS
У нас были требования клиентов из разных уголков мира.
Мы разместили наше приложение в регионе Южной Азии AWS, время прохождения простого пинга из Южной Азии в Северную Америку составляет около 300 мс. Одна из главных проблем людей за пределами региона Южной Азии заключалась в том, что приложение реагировало медленно.
Мы знали, что нам нужно глобальное развертывание нашего приложения.
Как мы подошли к масштабированию
Первым шагом было составление плана развертывания приложения в нескольких регионах с учетом следующих критериев.
- Развертывание должно быть дешевым (мы небольшая компания).
- Ресурсы разработчиков были ограничены, поэтому нам требовалась стратегия с минимальными усилиями и лучшим результатом.
- Сервер базы данных должен присутствовать локально в регионе развертывания.
- Процесс развертывания должен быть простым, например, простая однострочная команда должна развернуть приложение глобально.
- Изменение конфигурации должно быть быстрым и простым.
- Выставление счетов и организация должны управляться из одного места.
Это была наша последняя установка.
Мы использовали mongoDB Atlas, чтобы разгрузить большую часть работы по управлению БД.
Было 2 разных варианта развертывания MongoDB Atlas.
- У нас может быть глобально избыточный единый кластер БД.
- Имейте разное развертывание кластера БД в каждом регионе.
После тщательного планирования мы решили, что будем использовать вариант 2. Возможно, это не лучший вариант для всех компаний, но для нас он был лучше как с точки зрения стоимости, так и скорости.
Наша цель, развернуть приложение в 3 регионах
- Южная Азия
- Юго-Восточная Азия
- Восток США
Когда вы выберете вариант 1?
Это то, что вы бы выбрали, если вы ориентируетесь на клиентов, которые имеют доступ к одним и тем же данным по всему миру. В нашем случае каждый клиент находился в определенном регионе, и они имели доступ к данным, относящимся только к ним, поэтому для нас был лучше выбор варианта 2.
Сервер конфигурации + база данных конфигурации — Южная Азия
Имя конечной точки: config.xyz.com
Здесь мы храним все настройки наших клиентов и платежные данные.
Первый вызов API будет сделан на этот сервер, и он, в свою очередь, вернет региональный сервер для конкретного клиента.
Региональный сервер + региональная база данных — Южная Азия, Юго-Восточная Азия и Восток США
Имя конечной точки: region.data.xyz.com
Здесь мы хранили данные о клиентах и кешировали копии конфигураций.
Когда клиент загружает веб-приложение
Мы вызываем config.xyz.com, это возвращает сервер, на котором находятся данные клиента, скажем, south-east-asia.data.xyz.com.
После этого все вызовы API будут осуществляться на сервер Юго-Восточной Азии.
Развертывание на серверах
Мы использовали сборку кода AWS для написания конвейера сборки и развертывания, а Elastic Beanstalk — для управления приложением развертывания. Существует множество ресурсов о том, как развернуть ваше приложение на эластичном beanstalk.
Мы можем настроить триггеры сборки в сборке кода. Как только мы фиксируем код, сборка кода сначала запускает тестовые случаи, если все тестовые примеры пройдены, приложение будет развернуто в разных регионах beanstalk.
Проблемы, с которыми мы столкнулись
- Как только у вас есть развертывание в нескольких регионах, стоимость развертывания значительно возрастает.
- Мы решили, что есть определенные сервисы, которым не нужны локальные серверы, и мы могли бы оптимизировать время отклика с помощью кэширования и CDN.
- Нам пришлось создать централизованный модуль конфигурации, чтобы управлять всеми конфигурациями развертывания из одного места.
В итоге мы переписали большую часть нашей логики развертывания, даже логика выставления счетов и управления организацией также значительно изменилась.
Основные выводы
- Кэширование и CDN очень помогают с точки зрения производительности, особенно при глобальном развертывании приложения.
- Поэкспериментируйте с различными подходами, универсального решения для всех не существует.
Например, вы можете выбрать независимое развертывание серверов баз данных в разных регионах или глобальное развертывание с несколькими репликами. Это полностью зависит от варианта использования.
Советы и советы
- Используйте такие сервисы, как MongoDB Atlas, DocumentDB или любую размещенную службу базы данных, чтобы разгрузить большую часть рабочей нагрузки по управлению сервером базы данных.
- Используйте Elastic Beanstalk / App Engine и т. д. для развертывания приложения. Развертывание в кластере с балансировкой нагрузки будет таким же простым, как развертывание gcloud или eb deploy.
- Планируйте мультирегиональность, если вы являетесь компанией SAAS, как можно раньше в жизненном цикле разработки. Потому что рано или поздно вам это понадобится.
- Используйте бессерверные функции всякий раз, когда у вас есть повторяющиеся задачи, которые не занимают много времени, или задачи, которые выполняются время от времени.
Вы должны быть осторожны при использовании бессерверной функции, в нашем случае мы используем ее для загрузки файлов. Загрузка файлов редко выполняется на нашей платформе, и в большинстве случаев это файлы размером менее 1 МБ. Если у вас слишком много загрузок файлов, эта стоимость может возрасти. Бессерверные функции оплачиваются на основе использования ЦП и памяти в миллисекундах, поэтому избегайте этого, если вы собираетесь использовать его в избытке. - Определите вызовы API, загрузка которых занимает много времени, попробуйте CDNize/кэшировать их, если это возможно.
Заключительные мысли и следующие шаги
Наша архитектура постоянно развивается, и мы сосредоточены и будем продолжать улучшать качество обслуживания клиентов в нашем продукте.
Хотел бы помочь компаниям SAAS развернуть приложение по всему миру. Пингуйте меня в любое время.
