Каков наилучший вариант для расширения избыточности приложения SaaS?

Question

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

Я использую ISPConfig, который, как представляется, поддерживает кластеризацию или зеркалирование серверов, но зеркалирует правильный метод для поддержки широкомасштабного использования? Должна ли одна настройка ISPConfig в ситуации с несколькими серверами и иметь множество отдельных серверов/баз данных или же у одного сервера есть много серверов в качестве зеркального кластера? Какими последствиями это повлияет на базу данных? Следует ли искать внешнюю базу данных, возможно, Amazon RDS, к которой подключены все серверы?

Я ценю любое направление, которое может обеспечить это.

Answer 1

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

По этой причине многие крупные веб-сайты, такие как Facebook и Twitter, отошли от баз данных SQL и перешли на использование систем, которые позволяют масштабировать их в основном горизонтально. Это база данных вызовов NoSQL. Этот, который я использую, называется Cassandra. Чем больше пользователей вы получите, тем больше узлов Cassandra вы добавите, и оно может расти настолько, насколько вам хотелось бы. Netflix заявила около 2015 года, что у них было более 2000 таких узлов.

Cassandra автоматически отражает данные между узлами.

Если вы хотите, вы также можете посмотреть Scyllab, который является Cassandra в C++ вместо Java. Я бы использовал это, если бы у меня не было проблемы с удалением из базы данных ... прямо сейчас, это не вариант для меня, к сожалению. Существует несколько других систем NoSQL, но это единственные два, которые я пробовал.

Далее ... вы пишете приложение, которое запускается на отдельном компьютере (при разработке вы можете сделать это на одном компьютере, это нормально, но вам нужно как минимум 4 ГБ ОЗУ для Cassandra ...) Сделайте 100 % уверен, что ВСЕ данные, которые не являются статичными данными, доступными только для чтения, установленные вашим приложением, сохраняются в базе данных. В противном случае у вас будет копия на компьютере A, а не на компьютере B. Таким образом, у кого-то доступ к компьютеру B никогда не будет доступа к этим данным на компьютере A. Однако, если все данные (т.е. даже файлы загружены) находятся в базе данных, любой фронт конец приложения может получить к нему доступ. Что это значит? У вас может быть столько передних концов, сколько вам нужно для поддержания нагрузки. Структурировать становится чем-то вроде этого:

     Internet Users 
           | 
           v 
        +--------------------+ 
        |     | 
        | Load Balancer | 
        |     | 
        +--------------------+ 
           | 
     +-----------------------+--------------------+ 
     |      |     | 
     v      v     v 
+----------------+ +----------------+ +----------------+ 
|    | |    | |    | 
| Apache/App | | Apache/App | | Apache/App | 
|    | |    | |    | 
+----------------+ +----------------+ +----------------+ 
    ^     ^    ^
     |      |     | 
     v      v     v 
+----------------+ +----------------+ +----------------+ 
|    | |    | |    | 
| Cassandra  |<-->| Cassandra  |<-->| Cassandra  | 
|    | |    | |    | 
+----------------+ +----------------+ +----------------+ 

Примечание: Каждая коробка представляет собой компьютер, ваш минимальный кластер, вероятно, будет около 7 компьютеров. Тем не менее, каждый из них может быть довольно дешевым облачным компьютером вместо 16 процессоров выделенного сервера ...

Важное замечание: для правильной работы (как безопасно для данных), Cassandra требует не менее 4 узлов и коэффициент репликации 3. Вам также нужна защищенная (личная) сеть ЛВС. Если таковой не имеется, то вам придется установить что-то такое, как OpenVPN, чтобы убедиться, что все путешествия данные зашифрованы между узлами (это верно даже с другими продуктами, которые предлагают такое дублирование.)

Load Balancer является только процесс который проверяет загрузку интерфейсных компьютеров и решает отправить следующий запрос. Для этого у Apache2 есть модуль. Обратите внимание, что я знаю Apache, я бы пообещал, что другие HTTP-серверы также предлагают аналогичные модули. Это зависит от вас, чтобы решить, какое решение лучше всего подходит для вашей компании.Вы также можете полностью их поцарапать и использовать функцию DNS round robins. Это не так хорошо, но определенно намного проще настроить и может быть достаточно, если каждый доступ к вашему приложению. довольно симметрична (используется примерно столько же времени). Если некоторые запросы занимают 3 секунды, когда другие используют 50 мс, вы можете столкнуться с проблемами только с настройкой DNS RR.

Приложение может быть на любом языке. Я использую C++, но я мог бы использовать Java, PHP, plain C (действительно ?!), perl и т. Д. Все, что работает для вас. Просто помните, НЕТ ДАННЫХ на интерфейсах. Все в базе данных, и все будет хорошо. Зеркалирование выполняется Cassandra, поэтому ваша работа в этом была выполнена.

Обратите внимание, что приведенный выше график не совсем корректен. Интерфейсы должны подключаться к любому узлу Cassandra. Часто драйверы подключаются к 2 или 3 узлам, чтобы всегда иметь доступ к данным. Затем, как только вы перейдете от 1000 пользователей до 10 000, вы просто добавите несколько интерфейсов и несколько узлов Cassandra, и voilà! Все будет работать по-прежнему (такая же скорость для клиентов).

Что касается использования ISPConfig, обязательно. Будет ли ISPConfig помочь вам со всеми этими частями? Возможно нет. По крайней мере, не добавляя свой собственный модуль (модули) ... Но вы должны иметь возможность использовать его для своих целей: настроить DNS, настроить электронную почту, возможно, сделать большую часть установки Apache и т. Д.