Выбор между 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 автоматически выделяет процессорные ресурсы и память для каждого контейнера в зависимости от нагрузки.

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 в контейнере обычно может быть запущено менее чем за две секунды, что делает его идеальным вариантом для сред, построенных на контейнерах и автомасштабировании.
• Работа часто связана с операциями ввода-вывода: большая часть времени у большинства сервисов 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, в котором указываются следующие параметры:

• Размер выделения 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, когда наступит такой момент.