У меня есть дебаты по поводу масштабирования инстансов Amazon EC2. Я разработал свое приложение с использованием ASP.NET, поэтому мне нужно выбрать экземпляр Windows EC2. MySQL и изображения обслуживаются из других экземпляров, поэтому масштабирование выполняется (пока) только для экземпляра веб-приложения.
Мои варианты (пока):
Первый вариант дешевле и позволяет постепенно масштабировать приложение по сравнению с экземпляром Medium. Экземпляр Medium работает только с 32-битной версией, поэтому я как бы привязан к 32-битной версии. Я не хочу увеличивать масштаб, так как предпочитаю масштабировать по горизонтали. Это означает, что при низком трафике я не буду платить высокую цену за экземпляр Medium. Таким образом, со вторым вариантом я могу выбрать небольшой 64-битный экземпляр и масштабировать его по горизонтали, добавляя дополнительные серверы в Elastic Load Balancer, автоматически в зависимости от характеристик, полученных от Amazon CloudWatch (например, ЦП, ОЗУ и т. Д.).
Моя проблема в том, что мне сложно решить, какой из них выбрать. Я читал, что экземпляр Medium High-CPU в 5 раз мощнее, чем Small. Но цена для начала слишком агрессивна. В общем, я предпочитаю платить меньше и масштабировать при необходимости, добавляя больше мелких экземпляров.
Мне нужна твоя помощь в выборе пути. В чем преимущества каждого подхода? Почему лучше получить Medium high-CPU по сравнению с small с точки зрения горизонтального масштабирования, если есть преимущество. В конце концов, вся идея облачной архитектуры состоит в том, чтобы иметь возможность сэкономить на серверах, для которых вам не нужна их вычислительная мощность в заданный период времени.
Я сделал все возможное, чтобы оптимизировать экземпляр, используя кеширование как для страницы, так и для SQL-запросов к MySQL (которое существует в Xeround, что решило проблему масштабирования, когда дело доходит до БД). Моя БД относительно мала (1000 строк с небольшим количеством данных), поэтому 1,7 ГБ оперативной памяти на небольшом экземпляре вполне подходит для моих нужд кеширования. Я думаю, что при росте трафика основная проблема будет в ЦП. Кроме того, хранилище также очень маленькое, на нем размещаются только страницы ASPX моего веб-сайта.
Я предполагаю, что приложение может привлекать десять тысяч посетителей каждый день, а может и больше. Итак, масштабирование необходимо - НО будет ли небольшое горизонтальное масштабирование разумным ходом? - Будет ли это более разумным выбором даже для веб-приложений с высоким трафиком?
Сейчас я больше предпочитаю решение для небольшого экземпляра + Elastic Load Balancer. Кажется логичным платить меньше и платить больше по мере роста приложения.
Жду ваших знающих ответов. Спасибо.
Если ЦП действительно является узким местом, то лучше выбрать средний, так как он в 5 раз больше ЦП за 2 раза дороже. Однако я подозреваю, что ваше узкое место будет с файлом io, и в этом случае носитель может лишь немного превзойти малый.
Обязательно начните с малого. Вы всегда можете в любой момент перейти к экземпляру большего размера. Если вы проектируете с учетом горизонтального масштабирования, серверной частью может быть любое сочетание систем.