Лютий 2005 року - Каліфорнія, США.
Троє ранніх співробітників PayPal хотіли створити платформу для обміну відео. Тож вони заснували YouTube у себе в гаражі.
Але вони мали обмежені фінансові ресурси. Тому вони фінансували YouTube коштом кредитних карток та інфраструктурних запозичень. Фінансові обмеження змусили їх створити інноваційні методи масштабування.
Наступного року вони досягли 100 мільйонів переглядів відео на день. І вони зробили це, маючи лише 9 інженерів.
Масштабованість YouTube
Ось 11 методів масштабування YouTube:
1. Магічний маховик
Вони застосували науковий підхід до масштабування: зібрали та проаналізували системні дані.
Їхній робочий процес був постійним циклом: виявлення та усунення вузьких місць. Такий підхід дозволив уникнути потреби у висококласному обладнанні та зменшити витрати на нього.
2. Нудний технічний стек
Вони спростили свій технічний стек і використовували перевірені технології. Їхній технічний стек:
У MySQL зберігалися метадані: назви відео, теги, описи та дані користувачів. Тому що в MySQL було легко виправити проблеми.
Вебсервер Lighttpd обслуговував відео.
Операційною системою став Linux. Вони використовували інструменти Linux для перевірки поведінки системи: strace, ssh, rsync, vmstat і tcpdump.
Python на сервері прикладних програм. Тому що він пропонує багато універсальних бібліотек, і вони не хотіли вигадувати велосипед. Іншими словами, Python дозволяв швидку та гнучку розробку. За їхніми оцінками, Python ніколи не був вузьким місцем.
Проте вони використовували компілятор Python-to-C та розширення мови C для виконання завдань, що вимагають інтенсивного використання процесора.
3. Не ускладнюйте
Вони вважали архітектуру програмного забезпечення основою масштабованості. Вони не слідували модним словам для масштабування. Але зберігали архітектуру простою, що полегшувало перегляд коду. І це дозволило їм швидко змінювати архітектуру відповідно до мінливих потреб. Наприклад, вони перетворили сайт знайомств на сайт для обміну відео.
Вони тримали мережевий канал простим. Тому що мережеві пристрої мають обмеження щодо масштабування.
Також вони використовували звичайне обладнання. Це дозволило їм зменшити енергоспоживання та витрати на обслуговування - і утримати витрати на низькому рівні.
Крім того, код, що враховує масштабування, залишався невидимим для розробки застосунків.
4. Обирайте свою битву
Вони передали свої проблеми на аутсорсинг. Тому що хотіли зосередитися на важливих речах. У них не було ні часу, ні ресурсів на створення власної інфраструктури для обслуговування популярних відео. Тому вони розмістили популярні відео на сторонньому CDN. Переваги:
- Низька затримка. Завдяки меншій кількості мережевих переходів від користувача
- Висока продуктивність. Завдяки тому, що відео віддається з пам'яті
- Висока доступність. Завдяки автоматичній реплікації
Вони обслуговували менш популярні відео з колокаційного дата-центру. І використовували програмний RAID для підвищення продуктивності внаслідок паралельного доступу до декількох дисків. Також налаштували свої сервери, щоб запобігти переповненню кешу.
Вони розмістили свою інфраструктуру в колокаційному дата-центрі з 2 причин. Щоб легко налаштовувати сервери відповідно до своїх потреб. І щоб укладати власні контракти.
Кожне відео мало 4 мініатюри. Отже, вони зіткнулися з проблемами в обслуговуванні невеликих об'єктів: багато дискових пошуків і обмеження файлової системи. Тому вони помістили мініатюри у BigTable. Це розподілене сховище даних з багатьма перевагами:
- Уникає проблем з малими файлами завдяки кластеризації файлів
- Покращена продуктивність
- Низька затримка завдяки багаторівневому кешу
- Простота експлуатації
Також вони підробляли дані, щоб запобігти дорогим транзакціям. Наприклад, вони підробляли кількість переглядів відео та асинхронно оновлювали лічильник. Популярною сьогодні технікою для наближення до коректності є блум-фільтр. Це імовірнісна структура даних.
5. Принципи масштабування
Вони покладалися на 3 основні принципи масштабованості: відсутність стану, реплікація та розбиття на розділи.
Їхні веб-сервери не мали статусу. І масштабували їх за допомогою реплікації.
Вони реплікували сервер бази даних для масштабування операцій читання та високої доступності. І збалансували трафік між репліками. Але такий підхід спричинив проблеми: затримку реплікації та проблеми з масштабуванням на запис.
Отже, вони розбили базу даних на розділи для поліпшення масштабування на запис, локалізації кешу та продуктивності. Це також зменшило витрати на апаратне забезпечення на 30%.
Крім того, вони вивчили шаблони доступу до даних, щоб визначити рівень розділів. Наприклад, вивчили популярні запити, об'єднання та узгодженість транзакцій. І вирішили, що рівнем розділу буде користувач.
6. Надійна команда інженерів
Кваліфікована команда є важливим активом для масштабованості.
Вони зберегли невеликий розмір команди для кращої комунікації - 9 інженерів. І їхня команда чудово володіла багатопрофільними навичками.
7. Не повторюйтесь
Вони використовували кеш, щоб запобігти повторенню дорогих операцій. Це дозволило їм масштабувати зчитування.
Також вони впровадили кешування на багатьох рівнях - і це зменшило час відгуку.
8. Визначте пріоритетність ваших задач
Вони ставили трафік перегляду відео вище за все інше. Тому вони виділили окремий кластер ресурсів для трафіку, пов'язаного з переглядом відео. Це забезпечило високу доступність.
9. Запобігайте появі проблеми громового стада (Thundering Herd)
Проблема громового стада виникає, якщо багато одночасних клієнтів запитують сервер. Це погіршує продуктивність.
Вони використовували джиттер, щоб запобігти проблемі "громового стада". Наприклад, вони додали джиттер до закінчення терміну дії кешу популярних відео.
10. Гра в довгу
Вони зосередилися на макрорівні речей: алгоритмах і масштабованості. Вони робили швидкі хаки, щоб виграти більше часу для створення довгострокових рішень. Наприклад, замінили поганий API на Python, щоб запобігти короткостроковим проблемам.
Вони мирилися з недосконалістю своїх компонентів. Коли виникало вузьке місце, вони або переписували компонент, або позбувалися його.
Вони жертвували ефективністю заради масштабованості. Приклади:
- Вони обрали Python замість C
- Вони тримали чіткі межі між компонентами для масштабування. І мирилися з затримками
- Вони оптимізували програмне забезпечення, щоб воно було достатньо швидким. Але не зациклювалися на ефективності машини
- Вони обслуговували відео з сервера на основі доступної пропускної здатності. А не на основі затримок.
11. Адаптивна еволюція
Вони налаштовували систему відповідно до своїх потреб. Приклади:
- Критичні компоненти використовували RPC замість HTTP REST. Це покращило продуктивність
- Кастомний BSON як формат серіалізації даних. Це забезпечило високу продуктивність
- Кінцева узгодженість у певних частинах програми для масштабованості. Наприклад, модель узгодженості читання і запису для коментарів користувачів
- Вивчали Python, щоб запобігти поширеним помилкам. Також покладалися на профілювання
- Спеціальне програмне забезпечення з відкритим вихідним кодом
- Оптимізували запити до бази даних
- Зробили некритичні завдання в режимі реального часу асинхронними
Вони не витрачали час на написання коду, для того, щоб обмежити людей. Замість цього вони застосували чудові інженерні практики - конвенції кодування, щоб покращити структуру коду.
Результат
Google придбав YouTube у 2006 році. І він залишається лідером на ринку відеообміну з 5 мільярдами переглядів відео на день.
За даними Forbes, статки засновників YouTube становлять понад 100 мільйонів доларів США.
Ще немає коментарів