Сучасні додатки Node.js повинні обробляти сотні тисяч запитів з мінімальною затримкою. Два найпопулярніші механізми масштабування – вбудований cluster та менеджер процесів PM2. У цій статті розкладаємо їхню роботу на складові, вимірюємо вплив на продуктивність і описуємо, коли обрати одне рішення замість іншого.
Як працює Node.js Cluster?
Модуль cluster є частиною стандартної бібліотеки Node.js. Він створює групу робочих процесів (worker‑ів), які спільно використовують один і той самий TCP‑порт завдяки механізму master‑worker. Master приймає з’єднання і розподіляє їх по черзі (round‑robin) або за алгоритмом os.sched залежно від платформи.
Приклад реалізації:
const cluster = require('cluster');
const http = require('http');
const numCPUs = require('os').cpus().length;
if (cluster.isMaster) {
console.log(`Master ${process.pid} стартує`);
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
cluster.on('exit', (worker, code, signal) => {
console.log(`Worker ${worker.process.pid} помер, перезапускаю`);
cluster.fork();
});
} else {
http.createServer((req, res) => {
res.writeHead(200);
res.end('Hello from worker ' + process.pid);
}).listen(3000);
}
Ключові особливості:
- Відсутність зовнішніх залежностей – працює з Node 0.8.
- Автоматичний перезапуск окремого процесу після збою.
- Спільний доступ до пам’яті неможливий – кожен worker має власну heap.
Що пропонує PM2?
PM2 – це менеджер процесів, написаний на Node.js, доступний як npm‑пакет. Окрім простого запуску багатьох інстанцій, PM2 забезпечує:
- Load balancing за допомогою вбудованого модуля
cluster_mode(на базі того ж API, що іcluster). - Zero‑downtime reload (команда
pm2 reload). - Моніторинг у реальному часі (PM2‑Monit, Keymetrics).
- Вбудований watchdog, logrotate та підтримка systemd.
Базова конфігурація у файлі ecosystem.config.js:
module.exports = {
apps: [{
name: 'api',
script: './src/server.js',
instances: 'max', // використовує всі ядра
exec_mode: 'cluster',
watch: false,
env: { NODE_ENV: 'production' }
}]
};
Після запуску pm2 start ecosystem.config.js менеджер піклується про перезапуск, масштабування та звітування.
Продуктивність Cluster vs PM2 у продакшн
Щодо чистої пропускної здатності різниця мінімальна, оскільки PM2 у режимі cluster використовує саме той самий механізм Node.js. Основні фактори, що впливають на результати:
- Навантаження комунікації з master‑ом – PM2 додає IPC‑шар для моніторингу, що в найгіршому випадку збільшує використання CPU на ~2‑3% при високому QPS.
- Стратегія перезапуску – PM2 може виконувати graceful reload без втрати з’єднань, що важливо для безперервної доступності.
- Управління пам’яттю – PM2 дозволяє автоматично обмежувати пам’ять (
max_memory_restart), що знижує ризик витоків у довготривалих процесах.
У практичних тестах (наприклад, 100 000 GET‑запитів /api за 30 s) різниця в середньому часі відповіді склала 1‑2 ms на користь чистого cluster, проте PM2 забезпечив стабільніший результат при випадкових збоях worker‑ів.
Коли використовувати Cluster, а коли PM2?
Node.js Cluster – хороший вибір, коли:
- Потрібен мінімальний стек залежностей і хочемо контролювати кожну деталь коду master‑а.
- Додаток простий, а процеси не потребують розширеного моніторингу.
- Середовище запуску не дозволяє встановлювати додаткові пакети (наприклад, контейнери дуже малого розміру).
PM2 підходить, коли:
- Необхідний zero‑downtime deploy і автоматичний перезапуск після перевищення ліміту пам’яті.
- Хочемо централізовано моніторити використання ресурсів і мати доступ до дашборду.
- Проект розподілений і потрібна інтеграція з системою ініціалізації (systemd, upstart).
Практичний чек‑лист впровадження
- Перевірте кількість доступних CPU (
os.cpus().length) і встановіть кількість worker‑ів рівною цій величині або'max'у PM2. - Визначте ліміт пам’яті (
max_memory_restartу PM2 або власний watchdog у Cluster) – типово 300 MiB для API‑процесів. - Налаштуйте логування – PM2 підтримує ротацію, у Cluster треба самостійно перенаправляти
stdout/stderr. - Протестуйте сценарій збою: вбийте один worker і спостерігайте, чи master/PM2 автоматично його відновить.
- Zero‑downtime впровадження: у PM2 використайте
pm2 reload, у чистому Cluster реалізуйтеcluster.disconnect()іcluster.fork()вручну.
Типові пастки та компроміси
1. Використання одного процесу на CPU – у деяких випадках кращими є два воркери на ядро, коли застосунок є I/O‑bound і не використовує повністю CPU. Однак це збільшує навантаження на пам'ять.
2. Відсутність ліміту пам'яті – і Cluster, і PM2 за замовчуванням не перезапускають процес при витоку пам'яті. У PM2 можна задати max_memory_restart, у Cluster потрібно моніторити process.memoryUsage() і вручну форкати.
3. Логи в режимі кластеру – без централізованого збору логів (наприклад, Winston + транспорт до Elastic) важко аналізувати проблеми у виробничому середовищі.
«Вибір між Cluster та PM2 не є питанням «краще vs гірше», а підбором інструменту до операційних та командних вимог.»
Підсумок і подальші кроки
Node.js Cluster і PM2 пропонують подібний фундамент масштабування, але відрізняються за функціональними можливостями. Якщо потрібен повний контроль і мінімальне навантаження, оберіть чистий cluster. Коли важлива автоматизація, моніторинг і безпроблемне розгортання, PM2 – природний вибір. В обох випадках ключовим є свідоме управління кількістю воркерів, лімітами пам'яті та стратегією перезапуску.
Є питання щодо впровадження масштабування у вашій інфраструктурі? Зв'яжіться з Coderia.it – ми допоможемо підібрати оптимальне рішення та здійснити його безпечну реалізацію.
