Клас буде активний з 11 жовтня 2023 року до 11 квітня 2024 року, після чого буде відкрито наступний потік. Слідкуйте за оновленнями.
Збір вимог до системи
Збір вимог до системи
Оскільки задача проєктування систем майже завжди формується у відкритій формі, нам потрібно окреслити функціонал та визначити вимоги до системи.
Слід почати з пошуку відповідей на наступні питання:
Функціональні вимоги: які основні можливості дає система користувачам?
Нефункціональні вимоги: наскільки надійною та швидкою має бути система?
Обмеження функціоналу: які обмеження на функціонал системи накладаються зовнішніми факторами?
Функціональні вимоги
Функціональні вимоги
Функціональні вимоги - це можливості, які система надає користувачеві.
Наприклад, для соціальних мереж це:
додавання в друзі;
спілкування між користувачами;
створення пабліків.
Для цього варто виписати основні можливості системи в порядку важливості та вказати, над якими ми плануємо сконцентруватися надалі.
Приклад соціальних мереж
Створення профілю (додавання опису і фото)
Приклад соціальних мереж
Потім, залежно від спрямованості соціальної мережі, можемо представити такі функції, як:
створення контенту (публікації, фото, відео, історії)
відстеження контенту (за користувачами чи тегами?)
додавання контактів з мережі (номер телефону?)
спілкування зі своїми контактами (текстові повідомлення, відео-дзвінки, голосові повідомлення?)
Приклад соціальних мереж
Якісь соцмережі можуть підтримувати всі напрямки і додаткові можливості, на кшталт додавання геотегів, пошуку контенту, рекомендацій тощо.
Функціональні вимоги
Основні думки для створення соціальної мережі
Має сенс вибрати той функціонал, на якому зупинимося:
створення профілю з юзернеймом;
створення тільки текстових постів;
підписка на пости інших користувачів.
А інші можливості згадати, але винести за рамки проектованої версії:
додавання контактів за номером телефону;
спілкування зі своїми контактами з відеодзвінками;
додавання тегів і геоміток до постів;
повнотекстовий пошук контенту;
відображення постів від користувачів поблизу та ін.
Нефункціональні вимоги
Нефункціональні вимоги
Нефункціональні вимоги - це те, як має поводитися система в роботі.
Типові запитання, на які хочемо відповісти:
Чи має система бути абсолютно надійною або якісь дані можуть загубитися?
Що нам важливіше - швидка відповідь системи чи гарантія врахування останніх змін?
З якою затримкою можуть застосовуватися внесені нами зміни?
З якою затримкою відображаються запитувані дані?
Нефункціональні вимоги
На перший погляд всі ці питання можуть виглядати дивними — чому б не зробити систему якомога швидшою та надійнішою? Але відповіді на них допоможуть нам зрозуміти, які компроміси ми готові робити.
Наприклад, CAP-теорема говорить, що розподілена система не може одночасно бути:
Consistent (консистентною),
Available (доступною),
Partition-tolerant (стійкою до розділення мережі).
Збої мережі неминучі, тому на час розділення обираємо між C та A.
Нефункціональні вимоги
Для соціальної мережі важливо, щоб вона завжди була доступною.
Соціальна мережа також розподілена, маючи користувачів по всьому світу (і сервери, відповідно).
Однак, якщо користувач публікує пост, можливо, ми не одразу його побачимо.
Нічого страшного, якщо станеться затримка, рано чи пізно він все одно стане доступним для всіх користувачів. Тобто, консистентність не така критична.
Нефункціональні вимоги
У випадку з банківським додатком успішно проведена грошова транзакція повинна означати надходження і видимість коштів на рахунку адресата, ніяк інакше.
Ціною цьому може бути недоступність застосунку якийсь час.
Приклади
Сервіс коротких посилань
Навіщо потрібен такий сервіс?
Щоб перетворювати довгі посилання на короткі, зручні для обміну.
Сервіс коротких посилань
Функціональні вимоги:
користувач може ввести довге посилання та отримати коротке;
коли користувач переходить по короткому посиланню, він перенаправляється на вихідне посилання.
користувач може вибрати коротке посилання самостійно.
посилання “протухає” через певний час.
Нефункціональні вимоги:
система повинна бути доступною.
перенаправлення з мінімальною затримкою.
коротке посилання має бути унікальним.
коротке посилання має бути випадковим, щоб його не було легко підібрати.
Бонус: збір аналітики, API для розробників.
Хостинг текстів
Навіщо потрібен такий сервіс?
Щоб ділитися кодом і шукати в ньому помилки разом.
Користувачам рекомендуються нові фільми та серіали
Нефункціональні вимоги:
Висока доступність сервісу - інакше користувачі будуть дивитися котиків у конкурентів.
Висока швидкодія сервісу - відео повинні програватися без підвисань.
Консистентність не така критична - після тижневого очікування одна хвилина непомітна.
Бонус: жанри, популярне, вибране, списки на подивитися потім.
Пошук ресторанів
Навіщо потрібен такий сервіс?
Щоб не їсти їжу з жовтих сумок.
Пошук ресторанів
Функціональні вимоги:
Користувачі можуть знаходити відповідні заклади поблизу.
Користувачі можуть додавати/оновлювати/видаляти заклади.
Користувачі можуть залишати відгуки до відвіданих місць із фото та оцінками
Нефункціональні вимоги:
Пошук має відбуватися швидко, інакше користувач замовить доставку.
Набагато більше навантаження очікується на підсервіс пошуку, ніж на редагування.
Бонус: фільтри за категоріями, рекомендації нових закладів.
Пошук таксі
Навіщо потрібен такий сервіс?
Щоб не їздити на маршрутках.
Пошук таксі
Функціональні вимоги:
Водії можуть виходити на зміну і чекати на замовлення.
Пасажири можуть знаходити водіїв поблизу.
Пасажири можуть замовляти поїздку, для неї знаходиться водій.
Позиції відстежуються з моменту прийняття поїздки і до її закінчення. В кінці поїздки водій продовжує зміну.
Нефункціональні вимоги:
Висока доступність сервісу - інакше пасажири поїдуть на метро, а водії на вокзал.
Низький час очікування для пасажира, маленький простій для водія.
Бонус: оцінки водіям, оцінки пасажирам, пояснення ціноутворення.
Розрахунок навантаження на систему
Загальні відомості
Після збору первинних вимог до системи дуже важливо оцінити необхідну інфраструктуру для розгортання і підтримки системи, а також вартість усього обладнання і процесів.
Від того, наскільки точним буде розрахунок, залежатиме успіх проєкту і його життєздатність, а найголовніше - чи вистачить у замовника матеріальних ресурсів, щоб втілити всі сформульовані побажання і вимоги до системи.
Оцінка дасть змогу скоригувати очікування від продукту.
Розрахунок навантаження на систему
На цій стадії проєктування ми оцінюємо з різних сторін яке навантаження може бути на систему.
Чи є якісь перекоси у бік читання або запису і яке залізо або інтернет-канал може знадобитися для передачі необхідної кількості даних.
З яких складових складається загальне навантаження?
flowchart LR
A[User] --> B((Internet))
B --> C[Service]
C --> D((Network))
D --> E[(Storage)]
style A fill:#5cb85c
style B fill:#5bc0de
style C fill:#d9534f
style D fill:#5bc0de
style E fill:#428bca
Основні метрики розрахунку
Трафік користувачів
Мережеве навантаження
Обчислювальне навантаження
Навантаження на сховище
Трафік користувачів
Щоб розрахувати необхідний обсяг трафіку, потрібно оцінити потенційну аудиторію системи та підрахувати загальну кількість користувачів.
Якщо це якась закрита система для внутрішнього користування організації - кількість користувачів оцінюємо, виходячи з поточного штатного розкладу та обов’язків співробітників. Також можна закласти відсоток розширення персоналу, щоб врахувати приріст користувачів у майбутньому.
Якщо майбутня система це загальнодоступний ресурс - соціальна мережа або інший сервіс, тоді для приблизної оцінки можна проаналізувати метрики найближчих конкурентів.
Виходячи з кількості потенційних користувачів, далі можна оцінити час роботи користувачів у системі на день/місяць, оцінити обсяг контенту, що генерується і споживається під час роботи, а також обсяг місця на жорстких дисках під зберігання цього контенту.
Трафік користувачів
Джентльменський набір користувацьких метрик:
Кількість активних користувачів в місяць (Monthly Active Users, MAU)
Кількість активних користувачів в день (Daily Active Users, DAU)
Загальна кількість користувачів на заданому горизонті (наприклад, 5 років)
Скільки та якого контенту у середньому створює один користувач на день
Від бізнес-показників до оцінки навантаження:
Яка максимальна кількість запитів в секунду (RPS) буде до складових системи?
Скільки одночасних користувачів (CCU, concurrent users) і їхніх з’єднань необхідно буде утримувати?
Яким буде навантаження на мережевий канал і який обсяг трафіку ми використаємо?
Яким буде приріст необхідного місця на жорстких дисках та скільки даних набереться?
Які будуть витрати на інфраструктуру?*
Мережеве навантаження
Мережеве навантаження складається з кількості одночасно утримуваних з’єднань і загального обсягу трафіку, який проходить через мережу за одиницю часу.
Обмеження
Кількість з’єднань:C10k (1999), C1M (2011), C10M (2013).
Пропускна здатність каналу:
хмарна віртуальна машина — від 1 Гбіт/с (великі інстанси — десятки Гбіт/с);
З мережевого навантаження на сервіс можна вивести загальну вартість трафіку.
Хмарні провайдери беруть плату переважно за вихідний трафік: від $0.01 (між зонами доступності) до $0.1 (в інтернет) за 1 ГБ. Вхідний трафік зазвичай безкоштовний.
Обчислювальне навантаження
Під обчислювальним навантаженням зазвичай мається на увазі кількість запитів користувачів до сервісу за секунду. Цей показник вимірюється в RPS (requests per second).
Залежно від операції, з якою користувач звертається до сервісу, обчислювальне навантаження помітно різниться, тому показники рахують для групи операцій, наприклад, окремо для операції на отримання текстових даних, окремо для читання з БД і окремо для запису в БД.
Обчислювальне навантаження на старті, звісно, оцінити найскладніше.
Обчислювальне навантаження
Природним чином воно залежатиме від складності створюваної нами системи. Але на якийсь порядок цифр для простих сценаріїв можна орієнтуватися за бенчмарками TechEmpower Web Framework Benchmarks
За грубою оцінкою можна виходити з того, що в простих сценаріях у хмарі ми зможемо витримувати навантаження в 100k RPS для текстових даних, 10k RPS на читання і 1k RPS на запис у БД.
Обчислювальне навантаження
За наявності потужних фізичних серверів у тих самих сценаріях можна прикидати ймовірне навантаження в 500k RPS для текстових даних, 50k RPS на читання і 5k RPS на запис у БД.
Реальні характеристики системи, звісно ж, виявлятимуться вже під час тестувань
Навантаження на сховище
Оцінивши кількість створюваного контенту з боку користувачів, ми можемо прикинути скільки місця він займатиме, який постійний приріст при цьому очікується і, відповідно, скільки того чи іншого заліза нам знадобиться для нашої системи.
Найпоширеніші види сховищ і значення показників їхньої швидкості обробки даних, а також вартість зберігання даних:
HDD зі швидкістю 100-300 МБ/с, диск на 20 ТБ коштує до $500.
NVMe SSD зі швидкістю 3-5 ГБ/с, диск на 8 ТБ коштує до $2000.
Оперативна пам’ять (RAM) зі швидкістю 50 ГБ/с, вартість планки 128 ГБ близько $1000.
Навантаження на сховище
Найпоширеніші види сховищ і значення показників їхньої швидкості обробки даних, а також вартість зберігання даних:
HDD зі швидкістю 100-300 МБ/с, диск на 20 ТБ коштує до $500.
NVMe SSD зі швидкістю 3-5 ГБ/с, диск на 8 ТБ коштує до $2000.
Оперативна пам’ять (RAM) зі швидкістю 50 ГБ/с, вартість планки 128 ГБ близько $1000.
У середньому зберігання 1 ТБ обійдеться приблизно в $10000 в RAM, $300 на SSD і $30 на HDD.
Для оцінок можна вважати, що в одному сервері буде близько 1 ТБ RAM, 50 ТБ SSD або 200 ТБ HDD.
Якщо дисків багато, у гру вступає і річний рівень відмов (Annualized Failure Rate, AFR) — близько 1–2% дисків на рік.
Ще про продуктивність
Один з важливих факторів для системи — це час/затримка відповіді або latency.
В деяких сценаріях вона буде визначатися швидкістю мережі/диску, але можуть бути й інші причини.
У 2007 році відомий інженер Jeff Dean з Google у лекції для студентів Стенфорда навів час виконання різних операцій на різних пристроях:
Звернення до кешу L1 0.5 ns
Помилка передбачення розгалуження 5 ns
Звернення до кешу L2 7 ns
Блокування/розблокування mutex 100 ns
Звернення до основної пам’яті 100 ns
Стиснення 1K байт алгоритмом Zippy 10 000 ns
Передача 2K байт через мережу 1 Гбіт/с 20 000 ns
Послідовне читання 1 МБ з пам’яті 250 000 ns
Запит туди і назад в межах одного дата-центру 500 000 ns
Ті самі операції графічно, але з пізніше уточненими значеннями (наприклад, mutex — 25 ns, читання 1 МБ з диска — 20 ms) і доданими SSD:
Ще про продуктивність
На які показники варто орієнтуватися під час розрахунків навантаження на систему:
Трафік: MAU, DAU, приріст контенту на день, загалом за 5 років, співвідношення R/W.
Мережа: C10k давно не питання, 1 Gbps навіть у хмарі, платимо не більше ніж $0.1/GB.
Обчислення: віддаємо 100k RPS тексту, зчитуємо 10k RPS і записуємо 1k RPS простих запитів у БД.
Сховище: HDD 300 MB/s і $30/TB, SSD 5 GB/s і $300/TB, RAM 50 GB/s і $10000/TB.
Для оцінок на одну машину беремо 1 TB RAM, 50 TB SSD або 200 TB HDD.
Приклади розрахунків
Приклад 1: сервіс коротких посилань
Робимо оцінки виходячи з припущень:
100М скорочень щомісячно (MAU 10M, DAU 1M, 3 скорочення у середньому).
Співвідношення читання до запису 100:1.
Звернень до сервісу в місяць: 100 * 100М = 10Млрд.
Навантаження на створення записів: 100М / (30 * 86400) ≈ 40 RPS. На читання: x100 = 4K RPS.
Якщо кожен запис займає 1 КБ, ми будемо генерувати трафік у 32 Мбіт/с1.
На горизонті 5 років ми будемо зберігати 100М * 5 * 12 = 6Млрд записів або 6 ТБ даних.
У підсумку, для такого навантаження достатньо і однієї робочої станції за декілька тисяч доларів.
Приклад 2: хостинг текстів
Робимо оцінки виходячи з припущень:
1М завантажень в день (MAU 10M, DAU 500K, 2 завантаження у середньому).
Співвідношення читання до запису 10:1.
Звернень до сервісу в місяць: 30 * 10 * 1М = 300 млн.
Навантаження на створення записів: 1М / (86400) ≈ 12 RPS. На читання: x10 = 120 RPS.
Якщо кожен запис займає 10 КБ, ми будемо генерувати трафік у 10 Мбіт/с.
На горизонті 5 років ми будемо зберігати 30М * 5 * 12 = 1.8 Млрд записів або 18 ТБ даних.
У підсумку, для такого навантаження достатньо і однієї робочої станції за декілька тисяч доларів.
Приклад 3: автодоповнення
Робимо оцінки виходячи з припущень:
1 млрд. звернень до сервісу в день.
10 млн. унікальних запитів покриває більшу частину звернень.
Запити складаються в середньому не більше ніж з 5 слів до 10 символів кожне.
Маємо: 50 символів на запит в середньому, тобто в 200 байт точно поміститься.
Всього на збереження 10 млн. унікальних запитів піде: 10 млн. * 200 байт = 2 ГБ.
Якщо припустити, що кожен день з’являється 5% нових унікальних запитів, то на горизонті 5 років ми будемо зберігати індекс розміром 2 ГБ + 2 ГБ * 0.05 * 365 * 5 ≈ 185 ГБ.
У підсумку, для такого навантаження достатньо і однієї робочої станції за декілька тисяч доларів.
Приклад 4: хмарний диск
Робимо оцінки виходячи з припущень:
1 млрд. користувачів всього, 100 млн. DAU.
У користувачів в середньому 5 гаджетів.
У кожного користувача в середньому 100 файлів по 100 кБ, активні змінюють 1 файл.
Мережа: на оновлення 100 млн. * 100 кБ = 10 ТБ трафіку в день, 10 ТБ / 86 400 сек ≈ 1 Gbps, 10 ТБ * ≈ 2 тис. днів ≈ 20 PB за 5 років, відкрито 10 тис. з’єднань.
Обчислення: необхідно писати 100 млн. записів в день = 1 тис. RPS з записами до БД.
Сховище: всього зберігаємо 1 млрд. * 100 * 100 кБ = 10 PB, тобто 50 серверів з 200 TB HDD кожен.
Вартість: синхронізація змін на інші пристрої дасть щонайменше 20 PB вихідного трафіку, тобто від $2 млн., на зберігання 10 PB HDD потрібно $300 тис.
На датаноди нам знадобиться до 100 серверів, з’єднання і трафік витримає і один сервер, але краще більше.
Підтримка всієї системи обійдеться в декілька млн. доларів на горизонті 5 років.
Приклад 5: Instagram
Робимо оцінки виходячи з припущень:
1 млрд. користувачів всього, 100 млн. DAU.
Користувач завантажує по одному фото в день розміром 100 кБ.
Перегляди і завантаження співвідносяться 100:1.
Мережа:
завантаження фото 100 млн. / 100 тис. сек = 1 тис. RPS, 1 тис. * 100 кБ ≈ 1 Gbps і ≈ 20 PB за 5 років;
читання 100 тис. RPS / 100 Gbps, C100k.
Обчислення: 1 тис. RPS на запис фото, 100 тис. RPS на читання.
Сховище: всього зберігаємо 20 PB фото, тобто 100 серверів з 200 TB HDD кожен.
Вартість: на зберігання 20 PB HDD потрібно $600 тис., а віддача фото (100 Gbps ≈ 2 EB за 5 років) за прайсом $0.1/GB коштувала б ≈ $200 млн.
На датаноди нам знадобиться від 100 серверів, на з’єднання, трафік та читання БД — ще десятки.
Сервери та сховище обійдуться в декілька млн. доларів на горизонті 5 років, а фото вигідніше роздавати через CDN.
Приклад 6: Telegram
Робимо оцінки виходячи з припущень:
100 млн. DAU.
Кожен користувач відправляє до 100 повідомлень в день, кожне 1 кБ.
Кожне повідомлення читається 10 разів (приватні + групи).
Мережа:
завантаження повідомлень 100 млн. * 100 / 86400 ≈ 100 тис. RPS, 100 тис. * 1 кБ ≈ 1 Gbps і ≈ 20 PB за 5 років;
читання 1 млн. RPS / 10 Gbps, C1M.
Обчислення: 100 тис. RPS на запис повідомлень, 1 млн. RPS на читання.
Сховище: всього зберігаємо 20 PB повідомлень, тобто 100 серверів з 200 TB HDD кожен.
Вартість: на зберігання 20 PB HDD потрібно $600 тис., вихідний трафік на читання (10 Gbps ≈ 200 PB за 5 років) обійдеться у $20 млн.
Знадобляться сотні серверів: і для датанод, і для підтримки з’єднань, і для записів у БД.
Підтримка всієї системи обійдеться в десятки млн. доларів на горизонті 5 років.
Приклад 7: Twitter
Робимо оцінки виходячи з припущень:
100 млн. DAU.
Кожен користувач відправляє 1 повідомлення в день, кожне 10 кБ.
Кожен користувач переглядає стрічку 10 користувачів.
Отже, читання та запис відбуваються в пропорції 10:1.
Мережа:
завантаження повідомлень 100 млн. * 1 / 86400 ≈ 1 тис. RPS, 1 тис. * 10 кБ ≈ 100 Mbps і ≈ 2 PB за 5 років;
читання 10 тис. RPS / 1 Gbps, C10k.
Обчислення: 1 тис. RPS на запис повідомлень, 10 тис. RPS на читання + JOIN та алгоритмічна стрічка.
Сховище: всього зберігаємо 2 PB повідомлень, тобто 10 серверів з 200 TB HDD кожен.
Вартість: вихідний трафік на читання (1 Gbps ≈ 20 PB за 5 років) обійдеться у $2 млн., на зберігання 2 PB HDD потрібно $60 тис.
На датаноди нам знадобиться десятки серверів + сервери для обчислень і допоміжні сервери.
Підтримка всієї системи обійдеться в декілька млн. доларів на горизонті 5 років.
Приклад 8: Netflix
Робимо оцінки виходячи з припущень:
10 млн. DAU, 20 000 фільмів у бібліотеці.
Кожен користувач дивиться 1 годину контенту.
Навантаження зі сторони контент-мейкерів поки пропускаємо.
Мережа: відео 1080p потребує ≈ 5 Mbps; за день 10 млн. * 4000 сек * 5 Mbps = 200 Pb ≈ 25 PB, тобто в середньому ≈ 2 Tbps (2 000 Gbps 😧).
Обчислення: 10 млн. * 10 переглядів / 100 000 сек. = 1 тис. RPS на отримання метаданих між серіями.
Сховище: 20 000 найменувань по 10 годин (фільми, але і серіали): 20 тис. * 10 * 4000 сек * 10 Mbps = 8 Pb ≈ 1 PB = 1 тис. TB на одну якість відео.
Вартість: сховище навіть з десятками копій у різних якостях — до кількох мільйонів доларів, а мережа — мільярди: 25 PB * ≈ 2 тис. днів ≈ 50 EB, тобто ≈ $5 млрд. 😮.
За трафік по стандартному прайсу розплатитися неможливо, тому Netflix має власні CDN (мережі дистрибуції контенту).
