41장. 왜 컨테이너인가 — VM과의 차이

이 장에서 말하고자 하는 것

지금까지 우리는 EC2 위에 애플리케이션을 띄우는 그림을 그렸다.

그런데 운영해보면 EC2만으로 부족한 지점이 보인다.

이걸 한 번에 풀어주는 게

컨테이너 (Container)

이고 표준 도구가

Docker

다.

[하드웨어] → [Hypervisor] → [Guest OS] → [App]

OS 자체를 통째로 만든다. 무겁고 부팅이 느리다.

[하드웨어] → [Host OS] → [Container = 프로세스 격리] → [App]

OS는 공유하고 프로세스만 격리한다.
수십 MB, 초 단위 부팅.

"내 컴퓨터에서는 잘 됐는데..."

이미지에 OS · 런타임 · 라이브러리 · 코드를 다 담는다.
어디서든 동일하게 실행된다.

docker run my-app:v2

EC2 새로 띄우는 것보다 압도적으로 빠르다.

한 머신에 여러 컨테이너를 띄워도 런타임 충돌이 없다.

빌드 → 이미지 → 실행이 표준이라
ECS · EKS · K8s 어디서든 같은 이미지가 돈다.

척추 그림이 이 단원에서 바뀐다.

이전:
  ALB → EC2 (애플리케이션 직접 설치)

지금부터:
  ALB → ECS (Fargate) → 컨테이너 안의 애플리케이션

같은 트래픽 분배 구조에서 “서버” 가 “컨테이너” 로 바뀐 것이다.

docker run -p 8080:8080 nginx

8080 포트로 nginx가 즉시 뜬다. 이게 컨테이너의 첫 모습이다.

FROM node:20-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 8080
CMD ["node", "server.js"]

이 파일이 곧 컨테이너 이미지의 설계도다. 다음 장에서 자세히 다룬다.

컨테이너 죽으면 데이터도 사라진다.

영구 데이터는 RDS · S3 · EFS 같은 외부 저장소로

한 컨테이너 = 한 프로세스

배포마다 다른 이미지가 떨어진다. 롤백 불가.

항상 명시적 버전 태그 (커밋 해시 · 시맨틱 버전)

FROM ubuntu:22.04 (70MB+) 대신
FROM node:20-alpine (50MB) 또는 distroless 베이스를 쓴다.

컨테이너는 환경을 패키징해 어디서든 같게 돌리는 표준이며,
MSA가 자연스럽게 위에 올라타는 토대다