Я разрабатываю несколько простых приложений на платформе Django (вы можете представить их как более сложные блоги с различными функциями). Все приложения имеют много схожих функций - в основном настраиваемую CMS. Я могу создать их как один проект в Django с промежуточным программным обеспечением multihost для обработки запросов из разных доменов. Ожидаемое количество приложений 10–1000 и ожидаемый процент попаданий для приложения может составлять 100/10 КБ в день.
Моя идея - запустить этот проект (все приложения) на AWS или GCP.
Django довольно гибок, я могу использовать ту настройку, которую использую сейчас - промежуточное ПО с несколькими хостами, или я могу немного настроить параметры для каждого приложения - так что код, одинаковый для всех приложений, будет в одном месте, однако каждое приложение будет есть свой экземпляр. Возможны оба варианта, и они имеют одинаковый уровень сложности с точки зрения кодирования.
Итак, мой вопрос: должен ли я:
Что лучше масштабируемо? Что безопаснее? Что будет дешевле? Что вообще лучше?
С точки зрения масштабируемости вопрос сводится к тому, можно ли масштабировать отдельное приложение по горизонтали. Если приложение Django не сохраняет состояние, которое необходимо сохранять между запросами, вы можете просто создать столько реплик своей виртуальной машины, сколько вам необходимо для обслуживания пользователей.
Если ни одно из ваших приложений Django не поддерживает такое состояние внутри приложения, вы можете увеличить масштаб, добавив больше виртуальных машин, независимо от того, размещены ли на самих виртуальных машинах одно или несколько приложений.
Если какое-либо приложение действительно нуждается в данных по запросам и его нельзя легко масштабировать по горизонтали более чем на одну виртуальную машину, то лучшее, что вы можете сделать на начальном этапе, - это выделить для этих конкретных приложений по одной виртуальной машине для каждого приложения. Таким образом, они не поставят под угрозу масштабируемость других.
Возможно, некоторые из ваших приложений Django используют базу данных в качестве серверной части для хранения данных, и в этом случае тот же вопрос будет применяться и к базе данных. Горизонтальное масштабирование на уровне базы данных будет сложнее, потому что на уровне базы данных у вас определенно есть постоянные данные, которые необходимо реплицировать между вашими экземплярами.
Я бы порекомендовал отдельную базу данных для каждого приложения, если у вас нет каких-либо конкретных данных, которые нужно будет совместно использовать между приложениями. Вам также следует выяснить, предлагает ли облачный провайдер услугу базы данных, которая удовлетворяет ваши потребности, чтобы вам не приходилось администрировать собственную базу данных.
С точки зрения безопасности обычно считается лучше иметь большую изоляцию. Поэтому с этой точки зрения вы должны выбирать отдельные виртуальные машины для каждого приложения.
С точки зрения гибкости также есть преимущество разделения виртуальных машин для каждого приложения. Возможно, вы обнаружите, что вам нужна определенная конфигурация ваших виртуальных машин для поддержки одного из приложений и другая конфигурация для другого приложения. Если вы используете отдельные виртуальные машины, у вас есть возможность сделать это, если вам нужно.
Итак, все аргументы пока что в пользу отдельных виртуальных машин для каждого приложения. Итак, теперь давайте посмотрим, сколько это стоит.
Для резервирования я бы рекомендовал иметь как минимум 3 виртуальные машины в каждом пуле. С пулом для каждого из ваших 1000 приложений, что составляет 3000 виртуальных машин. Вдобавок к этому вам необходимо выделить достаточно виртуальных машин для любого из приложений, которые фактически получают достаточно трафика, чтобы потребовалось более одной виртуальной машины для обработки всего трафика.
Если вместо этого вы выбрали единый пул для всех своих приложений, вам просто нужно выделить достаточно виртуальных машин для обработки всего трафика плюс небольшое количество для резервирования.
Это означает, что вы собираетесь оплатить 2000–3000 дополнительных виртуальных машин за перечисленные выше преимущества. Вам решать, разумна ли это цена. Прежде чем вы примете это решение, я рекомендую вам в первую очередь проверить, сколько виртуальных машин вы бы справились с нагрузкой. Будет ли это число 100 или 10000, будет иметь большое значение для того, хотите ли вы потратить еще 3000 виртуальных машин.