Коли починати думати про масштабованість? [зачинено]

У мене є смішна, але і жахлива проблема. Я збираюся запустити нову програму (iPhone). Це покрокова багатокористувацька гра, що працює на моєму власному спеціальному бекенде. Але я боюся запускати.

Я чомусь думаю, що це може стати чимось великим і що його популярність вб’є мого бідного самотнього єдиного сервера + бази даних MySQL.

З одного боку, я думаю, що якщо він зростає, я краще буду готовий і мати масштабовану інфраструктуру.

З іншого боку, я просто відчуваю, як вивести його у світ і побачити, що відбувається.

Я часто читаю речі на кшталт "передчасна оптимізація - корінь усього зла", або люди говорять, що ви повинні просто створити свою вбивчу гру зараз, з інструментами під рукою, і піклуватися про інші речі, такі як масштабованість пізніше.

Я хотів би почути деякі думки з цього приводу від експертів чи людей, які мають з цим досвід. Дякую!

Це насправді досить простий вибір.

Зараз у вас немає користувачів, а масштабованість - це не проблема.

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

Зараз у вас немає проблеми зі масштабуванням; у вас проблема з кількістю користувачів. Якщо ви працюєте над проблемою масштабування, ви не будете виправляти проблему кількості користувачів, а це означає, що ви вирішили проблему, якої у вас ще немає, і не вирішили проблему, яку у вас є. Найімовірнішим результатом є те, що ваш продукт не виготовить його, і вся ваша робота буде витрачена ні на що.

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

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

Звичайно, це допомагає мати на увазі масштабованість під час написання потрібного вам коду, але це не має сенсу витрачати десятки чи навіть сотні людино-годин на функцію, про яку ви не знаєте, чи знаєте ви Вам це коли-небудь знадобиться, і найімовірніший сценарій - вам цього не вдасться. Зараз ваша головна проблема - доставка. Що відбувається після цього; ну, ви можете турбуватися про це пізніше.

Немає підстав для оптимізації, поки ви не знаєте, що потрібна оптимізація. Як ви знаєте, що потрібна оптимізація? Ви міряєте.

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

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

Насамперед. Масштабність! = Оптимізація

Вам слід подумати про масштабованість, перш ніж буде написано перший рядок коду. Це не означає, що ви розбудовуєте масивну інфраструктуру з випадкових випадків, що ваша гра може стати хітом. Думати про масштабованість означає:

• Переконайтесь, що код записаний, щоб він міг масштабуватися. Я бачив безліч проектів, де не було думки про необхідність масштабування. Результати є кодовою базою, яка не буде масштабуватись незалежно від обладнання, яке ви кидаєте на неї, або є надзвичайно дорогим для масштабування.
• Визначте свою стратегію масштабування. Майте план, як підтримувати всіх користувачів. У вас є MySQL db, чи збираєтесь ви його шарувати або кластер, або щось інше. Такі стратегії, як шардінг, потребують певної продуманості, оскільки це ставить вимоги до архітектури. Скупчення, рідше. Чи підтримуєте ви сеанси, і як реагуватимуть сеанси з декількома серверами на передньому кінці. Чи знадобляться вам клейкі сеанси у вашому балансирі навантаження.
• Визначте стратегію впровадження. Чи збираєтесь ви використовувати AWS для масштабування. Чи можете ви використовувати будь-які продукти чи послуги, які дають вам можливість динамічного масштабування поза межами поля? Це також включає розуміння ваших витрат.

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

Якщо ваш код схильний до масштабування, тоді ви зробите важку частину. Ви можете отримати аккаунт AWS, запускати сервери за потребою та далеко їхати.

Якщо ваш код не масштабується або має вузькі місця, то вам належить виконати роботу. Вам потрібно визначити, які ваші вузькі місця, і виправити їх. "Коли" насправді важко пізнати. Деякі плато служби, деякі стабільно піднімаються, а деякі вибухають. Вирішення питання, коли викидати ресурси на щось на зразок масштабування, як правило, є функцією бізнесу, і це оцінка ризиків.

На вашому положенні я можу випустити як "бета" та керувати очікуваннями користувачів. Таким чином я можу дістати товар і подивитися, як він розгортається.

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

По-перше, слід акуратно обміркувати, перш ніж написати єдиний рядок коду. Це робиться для того, щоб ви не записували себе в лунку масштабування та переконувались, що ваш код інструментується, щоб вдруге дати вам необхідні вимірювання.

Другий раз, щоб розглянути можливість масштабованості, достатньо, щоб заздалегідь речі стали неприпустимо повільними. Це означає, що вам потрібно знати, що означає "занадто повільно" і як ваша річ реагує під навантаженням. Якщо у вас є служба, чий драйвер (ймовірно, qps) збільшується на N% на місяць, ви відрізняєтесь від "95% спожитих машинних ресурсів", якщо використання ваших ресурсів має навантаження або лінійне навантаження.

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

Не знаючи конкретики, я б зайняв один-два дні, щоб подумати, де у вас є проблеми з масштабуванням та які можливі стратегії їх вирішення. Але це важливо, подумайте. Не робіть, просто подумайте (і документуйте). Якщо у вас не виникнуть проблеми зі масштабованістю, які починають проявлятися у кількох сотень користувачів, тоді вам слід встигнути перевірити завантаження та створити більше резервних ресурсів.

З вашого опису це здається, що є два можливі результати:

• Гра - це провал, і тоді вам все одно.
• Гра є успішною, і тоді ваш бекенд не зможе впоратися з навантаженням, і результатом буде провал.

Хммм.

Ось кілька питань, які потрібно задати собі:

• Скільки користувачів можуть обробляти ваш поточний бекенд з прийнятною продуктивністю?
• Чи є у вас якийсь план обмеження впливу на поточних користувачів, якщо ви бачите якесь швидке зростання (наприклад, тимчасово витягніть гру з магазину додатків)
• Як швидко ви можете придумати кращий запуск, якщо ви досягли успіху?
• Які ділові наслідки очікування. Ви можете годувати себе? Які ризики?
• Які наслідки випуску для бізнесу тепер даються відповіді на запитання вище.

Відповідь на ваше запитання має стати очевидною після їх врахування. Жоден експерт не може сказати вам, що робити без додаткової інформації, оскільки кожна система інша, і кожен бізнес інший.

Ваш сервер буде використовуватися інтерактивно інтерактивно. Це означає, що затримка дуже глибоко впливає на досвід користувача. Погана затримка завжди призводить до поганого досвіду користувача.

Принаймні зробіть кілька спеціальних тестів навантаження, як описано Брайаном.

Більш серйозний підхід

Виконайте декілька запусків моделювання та з’ясуйте, що затримка робить у вашому користувальницькому досвіді (або за допомогою симуляції затримки в мережі, або просто уві сні () у вашій програмі). Дізнайтеся, яка затримка стає помітною, дратує і стає непридатною.

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

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

Дуже приємна презентація про вимірювання затримки від Gil Tene: http://www.infoq.com/presentations/latency-pitfalls

На етапі вимог до бізнесу, який потім використовується для встановлення єдиного розуміння продуктивності для всіх елементів нижче за течією, таких як архітектура, операційні програми, розробка, контроль якості та моніторинг у виробництві. Якщо ви не встановите єдине розуміння того, що потрібно напередодні, тоді ви будете мати кожну з частин організації, які роблять припущення про ефективність (або взагалі не думають про них), займаючись певними завданнями протягом життєвого циклу застосування. Це вірно, чи займаєтесь ви водоспад, короткий водоспад, спритний або будь-яка інша методика розвитку в даний час є гарячою у списку резюме ключових слів.

Продуктивність та масштабованість важкі. Функціональність проста. Поганий код масштабування зростатиме, щоб заповнити той ресурс, який ви йому надаєте, тому зміщення міхура витрат на придбання більшого обладнання лише забирає вас так далеко, перш ніж вам доведеться або виправити неефективний код, або придбати все більше обладнання. Залишити це останньою у пріоритеті також дуже дорого. Є архітектурні та дизайнерські рішення, які приймаються на початку життєвого циклу програми, які, можливо, доведеться повністю змінити для того, щоб досягти вимоги, що надійшла пізно, пов'язаної з продуктивністю. вуглецеве волокно пізно в проектному циклі, щоб досягти співвідношення потужності / ваги, пов'язаного з робочими характеристиками, і як це впливає на оснащення, навчання, конструкцію автомобіля тощо ...

Запитайте у архітекторів, розробників та оперативних працівників у вашій організації, які вимоги щодо продуктивності програми. Якщо вони не захоплені бізнесом, то не дивуйтеся, якщо ви отримуєте різні відповіді (або немає відповідей) від різних осіб навіть у межах однієї групи. Ці "припущення" завжди повертаються, щоб примружити організацію в розгортанні.