Моноліт

Що насправді не так — шістнадцять скарг на моноліт і де живе кожна

Слово «моноліт» зазвичай звучить тоді, коли щось болить. Зміна йде в продакшн сорок хвилин. Ніхто не наважується торкнутися білінгу. Баґ у звіті поклав разом із собою оформлення замовлення. Кожна з цих скарг називає реальну ціну, і за кожною зазвичай іде та сама пропозиція: розрізати систему на сервіси. Але скарги походять із трьох різних місць. Одні живуть у коді — у межах між його частинами або в їхній відсутності. Інші — в інструментах збірки, тестування й деплою. Лише кілька останніх живуть у тому, що все виходить як одне ціле. Поділ деплою лікує лише цю останню групу. Ось шістнадцять скарг, які команди озвучують щодня, розкладені за тим, де вони насправді живуть. Наступні розділи посилаються на рядки за номерами.

Дві осі, які плутає кожна суперечка про архітектуру

Моноліт — це застосунок, чий код збирають, тестують і деплоять як одне ціле. Це все визначення. Воно нічого не каже про розмір кодової бази чи кількість людей на ній. Не каже воно й того, чи добре організовано код усередині. Продукт на десять людей і GitHub — обидва моноліти саме в цьому сенсі.

Образою це слово стало приблизно 25 березня 2014 року. Того дня Джеймс Льюїс і Мартін Фаулер опублікували статтю, що дала назву мікросервісам, і визначили новий стиль через протиставлення «монолітному застосунку». За кілька років «моноліт» почав означати старе, повільне й заплутане. Але заплутаний стан старший і має власну назву. Браян Фут і Джозеф Йодер назвали його великою грудкою бруду (big ball of mud) 1997 року: система без упізнаваної структури, де все пов’язано з усім. Це властивість коду, а не деплою. Велика грудка бруду, розрізана на двадцять сервісів, лишається великою грудкою бруду — просто тепер її зв’язки перетинають мережу.

Тож питань два, а не одне. Скільки в системи одиниць деплою? І наскільки добре її код поділено на модулі — частини з чіткою роботою, опублікованим інтерфейсом і без того, щоб хтось ліз у їхні нутрощі? Відповіді дають чотири види систем. Таблиця нижче показує, чого коштує кожен. Варто знати словник Сема Ньюмана для лівого стовпця: однопроцесний моноліт — це будь-який моноліт, а модульний моноліт — однопроцесний моноліт, чиї модулі справжні. Нижня права клітинка теж має назву, і саме від неї ця сторінка здебільшого намагається вас уберегти.

Чому один артефакт — правильний вибір за замовчуванням і найкращий аргумент проти

Аргумент на користь старту з одного артефакту — не ностальгія. Єдиний процес прибирає цілу категорію проблем, які інакше довелося б розв’язати ще до першого рядка бізнес-логіки. Кожен рядок таблиці нижче — робота, яка потрібна набору сервісів і не потрібна моноліту. Жодна з них не з’являється в продуктовій дорожній карті, і жодна ніколи не завершується.

Глибший аргумент — про знання, і Мартін Фаулер подав його під назвою «MonolithFirst» 3 червня 2015 року. Він навів два спостереження з проєктів, які бачив. Майже всі успішні історії мікросервісів починалися з моноліту, який виріс занадто великим і був розібраний. Майже всі системи, збудовані як мікросервіси з нуля, опинилися в серйозних проблемах. Його пояснення: межі сервісів дорого пересувати й важко провести правильно, а помиляються в них тоді, коли ще не розуміють предметної області, — а на старті продукту ви її не розумієте. Моноліт дозволяє дешево рухати межі, поки ви ще вчитеся, де їм бути. Він відкладає дороге зобов’язання до появи доказів.

Через шість днів Фаулер опублікував на власному сайті найсильнішу відповідь. Стефан Тільков у статті «Don’t start with a monolith» доводив протилежне, спираючись на такий самий довгий досвід. Розділити наявний моноліт, писав він, надзвичайно важко, бо за роки кожна частина починає залежати від спільних бібліотек, спільних доменних об’єктів і спільної бази даних. А старт нової системи — саме той момент, коли варто думати про поділ на частини, бо це останній момент, коли він дешевий. Тільков додав одну умову: предметну область, для якої ви будуєте, треба знати дуже-дуже добре. Ці два есеї досі найкраще коротке формулювання цього компромісу.

Найчастіше цитований захист цього стилю прийшов від невеликої команди. У тексті «The Majestic Monolith» (29 лютого 2016 року) Девід Гайнемаєр Ганссон описав Basecamp: дванадцять програмістів, мільйони користувачів і каталог застосунків, які вони пообіцяли підтримувати. Його теза: щоразу, коли співпрацю між об’єктами перетворюють на співпрацю між системами, ви погоджуєтеся на «цілий світ болю». Аргумент — про пропорцію. Розподілена система — це податок, який сплачують людьми. Дванадцять програмістів не можуть дозволити собі витрачати на нього чотирьох.

Як провести межі модулів і змусити їх триматися

Проводьте модулі навколо того, що робить бізнес, а не навколо того, яким кодом є файл. Замовлення, білінг, каталог і користувачі — це модулі. Контролери, сервіси й репозиторії — ні: це шари, а шар зачіпає кожну фічу. Допомагають два швидкі тести. Чи можна описати роботу модуля одним реченням без слова «і»? І чи лишається типова зміна фічі в межах одного модуля? У предметно-орієнтованому проєктуванні (domain-driven design) ця сама ідея зветься обмеженим контекстом: частиною системи, усередині якої кожен термін означає щось одне. «Замовлення» означає різне для складу й для білінгу, і саме ця різниця показує, де пройде межа.

Модуль володіє чотирма речами: своїм кодом, своїми таблицями, своїм публічним інтерфейсом і подіями, які він публікує. Інші модулі можуть викликати інтерфейс і слухати події — і нічого більше. Через межу мають іти прості дані й ідентифікатори, а не живі об’єкти. Передати ORMORMObject-Relational Mapping — обʼєкти замість SQLБібліотека, що підставляє обʼєкти мови там, де в базі лежать рядки таблиці, — тож SQL ви майже не пишете. Зручність коштує контролю: згенерований запит буває значно важчим за той, який ви написали б самі, і зʼясовується це вже під навантаженням.Докладніше в статті →Усі терміни-сутність з одного модуля в інший здається нешкідливим, але це віддає всю схему зберігання першого модуля: отримувач тепер може ліниво підвантажувати пов’язані рядки й зберігати зміни, яких власник ніколи не побачить. Те саме з базою даних. Кожна таблиця має рівно один модуль-власник, і жоден інший модуль не робить JOIN із нею й не тримає зовнішнього ключа на неї. Саме порушення цього правила показує діаграма вгорі сторінки.

Залежності між модулями мають утворювати граф без циклів: базовий код унизу, бізнес-модулі над ним, і нічого внизу не знає про те, що вище. Досвід Shopify додає уточнення, яке легко пропустити. Його інженери помітили, що розробники розкладають код по модулях за тим, що підказує назва, а не за тим, як код працює. Модель під назвою «налаштування білінгу магазину» жила в пакеті білінгу через свою назву — але вона ж тримала прапорець, що позначає магазин як шахрайський, а він потрібен кожному запиту. Їй було місце в основі графа, доступній усьому. Тож перш ніж вирішувати, якому модулю належить шматок коду, перевірте, де його використовують, а не як він називається.

Як змусити межі триматися

У моноліті ніщо не забезпечує межу, доки ви цього не зробите. Ніщо не заважає розробнику о другій ночі заімпортувати клас з іншого модуля, і ніщо не скаже йому, що так не можна. Між сервісами межу тримає мережа тим, що вона незручна. Усередині моноліту цю незручність треба створити свідомо — у мові, у збірці або в перевірці, що валить CICI/CDContinuous Integration / Continuous Delivery — автоматична збірка й доставкаКожен коміт автоматично складається і проганяється через тести (CI), а придатна збірка так само автоматично їде на сервери (CD). Сенс не в автоматизації як такій, а в тому, що поломку видно за хвилини, а не в день релізу.Докладніше в статті →Усі терміни. Що доступно, залежить від екосистеми:

Найкращу віддачу дає перевірка, що валить збірку. Десяток рядків, які стверджують, що ніщо поза білінгом не має права імпортувати billing.internal, перетворюють правило, з яким усі згодні й якого ніхто не дотримує, на червону збірку з файлом і номером рядка. Без такої перевірки межі модулів живуть рівно доти, доки в команді лишається людина, якій вони не байдужі. Для наявної кодової бази звичний вхід — записати всі поточні порушення у файл-список і валити збірку лише на нових. Packwerk називає це оголошенням банкрутства. Це працює з одним застереженням, яке Shopify опублікував сам: перевірка знаходить проблеми значно швидше, ніж команда їх виправляє, тож список потребує власника й бюджету, інакше він лише росте.

Як експлуатувати великий моноліт: масштабування, деплої й тести

Моноліт масштабується горизонтально, як і будь-що інше. Якщо застосунок не тримає стану між запитами у власній пам’яті — сесії в базі чи кеші, файли в об’єктному сховищі, — ви запускаєте стільки копій, скільки потребує навантаження, за балансувальником навантаження (load balancerload balancerрозподіляє запити між серверамиСервер чи керований сервіс, що приймає вхідні запити й розподіляє їх між кількома копіями застосунку, оминаючи копії, які не проходять перевірку стану. Це також ще один мережевий вузол із власними тайм-аутами, тож його налаштування й налаштування застосунку мають узгоджуватися.Усі терміни). Stack Overflow опублікував свої цифри за 9 лютого 2016 року: 209 мільйонів запитів і 66 мільйонів завантажень сторінок за день, які обслуговував один застосунок на ASP.NET на одинадцяти вебсерверах, і середня сторінка питання рендерилася за 22,71 мілісекунди. Його інженери додали, що на той час сайт міг працювати на одному вебсервері — і кілька разів випадково так і робив. Межею, над якою вони працювали, була продуктивність усередині застосунку, а не кількість одиниць деплою.

Коли навантаженому моноліту стає тісно, першою зазвичай закінчується база даних, а не застосунок. Відповіді ті самі, що знадобилися б і набору сервісів: кешування, репліки для читання для запитів, яким не страшні трохи застарілі дані, а зрештою — розбиття даних за клієнтом чи регіоном. Поділ коду на сервіси цієї межі не прибирає. Він дає кожному сервісу меншу базу й нову проблему — запити й транзакції, які раніше їх охоплювали.

Одна збірка не означає одного пулу однакових процесів. Той самий артефакт можна запустити як вебсервер, як фоновий воркер для однієї черги, як воркер для важкої на CPUCPUCentral Processing Unit — процесорПроцесор, що виконує інструкції програми. Коли кажуть, що завдання «впирається в CPU», мають на увазі, що воно обмежене обчисленнями, а не очікуванням диска чи мережі, — і лікуються ці два випадки протилежно, тому розрізняти їх варто одразу.Усі терміни черги на більших машинах або як єдиний планувальник, що ніколи не має працювати двічі. Кожен пул отримує власну кількість екземплярів, розмір машин, ліміт пам’яті й політику перезапуску. Це відповідь на рядки 13 і 14 без другої кодової бази. Обробка зображень отримує вшістнадцятеро більше CPU, а вебсервери з цього не отримують нічого, і витік пам’яті в генерації звітів перезапускає воркери звітів, а не оформлення замовлення: радіус ураження (blast radiusblast radiusнаскільки далеко сягає шкодаЯку частину системи зачіпає, коли щось одне йде не так, — поганий деплой, процес, що впав, витік облікових даних, помилка агента. Його зменшують межами: окремими процесами, вузькими дозволами, поетапними розгортаннями. Компроміс у тому, що кожна межа, яка стримує збій, ще й щось коштує, коли її треба перетнути.Усі терміни) збою звужується до одного пулу. Prime Video 2023 року дійшов до того самого патерну з іншого боку: об’єднавши розподілений сервіс в один процес, він запустив кілька його копій, кожну з власною частиною роботи.

Частота деплою — властивість розміру партії й автоматизації, а не архітектури (рядок 11). GitHub описав свій моноліт на Rails 2023 року: майже два мільйони рядків коду, понад тисяча інженерів, що працюють із ним щодня, і деплої до двадцяти разів на день. Навіть фреймворк оновлюють безперервно: щопонеділка запланована задача відкриває pull request, що переводить застосунок на останній коміт самого Rails, і зміна виходить того ж тижня. Уможливлює це механіка навколо коду: черга злиття, що тестує зміни в тому порядку, в якому вони потраплять у main, canarycanaryвипуск спершу для небагатьохСпершу спрямувати нову версію на малу частку трафіку й подивитись, перш ніж піде решта. Це купує те, чого не дає повний реліз: поломка коштує вам одного відсотка користувачів, а не всіх.Докладніше в статті →Усі терміни-релізи спершу на малу частку трафіку й feature flagsfeature flagперемикач навколо нового кодуПеремикач, що під час роботи вирішує, чи активний шматок коду, — тож код може потрапити в продакшен вимкненим і бути ввімкненим для обраної аудиторії пізніше. Він відділяє деплой від релізу й має ціну: кожен живий прапорець — це розгалуження в коді, яке має працювати в обох станах.Докладніше в статті →Усі терміни, щоб деплой коду та вмикання фічі були двома окремими рішеннями.

Тести — місце, де межі модулів окупаються вдруге. Маючи задекларований граф залежностей (рядок 2), CI може визначити, які модулі зміна могла зачепити, і запустити лише їхні тести — Shopify назвав саме це однією з цілей своїх компонентів. Без графа кожна зміна запускає всі тести, і набір росте разом із кодовою базою, доки люди не перестануть запускати його локально. Таблиця перелічує, що росте разом із монолітом, і виправлення, яке не потребує нової архітектури.

Де моноліт справді вичерпується

Реальні межі існують, і чесність щодо них відрізняє аргумент від уподобання. Це рядки 13–16 плюс одна межа, яку жоден рядок добре не передає: кількість команд. Мелвін Конвей 1968 року помітив, що структура системи зрештою віддзеркалює структуру комунікації організації, яка її будує. Для трьох команд один артефакт — зручність. Для тридцяти він стає нарадою, на яку мусять приходити всі. Таблиця перетворює кожну межу на те, що можна виміряти до рішення, — бо в кожної є дешевша відповідь, яку варто спробувати першою.

Виділити один сервіс, щоб зняти одне виміряне обмеження, — це не те саме рішення, що перейти на мікросервіси. Перше — одна міграція з чіткою причиною й чітким кінцем. Друге — операційна модель для всієї організації. Як безпечно зробити перше — фасад перед монолітом, перенесення по одній можливості, поділ даних наостанок, — тема сторінки «Моноліт → мікросервіси», а чого коштує друге — на сторінці про мікросервіси.

П’ять кейсів і те, чого в кожному бракувало

П’ять кейсів охоплюють обидва напрямки. Дві команди повернулися від сервісів до одного процесу, один проєкт об’єднав власні мікросервіси в один бінарник, одна компанія роками робила гігантський моноліт модульним, а один сайт обслуговував сотні мільйонів запитів на день одним застосунком. Кожен кейс задокументували інженери, які робили цю роботу.

Історію Segment цитують найчастіше, бо вона пройшла в обидва боки. Продукт пересилав події клієнтів до понад сотні партнерських APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни. Одна спільна черга означала, що один повільний партнер затримував усіх, тож команда дала кожному напряму доставки власний сервіс і чергу — розумне виправлення реальної проблеми. Потім кожен напрям отримав власний репозиторій, щоб один зламаний тест не блокував усіх інших. Слідом прийшли спільні бібліотеки, і їхні версії в десятках репозиторіїв розійшлися, бо оновити всі одразу було ризиком, на який ні в кого не було часу. Кожен сервіс мав власний профіль навантаження, і масштабувати його доводилося вручну. Зрештою троє інженерів на повну ставку витрачали більшість часу на те, щоб система просто жила. Команда злила понад 140 сервісів в один, закріпила 120 залежностей на одній версії й замінила в тестах живі виклики записаним трафіком, тож увесь набір проходив за мілісекунди замість години. Поліпшень спільних бібліотек стало 46 за рік після зміни проти 32 за рік до неї. У тексті названо й ціну: один баґ тепер може покласти всі напрями, а кеші в пам’яті розмазані по понад 3000 процесів.

Shopify — довга версія і найкорисніша, бо це модульний моноліт, описаний зсередини. 2019 року інженери компанії пояснили, чому вирішили зробити моноліт модульним, а не розділити його: кодова база, над якою понад десять років працювали понад тисяча розробників, і код оформлення замовлення та код тарифів доставки могли вільно викликати одне одного. Вони розклали тисячі файлів у пару десятків компонентів, по одному на напрям комерції, а у вересні 2020 року випустили Packwerk, щоб перевіряти залежності між ними в кожному pull request. У лютому 2024 року та сама команда опублікувала ретроспективу, і вона незвично відверта. Перевірки приватності в Packwerk, що позначали код публічним чи приватним, прибрали, бо команди почали шліфувати інтерфейси замість того, щоб виправляти залежності. Коли команда прибрала всі порушення одного базового пакета, вона знайшла в Packwerk баґ, який показав, що вона, найімовірніше, перший користувач, що взагалі дійшов до кінця списку. Щоб цей один пакет справді стартував і проходив тести ізольовано, знадобилося багато місяців. А компоненти, проведені навколо бізнес-доменів, не збіглися з тим, як працює код, тож тепер усередині них групують менші пакети, проведені за функцією.

Де це вироджується

Моноліт відмовляє повільно й тихо. Того дня, коли межу вперше перетинають, нічого не ламається; ціна приходить через рік, коли нічого не можна змінити окремо. Майже кожен збій — одне з цього:

• JOIN і зовнішні ключі через таблиці модулів, що зв’язують модулі через сховище замість інтерфейсів (рядок 4).
• Пакети за шарами — контролери, сервіси, репозиторії, — тож поверхнею кожної фічі є вся кодова база (рядок 3).
• Модуль common чи utils, від якого залежить усе і яким не володіє ніхто (рядок 5).
• Правила модулів, узгоджені в документі, а не перевірені в CI, тож вони тримаються квартал.
• Файл-список відомих порушень без власника, який лише росте.
• ORM-сутності, які передають між модулями, віддаючи сховище одного модуля іншому.
• Тести, достатньо повільні, щоб їх перестали запускати локально, — зникає той швидкий зворотний зв’язок, що робив моноліт дешевим (рядок 8).
• Щотижневі релізи, які захищають як обережність, хоча ризик — саме розмір партії (рядок 11).
• Один пул процесів для всіх видів роботи, тож найважча задача визначає розмір кожної машини (рядок 13).
• Поділ, щоб полагодити зв’язність, який дає розподілений моноліт: зв’язність лишається, мережа додається.

Чесна межа — люди. Моноліт тримає ціну межі близькою до нуля, і це водночас його сила й слабкість: межу, яку нічого не коштує перетнути, перетинають щоразу, коли хтось поспішає. Кожен інструмент на цій сторінці існує, щоб перетин знову щось коштував. Навіть з усіма ними моноліт не може дати двом командам окремих баз, окремих днів релізу чи окремих чергувань — а від певної кількості команд саме це їм і потрібно. Нижче за цю кількість ціна моноліту — дисципліна; вище — ціна сервісів вимірюється інженерами. Більшість продуктів ніколи не досягає цієї кількості, а ті, що досягають, із модульним монолітом виділяють сервіси швидше, ніж ті, що приходять туди з грудкою бруду.

Практична перевірка займає пів дня. Складіть список модулів і команди, що володіє кожним; якщо не виходить — почніть із цього. Пошукайте в запитах JOIN між таблицями, що належать різним модулям. Згенеруйте граф залежностей і пошукайте цикли. З’ясуйте, чи є перевірка, яка валить CI, коли модуль імпортує нутрощі іншого. Заміряйте тести й спитайте, чи запускаються лише ті, що їх зачіпає зміна. Порахуйте деплої за останній місяць. І для кожної скарги на «моноліт», яку ви чуєте, знайдіть її рядок у таблиці вгорі сторінки, перш ніж хтось відкриє пропозицію його розділити.

Коли це застосовувати

Пов’язані сторінки

• РозробкаМікросервісиМікросервіси — це архітектура, у якій одну систему будують як набір невеликих сервісів: кожен деплоїться окремо, володіє власними даними й належить одній команді. Незалежний деплой — те, що цей стиль купує, а кожен виклик, який тепер іде через мережу, — те, чим за це платять. Сторінка починається з шістнадцяти проблем, які додає мережа, і патерну, що відповідає на кожну; далі — дев’ять характеристик, якими цей термін визначили, що потрібно мати до другого сервісу, дані між сервісами, виклики між сервісами, експлуатація багатьох сервісів, п’ять задокументованих збоїв і де все це вироджується.
• РозробкаМоноліт → мікросервісиМіграція з моноліту на мікросервіси — це перенесення можливостей наявної системи в окремі сервіси по одній, без зупинки системи. Міграція, яка працює, — не переписування з датою переходу, а послідовність невеликих виділень за фасадом, кожне з яких обґрунтоване виміряним обмеженням і має шлях назад; найскладніше тут — дані. Сторінка починається з одного виділення як шістнадцяти кроків; далі — що виділяти першим, шість способів переносити код без зупинки, поділ даних, модель і команди, як вести міграцію й коли зупинитися, п’ять задокументованих кейсів і де все це вироджується.
• МенеджментОрганізаційні структури управлінняОрганізаційна структура — це те, як компанія ділить роботу між підрозділами й хто кому підпорядковується, а отже — хто дає проєкту людей, гроші й рішення. Лінійна, функціональна й матрична — це не методології управління на кшталт Scrum чи Kanban. Це форма організації, всередині якої методології доводиться працювати, і вона визначає, скільки повноважень насправді має людина, що веде проєкт. Сторінка починається з усіх поширених структур поруч і п’яти питань, які покажуть, у якій із них ви працюєте, а далі — два питання за кожною структурою, класичні ієрархії, матриця і дев’ять її відомих збоїв, проєктні й продуктові команди, закон Конвея, компанії, що пробували обійтися без менеджерів, і де реструктуризація перетворюється на театр.