Когда начать думать о масштабируемости? [закрыто]

У меня смешная, но и ужасная проблема. Я собираюсь запустить новое приложение (iPhone). Это пошаговая многопользовательская игра, работающая на моем собственном бэкэнде. Но я боюсь запустить.

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

С одной стороны, я думаю, что если он будет расти, мне лучше подготовиться и уже иметь масштабируемую инфраструктуру.

С другой стороны, мне просто хочется выпустить это в мир и посмотреть, что произойдет.

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

Я хотел бы услышать некоторые мнения по этому поводу от экспертов или людей с опытом работы с этим. Спасибо!

На самом деле это довольно простой выбор.

Сейчас у вас нет пользователей, и масштабируемость не является проблемой.

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

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

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

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

Конечно, это помогает помнить о масштабируемости при написании кода, который вам нужен прямо сейчас, но не имеет большого смысла тратить десятки или даже сотни человеко-часов на функцию, о которой вы не знаете, это когда-нибудь понадобится, и наиболее вероятный сценарий - то, что вам не нужно. Прямо сейчас ваша главная задача - отправить. Что происходит после этого; ну, ты можешь об этом побеспокоиться позже.

Нет смысла оптимизировать, пока вы не узнаете, что оптимизация необходима. Как вы знаете, оптимизация необходима? Вы измеряете.

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

TL; DR Вам следует подумать о масштабируемости до того, как будет написана первая строка кода.

Обо всем по порядку. Scalabilty! = Оптимизация

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

• Убедитесь, что код написан так, чтобы он масштабировался. Я видел много проектов, в которых не думали о необходимости масштабирования. В результате получается кодовая база, которая не масштабируется независимо от оборудования, которое вы на нее бросаете, или слишком дорого масштабируется.
• Выясните свою стратегию масштабирования. Есть план о том, как поддержать всех пользователей. У вас есть MySQL db, собираетесь ли вы его осквернять, кластер или что-то еще? Стратегии, такие как шардинг, требуют некоторой предусмотрительности, поскольку предъявляют требования к архитектуре. Кластеризация менее. Поддерживаете ли вы сеансы, и как сеансы будут реагировать с несколькими интерфейсными серверами. Будут ли вам нужны липкие сессии, в вашем балансировщике нагрузки.
• Выясните стратегию реализации. Собираетесь ли вы использовать AWS для масштабирования. Можете ли вы использовать какие-либо продукты или услуги, которые обеспечивают динамическое масштабирование из коробки? Это также подразумевает понимание ваших затрат.

НО это звучит, как будто у вас уже есть кодовая база. Вопрос сейчас в том, когда начинать масштабирование. Это полностью зависит от вашего кода.

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

Если ваш код не масштабируется или имеет узкие места, то вам есть над чем работать. Вы должны определить свои узкие места и устранить их. «Когда» действительно трудно узнать. Некоторые плато услуг, некоторые неуклонно растут, а некоторые взрываются. Решение о том, когда использовать ресурсы при масштабировании, обычно зависит от бизнеса и оценки рисков.

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

Таким образом, вы должны подумать о масштабируемости два раза.

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

Второй раз, когда нужно рассмотреть масштабируемость, достаточно продвинуться вперед, чтобы стать неприемлемо медленным. Это означает, что вам нужно знать, что означает «слишком медленный» и как ваша вещь реагирует под нагрузкой. Если у вас есть служба, драйвер которой (вероятно, qps) увеличивается на N% в месяц, у вас будет время, отличное от «95% потребляемых ресурсов машины», если использование ресурсов является квадратом нагрузки или линейной нагрузкой.

В пошаговой игре у вас должен быть приличный запас прочности (у вас, вероятно, нет ни одного игрового мира, и если у вас есть, то, вероятно, существует внутренняя геометрия, то есть у вас ее нет), все взаимодействуют друг с другом каждый очередь "проблем).

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

Из вашего описания звучит так, что есть два возможных результата:

• Игра провалена, и тогда вам все равно.
• Игра успешна, и тогда ваш бэкэнд не сможет справиться с нагрузкой, и в результате будет провал.

Хммм.

Вот несколько вопросов, чтобы задать себе:

• Сколько пользователей может обработать ваш текущий бэкэнд с приемлемой производительностью?
• Есть ли у вас какой-то план по ограничению влияния на текущих пользователей, если вы видите какой-то быстрый рост (например, временно вытащите игру из магазина приложений)
• Как быстро вы можете придумать лучший бэкенд, если вы успешны?
• Каковы бизнес-последствия ожидания. Вы можете себя прокормить? Каковы риски?
• Каковы бизнес-последствия выпуска в настоящее время, учитывая ответы на вопрос выше.

Ответ на ваш вопрос должен стать очевидным, как только вы обдумаете это. Ни один эксперт не может сказать вам, что делать без дополнительной информации, поскольку каждая система отличается и каждый бизнес отличается.

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

По крайней мере, проведите специальное нагрузочное тестирование, как описано Брайаном.

Более серьезный подход

Сделайте некоторые прогоны симуляции и выясните, как задержка влияет на ваш пользовательский опыт (используя симуляцию сетевой задержки или просто sleep () внутри вашего приложения). Узнайте, с какой задержкой это становится заметным, становится раздражающим и становится непригодным для использования.

Затем наступает первый шаг в направлении оптимизации. Выберите SLA для своего сервера: например, в худшем случае 10% вызовов с раздражающей задержкой и 1% вызовов с неиспользуемой задержкой. С этими ограничениями вы можете использовать нагрузочное тестирование, чтобы узнать, сколько пользователей может поддерживать ваш сервер.

Тестирование чистой пропускной способности без измерения задержки (или, по крайней мере, ручного использования сервера во время нагрузочного теста) не очень полезно, поскольку оно не говорит вам, приводят ли измеренные значения пропускной способности к терпимому пользовательскому опыту.

Очень хорошая презентация об измерении латентности Джила Тене: http://www.infoq.com/presentations/latency-pitfalls

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

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

Спросите архитекторов, разработчиков и сотрудников вашей организации, каковы требования к производительности приложения. Если они не получены от бизнеса, то не удивляйтесь, если вы получите разные ответы (или не получите ответов) от разных людей даже в пределах одной группы. Эти «предположения» всегда возвращаются, чтобы ударить организацию при развертывании.