Лучше использовать несколько маленьких машин или меньше больших для развертывания стека?
Лучше ли разделить разные компоненты стека на несколько небольших машин или получить 1 или 2 больших машины и разместить несколько компонентов на одной машине?
Я думаю, что, если я начну с нескольких машин, будет легче масштабировать, увеличивая мощность каждой машины, когда это необходимо. Я пока не готов к горизонтальному масштабированию.
У меня есть бюджет 20 долларов в месяц, чтобы начать.
Я выбрал DigitalOcean, потому что он выглядит гибким с их каплей 512 МБ, поэтому вот мои варианты:
1, 2, 3 or 4 Machines of 512MB
2 Machines of 1GB
1 Machine of 2GB
1 or 2 Machines of 512MB + 1 Machine of 1GB
Вот мой стек:
Nginx
+
Gunicorn with 3 workers (=4 processes, memory footprint: ~50MB/process)
+
3 or 4 RQ workers (memory footprint of each worker: ~50MB)
+
Redis as Cache (limit to 100MB to start)
+
Redis as DataStore (small size: it is not meant to store a lot of data, mainly used to store the queues for the workers)
+
PostgreSQL (not sure how much RAM I would need)
Основной недостаток использования нескольких небольших машин состоит в том, что, поскольку ОС установлена на каждой машине, у каждой машины есть набор ресурсов, выделенных для ОС, который "теряется" для приложения. Основное преимущество, которое я вижу, заключается в том, что вертикальное масштабирование выглядит легче, поскольку каждая машина может быть обновлена отдельно.
Что было бы хорошим компромиссом?
Опция 1
512MB: Nginx, Gunicorn, Redis Cache
512MB: RQ Workers, Redis DataStore
1GB or 512MB: PostgreSQL
Я не уверен, стоит ли давать 1 ГБ только для PostgreSQL... Может быть, я должен просто использовать каплю 512 МБ? Кроме того, мне интересно, не будет ли машина объемом 512 МБ с Nginx, Gunicorn и кешем Redis слишком маленькой.
Так что я мог сделать это:
Вариант 2
1GB: Nginx, Gunicorn, Redis Cache
512MB: RQ Workers, Redis DataStore
512MB: PostgreSQL
Вариант 3 с использованием 2 больших машин
1GB: Nginx, Gunicorn, (RQ Workers), Redis Cache, (Redis DataStore)
1GB or 512MB: PostgreSQL, (RQ Workers here?), (Redis DataStore here?)
2 ответа
Один из способов распространения приложения на множество машин - запуск каждого слоя на отдельном оборудовании. Например, веб-сервер и сервер базы данных могут работать на одном компьютере или на разных компьютерах.
Выполнение одного или другого не потребует значительных изменений дизайна в программном стеке. В основном нужно следить за дополнительной задержкой связи, возникающей при разделении его на разные машины. Если, например, у вас есть приложение, использующее множество запросов к базе данных для визуализации веб-страницы, то большое количество циклических переходов приведет к ощутимому замедлению работы вашего приложения. Но это то, что вы можете создать вокруг.
Масштабирование, которое вы получаете от запуска разных слоев на разных машинах, невелико. Количество слоев в программном стеке имеет тенденцию расти медленнее, чем количество пользователей. Таким образом, вы просто не сможете масштабировать с помощью этого подхода в одиночку.
Однако разделение слоев на другом оборудовании может подготовить вас к масштабированию в другом направлении.
Если у вас есть один веб-сервер, взаимодействующий с одним сервером базы данных, вам не помешает настроить два веб-сервера, взаимодействующих с одним сервером базы данных. Другими словами, каждый уровень вашего программного стека можно масштабировать независимо.
Однако любое состояние поддержания слоя трудно масштабировать на нескольких машинах. В частности, база данных может оказаться самой сложной частью для масштабирования.
Что касается размеров отдельных машин, я бы стремился к размеру, дающему вам наибольшую производительность за эти деньги. Там будет размер, который является оптимальным с этой точки зрения. Большие машины будут слишком дорогими, а маленькие машины не будут достаточно дешевыми.
Но есть также вопрос о том, стоит ли проектировать для масштабируемости сейчас или позже. Вы можете тратить свое время на разработку масштабируемости, которая вам никогда не понадобится. С другой стороны, если вы не проектируете масштабируемость на многих машинах, вы можете попытаться найти единственную машину, достаточно большую для размещения той части вашей системы, которую вы не сможете распределить (база данных является вероятным кандидатом на часть, нуждающаяся в одной гигантской машине в некоторый момент).
Это интересный вопрос, и последнее замечание, сделанное @kasperd, является наиболее уместным (так что +1 только для этого). ИМО (и многие другие) - этот тип проблем хорош, но он определенно не тот, который вам следует делать, если вы действительно не ожидаете роста - иначе вы тратите время и деньги. С учетом сказанного здесь есть несколько соображений и вариантов.
По сути, есть несколько вопросов, включенных в этот вопрос, и главный из них заключается в том, следует ли увеличивать или уменьшать масштаб (с учетом затрат). Масштабирование, как правило, будет более ограниченным (и, возможно, немного более дорогостоящим, если вам потребуется избыточность), чем масштабирование, и с разнообразными доступными вариантами PaaS масштабирование будет менее сложным, чем в прошлом, но это говорит о том, что вы должны смотреть на цель приложения, которое вы доставляете, чтобы прийти к конкретному выводу о том, что лучше.
В Digital Ocean в настоящее время нет функции автоматического масштабирования, поэтому, если вы предполагаете всплески спроса, вам придется делать это вручную.
С точки зрения архитектуры, многие узкие места в системе будут являться базой данных, но это действительно зависит от того, насколько "управляемым данными" будет ваше приложение, не зная, что именно представляет собой приложение, или я не могу порекомендовать иметь более крупный экземпляр для вашей базы данных.
В некоторых отношениях управление несколькими небольшими экземплярами (исправление / обслуживание и т. Д.) Добавляет сложности, однако, если все уровни приложений разделены, это может, во многих случаях, упростить поиск узких мест (примечание: это также может сделать его более сложным). сложным, если это в конечном итоге является проблемой производительности сети).
Мой окончательный совет - начать как можно меньше и поместить весь свой стек в один маленький экземпляр и использовать такой инструмент, как Forge, чтобы управлять своим стеком, когда это необходимо. Ничто не мешает вам разделить уровни на более позднем этапе, масштабировать и отключать службы, которые вам не нужны, в данном окне (после разделения уровней).
Это дает вам гибкость выбора вертикального или горизонтального масштабирования, если это необходимо, предоставляет вам возможность легко разделять проблемы, и я полагаю, что наиболее важно, потому что у вас нет метрик, с которыми можно работать, чтобы вы эффективно работали с неизвестным.