Netflix - лідер ринку інтернет-телебачення - компанія, що створила і активно розвиває цей сегмент. Netflix відомий не лише великим каталогом кіно та серіалів, доступних з майже будь-якого куточка планети та будь-якого пристрою з дисплеєм, але й надійною інфраструктурою та унікальною інженерною культурою.
Наочний приклад Netflix підходу до розробки та підтримки складних систем на DevOops 2019 представив - Директор з розробки в Netflix. Випускник факультету ВМК ННГУ ім. Лобачевського, Сергій один із перших інженерів в Open Connect - CDN команди в Netflix. Він побудував системи моніторингу та аналізу відеоданих, запустив популярний сервіс для оцінки швидкості Інтернет-з'єднання FAST.com і останні кілька років працює над оптимізацією Інтернет запитів, щоб Netflix додаток працював якнайшвидше для користувачів.
Доповідь отримала найкращі відгуки від учасників конференції і ми підготували для вас текстову версію.
У доповіді Сергій докладно розповів
- про те, що впливає на затримку інтернет запитів між клієнтом та сервером;
- як цю затримку зменшити;
- як проектувати, підтримувати та моніторити стійкі до помилок системи;
- як досягати результату в стислий термін, і мінімальним ризиком для бізнесу;
- як аналізувати результати та вчитися на помилках.
Відповіді на ці питання потрібні не лише тим, хто працює у великих корпораціях.
Представлені принципи та техніки повинен знати та практикувати кожен, хто розробляє та підтримує інтернет продукти.
Далі - оповідання від імені спікера.
Важливість швидкості інтернету
Швидкість інтернет-запитів пов'язана з бізнесом. Розглянемо сферу шопінгу: компанія Amazon у 2009 році , Що затримка в 100 мс призводить до втрати 1% продажів.
Все більше стає мобільних пристроїв, а слідом за ними мобільних сайтів та додатків. Якщо ваша сторінка завантажується довше 3 секунд, ви втрачаєте близько половини користувачів. З Google враховує швидкість завантаження вашої сторінки в пошуковій видачі: чим швидше сторінка, тим вища її позиція в Google.
Швидкість з'єднання також важлива у фінансових організаціях, де затримка критична. У 2015 році компанія Hibernia Networks прокладання кабелю між Нью-Йорком та Лондоном вартістю 400 млн доларів, щоб зменшити затримку між містами на 6 мс. Уявіть, 66 млн. доларів за 1 мс зменшення затримки!
Згідно з , швидкість з'єднання вище 5 Мбіт/с перестає впливати на швидкість завантаження типового сайту. Однак між затримкою з'єднання та швидкістю завантаження сторінки простежується лінійна залежність:
Однак Netflix – не типовий продукт. Вплив затримки та швидкості на користувача – активна сфера аналізу та розробки. Є завантаження програми та вибір контенту, що залежать від затримки, але завантаження статичних елементів та стрімінг також залежать і від швидкості з'єднання. Аналіз та оптимізація ключових факторів, що впливають на якість сервісу для користувача, — активна сфера розробки кількох команд Netflix. Одним із завдань є зменшення затримки запитів між Netflix пристроями та хмарною інфраструктурою.
У доповіді ми сфокусуємось саме на зменшенні затримки (latency) на прикладі інфраструктури Netflix. Розглянемо з практичної точки зору, як підходити до процесів проектування, розробки та оперування складних розподілених систем та витрачати час на інновації та результати, а не діагностику операційних проблем та поломок.
Усередині Netflix
Тисячі різних пристроїв підтримують Netflix програми. Їхньою розробкою займаються чотири різні команди, які роблять окремі версії клієнта для Android, iOS, TV та веб-браузерів. І ми дуже багато сил витрачаємо на те, щоб поліпшити і персоналізувати інтерфейс користувача. Для цього ми запускаємо паралельно сотні A/B тестів.
Персоналізація підтримується завдяки сотні мікросервісів у хмарі AWS, що надають персональні дані для користувача, диспетчеризацію запитів, телеметрію, Big Data та Encoding. Візуалізація трафіку виглядає так:
Зліва знаходиться entry point, а потім трафік розподіляється між кількома сотнями мікросервісів, які підтримуються різними backend командами.
Ще один важливий компонент нашої інфраструктури – це Open Connect CDN, який доставляє до кінцевого користувача статичний контент – відео, зображення, код для клієнтів тощо. CDN розташована на кастомних серверах (OCA – Open Connect Appliance). Усередині розташовані масиви SSD та HDD-дисків під керуванням оптимізованої FreeBSD, з NGINX та набором сервісів. Ми проектуємо та оптимізуємо апаратні та програмні компоненти таким чином, щоб такий CDN сервер міг надсилати якомога більше даних користувачам.
"Стінка" з цих серверів у точці обміну інтернет-трафіком (Internet eXchange - IX), виглядає так:
Internet Exchange надає можливість інтернет-провайдерам та постачальникам контенту «підключитися» один до одного для прямого обміну даними в інтернеті. По всьому світу є приблизно 70-80 Internet Exchange точок, де встановлені наші сервери, і ми самостійно займаємось їх встановленням та обслуговуванням:
Крім цього, ми також надаємо сервери безпосередньо інтернет-провайдерам, які вони встановлюють у свою мережу, покращуючи локалізацію Нетфлікс трафіку та якість стрімінгу для користувачів:
Набір AWS сервісів відповідальний за диспетчеризацію відео запитів від клієнтів до CDN-серверів, а також конфігурування самих серверів - оновлення контенту, програмного коду, налаштувань і т.д. Для останнього ми також побудували backbone network, який з'єднує сервери в Internet Exchange точках з AWS. Backbone network є глобальною мережею з оптоволоконних кабелів і роутерів, які ми можемо проектувати і конфігурувати виходячи з наших потреб.
За , наша CDN інфраструктура доставляє в піковий годинник приблизно ⅛ частина світового інтернет-трафіку і ⅓ трафіку в Північній Америці, де Netflix існує найдовше. Вражаючі цифри, але для мене одним із найдивовижніших досягнень є те, що вся CDN система розробляється та підтримується командою з менш ніж 150 осіб.
Спочатку CDN інфраструктура була спроектована для доставки відео даних. Однак, з часом ми зрозуміли, що ми можемо використовувати її для оптимізації динамічних запитів від клієнтів в AWS хмара.
Про прискорення інтернету
Сьогодні у Netflix 3 регіону AWS і затримка запитів у хмару залежатиме від того, наскільки далеко клієнт знаходиться від найближчого регіону. При цьому ми маємо безліч CDN серверів, які використовуються для доставки статичного контенту. Чи можна використовувати цю інфраструктуру, щоб прискорити динамічні запити? При цьому кешувати ці запити, на жаль, не можна — API персоналізовано і кожен результат є унікальним.
Зробимо проксі на CDN-сервері і почнемо через нього проганяти трафік. Чи буде це швидше?
матчастину
Згадаймо, як працюють мережеві протоколи. Сьогодні більшість трафіку в інтернеті використовує HTTPs, який залежить від протоколів нижнього рівня TCP і TLS. Щоб клієнт підключився до сервера, він робить handshake, і для встановлення захищеного з'єднання клієнту потрібно обмінятися повідомленнями з сервером три рази і ще раз як мінімум, щоб передати дані. При затримці на один обмін (RTT) 100 мс нам знадобиться 400 мс, щоб отримати перший біт даних:
Якщо сертифікати розташуємо на CDN-сервері, то час «рукостискання» між клієнтом та сервером можемо суттєво скоротити, якщо CDN знаходиться ближче. Припустимо, що затримка CDN-сервера становить 30 мс. Тоді для отримання першого біта потрібно вже 220 мс:
Але плюси на цьому не закінчуються. Після того, як з'єднання вже встановлено, TCP збільшує congestion window (кількість інформації, яку він може передавати по цьому з'єднанню паралельно). Якщо втрачається пакет даних, то класичні реалізації TCP протоколу (на кшталт TCP New Reno) зменшують відкрите «вікно» вдвічі. Зростання конфігурації window, і швидкість його відновлення від втрати знову залежить від затримки (RTT) до сервера. Якщо це з'єднання йде лише до CDN-сервера, це відновлення буде швидше. При цьому втрата пакетів є стандартним явищем, особливо для бездротових мереж.
Пропускна спроможність інтернету може знижуватися, особливо в піковий годинник через трафіку від користувачів, що може призводити до «пробок». При цьому в інтернеті немає способу надати пріоритет одним запитам стосовно інших. Наприклад, дати пріоритет маленьким за обсягом та чутливим до затримки запитам щодо «важких» потоків даних, які завантажують мережу. Однак у нашому випадку наявність власної backbone мережі дозволяє це зробити на частині шляху запиту між CDN і хмарою, і ми її можемо повністю конфігурувати. Можна зробити так, щоб невеликі та залежні від затримки пакети пріорітізувалися, а великі потоки даних пішли трохи пізніше. Чим ближче CDN до клієнта — тим більша ефективність.
Ще вплив на затримку надають протоколи застосування рівня (OSI Level 7). Нові протоколи, такі як HTTP/2, дозволяють оптимізувати продуктивність паралельних запитів. Однак у нас є Netflix є клієнти зі старими пристроями, які не підтримують нові протоколи. Не всі клієнти можна оновити або оптимально налаштувати. При цьому між CDN проксі та хмарою – повний контроль та можливість використовувати нові, оптимальні протоколи та налаштування. Неефективна частина зі старими протоколами діятиме лише між клієнтом та CDN-сервером. Більш того, ми можемо робити мультиплекс запитів на вже встановлене з'єднання між CDN та хмарою, покращуючи утилізацію з'єднання на TCP рівні:
Вимірюємо
Незважаючи на те, що теорія обіцяє покращення, ми не кидаємося відразу запускати систему у production. Натомість ми повинні спочатку довести, що ідея спрацює на практиці. Для цього потрібно відповісти на кілька запитань:
- Швидкість: чи буде проксі швидше?
- Надійність: чи буде частіше ламатися?
- Складність: як інтегрувати з програмами?
- Вартість: скільки коштує розгортання додаткової інфраструктури?
Розглянемо детально наш підхід до оцінки першого пункту. Інші розбираються схожим чином.
Для аналізу швидкості запитів ми хочемо отримати дані всім користувачів, не витрачати багато часу на розробку і не зламати production. Для цього є кілька підходів:
- RUM або пасивний вимір запитів. Вимірюємо час виконання поточних запитів від користувачів та забезпечуємо повне покриття користувачів. Недолік — не дуже стабільний сигнал через безліч факторів, наприклад, через різні розміри запитів, час обробки на сервері та клієнта. Крім цього, не можна протестувати нову конфігурацію без впливу на production.
- Лабораторні випробування. Спеціальні сервери та інфраструктури, що імітують клієнтів. З їхньою допомогою проводимо необхідні тести. Так ми отримуємо повний контроль над результатами вимірювань та чіткий сигнал. Але немає повного покриття пристроїв та розташування користувачів (особливо із сервісом по всьому світу та підтримкою тисяч моделей пристроїв).
Як можна поєднати переваги обох методів?
Наша команда знайшла рішення. Ми написали невеликий шматочок коду – пробу – який вбудували у наш додаток. Проби дозволяють робити повністю контрольовані мережеві тести з наших пристроїв. Працює це так:
- Незабаром після завантаження програми та завершення початкової активності ми запускаємо наші проби.
- Клієнт робить запит на сервер та отримує «рецепт» тесту. Рецепт є список з URL-адрес, до яких потрібно зробити HTTP(s) запит. Крім цього рецепт конфігурує параметри запитів: затримки між запитами, обсяг даних, HTTP(s) headers і т.д. При цьому ми можемо паралельно тестувати кілька різних рецептів – при запиті на конфігурацію ми випадково визначається, який рецепт видати.
- Час запуску проби вибирається те щоб не конфліктувати з активним використанням мережевих ресурсів клієнта. По суті, вибирається час, коли клієнт не активний.
- Після отримання рецепту клієнт робить запити на кожну з URL-адрес, паралельно. Запит на кожну з адрес може повторюватися — т.зв. "пульси". На першому пульсі ми вимірюємо, скільки часу знадобилося для встановлення з'єднання та закачування даних. На другому пульсі ми вимірюємо час завантаження даних по вже встановленому з'єднанню. Перед третім ми можемо поставити затримку та виміряти швидкість встановлення повторного з'єднання тощо.
Під час тесту ми вимірюємо всі параметри, які може отримати пристрій:
- час запиту DNS;
- час встановлення з'єднання TCP;
- час встановлення з'єднання TLS;
- час отримання першого байта даних;
- повний час завантаження;
- статус код результату.
- Після закінчення всіх пульсів проба завантажує результати всіх вимірів аналітики.
Ключовими моментами є мінімальна залежність від логіки на клієнта, обробки даних на сервері та вимірювання паралельних запитів. Таким чином, ми отримуємо можливість ізолювати та тестувати вплив різних факторів, що впливають на продуктивність запитів, варіювати їх у межах одного рецепту та отримувати результати з реальних клієнтів.
Така інфраструктура виявилася корисною як для аналізу продуктивності запитів. В даний момент у нас 14 активних рецептів, більше 6000 проб в секунду, які отримують дані з усіх куточків землі та повним покриттям пристроїв. Якби Netflix купувала подібний сервіс у сторонніх компаній, то він коштував би мільйони доларів на рік, при набагато гіршому покритті.
Перевіряємо теорію практично: прототип
З такою системою ми отримали можливість оцінити ефективність проксі CDN на затримку запитів. Тепер потрібно:
- створити прототип проксі;
- розмістити прототип на CDN;
- визначити, як направляти клієнтів до проксі на конкретному CDN-сервері;
- порівняти продуктивність із запитами в AWS без проксі.
Завдання — якнайшвидше оцінити ефективність запропонованого рішення. Для реалізації прототипу ми вибрали Go завдяки наявності хороших мережевих бібліотек. На кожному CDN-сервері ми встановили прототип проксі як static binary, щоб мінімізувати залежність та спростити інтеграцію. У початковій реалізації ми максимально використовували стандартні компоненти і невеликі модифікації для HTTP/2 connection pooling і request multiplexing.
Для балансування між регіонами AWS ми використовували географічну базу даних DNS, ту ж, що використовується для балансування клієнтів. Для вибору CDN-сервера для клієнта використовуємо TCP Anycast для серверів в Internet Exchange (IX). У цьому варіанті ми використовуємо одну IP-адресу на всі CDN сервери, при цьому клієнт буде спрямований до CDN сервера з найменшою кількістю IP hops. У CDN серверах встановлених в інтернет провайдерів (ISP) у нас немає контролю над роутером для налаштування TCP Anycast, тому задіємо , через яку клієнти направляються до інтернет-провайдерів для відеостримінгу.
Отже, у нас є три типи шляхів для запиту: у хмару через відкритий інтернет, через CDN-сервер у IX або через CDN-сервер, розташований у інтернет-провайдера. Наша мета — зрозуміти який шлях кращий, і яка користь від проксі порівняно з тим, як запити надсилаються в production. Для цього використовуємо систему проб наступним чином:
Кожен із шляхів стає окремим таргетом, і ми дивимося на час, який у нас вийшов. Для аналізу об'єднуємо результати проксі в одну групу (вибираємо найкращий час між IX і ISP проксі), і порівнюємо з часом запитів в хмару без проксі:
Як видно, результати виявилися неоднозначними — у більшості випадків проксі дає гарне прискорення, але також є достатньо клієнтів, для яких ситуація значно погіршиться.
У результаті ми зробили кілька важливих речей:
- Оцінили очікувану продуктивність запитів від клієнтів у хмару через проксі CDN.
- Отримали дані від справжніх клієнтів з усіх типів пристроїв.
- Зрозуміли, що теорія не підтвердилася на 100% і початкова пропозиція з проксі CDN для нас не спрацює.
- Чи не ризикували - не змінювали production конфігурації для клієнтів.
- Нічого не зламали.
Прототип 2.0
Отже, повертаємось до креслярської дошки та повторюємо процес заново.
Ідея — замість 100% проксі будемо для кожного клієнта визначимо найшвидший шлях і туди направлятимемо запити — тобто робитимемо те, що називається client steering.
Як це реалізувати? Ми можемо використовувати логіку на серверній боці, т.к. ціль - до цього сервера підключитися. Потрібно якимось чином це робити на клієнті. І ідеально зробити це з мінімальною кількістю складної логіки, щоб не вирішувати питання інтеграції з великою кількістю клієнтських платформ.
Відповідь — використання DNS. У нашому випадку ми маємо свою DNS інфраструктуру, і ми можемо налаштувати доменну зону, для якої наші сервери будуть авторитарними. Працює це так:
- Клієнт робить запит до DNS-сервера, використовуючи хост, наприклад api.netflix.xom.
- Запит надходить на наш DNS-сервер
- DNS-сервер знає який шлях для цього клієнта найшвидший і видає відповідну IP-адресу.
У рішенні є додаткова складність: авторитарні DNS-провайдери не бачать IP-адресу клієнта і можуть вважати лише IP-адресу рекурсивного resolverу, яким користується клієнт.
Через війну наш авторитарний resolver повинен приймати рішення задля окремого клієнта, а групи клієнтів з урахуванням рекурсивного resolver.
Для вирішення ми використовуємо ті ж проби, агрегуємо результати вимірювань від клієнтів за кожним із рекурсивних resolver та вирішуємо, куди їх цю групу направити — проксі через IX за допомогою TCP Anycast, через ISP проксі або безпосередньо у хмару.
Ми отримуємо таку систему:
Отримана модель DNS steering дозволяє направляти клієнтів на основі історичних спостережень швидкості з'єднань від клієнтів до хмари.
Знову ж таки, питання — наскільки ефективно такий підхід працюватиме? Для відповіді знову використовуємо нашу систему проб. Тому ми налаштовуємо конфігурацію рецента, де один із таргетів слідує напряму від DNS steering, інший - йде безпосередньо в хмару (поточний production).
У результаті порівнюємо результати та отримуємо оцінку ефективності:
У результаті ми дізналися кілька важливих речей:
- Оцінили очікувану продуктивність запитів від клієнтів у хмару із використанням DNS Steering.
- Отримали дані від справжніх клієнтів з усіх типів пристроїв.
- Довели ефективність запропонованої ідеї.
- Чи не ризикували - не змінювали production конфігурації для клієнтів.
- Нічого не зламали.
Тепер про складне - запускаємо в production
Найлегше тепер позаду є працюючий прототип. Тепер складна частина - запустити рішення для всього Netflix трафіку, розгорнути на 150 млн користувачів, тисячі пристроїв, сотні мікросервісів і продукт, що постійно змінюються, і інфраструктура. На сервери Netflix надходять мільйони запитів за секунду, і можна легко зламати сервіс необережною дією. При цьому ми хочемо динамічно спрямовувати трафік через тисячі CDN серверів, в інтернеті, де щось змінюється і ламається постійно і в самий невідповідний момент.
І при цьому, в команді - три інженери, відповідальні за розробку, розгортання і повну підтримку системи.
Тому далі говоритимемо про спокійний і здоровий сон.
Як продовжувати розробку, а чи не витрачати весь час на підтримку? В основі нашого підходу лежать 3 принципи:
- Зменшуємо потенційний масштаб поломок (blast radius).
- Готуємось до сюрпризів – очікуємо, що щось зламається, незважаючи на тестування та особистий досвід.
- Поступова деградація (graceful degradation) — якщо щось працює не так, воно має чинитися автоматично, хай і не найефективнішим способом.
Виявилося, що в нашому випадку, за такого підходу до проблеми, можна знайти просте та ефективне рішення та значно спростити підтримку системи. Ми зрозуміли, що можемо додати до клієнта невеликий шматочок коду та стежити за помилками мережевих запитів, викликаними неполадками зі з'єднанням. При мережевих помилках робимо fallback безпосередньо в хмару. Таке рішення не потребує значних зусиль для клієнтських команд, але зменшує ризик від несподіваних поломок і сюрпризів для нас.
Зрозуміло, незважаючи на fallback, ми проте слідуємо чіткій дисципліні в ході розробки:
- Тест на пробах.
- A/B-тестування або Canaries.
- Поступовий випуск (progressive rollout).
З пробами підхід було описано — зміни спочатку тестуються за допомогою настроєного рецепту.
Для canary-тестування нам потрібно отримати порівняні пари серверів, на яких можна порівняти, як працює система до і після змін. Для цього з наших численних сайтів CDN ми робимо вибірку пар серверів, які отримують порівняний трафік:
Потім ми ставимо збірку зі змінами на сервері Canary. Для оцінки результатів ми запускаємо систему, яка порівнює приблизно 100-150 метрик із вибіркою Control серверів:
Якщо Canary-тестування пройшло успішно, ми робимо реліз поступово, хвилями. На кожному з сайтів ми не оновлюємо сервери одночасно — втрата цілого сайту у разі проблем значно впливає на сервіс для користувачів, ніж втрата такої ж кількості серверів, але в різних місцях.
Загалом ефективність та безпека такого підходу залежить від кількості та якості зібраних метрик. Для нашої системи прискорення запитів ми збираємо метрики з усіх можливих компонентів:
- від клієнтів - кількість сесій та запитів, fallback rates;
- проксі - статистика за кількістю та часом запитів;
- DNS - кількість та результати запитів;
- cloud edge — кількість та час на обробку запитів у хмарі.
Все це збирається в єдиний pipeline, і, залежно від потреб, ми вирішуємо, які метрики відправляти на real-time аналітику, а які в Elasticsearch або Big Data для більш детальної діагностики.
Моніторимо
У нашому випадку ми робимо зміни на критичному шляху запитів між клієнтом та сервером. При цьому кількість різних компонентів на клієнті, на сервері, і на шляху через інтернет — величезна. Зміни на клієнті та сервері відбуваються постійно – під час роботи десятків команд та природних змін в екосистемі. Ми посередині — при діагностиці проблем великий шанс, що ми братимемо в цьому участь. Тому нам потрібно чітко розуміти, як визначати, збирати та аналізувати метрики для швидкої локалізації проблем.
Ідеально - повний доступ до всіх видів метрик та фільтрів у реальному часі. Але метрик дуже багато, тож постає питання вартості. У нашому випадку ми обробимо метрики та інструменти розробки таким чином:
Для виявлення та triage проблем ми використовуємо власну real-time систему з відкритим вихідним кодом и - Для візуалізації. Вона зберігає агреговані метрики у пам'яті, надійна та інтегрується з alerting system. Для локалізації та діагностики ми маємо доступ до логів з Elasticsearch та Kibana. Для статистичного аналізу та моделювання - задіємо big data і візуалізацію в Tableau.
Здається, що з таким підходом дуже важко працювати. Однак при ієрархічній організації метрик та інструментів ми можемо швидко проаналізувати проблему, визначити тип проблеми і потім заглибитись у детальні метрики. Для виявлення джерела поломки ми загалом витрачаємо близько 1-2 хвилин. Після цього ми вже працюємо з конкретною командою над діагностикою – від десятків хвилин до кількох годин.
Навіть якщо діагностика робиться швидко, ми хочемо, щоб це відбувалося часто. В ідеальному випадку ми отримуватимемо критичний alert тільки тоді, коли є значний вплив на сервіс. Для нашої системи прискорення запитів у нас всього 2 alert, які повідомлятимуть:
- відсоток Client Fallback - оцінка поведінки клієнтів;
- відсоток Probe errors – дані стабільності мережевих компонентів.
Ці critical alerts стежать, чи працює система більшість користувачів. Ми дивимося, скільки клієнтів скористалися fallback, якщо вони не змогли отримати прискорення запитів. У нас в середньому менше 1 критичного оповіщення на тиждень, хоча в системі відбувається величезна кількість змін. Чому нам цього достатньо?
- Є client fallback у випадку якщо наша проксі не працює.
- Існує автоматична steering система, яка реагує на проблеми.
Про останній детальніше. Наша система проб, і система автоматичного визначення оптимального шляху для запитів від клієнта до хмари дозволяють автоматично справлятися з деякими проблемами.
Повернімося до нашої конфігурації проб та 3 категорії шляхів. Крім часу завантаження ми можемо дивитися сам факт доставки. Якщо не вдалося завантажити дані, то, дивлячись на результати по різних шляхах ми можемо визначити, де і що зламалося, і чи можемо це автоматично відремонтувати, змінивши шлях запиту.
приклади:
Цей процес можна автоматизувати. Включити його в стереж-систему. І навчити її реагувати на проблеми з продуктивністю та надійністю. Якщо щось починає ламатися – зреагувати, якщо є найкраща опція. При цьому миттєва реакція не критична завдяки fallback на клієнтах.
Таким чином, принципи підтримки системи можна сформулювати так:
- зменшуємо масштаб поломок;
- збираємо метрики;
- автоматично чинимо поломки, якщо можемо;
- якщо не може – сповіщаємо;
- працюємо над dashboards та triage toolset для швидкої реакції.
Здобуті уроки
Для написання прототипу не потрібно багато часу. У нашому випадку він був готовий уже за 4 місяці. З ним ми отримували нові метрики, і через 10 місяців з початку розробки ми отримали першу продукцію трафік. Потім почалася нудна та дуже складна робота: поступово продуктизувати та масштабувати систему, мігрувати основний трафік та вчитися над помилками. При цьому цей ефективний процес не буде лінійним — попри всі зусилля не можна все передбачити. Набагато ефективніше — швидка ітерація та реагування на нові дані.
Виходячи з нашого досвіду, можемо порадити таке:
- Чи не вірте інтуїції.
Наша інтуїція підводила нас постійно, незважаючи на величезний досвід членів команди. Наприклад, ми неправильно передбачали очікуване прискорення від використання проксі CDN, або поведінка TCP Anycast.
- Отримуйте дані з production.
Важливо якнайшвидше отримати доступ хоча б до невеликої кількості даних. Кількість унікальних випадків, конфігурацій, налаштувань у лабораторних умовах одержати практично неможливо. Швидкий доступ до результатів дозволить швидше дізнатися про потенційні проблеми та врахувати їх в архітектурі системи.
- Не слідуйте чужим порадам і результатам — збирайте свої дані.
Дотримуйтесь принципів збору та аналізу даних, але не беріть сліпо чужі результати та затвердження. Тільки ви можете точно знати, що працює для ваших користувачів. Ваші системи та ваші клієнти можуть суттєво відрізнятися від інших компаній. Добре, що інструменти для аналізу зараз доступні і легкі у використанні. Отримані результати можуть не збігатися з тим, що стверджують Netflix, Facebook, Akamai та інші компанії. У нашому випадку, продуктивність TLS, HTTP2 або статистика по DNS запитам відрізняється від результатів Facebook, Uber, Akamai – тому що ми маємо інші пристрої, клієнти та потоки даних.
- Не прагнете модних трендів без потреби та оцінки ефективності.
Починайте із простого. Краще зробити просту робочу систему за короткий час, ніж витратити багато часу на розробку непотрібних вам компонентів. Вирішуйте завдання та проблеми, які важливі на основі ваших вимірювань та результатів.
- Будьте готові до нових застосувань.
Також, як складно передбачити всі проблеми – складно заздалегідь передбачити переваги та застосування. Беріть приклад зі стартапів – їхня здатність адаптуватися під умови клієнтів. У вашому випадку – ви можете виявити нові проблеми та їх вирішення. У нашому проекті ми ставили за мету зменшити затримку запитів. Проте, під час аналізу та обговорень, ми зрозуміли, що проксі-сервери ми можемо застосовувати також:
- для балансування трафіку по AWS регіонах та зменшення витрат;
- для моделювання стабільності CDN;
- для конфігурування DNS;
- конфігурування TLS/TCP.
Висновок
У доповіді я описав, як Netflix вирішує завдання прискорення інтернет запитів між клієнтами та хмарою. Як ми збираємо дані за допомогою системи проб на клієнтах, і використовуємо зібрані історичні дані, щоб спрямовувати production запити з клієнтів через швидкий шлях в інтернеті. Як ми використовуємо принципи роботи мережевих протоколів, нашу CDN інфраструктуру, backbone мережу, і сервер DNS, для досягнення цього завдання.
Однак, наше рішення — це лише приклад того, як ми в Netflix реалізували таку систему. Що спрацювало для нас? Прикладна частина моєї доповіді для вас — принципи розробки та підтримки, які ми дотримуємося і досягаємо хороших результатів.
Наше вирішення проблеми може не підійти. Однак теорія та принципи розробки залишаються, навіть якщо у вас немає власної CDN інфраструктури, або якщо вона суттєво відрізняється від нашої.
Також залишається важливістю швидкості запитів на бізнес. І навіть для простого сервісу потрібно робити вибір: між «хмарними» провайдерами, розташування серверів, CDN і DNS провайдерами. Ваш вибір буде впливати на ефективність Інтернет-запитів для ваших клієнтів. І для вас важливим є цей вплив вимірювати і розуміти.
Починайте з простих рішень, дбайте про те, як ви змінюєте продукт. Навчайтеся в процесі і вдосконалення системи на основі даних з ваших клієнтів, вашої інфраструктури, і вашого бізнесу. Думайте про можливість несподіваних поломок у процесі проектування. І тоді ви зможете прискорити ваш процес розробки, покращити ефективність рішення, уникнути зайвого навантаження на підтримку та спати спокійно.
У цьому році у онлайн-форматі. Можна буде запитати одного з батьків DevOps, самого Джона Вілліса!
Джерело: habr.com