Wybór między EC2, ECS a EKS dla zadań Node.js

Gdy nadchodzi czas przeniesienia backendu opartego na Node.js na Amazon Web Services, musimy podjąć decyzję niemal natychmiast. Konsola AWS oferuje co najmniej trzy odrębne produkty obliczeniowe: Amazon EC2, Amazon ECS oraz Amazon EKS.

Gdy zapytasz innych, usłyszysz sprzeczne porady. Niektórzy programiści twierdzą, że zwykła maszyna wirtualna na EC2 to najprostsza i najlepsza opcja. Inni upierają się, że nic nie dorównuje działaniu Kubernetes za pośrednictwem EKS, jeśli chce się mieć naprawdę nowoczesną architekturę. Tymczasem wiele zespołów zajmujących się platformami produkcyjnymi w tajemnicy ustandaryzowało swoje mikrosługi na ECS.

Wybór niewłaściwego narzędzia zwykle prowadzi do jednego z dwóch frustrujących scenariuszy: albo musisz ręcznie naprawiać systemy operacyjne i nadzorować serwery, albo toniesz w plikach konfiguracyjnych Kubernetes tylko po to, by utrzymać w działaniu małą API Express – taką, która może obsługiwać zaledwie kilkadziesiąt żądań na sekundę.

To porównanie odrzuca nadmierną publiczną promocję i koncentruje się bezpośrednio na tym, jak EC2, ECS oraz EKS radzą sobie ze szczególnie aplikacjami Node.js: jakie wymagania stawiają one pod względem operacyjnym przed twoim zespołem oraz jak można wybrać odpowiednią opcję dla danej sytuacji.

Try service wyjaśnione prosto

Zanim porównamy różnice, pomocne jest dokładne określenie, czym jest każdy z tych service’ów.

+-------------------------------------------------------------------------+
|                               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 dostarcza wam maszynę wirtualną, określaną mianem „instance”. Wybieracie system operacyjny – popularnymi opcjami są Ubuntu i Amazon Linux – logujecie się przez SSH, instalujecie Node.js wraz z menedżerem procesów takim jak PM2, a następnie sami uruchamiacie swoją aplikację.

Wszystko, począwszy od jądra, znajduje się pod waszym bezpośrednim kontrolowaniem.

2. Amazon ECS (Elastic Container Service)

ECS to własny system AWS do zarządzania kontenerami Docker. Zamiast bezpośrednio administrować systemem operacyjnym, budujecie swoją aplikację Node.js jako obraz Dockera i instruujecie ECS, aby utrzymywało w działaniu określoną liczbę kopii tego kontenera – na przykład cztery repliki.

Jeśli połączysz ECS z AWS Fargate, warstwą obliczeniową typu serverless, całkowicie uwolnisz się od konieczności zarządzania serwerami znajdującymi się pod kontenerami. AWS automatycznie przydziela CPU i pamięć dla każdego kontenera w zależności od zapotrzebowania.

3. Amazon EKS (Elastic Kubernetes Service)

EKS oferuje zarządzane klastry Kubernetes na bazie infrastruktury AWS. Sam Kubernetes to standard otwartego oprogramowania do orkiestracji kontenerów, który powstał w Google.

Dzięki EKS AWS przejmuje odpowiedzialność za płaszczyznę sterowania Kubernetes – węzły główne – natomiast ty nadal jesteś odpowiedzialny za definiowanie podów, implementacji, usług, reguł ingress oraz polityk sieciowych.

Dlaczego cechy Node.js są tu ważne

Zanim zdecydujesz się na dany serwis, warto przypomnieć sobie kilka faktów dotyczących sposobu działania Node.js:

• Eksploatacja JavaScript jest jednowątkowa: proces Node.js wykorzystuje zawsze tylko jeden rdzeń CPU do uruchamiania kodu JS. Jeśli umieścisz jeden proces na instancji EC2 z 8 rdzeniami, siedem z nich pozostanie nieużywanych, chyba że wyraźnie uruchomisz klastr procesów lub rozproszyz pracę między kilkoma instancjami.
• Rozruch jest szybki, a zużycie zasobów niewielkie: aplikacja Node.js w formacie kontenera zazwyczaj jest gotowa do działania w mniej niż dwie sekundy, co sprawia, że doskonale pasuje do środowisk opartych na kontenerach i automatycznym skalowaniu.
• Zadania są zazwyczaj uzależnione od operacji wejścia/wyjścia: większość usług Node.js spędza większość czasu na czekaniu na bazy danych, zewnętrzne wywołania API lub operacje dyskowe, zamiast wykonywać intensywne obliczenia na CPU.

Te cechy mają bezpośredni wpływ na to, na jak proste – lub trudne – okaże się skalowanie w każdym z tych trzech usług.

1. Amazon EC2: maksymalna kontrola, intensywna konserwacja

Praca z EC2 przypomina bardzo rozwijanie oprogramowania na własnym komputerze z systemem Linux, ponieważ w istocie jest to taki sam komputer.

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

Zalety:

• Przewidywalne ceny: płacisz stałą stawkę godzinową zależną od wybranej wielkości instancji.
• Pełny dostęp do systemu: możesz przeglądać logi systemowe, dostosowywać parametry jądra za pomocą sysctl lub instalować wszystkie niezbędne biblioteki natywne dla twojego aplikacji.

Koszty:

Rozwijanie aplikacji produkcyjnych na EC2 wiąże się z koniecznością intensywnej konserwacji. Musisz zajmować się:

• Stosowaniem aktualizacji bezpieczeństwa systemu operacyjnego.

wdrażanie aktualizacji środowiska Node.js na wszystkich instancjach.

zarządzanie grupami automatycznego skalowania oraz tworzenie obrazów maszyn (AMI).

ponowne uruchamianie procesów, które uległy awarii, oraz wykrywanie wycieków pamięci w usługach działających przez długi czas.

Praktyczna wskazówka dla programistów: EC2 sprawdza się dobrze przy pojedynczej aplikacji monolitycznej, która nie zmienia się zbyt często. Jednak gdy uruchamiasz trzy lub cztery mikrosłużby, rozproszenie ich na oddzielnych instancjach EC2 albo marnuje zasoby, albo zmusza do używania skomplikowanej konfiguracji serwera współdzielonego.

2. Amazon ECS: Optymalne rozwiązanie dla większości zespołów

Jeśli twoja aplikacja Node.js znajduje się już w kontenerze Docker, ECS jest zazwyczaj najskuteczniejszym rozwiązaniem w AWS.

Napisanie pliku Dockerfile o standardzie produkcyjnym dla Node.js nie zajmuje wiele czasu:

# 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"]

Gdy tylko umieścisz tę obrazek w Amazon ECR (Elastic Container Registry), tworzysz definicję zadań ECS, która określa:

• Przypisanie zasobów CPU (na przykład 0,5 vCPU) oraz pamięci (na przykład 1 GB) dla kontenera.
• Zmienne środowiskowe pobierane z AWS Secrets Manager lub Parameter Store.
• Końce punktów kontrolnych stanu.

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)

Dlaczego ECS z Fargate jest doskonały dla Node.js:

Kombinacja ECS z Fargate całkowicie eliminuje warstwę serwerową — nie musisz zarządzać żadnymi instancjami EC2.

Gdy ruch sieciowy gwałtownie rośnie, ECS może uruchomić pięć nowych zadań w ciągu kilku sekund. Ponieważ procesy Node.js zajmują niewiele zasobów, można dostosowywać moc obliczeniową w małych krokach (0,25 vCPU i 512 MB RAM), co utrzymuje zdolności przetwarzania i koszty bliskie zeru.

Kompromisy:

• Związanie z AWS: konfiguracja ECS jest specyficzna dla AWS. Definicja zadań w formacie JSON napisana dla ECS nie będzie mogła zostać przeniesiona do Google Cloud lub Azure bez dodatkowej pracy.
• Bardziej ograniczony ekosystem narzędzi: ECS łączy się dobrze z CloudWatch i IAM, ale nie posiada nawet w przybliżeniu tak rozbudowanego ekosystemu plugini od firm trzecich, jaki istnieje wokół Kubernetes.

3. Amazon EKS: skalowalność na poziomie przedsiębiorstwa i przenośność

EKS to usługa zarządzana Kubernetes oferowana przez AWS. Kubernetes idzie dalej niż zwykłe uruchamianie kontenerów — dostarcza wspólną platformę do zarządzania siecią, odkrywania usług, implementacji w trybie rotacyjnym oraz przechowywania poufnych danych.

W EKS implementacja w Node.js jest opisywana za pomocą manifestów 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

Zalety:

• Prawdziwa przenośność: te same pliki YAML będą działać w EKS, GKE firmy Google, AKS firmy Azure lub na serwerach w twoim własnym centrum danych.
• Szeroki ekosystem: narzędzia takie jak Helm, ArgoCD, Prometheus i Istio integrują się za pomocą standardowej konfiguracji.
• Dokładna kontrola skalowania automatycznego: możesz skalować kontenery na podstawie własnych metryk — takich jak liczba wiadomości w kolejce SQS lub rozmiar bufora Redis — przy użyciu KEDA (Kubernetes Event-driven Autoscaling).

Koszty i ograniczenia:

Kubernetes niesie ze sobą również znaczne obciążenie operacyjne:

• Koszt płaszczyzny sterowania: EKS pobiera około 73 dolarów miesięcznie za klaster tylko na utrzymanie płaszczyzny sterowania, nie licząc kosztów węzłów roboczych i uruchamiania kontenerów.

Dostojna krzywa uczenia się: zespół musi posiadać praktyczną wiedzę na temat kontrolerów Ingress, CoreDNS, Cluster Autoscaler, plugini CNI oraz zasad RBAC.

Powszechny błąd: Zespoły czasami decydują się na EKS wyłącznie dlatego, że Kubernetes jest standardem w branży. Dla małego zespołu inżynierskiego — składającego się z mniej niż 15 programistów — utrzymanie działającego klastra Kubernetes może pochłonąć od 20 do 30 procent tygodnia doświadczonego inżyniera, czasu, który mógłby zostać przeznaczony na sam produkt.

Direktywne porównanie

Wysoki Ciągła konserwacja Wysoki (naprawy, system operacyjny, bezpieczeństwo) Bardzo niski Wysoki (utrzymanie klastra) Bazowy koszt w stanie spoczynku Niski (około 3–15 dolarów/miesiąc dla instancji t4g lub t3) Płacisz tylko za zadania, które faktycznie są uruchamiane Około 73 dolarów/miesiąc za warstwę sterującą, plus obliczenia Szybkość skalowania Minuty (musi uruchomić się pełna maszyna wirtualna) Sekundy (pobierana jest obraz i rozpoczyna się zadanie) Sekundy (planowany jest pod) Przenośność między chmurami Niski Niski (związany z AWS) Wysoki (standard Kubernetes) Idealna wielkość zespołu Jednoosobowi programiści lub małe systemy starsze Od 2 do 50 inżynierów Dedykowana platforma lub zespół DevOps

Praktyczny sposób podjęcia decyzji

Zamiast dręczyć się każdą funkcją, skorzystaj z tej prostej zasady ogólnej:

Wybierz EC2, gdy:

• Twoja aplikacja Node.js jest starsza i polega na lokalnych demonach w tle, oprogramowaniu specyficznym dla systemu operacyjnego lub plikach, które muszą pozostać na lokalnym dysku.
• Tworzysz tymczasowy prototyp na serwerze za 5 dolarów miesięcznie, gdzie cena jest jedyną istotną kwestią.

Wybierz ECS z Fargate, gdy:

• Chcesz uruchamiać nowoczesne, kontenerizowane usługi Node.js bez konieczności obsługi podstawowego systemu operacyjnego.
• Twoja zespół składa się z inżynierów backendu bez dedykowanego specjalisty od infrastruktury lub DevOps.
• Jesteś w pełni zaangażowany w ekosystem AWS (DynamoDB, SQS, RDS, IAM) i chcesz integrację bezpieczeństwa, która działa od razu po wdrożeniu.
• Ta konfiguracja pasuje mniej więcej do 80 procent firm budujących na AWS, co czyni ją rozsądnym standardem.

Wybierz EKS, gdy:

• Zarządzasz dziesiątkami lub setkami mikrosług w różnych językach programowania, takich jak Node.js, Go, Python i Java.
• Twoja organizacja wymaga podejścia typu multi-cloud lub hybrid-cloud, które wymaga spójnych narzędzi wszędzie.
• Masz już platformę lub zespół SRE zdolny do bezpiecznego monitorowania, zabezpieczania i aktualizacji klastrów Kubernetes.

Podsumowanie

Dobra architektura chmury nie polega na wyborze najbardziej efektownej dostępnej technologii; chodzi o wybór rozwiązania, które rozwiązuje problem przy minimalnych kosztach konserwacji.

Jeśli chodzi konkretnie o Node.js:

• EC2 daje pełną kontrolę, ale obciąża Cię rutynową konserwacją serwerów.
• EKS oferuje ogromną moc oraz możliwość przenoszenia się pomiędzy ekosystemami, ale kosztem rzeczywistej złożoności i dodatkowych obciążeń związanych z zarządzaniem klastrami.
• ECS z Fargate eliminuje konieczność obsługi serwerów, skaluje kontenery w ciągu sekund i umożliwia programistom skupienie się na tworzeniu solidnego kodu w Node.js.

Rozsądne podejście to rozpoczęcie od małych kroków: umieść swoją aplikację w lekkim kontenerze Dockera, uruchom ją najpierw na ECS, a przenieś się do Kubernetes dopiero wtedy, gdy twoja organizacja naprawdę tego potrzebuje. Ponieważ sam kontener się nie zmienia, jest już przygotowany do pracy w EKS, gdy nadejdzie ten dzień.