Ви витратили місяці, переробляючи свій моноліт у мікросервіси, і нарешті всі зібралися, щоб клацнути вимикачем. Ви переходите на першу веб-сторінку і нічого не відбувається. Перезавантажуєте її - і знову нічого хорошого, сайт працює так повільно, що не відповідає протягом кількох хвилин. Що ж сталося?
У своєму виступі Джиммі Богард проведе «посмертне розтин» реальної катастрофи мікросервісу. Він покаже проблеми моделювання, розробки та виробництва, які виявив, та розповість, як його команда повільно трансформувала новий розподілений моноліт на остаточну картину здорового глузду. Хоча повністю запобігти помилкам проекту неможливо, можна принаймні виявити проблеми на ранній стадії проектування, щоб кінцевий продукт перетворився на надійну розподілену систему.
Вітаю всіх, Джіммі, і сьогодні ви почуєте, як можна уникнути мегакатастроф при створенні мікросервісів. Ця історія компанії, в якій я пропрацював близько півтора року, щоб допомогти запобігти зіткненню їх корабля з айсбергом. Щоб розповісти цю історію належним чином, доведеться повернутись у минуле і поговорити про те, з чого починалася ця компанія і як згодом зростала її ІТ-інфраструктура. Щоб захистити імена невинних у цій катастрофі, я змінив назву цієї компанії на Bell Computers. На наступному слайді показано, як виглядала ІТ інфраструктура таких компаній у середині 90-х. Це типова архітектура великого універсального стійкого до відмови HP Tandem Mainframe для функціонування магазину комп'ютерної техніки.
Їм потрібно було побудувати систему управління всіма замовленнями, продажами, поверненням, каталогами продуктів, клієнтською базою, так що вони обрали найпоширеніше на той час рішення мейнфрейму. Ця гігантська система містила в собі кожну крихту інформації про компанію, все, що тільки можна, і будь-яка транзакція проводилася через цей мейнфрейм. Вони тримали всі свої яйця в одному кошику та вважали, що це нормально. Єдине, що сюди не увійшло – це каталоги поштових замовлень та оформлення замовлень телефоном.
Згодом система ставала дедалі більше, у ній накопичувалося дуже багато сміття. Крім того, COBOL не найвиразніша мова у світі, так що в кінцевому підсумку система перетворилася на великий монолітний ком сміття. До 2000 року вони побачили, що багато компаній мають сайти, за допомогою яких ведуть абсолютно весь бізнес, і вирішили побудувати свій перший комерційний сайт.
Початковий дизайн виглядав досить симпатично і складався із сайту верхнього рівня bell.com та низки піддоменів для окремих додатків: каталогу catalog.bell.com, акаунтів account.bell.com, замовлень orders.bell.com, пошуку товарів search.bell.com. Кожен піддомен використовував фреймворк ASP.Net 1.0 та власні бази даних, і всі вони спілкувалися з бекендом системи. Проте всі замовлення продовжували оброблятися і виконуватися всередині єдиного величезного мейнфрейму, в якому залишалося все сміття, натомість фронтенд був окремими веб-сайтами з індивідуальними додатками та окремими базами даних.
Отже, дизайн системи виглядав упорядкованим та логічним, але реальна система була такою, як показано на наступному слайді.
Усі елементи адресували виклики один одному, зверталися до API, вбудовували сторонні бібліотеки dll тощо. Часто траплялося, що системи управління версіями хапали чужий код, запихали його всередину проекту, а потім все ламалося. MS SQL Server 2005 використовував концепцію лінк-серверів, і хоча я не показав стрілками на слайді, кожна з баз даних також спілкувалася один з одним, тому що немає нічого поганого в тому, щоб будувати таблиці на основі даних, отриманих з декількох БД .
Оскільки тепер у них були деякі поділи між різними логічними областями системи, це перетворилося на розподілені грудки бруду, а найбільший шматок сміття, як і раніше, залишався в бекенді мейнфрейму.
Найсмішніше було те, що цей мейнфрейм був побудований конкурентами Bell Сomputers і досі обслуговувався їх технічними консультантами. Переконавшись у незадовільній роботі своїх додатків, компанія вирішила їх позбутися і зробити редизайн системи.
Існуючий додаток був у продакшені протягом 15 років, що є рекордним для додатків на базі ASP.Net. Сервіс приймав замовлення з усього світу, і щорічний прибуток від цієї єдиної програми сягав мільярда доларів. Значну частину прибутку формував саме сайт bell.com. Щодо «чорних п'ятниць» кількість замовлень, зроблених через сайт, досягала кілька мільйонів. Однак існуюча архітектура не дозволяла жодного розвитку, оскільки жорсткі взаємозв'язки елементів системи практично не дозволяли вносити до сервісу жодних змін.
Найсерйознішою проблемою стала неможливість зробити замовлення з однієї країни, сплатити його в іншій і відправити до третьої при тому, що подібна схема торгівлі дуже поширена у глобальних компаніях. Існуючий веб-сайт не дозволяв нічого подібного, тому вони змушені були приймати та оформлювати такі замовлення по телефону. Це призводило до того, що компанія все більше думала про зміну архітектури, зокрема про перехід на мікросервіси.
Вони вчинили розумно, вивчивши досвід інших компаній, щоб подивитися, як вирішили аналогічну проблему. Одним з таких рішень була архітектура сервісу Netflix, що є мікросервісами, з'єднаними через API, і зовнішню базу даних.
Керівництво Bell Сomputers вирішило побудувати саме таку архітектуру, дотримуючись якихось основних принципів. По-перше, вони відмовилися від дублювання даних, використовуючи підхід загального доступу до БД. Ніякі дані не пересилалися, навпаки, всі, хто їх потребував, мали звертатися до централізованого джерела. Далі були ізольованість і автономність – кожен сервіс був незалежний від інших. Вони вирішили використовувати Web API абсолютно для всього - якщо ви хотіли отримати дані або внести зміни до іншої системи, все це робилося через Web API. Останньою важливою річчю був новий головний мейнфрейм під назвою Bell on Bell на відміну від мейнфрейму Bell, заснованого на залізі конкурентів.
Отже, протягом 18 місяців вони створювали систему, керуючись цими основними принципами, і довели її до стадії передпродакшену. Повернувшись на роботу після вихідних, розробники зібралися разом і включили всі сервери, до яких було підключено нову систему. 18 місяців роботи, сотні розробників, найсучасніше апаратне забезпечення Bell – і позитивного результату! Це розчарувало безліч людей, тому що вони неодноразово запускали цю систему на своїх ноутбуках, і все було гаразд.
Вони вчинили розумно, кинувши всі гроші на вирішення цієї проблеми. Вони встановили найсучасніші серверні стійки зі світильниками, використовували гігабітне оптоволокно, найпотужніше серверне «залізо» з божевільним обсягом RAM, з'єднали все це, налаштували – і знову нічого! Тоді вони почали підозрювати, що причина може бути в таймаутах, тому зайшли у всі веб-налаштування, всі налаштування API і оновили всю конфігурацію таймаутів до максимальних значень, тому залишалося тільки сидіти і чекати, коли щось станеться з сайтом. Вони чекали, чекали і чекали протягом 9 з половиною хвилин, поки веб-сайт завантажився.
Після цього до них дійшло, що ситуація, що склалася, потребує ретельного розбору, і вони запросили нас. Перше, що ми з'ясували – протягом усіх 18 місяців розробки так і не було створено жодного реального «мікро» – все ставало ще більше. Після цього ми приступили до написання post-mortem, відомого також як "regretrospective", або "сумна ретроспектива", вона ж "blame storm" - "обвинувальний штурм" за аналогією з мозковим штурмом "brain storm", щоб розібратися внаслідок катастрофи.
У нас було кілька доказів, одним із яких було повне насичення трафіком у момент виклику API. Коли ви використовуєте монолітну архітектуру сервісу, то відразу можете зрозуміти, що саме пішло не так, тому що у вас є трасування до єдиного стеку, яке повідомляє про все, що могло викликати збій. У випадку, коли купа сервісів одночасно звертаються до одного API, немає жодної можливості відстежити трасування, крім використання додаткових інструментів мережевого моніторингу типу WireShark, завдяки яким можна розглянути окремий запит і з'ясувати, що сталося при його реалізації. Тому ми взяли одну веб-сторінку і протягом майже 2-х тижнів складали шматочки мозаїки, здійснюючи до неї різні виклики і аналізуючи, до чого призводить кожен з них.
Подивіться на цю картинку. Вона показує, що один зовнішній запит спонукає сервіс здійснювати величезну кількість внутрішніх викликів, які повертаються назад. Виходить, кожен внутрішній виклик здійснює додаткові хопи, щоб бути здатним самостійно обслужити цей запит, тому що не може більше нікуди звернутися за отриманням потрібної інформації. Ця картинка виглядає безглуздим каскадом викликів, оскільки зовнішній запит викликає додаткові послуги, які викликають інші додаткові послуги, і так практично до нескінченності.
Зеленим кольором на цій схемі показано півколо, в якому послуги викликають один одного - сервіс А викликає сервіс В, сервіс В викликає сервіс С, а той знову викликає сервіс А. В результаті ми отримуємо «розподілений глухий кут». Єдиний запит створював тисячу мережевих викликів API, і оскільки система не мала вбудовану відмовостійкість і захист від зациклювання, то запит закінчувався невдачею, якщо хоча б один з цих API-дзвінків давав збій.
Ми зробили деякі математичні обчислення. Кожен API виклик мав SLA не більше 150 мс і 99,9% аптайм. Один запит викликав 200 різних викликів, і у кращому разі сторінка могла бути показана через 200 x 150 мс = 30 секунд. Звичайно, це нікуди не годилося. Перемноживши 99,9% аптайм на 200 ми отримували 0% доступність. Виходить, що ця архітектура була приречена на провал із самого початку.
Ми звернулися до розробників з питанням, як же вони не зуміли розглянути цю проблему протягом 18 місяців роботи? Виявилося, що вони підраховували SLA тільки для запущеного ними коду, але якщо їхній сервіс викликав інший сервіс, вони не вважали цей час у своїх SLA. Все, що запускалося в межах одного процесу, дотримувалося значення 150 мс, але звернення до інших сервісних процесів збільшувало сумарну затримку. Перший викладений з цього урок формулювався так: «Чи розпоряджаєтеся ви своїм SLA або SLA розпоряджається вами»? У нашому випадку виходило друге.
Наступне, що ми виявили – вони знали про існування концепції помилок про розподілені обчислення, сформульовані Пітером Дейчем та Джеймсом Гослінгом, але проігнорували її першу частину. У ній говориться, що твердження «мережа надійна», «нульова латентність» і «пропускна здатність нескінченна» є помилками. Оманами також є твердження «мережа безпечна», «топологія ніколи не змінюється», «адміністратор завжди лише один», «ціна передачі даних нульова» та «мережа однорідна».
Вони припустилися помилки, тому що обкатували свій сервіс на локальних машинах і ніколи не «підчіпляли» зовнішні сервіси. Під час локальної розробки та використання локального кешу вони ніколи не стикалися з мережевими хопами. За всі 18 місяців розробки вони жодного разу не задалися питанням, що може статися, якщо торкнутися зовнішніх послуг.
Якщо подивитися на межі сервісів на попередньому зображенні, видно, що всі вони неправильні. Існує маса джерел, які радять, як визначати межі сервісів, і більшість роблять це неправильно, як, наприклад, Microsoft на наступному слайді.
Це зображення з блогу MS на тему «Як будувати мікросервіси». Тут показано просте веб-додаток, блок бізнес-логіки та базу даних. Запит надходить безпосередньо, ймовірно, тут є один сервер для Інтернету, один сервер для бізнесу і один для БД. Якщо збільшити трафік, картинка трохи зміниться.
Тут з'являється балансувальник навантаження для розподілу трафіку між двома веб-серверами, кеш, розташований між веб-сервісом та бізнес-логікою та ще один кеш між бізнес-логікою та базою даних. Саме таку архітектуру використовувала компанія Bell для свого застосування – балансування навантаження та blue/green розгортання, виконане в середині 2000-х. До деякого часу все працювало добре, оскільки ця схема призначалася для монолітної структури.
На наступній картинці показано, як MS рекомендує здійснювати перехід від моноліту до мікросервісів – просто розділити кожен із основних сервісів окремі мікросервіси. Саме при впровадженні цієї схеми Bell і припустилися помилки.
Вони розбили всі свої послуги на різні рівні, кожен з яких складався з безлічі індивідуальних сервісів. Наприклад, веб-сервіс включав мікросервіси для рендерингу контенту та аутентифікації, сервіс бізнес-логіки складався з мікросервісів для обробки замовлень та інформації про облікові записи, база даних була розділена на купу мікросервісів зі спеціалізованими даними. І веб, і бізнес-логіка, і БД були stateless-сервіси.
Однак ця картинка була абсолютно неправильною, тому що не картувала жодні бізнес-одиниці поза IT-кластером компанії. Ця схема не враховувала жодного зв'язку із зовнішнім світом, тому було незрозуміло, як, наприклад, отримувати сторонню бізнес-аналітику. Зауважу, що в них до того ж було кілька сервісів, придуманих просто для розвитку кар'єри окремих співробітників, які прагнули керувати якомога більшою кількістю людей, щоб отримувати за це більше грошей.
Вони вважали, що для переходу на мікросервіси досить просто взяти їхню внутрішню інфраструктуру фізичного рівня N-tier і вставити в неї Docker. Погляньмо, як виглядає традиційна архітектура N-tier.
Вона складається з 4 рівнів: рівень інтерфейсу UI, рівень бізнес-логіки, рівень доступу до даних і база даних. Більш прогресивна DDD (Domain-Driven Design), або програмно-орієнтована архітектура, де два середні рівні є доменними об'єктами і репозиторіями.
Я спробував розглянути в цій архітектурі різні сфери змін, різні сфери відповідальності. У звичайному додатку N-tier класифікуються різні області змін, які пронизують структуру вертикально зверху вниз. Це Catalog, налаштування Config, що виконуються на індивідуальних комп'ютерах та перевірки Checkout, якими займалася моя команда.
Особливість даної схеми полягає в тому, що межі цих областей змін зачіпають не лише рівень бізнес-логіки, а й поширюються на базу даних.
Давайте розглянемо, що означає бути сервісом. Існує 6 характерних властивостей визначення сервісу - це програмне забезпечення, яке:
- створюється та використовується конкретною організацією;
- відповідає за зміст, обробку та/або надання певного виду інформації в рамках системи;
- може бути створено, розгорнуто та запущено незалежно для задоволення певних операційних завдань;
- спілкується із споживачами та іншими сервісами, надаючи інформацію на основі угод чи договірних гарантій;
- захищає себе від несанкціонованого доступу, а свою інформацію – від втрати;
- оперує збоями таким чином, щоб вони не призвели до пошкодження інформації.
Всі ці властивості можна виразити одним словом "автономність". Сервіси працюють незалежно один від одного, задовольняють певним обмеженням, визначають контракти, на основі яких люди можуть отримувати необхідну інформацію. Я не згадав специфічних технологій, використання яких мається на увазі само собою.
Тепер розглянемо визначення мікросервісів:
- мікросервіс має малий розмір і призначений для вирішення одного конкретного завдання;
- мікросервіс автономен;
- під час створення архітектури мікросервісу використовується метафора «міського планування» town planning metaphor. Це визначення книги Сема Ньюмана «Створення мікросервісів».
Визначення Bounded Context взято з книги Еріка Еванса "Domain-Driven Design". Це основний патерн у DDD, центр проектування архітектури, який працює з об'ємними архітектурними моделями, поділяючи їх на різні Bounded Context та явно визначаючи взаємодію між ними.
Простіше кажучи, обмежений контекст Bounded Context позначає область, де може застосовуватися конкретний модуль. Усередині цього контексту розташована логічно уніфікована модель, яку можна побачити, наприклад у вашому бізнес-домені. Якщо ви запитаєте "хто такий клієнт" у персоналу, який займається замовленнями, то отримаєте одне визначення, якщо запитаєте у тих, хто займається продажами - отримаєте інше, а виконавці видадуть вам третє визначення.
Так от, Bounded Context каже, що якщо ми не можемо дати однозначного визначення того, що є споживачем наших послуг, давайте визначимо межі, в межах яких можна міркувати про значення цього терміна, а потім визначимо точки переходу між цими різними визначеннями. Тобто, якщо ми говоримо про клієнта з погляду оформлення замовлень, це означає те й те, а якщо з погляду продажів – те й те.
Наступним визначенням мікросервісу є інкапсуляція будь-якого виду внутрішніх операцій, що запобігає «витіканню» складових робочого процесу в навколишнє середовище. Далі слідує «визначення явних контрактів для зовнішніх взаємодій, або зовнішніх зв'язків», яке представлено ідеєю контрактів, що повертаються від SLA. Останнім визначенням є метафора клітини, або комірки, яка означає повну інкапсуляцію набору операцій усередині мікросервісу та наявність у ньому рецепторів для спілкування із зовнішнім світом.
Отже, ми сказали хлопцям із Bell Computers: «Ми не зможемо виправити нічого у створеному вами хаосі, тому що у вас просто не вистачить для цього грошей, але ми виправимо лише один сервіс, щоб надати всьому цьому сенсу». З цього місця я почну розповідь про те, як ми виправили єдиний сервіс, щоб він став відповідати на запити швидше, ніж через 9 хвилин.
22:30 хв
Продовження буде зовсім скоро.
Небагато реклами
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог 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