Масштабування блокчейн-інфраструктури: де ламається під навантаженням
Під навантаженням інфраструктура ламається не там, де її зазвичай шукають. Першою здається не диск і не процесор, а черга запитів: JSON-RPC-нода приймає їх в обмежений буфер, і на піку активності черга зростає швидше, ніж розбирається.
Далі вмикається деградація відгуку ноди — час відповіді на читання зростає нелінійно, бо запити конкурують за одні й ті самі стани.
Друге вузьке місце блокчейн-мережі — розсинхрон. Одна нода йде вперед за висотою, друга відстає на кілька блоків, і баланс, прочитаний з відстаючої, розходиться з тим, що бачить клієнт.
На реоргах це помітніше: кеш віддає застарілий стан, а індекс, зібраний за логами, відстає від голови ланцюга.
Третє — стан і підписки. Запит до історичних даних на архівній ноді читає тисячі ключів, і такий виклик тримає потік, поки інші чекають.
Постійні підписки через WebSocket копіюють навантаження інакше: кожен новий слухач не додає користувачів, але додає з'єднань, які потрібно тримати відкритими й перепідключати при обриві.
Кожна з цих точок має межу, за якою відгук падає сходинкою, а не плавно.
Навантаження на ноди мережі зростає від кількості підписок сильніше, ніж від кількості користувачів, — тому масштабування блокчейн-інфраструктури починається з розбору, де саме закінчується буфер і що відбувається після. Розбираємо, як це закривається.
Що дає перебудова мережі: швидкість і відмовостійкість
Одна нода, яка одночасно віддає історію, приймає транзакції й транслює події, — найчастіше вузьке місце.
Поки навантаження зростає, пропускна здатність нод упирається в один процес: час відгуку на читання збільшується швидше за кількість клієнтів, а потік подій починає відставати від стану мережі.
Тому розводимо ролі — валідувальні, архівні та обслуговувальні запити — і кожну групу масштабуємо окремо, під її профіль навантаження.
Відмовостійкість блокчейн-мережі — це не «нода у двох екземплярах». Резерв тримаємо гарячим, з відставанням в один блок, а балансувальник перевіряє живучість кожної ноди і знімає трафік з тієї, що перестала відповідати. Переведення займає секунди, і простій сервісу вимірюється вже не хвилинами, а часом перемикання.
Окрема історія — підписки. З'єднання WebSocket прив'язане до конкретної ноди, тому при її падінні клієнт мовчки втрачає потік подій.
Ми тримаємо сесії з прив'язкою до ноди й буфер із курсором останнього обробленого блока: після розриву клієнт доганяє пропущене, а не починає з чистого аркуша. Частка втрачених підписок прямує до нуля.
На Ethereum і сумісних мережах такий шар дає передбачувані метрики: час відгуку на читання тримається в межах, заданих профілем навантаження, відновлення після відмови ноди вкладається в секунди, а клас відмов «сервіс недоступний через одну ноду» зникає зі статистики. Що саме змінюємо в конкретній мережі — визначає замір до перебудови, а не загальний шаблон.
Режими: вертикальне зростання, розподіл, гібридна схема
Три режими різняться не запасом потужності, а місцем, де виникає межа. Вертикальне масштабування — це продуктивніша нода: стан і черга непідтверджених транзакцій повністю на одній машині, тому відгук на запити передбачуваний, а логіка консистентності не ускладнюється.
Платите стелею заліза й тривалою синхронізацією: повне перезбирання індексів займає години, а будь-яке обслуговування — це вікно простою.
Горизонтальний розподіл нод будується інакше: кілька реплік за балансувальником, читання й підписки йдуть на них, запис і підпис залишаються на головній ноді. Гібридна схема поєднує обидва підходи — посилена нода для запису плюс пул реплік під потік читань і WebSocket-підписок.
| Режим | Коли підходить | Чим розплачуєшся |
|---|---|---|
| Вертикальне масштабування | Навантаження зростає помірно, кількість клієнтів передбачувана, важлива проста схема | Стеля заліза, години на синхронізацію, простій під час обслуговування, прискорюване зростання обсягу індексів |
| Горизонтальний розподіл нод | Багато паралельних читань і підписок, запити допускають невелике відставання даних | Репліки відстають: частина відповідей віддає застарілий стан, потрібен контроль відставання й акуратне переведення клієнтів між нодами |
| Гібридна схема | Змішаний профіль: важкий запис і масові читання одночасно | Дорожче в супроводі: два контури, окремі правила оновлення й відмовостійкості, більше точок відмови |
Вибір визначається не «найпотужнішим» варіантом, а тим, чия межа лежить далі за ваш профіль навантаження. Рахуємо частку читань, кількість одночасних підписок і вимоги до свіжості даних — і тільки після цього фіксуємо режим роботи нод.
Порядок робіт: від обстеження до передачі в експлуатацію
Масштабування починають не з розгортання, а із заміру поточних меж: скільки одночасних підписок тримає шлюз, на якому обсязі викликів упирається шар читання даних, як поводиться синхронізація при відставанні ноди.
Нижче — порядок робіт, де кожен крок закінчується результатом, який приймається до переходу до наступного.
Сім кроків з вимірюваним результатом
- Обстеження інфраструктури. Знімаємо профіль навантаження: одночасні підписки, склад і частоту викликів, пікові інтервали, запас за диском і мережею. На виході — звіт з фактичними межами, а не оцінки на око.
- Схема розміщення нод. Розподіляємо ролі — валідувальні, ноди читання, архівні, шлюзи підписок — і фіксуємо зв'язки та точки відмови. Топологія узгоджується до налаштування.
- Налаштування нод. Конфігурація під знятий профіль: ліміти з'єднань, таймаути, глибина зберігання, розділення читання й запису, репліки. Кожна зміна версіонується й оборотна.
- Навантажувальна перевірка. Відтворюємо пік і запас понад нього, перевіряємо поведінку при відмові однієї ноди: плавна деградація чи падіння. Конфігурацію правимо за метриками.
- Дослідна експлуатація. Реальний трафік із розширеним спостереженням: звіряємо прогноз із фактом і доналаштовуємо те, що поводиться інакше.
- Спостережуваність і регламенти. Дашборди, алерти, процедури діагностики й відкату — щоб збій ловився раніше, ніж його помітять користувачі.
- Передача в експлуатацію. Доступи, інструкції з відновлення й навчання чергової зміни: систему піднімають і лагодять без нашої участі.
Що залишається у вас: конфігурації, схеми, регламенти
Інфраструктура без документації живе рівно до першого звільнення інженера або аварії. Тому все, що ми налаштовуємо, передається робочими артефактами: їх можна перевірити, розгорнути заново в чистому середовищі й віддати своїй команді без переказів «на словах». Нижче — комплект, який залишається у вас після здачі.
- Конфігурації нод — параметри синхронізації, ліміти з'єднань, таймаути, політика повторів, обсяги кешу; поруч пояснення, чому вибрано саме це значення і що змінюється при зростанні навантаження.
- Схеми топології — розподіл нод за зонами, резервні маршрути, дубльовані ділянки й точки, відмова яких обвалить весь контур.
- Правила доступу — ролі, ключі, межі прав на читання й запис, порядок видачі та відкликання, журнал дій.
- Налаштування розподілу потоку — як запити розходяться за нодами і що відбувається при відмові однієї з них.
- Регламенти обслуговування — планові роботи, порядок оновлень, перевірка стану, пороги оповіщень і чергові дії.
- Регламенти відновлення — резервні копії, цільовий час повернення в роботу, відкат на попередній стан, тренування сценарію.
- Документація інфраструктури — карта сервісів, залежності, відповідальні, інструкції для чергового інженера.
Кожен пункт — не опис, а робочий файл або перевірений сценарій: його можна віддати новій команді, і вона підніме контур без нас.
Кейс: зростання навантаження втричі без деградації відгуку
До перебудови інфраструктура трималася на одній ноді зі спільним публічним ендпоінтом.
Застосунок виріс, кількість запитів потроїлася за квартал, і в пікові години підписки на нові блоки рвалися десятками: клієнти бачили пропуски подій, а відновлення ноди, що впала, займало близько сорока хвилин ручної роботи інженера.
Почали з навантажувального тестування — відтворили трикратний пік на стенді й знайшли точку відмови: переповнювалася не мережа, а черга підписок усередині процесу ноди.
Далі розділили ролі: читання пішло на пул нод під балансувальником, запис і трансляція подій — на окремий шар підписок із буферизацією й повтором, а оркестрація на Kubernetes замінила ручний підйом нод на автоматичний перезапуск із перевірками стану.
Метрики до і після
- обсяг запитів — з 1,2 до 3,6 тис. за хвилину на тому самому парку машин;
- відгук під піком — 95-й процентиль скоротився з 4 до 1,1 секунди;
- обриви підписок — з 60–80 за пікову годину до нуля за місяць спостережень;
- відновлення ноди — з 40 хвилин вручну до 90 секунд автоматично.
Запас за навантаженням залишився: наступне трикратне зростання упирається вже не в ноди, а в сховище історії подій — це наступна точка, яку тримаємо під наглядом.
Окремо закріпили регламент відкату: шар підписок розгортається окремо від нод, тому невдале оновлення відкочується без втрати потоку подій.
Що робити, якщо блокчейн-інфраструктура вже розгорнута?
Уже розгорнуті ноди рідко вимагають повної зупинки сервісу — простій виникає там, де є єдина копія й один шлях до даних. Спочатку інвентаризація блокчейн-інфраструктури: які екземпляри обслуговують читання й запис, де стоїть балансувальник, хто тримає підписки на події. Потім поруч піднімається паралельна нода й синхронізується з мережею.
Перенесення нод іде через звірку, а не перемиканням «в лоб». Новий екземпляр порівнюється зі старим на контрольних діапазонах блоків — розходження в стані зупиняє роботу до з'ясування причини.
Збіглося: нода вмикається реплікою тільки на читання, у неї дивляться відставання від мережі й частку помилкових відповідей.
На ходу змінюється все, що лежить вище за рівень зберігання: RPC-ендпоінти, балансувальник, квоти, кеш відповідей, склад реплік читання. Індексатор перебудовується паралельно — новий пише свою базу, старий продовжує віддавати дані. Підписки на події переводяться з перекриттям, щоб клієнт не втратив блок на стику.
Коротке вікно обслуговування потрібне там, де змінюється формат зберігання або роль ноди в мережі. Зміна схеми бази, перенесення основної ноди запису, ротація ключів валідатора й підготовка до мережевого оновлення консенсусу синхронізуються за висотою блока. На цей час сервіс переводиться на репліки: читання не страждає, зупиняється тільки запис.
Вікно вибирається за мінімальною активністю мережі, а на перемиканні завжди залишається зворотний шлях: стару ноду гасять не одразу, а після того як нова відпрацювала без помилок весь період спостереження.
Так модернізація без зупинки перетворюється на регламент — зрозумілий порядок, перевірювані точки й передбачувана поведінка при збої.
Часті технічні сумніви перед стартом робіт
Складнощі в роботі з нодами рідко пов'язані з кодом — вони проявляються на стику навантаження, заліза й меж відповідальності. Зібрали п'ять питань інженерного рівня, які найчастіше ставлять перед стартом.
Що робити, якщо вимоги до обладнання зростуть після запуску?
Закладаємо запас за диском і пам'яттю та описуємо пороги, після яких потрібен інший клас машин. Нода й сервіси доступу масштабуються окремо, тому переробляти всю схему одразу не доводиться.
Хто відповідає за збій після передачі нод?
Передаємо конфігурації, схеми мережі й регламенти, за якими чергова команда відтворює будь-який стан. Окремо фіксуємо зону відповідальності: що закриває наш моніторинг, а що залишається на вашому боці.
Як зрозуміти, де вузьке місце — нода, мережа чи клієнтський доступ?
Рахуємо частинами: час обробки на ноді, затримку каналу й поведінку сервісу доступу під навантаженням. Видно, що масштабувати — сховище, пропускну здатність чи точки підключення.
Що відбувається при піковому навантаженні й розривах зв'язку?
Обмежуємо кількість з'єднань на ноду, додаємо репліки й перепідключення з доганянням блоків. Клієнт не втрачає дані, а нода йде в перевантаження не цілком, а в межах однієї репліки.
Чи потрібно одразу піднімати кілька нод?
Стартуємо з однієї, знімаємо профіль навантаження й додаємо репліки за метриками. Надмірність з'являється тоді, коли вона реально потрібна, а не «про всяк випадок».
Обговоримо задачу: як будується план робіт
План робіт з масштабування блокчейн-інфраструктури будується не на здогадках, а на замірах: без розуміння поточної топології легко оптимізувати не те місце, де реально втрачається пропускна здатність.
Щоб обговорити задачу предметно й повернутися з чесною оцінкою строків, нам потрібні вихідні дані — ось з чого складається розмова.
- Поточна топологія: скільки нод у контурі, які ролі вони несуть (валідувальні, читання, архівні, індексатори), як розміщені й чим пов'язані між собою.
- Профіль навантаження: пікові запити за секунду, частка підписок у реальному часі, добовий і тижневий ритм, поведінка системи в момент піків.
- Що болить зараз: відставання ноди від мережі, обриви з'єднань, зростання диска, розсинхрон індексу, відмови під час віддачі даних.
- Вимоги до доступності: цільовий час відновлення після збою, допустима деградація, чи потрібен відкат на попередній стан.
- Обмеження: де дозволено розміщувати ноди, які хмарні майданчики й юрисдикції допустимі, як видаються доступи й хто відповідає за чергування.
- Критерії приймання: за якими метриками будемо вважати, що стало краще — затримка відгуку, частка втрачених підписок, час довантаження після перезапуску.
У відповідь ви отримуєте схему топології з позначеними точками відмови, розбитий за етапами план робіт, оцінку строків із залежностями й послідовність змін, за якої сервіс залишається доступним на кожному кроці. Якщо даних поки немає — підкажемо, які заміри зняти, щоб картина стала повною.
Опишіть задачу у вільній формі: поточний стан, що перестало справлятися й до якої поведінки хочете прийти. Повернемося з оцінкою, планом і питаннями, які варто закрити до старту.
