Архітектура YouTube

Ріст YouTube був феноменально швидким, кількість переглядів відео перевищила 100 мільйонів у добу при тім, що тільки біля п’яти чоловік працювало над масштабуванням проекту. Як їм вдається управляти наданням всіх цих відеороликів своїм відвідувачам? Як вони розвивалися з тих пор, як були придбані Google?

Платформа
• Apache
• Python
• Linux (SuSe)
• MySQL
• psyco, динамічний компілятор Python → C
• lighttpd для відео

Що усередині?
Статистика
• Підтримка обробки більше 100 мільйонів відеороликів у добу
• Сервіс був запущений у лютому 2005 року
• У березні 2006 року в середньому вироблялося близько 30 мільйонів переглядів відео в день
• До липня 2006 року ця цифра досягла 100 мільйонів переглядів у день
• Над проектом працюють: 2 системних адміністратора, 2 архітектора масштабованості програмного забезпечення, 2 розроблювача нових можливостей, 2 інженера по мережах, 1 архітектор баз даних

Рецепт керування величезними темпами росту
while (true) { identify_and_fix_bottlenecks(); drink(); sleep(); notice_new_bottleneck(); }
Цей цикл проходить далеко не одну ітерацію щодня.

Веб-Сервери
• NetScalar використовується для балансування навантаження й кешування статичного контента.
• Apache працює із включеним mod_fast_cgi
• Запити відправляються на обробку за допомогою серверного додатка на Python.
• Додаток взаємодіє з різними базами даних і інших джерел інформації для формування фінальної HTML-сторінки.
• Масштабування звичайно відбувається просто додаванням додаткових комп’ютерів.
• Код на Python звичайно не є вузьким місцем системи, він проводить більшу частину часу заблокованим RPC.
• Python надає швидкість і гнучкість у процесі розробки й розгортання. Цей факт є дуже актуальним, якщо врахувати хто є їхніми конкурентами.
• На формування сторінки звичайно йде не більше 100 мілісекунд.
• psyco, динамічний компілятор Python → C, використовує JIT підхід до компілювання для оптимізації внутрішніх циклів
• Для інтенсивних обчислень, таких як шифрування, використовуються розширення, написані на C.
• Якась частина заздалегідь сгенерированного HTML зберігається в кеші.
• Кешування даних у СУБД на рівні рядків.
• Кешуються повністю сформовані об’єкти Python.
• Якісь дані обчислюються й відправляється кожному серверу для кешування в локальній оперативній пам’яті. Ця стратегія доцільна далеко не завжди, найчастіше більш ефективний інший метод: найшвидшим кешем є сам серверний додаток, а відправлення вже готових даних іншим серверам для подальшої обробки звичайно не займає так багато часу. Для організації такого підходу необхідні агенти, що здійснюють відстеження змін, попередню обробку й відправлення даних.

Керування відео
• Витрати містять у собі витрати на пропускну здатність каналів зв’язку, придбання нового обладнання й оплату величезних рахунків за електроенергію.
• Кожний відеоролик розташований на міні-кластері, що означає керування ним групою з декількох комп’ютерів.
• Використання кластерів спричиняє:
– збільшення продуктивності пропорційно кількості дисків, на яких розташований контент;
– можливість підтримки функціонування всієї системи навіть у випадку припинення працездатності частини комп’ютерів;
– можливість організації створення резервних копій online.
• У ролі HTTP-Сервера для роботи з відео використовується lighttpd:
– Він здатний дати фору Apache у плані продуктивності надання статичного контента;
– Для роботи з подіями уведення-висновку використовується epoll;
– Багато поточна конфігурація здатна обробляти більшу кількість з’єднань одночасно;
• Найпопулярніша частина контента розміщається в CDN
– CDN реплікує весь контент у різних частинах системи;
– Комп’ютери CDN в основному надають дані прямо з кеша в оперативній пам’яті, тому що асортименти популярного відео із часом міняється досить повільно.
• Менш популярний контент, кількість переглядів у день якого варіюється в діапазоні від одного до двадцяти, звичайно розміщається на серверах YouTube, розташованих у датацентрах на colocation:
– Не дивлячись на той факт, що таке відео може бути переглянуто всього кілька разів за день, кількість таких роликів велика, що приводить до випадкових блокувань даних на жорстких дисках;
– У такій ситуації кешування практично даремно, інвестиції в кешування контента з низьким рейтингом звичайно є порожньою витратою засобів;
– Більше детальне налаштування низькорівневих компонентів системи, таких як, наприклад, RAID-контролери, у цій ситуації може досить позитивно вплинути на продуктивність;
– Вибір оптимального розміру оперативної пам’яті на кожній машині також дуже важливий: як недостатня, так і зайва її кількість не є ефективними рішеннями.

Ключові моменти
• Чим простіше – тим краще;
• Намагайтесь мінімізувати кількість пристроїв (маршрутизаторів, комутаторів і тому подібних) між контентом і користувачами: далеко не факт, що всі вони будуть здатні витримувати інтенсивне навантаження;
• Намагайтеся використовувати саме звичайне устаткування. Hi-end устаткування звичайно спричиняє ріст витрат, пов’язаних із супутніми процесами, наприклад технічною підтримкою, а також зменшує ймовірність знаходження рішення тої або іншої проблеми з устаткуванням у мережі;
• Використовуйте найпростіші розповсюджені утиліти. YouTube використовує набір утиліт для побудови системи, якій йдуть у комплекті з Linux;
• Не забувайте про випадкові доступи до жорстких дисків, цю, здавалося б, дрібницю теж варто налаштувати.

Керування мініатюрами відео
• Напрочуд складно розв’язуване завдання, особливо якщо необхідна ефективність;
• Для кожного відео зберігається 4 мініатюри, що призводить до істотної переваги кількості мініатюр над кількістю відеороликів;
• Мініатюри зберігаються всього на декількох комп’ютерах;
• Деякі проблеми спостерігаються у зв’язку з роботою з більшою кількістю маленьких об’єктів:
– Проблеми на рівні операційної системи, пов’язані з більшою кількістю запитів на пошук даних, а також кешем сторінок і inode‘ів файлової системи;
– Обмеження на кількість файлів в одній директорії (особливо актуально для ext3), можливо часткове рішення у вигляді переходу до більше ієрархічної структури зберігання даних, а також переході до ядра Linux версії 2.6, що може привести до більш ніж сторазового росту продуктивності, але в кожному разі зберігання такої величезної кількості файлів у локальній файловій системі – не найкраща ідея;
– Велика кількість запитів у секунду, тому що одна сторінка може містити до 60 мініатюр різних відеороликів;
– В умовах таких навантажень Apache показує погану продуктивність;
– Проводилися експерименти з використанням squid (зворотнього proxy) між Apache і відвідувачами. Якийсь час такий варіант здавався працездатним, але з ростом навантаження продуктивність почала падати. З обробки 300 запитів у секунду вона впала до 20;
– Спроби використовувати lighttpd також не завершилися успіхом: однопоточний режим не справлявся із завданням, а багатопоточний вимагав окремого кеша для кожного потоку, що зводило нанівець його ефективність;
– З такою кількістю зображень додавання в систему нового комп’ютера могло займати більше 24 годин;
– Перезавантаження займало 6-10 годин, тому що кеш повинен був “розігрітися” перш ніж перестати використовувати дані з жорстких дисків.
• Рішенням всіх описаних вище проблем стала розподілена система зберігання даних BigTable від Google:
– Вона дозволяє уникнути проблем, пов’язаних з більшою кількістю файлів, тому що поєднує маленькі файли разом.
– Вона працює швидко й стійка до збоїв, крім цього вона прекрасно пристосована для роботи з ненадійної мережі.
– Зменшує затримки, тому що використовує розподілений багаторівневий кэш, що здатний працювати навіть між датацентрами на відстані.

Бази даних
• Раніше:
– MySQL використовувалася для зберігання даних: користувачів, тэгів, описів і так далі.
– Дані зберігалися на монолітному RAID 10 масиві, що складається з 10 жорстких дисків;
– Устаткування орендувалося, що негативно позначалося на стані їхніх кредитних карток. Якщо буде потреба нового обладнання, на оформлення замовлення й доставку міг іти далеко не один день.
– Вони пройшли через весь шлях еволюції: спочатку був один сервер, потім додалося кілька додаткових серверів, що обслуговують операції читання, після чого вони вирішили розбити базу даних на частині, і, нарешті, вони прийшли до повноцінної розподіленої архітектури.
– Спочатку їхня система страждала від затримок, пов’язаних з репліціюванням даних. Основний сервер, що обробляє операції запису, був потужним сервером, що працює в багатопоточному режимі, це було необхідно для своєчасного виконання великого обсягу роботи. Другорядні сервера, які обробляли тільки операції читання, асинхронно репліціювали дані в одному потоці, що спричиняло можливість серйозного відставання деяких з них.
– Відновлення були причиною частої відсутності необхідної інформації в кеші, що змушувало сервера читати дані з жорстких дисків. Цей факт сильно сповільнював процес читання й реплікації.
– Архітектура реплікації вимагає чималих вкладень в устаткування, необхідного для підтримки постійно зростаючих темпів запису інформації.
– Основним з кардинальних рішень, прийнятих в архітектурі системи було відділення забезпечення процесу перегляду відео від основного кластера. Основною метою відвідувачів є перегляд відео, а другорядні завдання можна покласти й на менш продуктивний кластер.
• Зараз:
– Використовуються розподілені бази даних;
– Сегментована система;
– Розподілені читання й запис;
– Більше ефективне розташування кеша, що веде до зменшення роботи з жорсткими дисками;
– Така архітектура привела до 30%-й економії на устаткуванні;
– Затримки в реплікації зведені до нуля;
– Розміри бази даних можуть рости практично необмежено

Стратегія розміщення в датацентрах
• Спочатку використовувалися хостинг провайдери, що надають послуги colocation. Не самий економічний підхід, але тоді не було іншого виходу.
• Хостинг провайдери не можуть поспіти за темпами росту проекту. Не завжди виходить одержати контроль над необхідним устаткуванням або зробити необхідні угоди про надання мережних послуг.
• Рішенням цієї проблеми стало створення власної бази для розміщення устаткування. З’явилася можливість надбудовувати абсолютно все й підписувати свої власні контракти такого роду.
• Було використано 5 або 6 різних датацентрів на додаток до CDN.
• Відео надходить із випадкового датацентра, ніяких спеціальних перевірок не проводиться. Якщо ролик стає досить популярним – він переміщається в CDN.
• Основним фактором, що впливає на доступність того або іншого ролика є пропускна здатність каналу зв’язку.
• Для зображень же більше актуальні затримки, особливо якщо на одній сторінки повинне бути розміщене під 60 зображень.
• Реплікація зображень виробляється засобами BigTable. У цьому випадку використовуються різні міри для визначення найближчого місця, звідки можна одержати необхідні дані.

Підводимо підсумки
• Зупиніться на секунду. Креативні й ризиковані трюки можуть допомогти впоратися із завданням у короткостроковому періоді, але згодом знадобляться більше продумані рішення.
• Розставте пріоритети. Визначите які частини Вашого сервісу є більше важливими й будуйте систему забезпечення ресурсами й зусиллями саме відповідно до поставлених пріоритетів.
• Вибирайте свої битви. Не бійтеся користуватися аутсорсингом у деяких ключових сервісах. YouTube використовує CDN для розподілу свого найбільш популярного контента. Створення своєї власної подібної мережі коштувало б їм занадто багато й зажадало б занадто багато часу. Можливо у Вас з’являться подібні можливості відносно Вашої системи.
• Будьте простіше! Простота дозволяє змінювати архітектуру більш швидко, що дозволяє вчасно реагувати на виникаючі проблеми. Ніхто насправді не знає що таке простота, але якщо Ви не боїтеся робити зміни, те це непоганий знак що вашій системі властива та сама простота.
• Сегментування. Сегментування дозволяє ізолювати й обмежити дисковий простір, процесорний час, оперативну пам’ять і уведення-висновок. Воно виконується не тільки для підвищення продуктивності операцій запису.
• Постійна робота над пошуком і усуненням вузьких місць у системі:
– на програмному рівні це найчастіше буває кешування й робота із СУБД;
– на рівні операційної системи – операції уведення-висновку;
– на рівні устаткування – оперативна пам’ять і RAID масиви.
• Основа Вашого успіху – командна робота. Гарна команда різного роду фахівців повинна розуміти принцип системи вцілому і того, що лежить під нею. Кожний повинен знати свою справу: надбудовувати принтери, підключати до системи нові комп’ютери, будувати мережі й так далі. З відмінною командою Вам під силу все що завгодно!.

Читайте також:

coded by nessus