Вибір між EC2, ECS та EKS для завдань на Node.js

Коли настає час перенести бекенд на Node.js на Amazon Web Services, доводиться майже негайно приймати рішення. Консоль AWS пропонує щонайменше три окремі продукти обчислювальних ресурсів: Amazon EC2, Amazon ECS та Amazon EKS.

Якщо запитати інших, ви отримаєте суперечливі поради. Деякі розробники стверджують, що звичайна віртуальна машина на EC2 — це найпростіший та найкращий варіант. Інші наполягають на тому, що ніщо не може замінити використання Kubernetes через EKS, якщо потрібна справді сучасна архітектура. Тим часом багато команд, які працюють з продакшн-платформами, тихо стандартизувалися на ECS для всіх своїх мікросервісів.

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

Це порівняння відкидає всю рекламу та безпосередньо аналізує, як EC2, ECS та EKS підходять саме для додатків на Node.js: які вимоги кожен з них ставить до роботи вашої команди та як ви можете обрати найкращий варіант для своєї ситуації.

Три сервіси пояснені просто

Перш ніж порівнювати переваги та недоліки, корисно чітко визначити, що саме являє собою кожен сервіс.

+-------------------------------------------------------------------------+
|                               Amazon EKS                                |
|   Fully managed Kubernetes. High control, high complexity, multi-cloud. |
+-------------------------------------------------------------------------+
                                    ▲
                                    │ Built for complex orchestration
+-------------------------------------------------------------------------+
|                               Amazon ECS                                |
|   AWS-native container orchestration. Fast, simple, deeply integrated.  |
+-------------------------------------------------------------------------+
                                    ▲
                                    │ Built for containers
+-------------------------------------------------------------------------+
|                               Amazon EC2                                |
|   Raw virtual machines in the cloud. Full OS access, manual maintenance.|
+-------------------------------------------------------------------------+

1. Amazon EC2 (Elastic Compute Cloud)

EC2 надає вам віртуальну машину, яку називають „інстанцією“. Ви обираєте операційну систему — поширеними варіантами є Ubuntu та Amazon Linux — уходите підключенням через SSH, встановлюєте Node.js разом із менеджером процесів на кшталт PM2 та самостійно запускаєте своє застосунок.

Усе, що знаходиться вище ядра, знаходиться під вашим прямим контролем.

2. Amazon ECS (Elastic Container Service)

ECS — це власна система AWS для оркестрації контейнерів Docker. Замість прямого керування операційною системою ви створюєте свій застосунок на Node.js у вигляді образу Docker та даєте вказівку ECS підтримувати певну кількість працюючих та справних копій цього контейнера — скажімо, чотири репліки.

Якщо поєднати ECS із AWS Fargate, його безсерверним шаром обчислень, ви повністю звільняєтесь від необхідності керувати серверами, які знаходяться під контейнерами. AWS автоматично виділяє CPU та пам’ять для кожного контейнера в залежності від навантаження.

3. Amazon EKS (Elastic Kubernetes Service)

EKS надає керовані кластери Kubernetes на основі інфраструктури AWS. Сам Kubernetes — це стандарт оркестрації контейнерів з відкритим кодом, який був створений у Google.

За допомогою EKS AWS бере на себе відповідальність за контрольний план Kubernetes — мастер-вузли, тоді як ви все ще несете відповідальність за визначення подів, розгортань, сервісів, правил входу та мережевих політик.

Чому тут важливі характеристики Node.js

Перш ніж обрати певний сервіс, варто згадати кілька моментів щодо того, як насправді працює Node.js:

• Виконання JavaScript відбувається у одному потоці: процес Node.js використовує лише один ядро CPU для запуску вашого JS-коду. Якщо розмістити один процес на інстанції EC2 з 8 ядрами, сім з них залишаться невикористаними, якщо ви не запустите спеціально кластер процесів чи не розподілите роботу між кількома інстанціями.
• Швидке запуск та невеликі вимоги до ресурсів: додаток Node.js у контейнері зазвичай може почати працювати менш ніж за дві секунди, що робить його ідеальним для середовищ, побудованих на основі контейнерів та автомасштабування.
• Робочі навантаження здебільшого є I/O-орієнтованими: більшість сервісів Node.js проводять більшу частину часу у очікуванні від баз даних, зовнішніх API-запитів чи операцій з диском, а не виконуючи інтенсивні обчислення на CPU.

Ці характеристики безпосередньо впливають на те, наскільки простим — або складним — буде масштабування у кожному з трьох сервісів.

1. Amazon EC2: максимальний контроль, інтенсивне технічне обслуговування

Робота з EC2 дуже схожа на розробку на власному Linux-сервері, адже по суті це і є такий сервер.

Bash

# Typical manual setup on an EC2 instance:
sudo apt update && sudo apt install -y nodejs npm
git clone https://github.com/your-org/api.git
cd api && npm ci --omit=dev
npm install -g pm2
pm2 start app.js -i max

Traffic ──> Application Load Balancer (ALB)
                 │
        ┌────────┴────────┐
        ▼                 ▼
   [EC2 Instance]    [EC2 Instance]
   ├─ Node Process   ├─ Node Process
   ├─ Node Process   ├─ Node Process
   └─ PM2 Manager    └─ PM2 Manager

Переваги:

• Прогнозована ціна: ви платите фіксовану годинну ставку, залежну від обраного розміру інстанції.
• Повний доступ до системи: ви можете переглядати журнали системи, налаштовувати параметри ядра за допомогою sysctl чи встановлювати будь-які нативні бібліотеки, необхідні вашому додатку.

Недоліки:

Робота з вантажем у продакшені на EC2 потребує значних зусиль у технічному обслуговуванні. Ви несете відповідальність за:

• Застосування патчів безпеки операційної системи.

Впровадження оновлень середовища виконання Node.js на кожній інстанції.

Підтримка груп автоматичного масштабування та створення образів машин (AMI).

Перезапуск зламаних процесів та усунення витоків пам’яті у довгострокових сервісах.

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

2. Amazon ECS: ідеальний вибір для більшості команд

Якщо ваш додаток на Node.js вже знаходиться у контейнері Docker, ECS, як правило, є найефективнішим варіантом у AWS.

Написати кодовий файл Dockerfile для продакшн-додатку на Node.js не складно:

# Multi-stage Dockerfile for Node.js
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:20-alpine
WORKDIR /app
ENV NODE_ENV=production
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]

Як тільки ви завантажите це зображення до Amazon ECR (Elastic Container Registry), ви створюєте ECS Task Definition, яка визначає:

• Розподіл CPU (наприклад, 0.5 vCPU) та пам’яті (наприклад, 1 GB) для контейнера.
• Змінні середовища, отримані з AWS Secrets Manager або Parameter Store.
• Кінцеві точки перевірки стану.

Traffic ──> ALB
             │
             ├── Path /api/users ──> [ECS Task: Users] (0.5 vCPU)
             └── Path /api/orders ─> [ECS Task: Orders] (0.5 vCPU)
                                     [ECS Task: Orders] (0.5 vCPU)

Чому ECS з Fargate ідеально підходить для Node.js:

Поєднання ECS з Fargate повністю усуває серверний шар — немає потреби керувати базовими інстанцями EC2.

Під час сплеску трафіку ECS може створити п’ять нових завдань протягом кількох секунд. Оскільки процеси Node.js використовують мало ресурсів, можна налаштовувати обчислювальні ресурси у дрібних порціях (0.25 vCPU та 512 MB RAM), що дозволяє тримати неактивну потужність — та витрати — майже на рівні нуля.

Компроміси:

• Залежність від AWS: конфігурація ECS є специфічною для AWS. JSON-опис завдань, який ви створюєте для ECS, не може бути перенесений до Google Cloud чи Azure без додаткової роботи.
• Обмежена екосистема інструментів: ECS гармонійно інтегрується з CloudWatch та IAM, але у нього значно менше екосистеми сторонніх плагінів, ніж у Kubernetes.

3. Amazon EKS: масштабування та портативність на рівні корпорацій

EKS — це сервіс Kubernetes під управлінням AWS. Kubernetes дозволяє не лише запускати контейнери, а й надає спільну платформу для мережевих з’єднань, виявлення сервісів, поступового розгортання та керування конфіденційними даними.

У EKS розгортання Node.js описується за допомогою маніфестів Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: node-api
  template:
    metadata:
      labels:
        app: node-api
    spec:
      containers:
      - name: node-api
        image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/node-api:v1.2.0
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "250m"
            memory: "256Mi"
        ports:
        - containerPort: 3000

Переваги:

• Справжня портативність: ті самі YAML-маніфести будуть працювати в EKS, GKE від Google, AKS від Azure чи на серверах у вашому власному дата-центрі.
• Широка екосистема: інструменти на кшталт Helm, ArgoCD, Prometheus та Istio інтегруються за допомогою стандартної конфігурації.
• Точний контроль автомасштабування: ви можете масштабувати поди на основі користувацьких метрик — таких як кількість повідомлень у черзі SQS чи розмір буфера Redis — за допомогою KEDA (Kubernetes Event-driven Autoscaling).

Компроміси:

Kubernetes також створює значний операційний тягар:

• Витрати на план керування: EKS стягує приблизно 73 долари на місяць за кластер лише для підтримки роботи плану керування, окремо від витрат на робочі вузли та запуск контейнерів.

Крута крива навчання: вашій команді потрібні практичні знання щодо контролерів Ingress, CoreDNS, Cluster Autoscaler, плагінів CNI та правил RBAC.

Поширена помилка: Іноді команди обирають EKS лише через те, що Kubernetes є стандартом у галузі. Для невеликої інженерної команди — з менше ніж 15 розробниками — підтримка роботи кластера Kubernetes може зайняти від 20 до 30 відсотків часу старшого інженера на тиждень, час, який інакше можна було б використати на розробку самого продукту.

Пряме порівняння

Високий Постійне технічне обслуговування Високий (виправлення помилок, ОС, безпека) Дуже низький Високий (підтримка кластера) Базові витрати у неактивному стані Низькі (приблизно 3–15 доларів/місьця для інстанцій t4g або t3) Ви платите лише за завдання, які фактично виконуються Приблизно 73 долари/місьця за контрольну платформу, плюс обчислення Швидкість масштабування Хвилини (необхідно завантажити повну віртуальну машину) Секунди (завантажується образ та починається завдання) Секунди (под отримує розклад) Переносимість між хмарами Низький Низький (пов’язаний з AWS) Високий (стандарт Kubernetes) Ідеальний розмір команди Один розробник або невеликі системи старого типу Від 2 до 50 інженерів Спеціалізована платформа або група DevOps

Практичний спосіб прийняття рішення

Замість того, щоб мучитися через кожну функцію, скористайтеся цим простим критерієм:

Обирайте EC2, коли:

• Ваша додаток на Node.js є застарілою та залежить від локальних фонових демонів, програмного забезпечення, специфічного для операційної системи, або файлів, які мають зберігатися на локальному диску.
• Ви створюєте тимчасовий прототип на сервері за $5 на місяць, де єдиним важливим фактором є ціна.

Обирайте ECS з Fargate, коли:

• Ви хочете запускати сучасні, контейнеризовані сервіси на Node.js без необхідності контролю за операційною системою.
• У вашій команді є інженери бекенду без спеціаліста з інфраструктури чи DevOps.
• Ви повністю орієнтуєтесь на екосистему AWS (DynamoDB, SQS, RDS, IAM) та хочете інтеграцію безпеки, яка працює автоматично.
• Ця конфігурація підходить приблизно для 80 відсотків компаній, які працюють з AWS, тому є розумним стандартом.

Обирайте EKS, коли:

• Ви керуєте десятками чи сотнями мікросервісів, створених на різних мовах програмування, таких як Node.js, Go, Python та Java.
• У вашій організації вимагається підхід багатохмарності чи гібридної хмарності, який потребує єдиних інструментів у всіх середовищах.
• У вас вже є платформа чи команда SRE, здатна ефективно відстежувати, захищати та оновлювати кластери Kubernetes.

Підсумок

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

Щодо Node.js зокрема:

• EC2 надає вам повний контроль, але змушує брати на себе рутинне обслуговування серверів.
• EKS забезпечує величезні можливості та здатність переміщуватися між екосистемами, але це супроводжується значною складністю та додатковими витратами на керування кластером.

ECS з Fargate звільняє вас від турбот про сервери, швидко масштабує контейнери протягом кількох секунд та дозволяє розробникам зосередитися на створенні якісного коду на Node.js.

Розумний підхід — почати з малого: запакуйте свій додаток у легкий Docker-контейнер, спочатку запустіть його на ECS, а лише пізніше перейдіть на Kubernetes, якщо ваша організація справді переросте цей інструмент. Оскільки сам контейнер не змінюється, він вже готовий до використання в EKS у момент, коли це станеться.