Новая инфраструктура для нашего проекта (AWS, GCP) - PullRequest
Новая
       22

Новая инфраструктура для нашего проекта (AWS, GCP)

0 голосов
/ 10 ноября 2019

Я начал в прошлом месяце в новой компании. Где я буду отвечать за инфраструктуру и бэкэнд SAAS.

В настоящее время у нас есть одна капля / экземпляр на клиента. На текущем этапе развития компании это хороший выбор. Но в будущем, когда количество экземпляров будет расти, его будет сложно поддерживать. На данный момент в сети 150 экземпляров, каждый с 1 ЦПУ и 1 ГБ памяти.

Наши клиенты используют среду только в течение нескольких недель, месяцев или года. Поэтому большую часть времени они ничего не делают. Итак, мы хотим изменить это. Я думаю о Kubernetes, Docker Swarm или другом инструменте.

Какой совет вы можете дать нам? Должны ли мы сделать шаг к Kubernetes или Docker Swarm или остаться с дроплетами / виртуальными машинами в DigitalOcean, AWS или GCP?

Если мы перейдем на AWS или GCP, наша средняя цена вырастет с 5 $ в месяц до 10 $ в месяц.

Мы хотим сделать следующий шаг, чтобы понизитьтрата ресурсов, но и думать о ежемесячном счете. На мой взгляд, было бы лучше иметь 2 наши 3 большие виртуальные машины, работающие с Kubernetes или Docker Swarm, чтобы снизить ежемесячный счет и уменьшить наши зарезервированные ресурсы.

Что ты думаешь?

1 Ответ

5 голосов
/ 10 ноября 2019

Если вы серьезно относитесь к масштабированию, вам следует переосмыслить архитектуру вашего приложения . Самая дорогая часть вычислений - это память (RAM), поэтому выделенная память для каждого клиента не позволит вам масштабировать.

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

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

Вот еще пара примеров ...

Atlassian раньше имел именно то, что выимеют. Каждому клиенту JIRA Cloud будет назначена собственная виртуальная машина с ЦП, ОЗУ и базой данных. Им пришлось довести свой центр обработки данных до невероятных размеров, и это было дорого!

Затем они отправились в путешествие, чтобы перейти к мультитенантности, сначала отделив базы данных от каждого клиента (и используя общий пул). баз данных), затем перейдя на общие микросервисы и, в конечном итоге, они удалили все ресурсы для каждого клиента.

См .:

Salesforce с самого начала решили стать мультитенантом. Они определили концепцию SaaS и привыкли называть себя «облаком» (до облачных вычислений, как мы его знаем сейчас). В то время как их системы сегментированы для масштабирования, несколько клиентов совместно используют одни и те же ресурсы в пределах сегмента. Разделение данных о клиентах осуществляется на уровне базы данных.

См .:

Итог: Конечно, вы можете попытаться оптимизировать текущую архитектуру с помощью контейнеров, но если выЕсли вы хотите серьезно отнестись к масштабу (я говорю 10x или 100x), то вам нужно переосмыслить архитектуру .

...