EC2 + Docker가 ECS보다 나았던 작은 규모의 선택

AWS 실전 운영 시리즈 7/12

컨테이너를 운영한다고 하면 ECS나 EKS를 먼저 떠올릴 수 있다.

AWS에서 컨테이너를 운영하는 표준적인 방법이고, 오토스케일링과 배포 관리에도 강하다.

하지만 모든 컨테이너 워크로드에 처음부터 오케스트레이션이 필요한 것은 아니다.

작은 운영 콘솔의 상주 API 서버라면 EC2 한 대에 Docker로 운영하는 방식이 더 단순할 수 있다.

문제 상황

운영 콘솔 일부 API는 Lambda보다 상주 서버가 더 적합했다.

이 API들은 다음 특성이 있었다.

• 대시보드 조회처럼 짧고 잦은 요청
• DB connection pool 유지 필요
• 내부 인증 쿠키 처리
• 낮은 지연 시간 필요
• 무거운 배치 작업과 분리 필요

Lambda만으로 처리하면 cold start와 DB connection storm이 걱정되었다.

그래서 Node.js Express 서버를 별도로 두었다.

문제는 이 서버를 어디에서 운영할 것인가였다.

선택지

선택지는 세 가지였다.

1. EC2에 직접 Node process 실행
2. EC2 + Docker
3. ECS/Fargate

직접 Node process를 실행하는 방식은 가장 단순하지만, 배포와 환경 일관성이 약하다.

ECS/Fargate는 관리형 컨테이너 운영에 좋지만, 단일 서버 단일 컨테이너 규모에서는 설정과 개념이 늘어난다.

그래서 중간 선택으로 EC2 + Docker를 택할 수 있다.

판단 기준은 "컨테이너냐 서버리스냐"가 아니라 워크로드의 모양이었다.

처음부터 ECS를 쓰지 않았더라도 Docker 이미지를 기준으로 배포하면 나중에 이동 경로가 남는다.

EC2 + Docker의 장점

EC2 + Docker는 작은 규모에서 균형이 좋다.

• 컨테이너 이미지로 실행 환경을 고정할 수 있다.
• 서버는 한 대만 운영하면 된다.
• Docker restart로 복구가 단순하다.
• 나중에 ECS로 옮길 때 이미지 기반 배포를 유지할 수 있다.
• 오케스트레이션 설정을 당장 도입하지 않아도 된다.

즉, 애플리케이션은 컨테이너화하되 운영 플랫폼은 단순하게 시작하는 방식이다.

ECS가 과할 수 있는 경우

ECS/Fargate가 과할 수 있는 조건은 다음과 같다.

• 컨테이너가 하나뿐이다.
• 트래픽이 내부 사용자 중심이다.
• 오토스케일링이 당장 필요 없다.
• 무중단 배포가 절대 요구사항은 아니다.
• 운영자가 인프라 복잡도를 줄이고 싶다.
• 비용보다 단순성이 중요하다.

이런 조건에서는 ECS의 장점보다 학습과 설정 비용이 더 크게 느껴질 수 있다.

물론 서비스가 커지면 이야기가 달라진다.

Docker를 쓰는 이유

EC2를 쓰더라도 Docker를 쓰면 장점이 있다.

첫째, 실행 환경이 고정된다.

Node 버전, package 설치, 환경 변수를 container 기준으로 관리할 수 있다.

둘째, 배포 단위가 명확하다.

이미지를 build하고 push하고 run한다.

셋째, 나중에 ECS로 이전하기 쉽다.

이미 Dockerfile과 이미지 레지스트리를 쓰고 있다면, 운영 플랫폼만 바꾸면 된다.

넷째, 롤백이 단순해진다.

이전 이미지 tag로 다시 실행할 수 있다.

EC2 + Docker 운영에서 필요한 것

단순하다고 해서 아무 것도 필요 없는 것은 아니다.

다음은 반드시 있어야 한다.

• Dockerfile
• 이미지 build/push 절차
• EC2에서 container 실행 스크립트
• 환경 변수 관리
• 로그 확인 방법
• health check endpoint
• 재시작 방법
• 이전 이미지로 롤백하는 방법

이 정보는 운영 문서에 남겨야 한다.

단일 EC2의 한계

EC2 한 대는 단순하지만 한계가 있다.

• 인스턴스 장애에 취약하다.
• 오토스케일링이 없다.
• 무중단 배포가 어렵다.
• 배포 중 잠깐의 중단이 있을 수 있다.
• OS 패치 책임이 있다.
• 모니터링과 백업을 직접 챙겨야 한다.

이 한계를 알고 선택해야 한다.

작은 내부 도구에서는 감수할 수 있는 한계일 수 있다.

하지만 외부 사용자 트래픽이 커지거나 SLA가 중요해지면 ECS/Fargate 또는 ALB 기반 다중 인스턴스 구성을 검토해야 한다.

언제 ECS로 옮길까

다음 조건이 생기면 ECS/Fargate 이전을 검토할 수 있다.

• 컨테이너가 여러 개로 늘어난다.
• 무중단 배포가 필요하다.
• 트래픽에 따라 scale-out이 필요하다.
• 한 대 장애가 서비스 중단으로 이어지면 안 된다.
• 배포 빈도가 높아진다.
• 운영자가 서버 패치를 직접 관리하기 어렵다.
• task definition 기반으로 환경을 표준화하고 싶다.

처음부터 ECS로 가지 않은 것은 ECS를 부정한 것이 아니다.

지금 규모에서 다음 단계로 남겨둔 것이다.

Lambda와 EC2의 역할 분리

상주 API 서버를 두더라도 모든 백엔드를 EC2로 옮길 필요는 없다.

짧고 잦은 조회는 EC2가 맡고, 드물고 무거운 작업은 Lambda가 맡을 수 있다.

예를 들어:

작업	실행 모델
대시보드 조회	EC2 + Docker API
DB connection pool 필요한 분석 API	EC2 + Docker API
오래 걸리는 파일 생성	Lambda worker
이벤트성 동기화	Lambda

이렇게 나누면 EC2 서버가 무거운 작업으로 막히는 일을 줄일 수 있다.

정리

EC2 + Docker는 최신의 화려한 선택은 아닐 수 있다.

하지만 작은 운영 콘솔의 상주 API 서버에는 현실적인 선택이 될 수 있다.

중요한 것은 Docker를 써서 애플리케이션 실행 단위를 이미지로 고정하는 것이다.

그러면 지금은 EC2 한 대에서 단순하게 운영하고, 나중에 필요해지면 ECS/Fargate로 옮길 수 있다.

좋은 설계는 처음부터 가장 큰 플랫폼을 쓰는 것이 아니라, 현재 규모에 맞게 단순하게 시작하고 다음 이동 경로를 열어두는 것이다.

함께 볼 GitHub 저장소

• aws-console-operations-notes