Развертывание масштабируемой архитектуры средних стека на Google Compute Engine

Question

Я развернула MEAN Stack приложение (не используя каких-либо рамок Mean) на Google Compute Engine. В настоящее время он развернут поверх одной виртуальной машины n1-standard-1 (1 виртуальный процессор + 3,75 ГБ памяти).

Внутри этого я работает 4 докерных контейнеров. Один каждый для:

• обратный прокси-сервер - прослушивает порт 80 (HTTP) & 443 (HTTPS), то прокси-сервер запрос на локально запущенный экземпляр узла (порт 3000)
• веб-приложений (nodejs + expressjs)
• MongoDB
• Redis

Я использовал это как мой Dev. и теперь, поскольку сайт находится в производстве (он работает довольно медленно).

Как преобразовать это в более масштабируемую архитектуру?

Мои решения:

• развернуть по меньшей мере, 4 ВМ с выше конфигурации. (каждый работает с одним контейнером докера): обратный прокси (1 vm), mongodb - (1 vm), redis - (1 vm), приложение - (несколько vm). гибкий, но немного дорогостоящий?
• развертывание с большим vm (больше CPU & RAM). дешевле альтернативы, чем выше?

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

Могу ли я найти несколько хороших решений?

Answer 1

Если ваша среда уже контейнеризована, и вы готовы сохранить ее таким образом, я могу предложить использовать Google Container Engine.

Google Container Engine - это мощный менеджер кластеров и система оркестровки для запуска ваших контейнеров Docker. Container Engine рассылает ваши контейнеры в кластер и управляет ими автоматически на основе требований, которые вы определяете (например, процессора и памяти). Он построен поверх открытого источника Kubernetes.

Вы будете разворачивать небольшой кластер из 3 узлов (может быть одноядерными узлами), и вы будете разворачивать свои контейнеры в виде стручков. Вероятно, вы можете избавиться от обратного прокси-сервера, поскольку это то, что Google может сделать для вас, используя понятие «service».

Когда вам может понадобиться больше ресурсов, вы можете просто изменить размер своего кластера, добавив к нему больше узлов (экземпляров).

Балансировщик нагрузки HTTP/S может помочь вам с завершением работы ssl и распространением нагрузки на несколько узлов.