Как мы создали глобально масштабируемую платформу SAAS

Обо мне

Я бегу и управляю Корабль, мы являемся платформой SAAS, предлагающей полный набор программных услуг для экспедиторских и логистических компаний. Мы очень маленькая компания (2 разработчика).

Создание глобально масштабируемой платформы SAAS

У нас были требования клиентов из разных уголков мира.
Мы разместили наше приложение в регионе Южной Азии AWS, время прохождения простого пинга из Южной Азии в Северную Америку составляет около 300 мс. Одна из главных проблем людей за пределами региона Южной Азии заключалась в том, что приложение реагировало медленно.
Мы знали, что нам нужно глобальное развертывание нашего приложения.

Как мы подошли к масштабированию

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

  1. Развертывание должно быть дешевым (мы небольшая компания).
  2. Ресурсы разработчиков были ограничены, поэтому нам требовалась стратегия с минимальными усилиями и лучшим результатом.
  3. Сервер базы данных должен присутствовать локально в регионе развертывания.
  4. Процесс развертывания должен быть простым, например, простая однострочная команда должна развернуть приложение глобально.
  5. Изменение конфигурации должно быть быстрым и простым.
  6. Выставление счетов и организация должны управляться из одного места.

Это была наша последняя установка.
Мы использовали mongoDB Atlas, чтобы разгрузить большую часть работы по управлению БД.
Было 2 разных варианта развертывания MongoDB Atlas.

  1. У нас может быть глобально избыточный единый кластер БД.
  2. Имейте разное развертывание кластера БД в каждом регионе.

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

  1. Южная Азия
  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.

Проблемы, с которыми мы столкнулись

  1. Как только у вас есть развертывание в нескольких регионах, стоимость развертывания значительно возрастает.
  2. Мы решили, что есть определенные сервисы, которым не нужны локальные серверы, и мы могли бы оптимизировать время отклика с помощью кэширования и CDN.
  3. Нам пришлось создать централизованный модуль конфигурации, чтобы управлять всеми конфигурациями развертывания из одного места.

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

Основные выводы

  1. Кэширование и CDN очень помогают с точки зрения производительности, особенно при глобальном развертывании приложения.
  2. Поэкспериментируйте с различными подходами, универсального решения для всех не существует.
    Например, вы можете выбрать независимое развертывание серверов баз данных в разных регионах или глобальное развертывание с несколькими репликами. Это полностью зависит от варианта использования.

Советы и советы

  1. Используйте такие сервисы, как MongoDB Atlas, DocumentDB или любую размещенную службу базы данных, чтобы разгрузить большую часть рабочей нагрузки по управлению сервером базы данных.
  2. Используйте Elastic Beanstalk / App Engine и т. д. для развертывания приложения. Развертывание в кластере с балансировкой нагрузки будет таким же простым, как развертывание gcloud или eb deploy.
  3. Планируйте мультирегиональность, если вы являетесь компанией SAAS, как можно раньше в жизненном цикле разработки. Потому что рано или поздно вам это понадобится.
  4. Используйте бессерверные функции всякий раз, когда у вас есть повторяющиеся задачи, которые не занимают много времени, или задачи, которые выполняются время от времени.
    Вы должны быть осторожны при использовании бессерверной функции, в нашем случае мы используем ее для загрузки файлов. Загрузка файлов редко выполняется на нашей платформе, и в большинстве случаев это файлы размером менее 1 МБ. Если у вас слишком много загрузок файлов, эта стоимость может возрасти. Бессерверные функции оплачиваются на основе использования ЦП и памяти в миллисекундах, поэтому избегайте этого, если вы собираетесь использовать его в избытке.
  5. Определите вызовы API, загрузка которых занимает много времени, попробуйте CDNize/кэшировать их, если это возможно.

Заключительные мысли и следующие шаги

Наша архитектура постоянно развивается, и мы сосредоточены и будем продолжать улучшать качество обслуживания клиентов в нашем продукте.

Хотел бы помочь компаниям SAAS развернуть приложение по всему миру. Пингуйте меня в любое время.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *