Блог

Я практикуюсь в концепциях системного проектирования, и мне неясно, какую конфигурацию (процессор, память, дисковое хранилище) выбрать для экземпляра приложения? Кроме того, сколько экземпляров необходимо (при условии, что вы запускаете приложение в кластере Kubernetes)

Для расчета обратной стороны конверта я видел примеры расчета tps для вызовов чтения и записи ,расчета потребностей в пропускной способности, потребностей в хранении базы данных и т.д. Но я не видел, как определить процессор, потребности в памяти и сколько экземпляров достаточно. Существует ли процедура, которая поможет решить эту проблему?

Моя догадка говорит о том, что мы выбираем экземпляр сервера малого и среднего размера (если мы используем облачного провайдера, такого как AWS) и проводим стресс-тесты для расчета TPS, смотрим использование процессора и памяти и видим, нужно ли нам увеличивать или уменьшать конфигурацию сервера на основе результатов?

Я был бы очень признателен за любые ваши предложения.

Мне не ясно, какую конфигурацию (процессор, память, дисковое хранилище) выбрать для экземпляра приложения? Кроме того, сколько экземпляров необходимо (при условии, что вы запускаете приложение в кластере Kubernetes)

В основном это вопрос экономики. Если бы ресурсы были очень дешевыми, вы могли бы использовать их много — но, к сожалению, они имеют экономическую стоимость.

Масштабирование по горизонтали или увеличение по вертикали

Первый фундаментальный вопрос, который нужно задать, следует ли вам масштабировать свое приложение по вертикали (например, до более крупных экземпляров) или следует масштабировать приложение по горизонтали.

Самое главное здесь то, что масштабирование по горизонтали намного проще. Но сможете ли вы масштабироваться по горизонтали, если вам нужно масштабироваться по вертикали, зависит от вашего приложения. Если ваше приложение является веб-сервером без состояния, его обычно очень легко масштабировать, но если у вас есть кэш с отслеживанием состояния или база данных, масштабирование по вертикали может быть вашим единственным краткосрочным вариантом. Попробуйте спроектировать так, чтобы вы могли масштабироваться горизонтально, так как это намного проще.

Точный размер — наблюдаемость использования

Чтобы определить свой точный размер, используйте наблюдаемость, исследуйте свои узкие места и приспосабливайтесь к этому.

Например, если вы используете слишком мало памяти, ваше приложение будет закрыто, или если вы используете слишком мало процессора, ваше время отклика будет медленным. Просто начните с чего-нибудь и приспособьтесь.

В дополнение к ответу Джонаса:

У вас есть два подхода (которые не являются взаимоисключающими):

1. Оцените свои потребности на основе ожидаемой нагрузки и т.д.
2. Корректируйте свои потребности в зависимости от того, что вы наблюдаете на производстве.

Что касается первого подхода:

1. Вы провели какой-либо анализ того, какова ваша ожидаемая нагрузка? Например, сколько пользователей (уникальные сеансы), сколько запросов в среднем в час (просмотры страниц, вызовы API и т. Д.), Потенциальные пики активности, приводящие к увеличению нагрузки и т. Д.
2. Вы проводили какой-либо сравнительный анализ?
3. Вы посмотрели на свою систему и то, что она делает, и выяснили, есть ли у нее какие-либо конкретные потребности в ресурсах (процессор, память, диск и т. Д.)?

Для заблаговременной оценки ресурсов требуются некоторые знания (или обоснованные предположения) относительно того, какой будет нагрузка, в соответствии с 3 пунктами выше. Иметь представление о том, каково среднее значение ежедневных или почасовых запросов, — неплохое место для начала.

Также убедитесь, что вы знаете, есть ли какие-либо потенциальные всплески, которые могут вас зацепить (конец месяца для финансовых систем/услуг). Являются ли они достаточно значительными или нет, о которых стоит беспокоиться, — это другое дело. Мой друг как-то работал над системой продажи билетов, и у них были огромные скачки трафика на крупных мероприятиях, которые требовали серьезного расширения и возврата… но вашей обычной системе, вероятно, не нужно будет быть такой экстремальной.

Процессор, вероятно, стоит «беспокоиться» только в том случае, если у вас есть что — то, что выполняет обработку выше среднего-это должно быть очевидно с помощью сравнительного анализа или если вы/ваша команда хорошо знаете свой код.

Можно рассчитать использование диска — например

• Если в среднем пользователь генерирует 1 МБ данных за сеанс (не включая системные журналы), и вы получаете 100 сеансов в день, то это 100 МБ в день, 500 МБ в рабочую неделю, 200 МБ в месяц и т. Д.
• Если профиль пользователя содержит в среднем 200 Кб данных и 300 Кб места для хранения (изображений), вы можете рассчитать это.
• Вы также можете сделать это для записей, особенно для записей, которые, как вы знаете, «большие» (например, >25 МБ) или где их будет много (например, миллионы).

Вы также можете начать прогнозировать рост с течением времени, если вы разрешите темпы роста (например, количество пользователей и их сеансов, а также объем генерируемых данных). Простой способ сделать это-создать электронную таблицу с несколькими простыми формулами, которые принимают различные входные данные, такие как количество пользователей, средние запросы на пользователя, дисковое пространство на пользователя и т.д. Затем вы можете выполнить моделирование «что, если», играя с входными данными.

С точки зрения второго подхода — как говорит Джонас, наблюдайте и приспосабливайтесь. Убедитесь, что вы знаете, как это сделать, и что ваше решение предоставляет необходимые вам данные. Это может быть использование показателей, предоставленных вашим облачным провайдером (если применимо), или инструментов / отчетов, которые вы специально встроили в свое решение.

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