Я впервые выпускаю веб-приложение. Я собираюсь использовать Django с Nginx и парой других скриптов, которые были переданы по конвейеру. Я хотел знать, какую стратегию автоматического масштабирования я могу использовать.
Прямо сейчас я играюсь с бесплатным экземпляром EC2 micro. Работает хорошо.
Я не уверен, могу ли я позволить себе выделенный RDS. Я ищу наиболее экономичную конфигурацию. Я думал об автоматическом масштабировании с помощью микро-экземпляров, которые были настроены с балансировщиком нагрузки, но я не понял, как синхронизировать базу данных во всех экземплярах.
Я также думаю о других альтернативах, таких как App Engine и Heroku, но я не думаю, что это даст мне свободу виртуальной машины. Есть ли PaaS, где обычную виртуальную машину можно без особого беспокойства масштабировать автоматически?
Кроме того, это какая-то диаграмма, которая может приблизительно сказать мне, сколько трафика могут выдержать экземпляры Micro, Small и т. Д.
Может кто-нибудь пролить свет?
Масштабирование приложения - это то, что вы должны спроектировать, чтобы иметь возможность делать это - независимо от платформы.
Некоторые соображения включают:
Я бы предположил, что лучший подход - сначала выгрузить вашу базу данных в другой экземпляр. Если ваши базы данных и приложение работают в разных экземплярах, вы можете масштабировать каждый независимо друг от друга, и вам будет намного проще справиться с проблемой. (Видеть Эта статья - староват, но не менее актуален).
Во-вторых, вы хотите увеличивать и уменьшать масштаб. С EC2 вы получаете гораздо лучшую производительность от более крупных типов инстансов - с точки зрения производительности небольшой инстанс лучше, чем 3 микроэкземпляра. Я предлагаю выполнить масштабирование до двух узлов (для отработки отказа), а затем начать переключать узлы на более крупные типы экземпляров, прежде чем продолжить масштабирование (на более постоянной основе). Тем не менее, в любом случае сохраняйте работоспособность автомасштабирования, чтобы ваше приложение могло справиться с дополнительной нагрузкой в любое время.
Масштабируйте свои базы данных отдельно - обычно вашему приложению требуется больше узлов, чем вашим базам данных (ваши базы данных могут выиграть от экземпляров с более высокой памятью). Также имейте в виду, что RDS не выполняет масштабирование за вас.
Amazon не предоставляет диаграмму «трафика», потому что она полностью зависит от вашего приложения (высокодинамичное приложение, интенсивно использующее процессор, может обслуживать гораздо меньше запросов, чем приложение, доставляющее статическую страницу на том же оборудовании). Однако это дает несколько «субъективное» сравнение. Вот. Стоит выделить один момент - «Производительность ввода-вывода». Этот дескриптор включает пропускную способность сети и дисковый ввод-вывод. Меньшие экземпляры более подвержены колебаниям производительности (особенно доступной пропускной способности). Поскольку томам EBS требуется пропускная способность сети, это также повлияет на их производительность.
Что касается микро-экземпляров - как только ваше приложение заслуживает, переходите к маленькому экземпляру. Вы обнаружите, что всякий раз, когда вы «разгоняете» процессор на микроконтроллере, возникает последующее снижение производительности (обозначенное значением «украсть» сверху). Другие экземпляры (которыми вы не владеете) могут использовать значительную часть вашего процессора на микро-экземпляре).
Также стоит упомянуть, что вы можете установить размер группы автомасштабирования равным «1», что позволит вам перезапустить экземпляр, если он станет недоступен. (Однако возникает проблема - вернуть ваши текущие данные в этот новый экземпляр, поскольку он запускается из моментального снимка).
Если вы можете использовать кластер MySQL (в нем используется другой механизм хранения - ndbcluster) или решение NoSQL с сегментированием, вам будет намного проще автоматизировать масштабирование ваших баз данных, чем при использовании традиционной репликации Master-Slave в MySQL. (Есть еще одно решение, которое, как сообщается, имело некоторый успех, но я бы, вероятно, не советовал на этом этапе - используя распределенную файловую систему, в частности GlusterFS, для хранения ваших баз данных - файловая система управляет блокировкой и распределением файлов, и каждый экземпляр обращается к базы данных по мере необходимости - это вызовет проблемы при добавлении дополнительных экземпляров, но может иметь некоторый успех с кластером баз данных из 2 узлов).
Таким образом, практический план действий может быть следующим:
(Вы должны обнаружить, что для большинства сайтов 2 больших экземпляров более чем достаточно для запуска вашей базы данных, особенно если вы правильно реализуете кеширование, но добавление дополнительного ведомого устройства по мере необходимости не должно быть слишком хлопотным).
Вышеупомянутый порядок действий достаточно хорошо подходит для масштабирования, но у него есть единственная точка отказа до шага 4 (т.е. если узел базы данных выходит из строя, ваше приложение отключается). Гораздо более сложная, но более устойчивая настройка: приложение и база данных находятся на одном узле, а затем настроены две копии этого узла с репликацией MySQL (и прокси-сервер MySQL для обработки запросов от балансировщика нагрузки) - вы потребуется самостоятельно управлять аварийным переключением (с помощью чего-то вроде Heartbeat / Pacemaker), а затем перейти непосредственно к 4 узлам (2 базы данных, 2 приложения).