Back-of-the-envelope calculations

Розрахунок без припущень неможливий. Наприклад, для оцінки навантаження потрібно знати:

• кількість активних користувачів;

• кількість дій одного користувача;

• кількість HTTP-запитів на одну дію;

• середній розмір запиту або відповіді;

• співвідношення читань і записів;

• коефіцієнт пікового навантаження;

• термін зберігання даних;

• кількість реплік.

Припущення не обов’язково будуть точними. Важливо явно їх назвати, щоб потім можна було змінити та перерахувати модель.

Корисні одиниці та наближення

Для швидких оцінок зручно використовувати такі значення:

• 1 хвилина ≈ 60 секунд;

• 1 година ≈ 3 600 секунд;

• 1 доба ≈ 86 400 секунд;

• 1 місяць ≈ 30 днів;

• 1 рік ≈ 365 днів;

• 1 KB ≈ 1 000 байт;

• 1 MB ≈ 1 000 KB;

• 1 GB ≈ 1 000 MB;

• 1 TB ≈ 1 000 GB.

У системному дизайні часто важливіше зберегти однакову систему одиниць, ніж сперечатися про різницю між 1 000 і 1 024.

Зручні наближення:

• 1 мільйон запитів на добу — це приблизно 12 запитів за секунду;

• 10 мільйонів запитів на добу — приблизно 116 запитів за секунду;

• 100 мільйонів запитів на добу — приблизно 1 160 запитів за секунду.

Формула:

Оцінка кількості запитів

Припустімо, що маємо:

• 2,5 мільйона активних користувачів на день;

• кожен користувач виконує 8 дій;

• одна дія в середньому породжує 1 HTTP-запит.

Тоді:

Середнє навантаження:

Середнє значення не показує реальний пік. Користувачі активні нерівномірно: вдень запитів більше, вночі — менше.

Якщо використати коефіцієнт піку 4:

У практичному розрахунку можна округлити це до 1 000 запитів за секунду.

Запас потужності

Система не повинна працювати на межі своїх можливостей. Додаємо, наприклад, 50% запасу:

Цей запас потрібен для:

• зростання кількості користувачів;

• нерівномірних піків;

• повторних запитів;

• фонових операцій;

• деградації окремих серверів;

• тимчасового зростання навантаження.

Коефіцієнт піку та запас не є універсальними константами. Їх потрібно обирати відповідно до продукту та наявних метрик.

Читання та записи

Загальну кількість запитів корисно розділити на читання і записи.

Нехай із 20 мільйонів запитів на добу:

• 97% — читання;

• 3% — записи.

Тоді:

Середня кількість записів за секунду:

Пікова кількість записів за секунду за коефіцієнта 4:

Це важливо для вибору сховища. Система може мати 1 000 запитів за секунду загалом, але лише 30 записів за секунду. Для бази даних це зовсім інший профіль навантаження, ніж 1 000 записів за секунду.

Оцінка обсягу даних

Нехай кожен запит повертає в середньому 35 KB даних.

Для 20 мільйонів запитів:

За 30 днів:

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

• частина відповідей генерується з даних, а не зберігається;

• дані можуть стискатися;

• у бази даних є індекси;

• зберігаються журнали та метадані;

• створюються резервні копії;

• використовуються репліки.

Якщо потрібно мати три копії даних:

До цього варто додати запас. Наприклад, із 30% запасом:

Дані, що додаються записами

Для оцінки довготривалого зберігання часто важливіший розмір одного запису, ніж розмір HTTP-відповіді.

Нехай:

• 600 000 записів створюється на добу;

• один запис займає 1,2 KB разом із необхідними полями.

Тоді:

За рік:

Якщо врахувати індекси, метадані та дві додаткові репліки, фізичний обсяг буде приблизно:

Це все ще наближена оцінка. Індекси можуть збільшити обсяг значно сильніше або слабше залежно від структури даних.

Оцінка пропускної здатності

Пропускна здатність залежить від кількості запитів та розміру даних.

Формула:

За пікового навантаження 1 000 запитів за секунду та відповіді розміром 35 KB:

Переведемо в біти:

З урахуванням запасу 50%:

Під час оцінки мережі потрібно уточнити, що саме рахується:

• лише трафік від сервера до клієнта;

• трафік у двох напрямках;

• трафік між сервісами;

• трафік між застосунком і базою даних;

• трафік реплікації;

• трафік резервного копіювання.

У розподіленій системі зовнішній трафік може бути невеликим, але внутрішній — значним через кілька міжсервісних викликів на один користувацький запит.

Оцінка кількості серверів

Припустімо, навантажувальний тест показав, що один сервер обробляє 150 запитів за секунду за прийнятної затримки.

Потрібна цільова пропускна здатність — 1 500 запитів за секунду.

Отже, мінімальна оцінка — 10 серверів.

У реальній системі потрібно також врахувати:

• резерв на відмову серверів;

• нерівномірний розподіл запитів;

• фонові задачі;

• різні типи запитів;

• обмеження бази даних;

• пам’ять і CPU;

• можливість горизонтального масштабування.

Якщо потрібно пережити відмову двох серверів, можна запустити 12 серверів. Тоді після втрати двох серверів залишиться 10 робочих серверів.

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

Оцінка оперативної пам’яті для кешу

Припустімо, що:

• є 2,5 мільйона профілів;

• у кеш потрібно помістити 10% найактивніших профілів;

• один профіль займає 2 KB у серіалізованому вигляді.

Кеш зазвичай потребує додаткової пам’яті на:

• ключі;

• структури даних;

• службові поля;

• індекси;

• фрагментацію;

• реплікацію.

Якщо використати коефіцієнт 2:

Якщо кеш має дві копії:

Це не означає, що потрібно орендувати кеш рівно на 2 GB. На практиці потрібен додатковий запас, а граничний розмір залежить від політики витіснення даних.

Зв’язок між пропускною здатністю та одночасністю

Для приблизної оцінки кількості одночасних запитів можна використати співвідношення:

Наприклад, за 1 000 запитів за секунду та середньої затримки 200 мс:

Якщо середня затримка зросте до 2 секунд:

Тому сервери, пули з'єднань і черги повинні бути розраховані не лише на RPS, а й на тривалість обробки запитів.

Це наближене застосування закону Літтла:

де:

• L — середня кількість елементів у системі;

• λ — швидкість надходження елементів;

• W — середній час перебування елемента в системі.

Приклад розрахунку в JavaScript

Нижче наведено невеликий самодостатній скрипт для оцінки запитів, трафіку, записів, сховища та кількості серверів.

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

Наприклад, збільшення actionsPerUser удвічі приблизно подвоїть:

• кількість запитів;

• мережевий трафік;

• навантаження на сервери;

• кількість записів, якщо співвідношення записів не зміниться.

Як перевіряти результат

Після розрахунку поставте собі кілька запитань:

• Чи правильно переведено добове навантаження в секунди?

• Чи враховано пікове навантаження?

• Чи відділено читання від записів?

• Чи однакові одиниці вимірювання в усіх формулах?

• Чи не переплутано KB із Kbit?

• Чи враховано реплікацію?

• Чи враховано індекси та службові дані?

• Чи має сервер гарантовану пропускну здатність, підтверджену тестом?

• Чи залишився запас після відмови частини інфраструктури?

• Чи не є середні значення небезпечно оптимістичними?

Корисно виконати розрахунок у трьох сценаріях:

• оптимістичному;

• базовому;

• песимістичному.

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

Типові помилки

Використання лише середнього навантаження

Середнє значення приховує піки. Система, яка витримує 250 запитів за секунду в середньому, може потребувати потужності для 1 000 запитів за секунду.

Відсутність явних припущень

Число «потрібно 10 серверів» нічого не пояснює без інформації про:

• кількість запитів;

• тип запитів;

• розмір відповідей;

• продуктивність одного сервера;

• запас потужності.

Плутанина між байтами та бітами

Розмір файлу зазвичай вказують у байтах, а мережеву швидкість — у бітах за секунду.

Тому 100 MB/с — це приблизно 800 Mbit/с.

Ігнорування реплік та індексів

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

Надто точні результати

Результат 926,37 запиту/с створює хибне відчуття точності. Якщо початкові дані приблизні, корисніше сказати «приблизно 1 000 запитів за секунду».

Вибір продуктивності сервера без вимірювань

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

Подвійне або пропущене врахування запасу

Потрібно чітко розділяти:

• коефіцієнт пікового навантаження;

• запас для зростання;

• резерв на відмову серверів.

Інакше запас можна випадково застосувати двічі або не застосувати взагалі.

Summary

• Back-of-the-envelope calculations допомагають швидко оцінити масштаб системи.

• Починайте з явних припущень і не намагайтеся отримати псевдоточний результат.

• Для RPS переводьте добову кількість запитів через 86 400 секунд.

• Окремо оцінюйте середнє, пікове та цільове навантаження із запасом.

• Розділяйте читання і записи, оскільки вони по-різному впливають на інфраструктуру.

• Для трафіку множте кількість запитів за секунду на розмір запиту або відповіді.

• Для сховища враховуйте термін зберігання, реплікацію, індекси та службові дані.

• Кількість серверів оцінюйте на основі виміряної продуктивності одного сервера.

• Пам’ятайте про зв’язок між RPS, затримкою та кількістю одночасних запитів.

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