Джош Еванс розповідає про хаотичний і яскравий світ мікросервісів Netflix, починаючи з самих основ — анатомії мікросервісів, проблем, пов'язаних із розподіленими системами та їх переваг. Спираючись на цей фундамент, він досліджує культурні, архітектурні та операційні методи, що ведуть до оволодіння мікросервісами.
На відміну від operational drift, впровадження нових мов для інтернаціоналізації сервісу та нових технологій, таких як контейнери, — це свідомі рішення додати нову складність у довкілля. Моя група операційістів стандартизувала «асфальтовану дорогу» найкращих технологій для Netflix, які «запікалися» у заздалегідь визначених найкращих практиках, заснованих на Java та EC2, однак у міру розвитку бізнесу розробники почали додавати нові компоненти, такі як Python, Ruby, Node-JS та Docker.
Я дуже пишаюся тим, що ми першими самі виступали за те, щоб наш продукт чудово працював, не чекаючи на скарги клієнтів. Все починалося досить просто - у нас були операційні програми на Python і кілька бек-офісних програм на Ruby, але все стало набагато цікавіше, коли наші веб-розробники заявили, що мають намір відмовитися від JVM і збираються перевести веб-додаток на програмну платформу Node. js. Після впровадження Docker речі стали набагато складнішими. Ми керувалися логікою і придумані нами технології стали реальністю, коли ми впровадили їх для клієнтів, тому що вони мали велике значення. Розповім вам, чому це так.
API-шлюз насправді має можливість інтеграції відмінних скриптів, які можуть діяти як endpoints для розробників інтерфейсу користувача. Вони конвертували кожен з цих скриптів таким чином, що після внесення змін могли розгорнути їх на продакшн і далі на пристрої користувачів, і всі зміни синхронізувалися з endpoints, які запускалися в API-шлюзі.
Однак це повторило проблему створення нового моноліту, коли API була перевантажена кодом так, що виникали різні сценарії збоїв. Наприклад, деякі кінцеві точки видалялися або ж скрипти випадково генерували так багато версій чогось, що ці версії займали всю доступну пам'ять API-сервісу.
Логічно було взяти ці endpoints і витягнути їх із API-сервісу. Для цього ми створили компоненти Node.js, які запускалися як невеликі програми у контейнерах Docker. Це дозволило ізолювати будь-які неполадки та збої, спричинені цими node-додатками.
Вартість цих змін досить велика і складається з наступних факторів:
- Інструменти для підвищення продуктивності. Управління новими технологіями вимагало нових інструментів, тому що UI-команда, що використовує дуже вдалі скрипти для створення ефективної моделі, не мала витрачати багато часу на управління інфраструктурою, вона мала займатися лише написанням скриптів та перевіркою їхньої працездатності.
Інсайт та сортування можливостей - ключовим прикладом є нові інструменти, необхідні для виявлення інформації про фактори продуктивності. Потрібно було знати, на скільки % зайнятий процесор, як використовується пам'ять, і збирання цієї інформації вимагало різних інструментів. - Фрагментація базових образів - проста базова AMI стала більш фрагментованою та спеціалізованою.
- Управління вузлами. Не існує доступної готової архітектури або технологій, які дозволяють керувати вузлами у хмарі, тому ми створили Titus — платформу управління контейнерами, яка забезпечує масштабоване та надійне розгортання контейнерів та хмарну інтеграцію з Amazon AWS.
- Дублювання бібліотеки чи платформи. Надання новим технологіям тих самих основних функцій платформи зажадало її дублювання в хмарні інструменти розробників Node.js.
- Крива навчання та виробничий досвід. Впровадження нових технологій неминуче створює нові проблеми, які необхідно подолати та винести з них уроки.
Таким чином, ми не могли обмежитися однією «асфальтованою дорогою» і мали постійно будувати нові шляхи для просування своїх технологій. Для зниження вартості ми обмежували централізовану підтримку та фокусувалися на JVM, нових вузлах та Docker. Ми розставляли пріоритети за рівнем ефективного впливу, інформували команди про вартість прийнятих ними рішень та стимулювали їх шукати можливість багаторазового використання вже розроблених ефективних рішень. Ми використовували цей підхід при перекладі сервісу іноземними мовами для доставки продукту до міжнародних клієнтів. Прикладам можуть бути відносно прості клієнтські бібліотеки, які можуть генеруватися автоматично, тому досить легко створювати Python-версію, Ruby-версію, Java-версію і т.д.
Ми постійно шукали можливість використовувати обкатані технології, які добре зарекомендували себе в одному місці, та в інших схожих ситуаціях.
Давайте поговоримо про останній елемент - зміни, або варіації. Подивіться, як нерівномірно змінюється споживання нашого продукту по днях тижня і по годинах протягом доби. Можна сказати, що о 9-й ранку для Netflix настає час важких випробувань, коли навантаження на систему досягає максимуму.
Як можна досягти високої швидкості впровадження програмних інновацій, тобто постійно вносити нові зміни до системи, не викликаючи перерв у доставці сервісу та не створюючи незручностей нашим клієнтам? Netflix досягли цього завдяки використанню Spinnaker – нової глобальної хмарної платформи управління та безперервної доставки (СD).
Критично важливо, що Spinnaker був розроблений для інтеграції наших кращих практик так, щоб у міру розгортання компонентів у продакшн ми можемо інтегрувати їх результат безпосередньо у технологію доставки медіаконтенту.
Нам вдалося використовувати в конвеєрі доставки дві технології, які ми високо цінуємо: автоматизований canary-аналіз та поетапне розгортання. Canary-аналіз означає, що ми направляємо струмок трафіку в нову версію коду, а решту продакшн-трафік пропускаємо через стару версію. Потім ми перевіряємо, як справляється із завданням новий код – краще чи гірше існуючого.
Поетапне розгортання означає, що якщо з розгортанням в одному регіоні відбуваються проблеми, ми переходимо до розгортання в іншому регіоні. При цьому конвеєр продакшена обов'язково включається згаданий вище чеклист. Я трохи заощаджу час і порекомендую вам ознайомитись з моїм попереднім виступом «Інжиніринг глобальних операцій Netflix у хмарному сервісі», якщо у вас є бажання глибше розібратися з цим питанням. Відеозапис виступу можна переглянути, пройшовши за посиланням унизу слайду.
Наприкінці виступу я коротко розповім про організацію та архітектуру Netflix. На самому початку у нас була схема під назвою Electronic Delivery – електронна доставка, яка була першою версією потокової передачі медіаконтенту NRDP 1.x. Тут можна використовувати термін «зворотний потік», тому що спочатку користувач міг тільки завантажувати контент для подальшого відтворення пристрою. Найперша платформа електронної доставки Netflix зразка 2009 виглядала приблизно так.
Користувальницький пристрій містив у собі додаток Netflix, який складався з інтерфейсу UI, модулів безпеки, активації сервісу та відтворення, що базуються на платформі NRDP - Netflix Ready Device Platform.
У той час інтерфейс користувача був дуже простий. Він містив так званий Queque Reader і користувач заходив на сайт, щоб додати щось у Queque, а потім переглядав доданий контент на своєму пристрої. Позитивним було те, що клієнтська команда та серверна команда належали одній організації Electronic Delivery та мали тісні робочі взаємини. Корисне навантаження було створено на основі XML. Паралельно було створено API Netflix для DVD бізнесу, який стимулював сторонні програми спрямовувати трафік до нашого сервісу.
Однак Netflix API був добре підготовлений до того, щоб допомогти нам з інноваційним інтерфейсом користувача, в ньому містилися метадані всього контенту, відомості про те, які фільми доступні, що створювало можливість генерувати списки перегляду. У нього був загальний REST API, що базується на схемі JSON, HTTP Response Code, такий же, що використовується в сучасній архітектурі, і модель безпеки OAuth - те, що було потрібно тоді для зовнішнього застосування. Це дозволило перейти від публічної моделі доставки потокового контенту до приватної.
Проблема переходу полягала у фрагментації, оскільки тепер у нашій системі функціонували два сервіси, засновані на абсолютно різних принципах роботи – один на Rest, JSON та OAuth, інший на RPC, XML та механізмі безпеки користувачів на основі системи NTBA. Це була перша гібридна архітектура.
По суті, між двома нашими командами існував файрвол, тому що спочатку API не дуже добре масштабувався за допомогою NCCP, і це призводило до розбіжностей між командами. Відмінності полягали в сервісах, протоколах, схемах, модулях безпеки, і розробниками часто доводилося перемикатися між різними контекстами.
У зв'язку з цим у мене була розмова з одним із старших інженерів компанії, якому я поставив питання: «Що повинна бути правильною довгостроковою архітектурою?», і він поставив зустрічне запитання: «Ймовірно, тебе більше хвилюють організаційні наслідки — що станеться, якщо ми інтегруємо ці речі, а вони зламають те, що добре навчилися робити?». Цей підхід є дуже актуальним для закону Конвея: «Організації, що проектують системи, обмежені дизайном, який копіює структуру комунікації в цій організації». Це дуже абстрактне визначення, тому я віддаю перевагу більш конкретному: «Будь-яка частина програмного забезпечення відображає організаційну структуру, яка його створила». Наведу вам мій улюблений вислів, що належить Еріку Реймонду: «Якщо над компілятором працюють чотири команди розробників, то у результаті ви отримаєте чотирипрохідний компілятор». Що ж, Netflix має чотирипрохідний компілятор, і це те, як ми працюємо.
Можна сказати, що в цьому випадку хвіст махає собакою. У нас на першому місці не рішення, а організація саме вона є драйвером архітектури, яку ми маємо. Поступово від мішанини сервісів ми перейшли до архітектури, яку назвали Blade Runner – «Той, що біжить по лезу», тому що тут йдеться про граничні сервіси та можливості NCCP розділятися та інтегруватися безпосередньо в Zuul-проксі, API-шлюз, причому відповідні функціональні «шматки» були перетворені на нові мікросервіси з більш сучасними функціями безпеки, відтворення, сортування даних і т.д.
Таким чином, можна сказати, що відомчі структури та динаміка розвитку компанії відіграють важливу роль у формуванні дизайну систем і є фактором, що сприяє чи перешкоджає змінам. Архітектура мікросервісів є комплексною та органічною, а її здоров'я базується на дисципліні та впроваджуваному хаосі.
Небагато реклами
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com