서비스 이용자가 증가하면 하나의 Container만으로는 모든 요청을 처리하기 어려워집니다.
초기 서버:
사용자
↓
Application Container 1개
↓
Database문제:
- 요청 증가
- CPU 사용량 증가
- 응답 속도 저하
- 서비스 장애 위험 증가
이때 필요한 것이 Container Scaling입니다.
Scaling은 동일한 Application Container를 여러 개 실행하여 트래픽을 분산 처리하는 방식입니다.
기본 구조:
사용자
↓
Load Balancer
↓
App Container 1
App Container 2
App Container 3
↓
Database이번 글에서는 Docker Compose Scaling 개념부터 Container 복제, Resource 관리, Load Balancer 연결, Production 확장 전략까지 알아보겠습니다.
Docker Compose Scaling이란?
Scaling은 하나의 Service를 여러 개의 Container로 확장하는 기능입니다.
기존:
app Container 1개Scaling 적용:
app Container 3개구조:
동일한 Application
↓
여러 Container 실행
↓
요청 분산 처리장점:
- 처리량 증가
- 장애 영향 감소
- 성능 향상
- 확장 가능
Docker Compose Scaling이 필요한 상황
대표적인 상황:
사용자 증가
100명 접속
↓
10,000명 접속API 요청 증가
초당 요청 증가특정 서비스 부하 증가
Application CPU 증가Database는 그대로 두고 Application만 확장하는 경우도 많습니다.
Docker Compose Scale 명령어
기본 실행:
docker compose up -d --scale app=3의미:
app Service
↓
Container 3개 실행확인:
docker compose ps결과:
app-1
app-2
app-3Docker Compose Scaling 구조
예:
docker-compose.yml
services:
app:
image: my-app
ports:
- "3000"Scale:
docker compose up -d --scale app=5결과:
app-1
app-2
app-3
app-4
app-5Docker Compose Scaling과 Port 문제
Scaling할 때 주의할 부분이 Port입니다.
잘못된 설정:
ports:
- "3000:3000"문제:
5개 Container
↓
같은 Host Port 사용 불가해결:
Container Port만 지정:
expose:
- "3000"그리고 Load Balancer가 연결합니다.
Docker Compose Load Balancer 필요성
여러 Container가 실행되어도 사용자가 직접 선택할 수 없습니다.
필요:
사용자
↓
Load Balancer
↓
Container 여러 개역할:
- 요청 분배
- 장애 Container 제외
- Traffic 관리
대표:
- Nginx
- HAProxy
- Traefik
Docker Compose Nginx Scaling 연결
구조:
Nginx
↓
app-1
app-2
app-3Nginx 설정:
upstream backend {
server app:3000;
}Docker Network 내부에서 여러 Container를 연결합니다.
Docker Compose Scaling과 Service Discovery
Container 이름이 계속 변경됩니다.
예:
app-1
app-2
app-3Docker Compose Network는 Service 이름으로 접근합니다.
예:
app:3000Docker가 내부 DNS를 통해 Container를 찾습니다.
Docker Compose Resource 제한
Scaling에서는 Resource 관리가 중요합니다.
예:
Container 1개:
CPU 1 Core
Memory 1GB5개 실행:
CPU 5 Core
Memory 5GB설정:
deploy:
resources:
limits:
memory: 1GDocker Compose Auto Scaling 개념
Docker Compose 자체는 자동 Scaling 기능이 제한적입니다.
자동 확장은 보통 다음 시스템과 함께 사용합니다.
- Kubernetes
- Docker Swarm
- Cloud Container Service
구조:
Traffic 증가
↓
Monitoring 감지
↓
Container 증가Docker Compose Scaling과 Database
Application은 쉽게 확장할 수 있지만 Database는 다릅니다.
Application:
App 1
App 2
App 3Database:
Database 1주의:
동시 Write 처리 필요
해결:
- Connection Pool
- Read Replica
- Cache
- Database Cluster
Docker Compose Redis Scaling
트래픽 증가 시 Cache도 중요합니다.
구조:
Application
↓
Redis
↓
Database효과:
- Database 부하 감소
- 응답 속도 향상
Docker Compose Scaling Monitoring
확장 후 반드시 확인:
CPU:
docker statsMemory:
사용량 확인Network:
Traffic 확인Container:
docker compose psDocker Compose Production Scaling 구조
실제 운영:
User
↓
Load Balancer
↓
Application Container x N
↓
Redis Cache
↓
Database
↓
Backup
↓
MonitoringDocker Compose Scaling Best Practice
운영 추천:
- Stateless Application 구성
- Container 여러 개 실행
- Load Balancer 사용
- Resource 제한 적용
- Monitoring 연결
- Database 별도 최적화
확장 흐름:
Traffic 증가
↓
Container 추가
↓
Load Balancer 연결
↓
성능 증가자주 묻는 질문
Docker Compose에서 여러 Container 실행이 가능한가요?
가능합니다.
Scale 옵션으로 동일 Service를 여러 개 실행할 수 있습니다.
모든 서비스를 Scale 해야 하나요?
아닙니다.
주로 부하가 높은 Application Layer를 확장합니다.
Database도 여러 개 실행하면 되나요?
Database는 데이터 동기화 문제가 있어 별도 설계가 필요합니다.
Scaling하면 자동으로 Traffic이 분배되나요?
아닙니다.
Load Balancer 구성이 필요합니다.
마무리
Docker Compose Scaling은 서비스 성장에 따라 처리량을 증가시키는 중요한 운영 전략입니다.
핵심 구조:
사용자 증가
↓
Container 확장
↓
Load Balancer
↓
요청 분산
↓
안정적인 서비스 운영Production 환경에서는 Scaling만 적용하는 것이 아니라 Load Balancer, Monitoring, Database 구조까지 함께 설계해야 합니다.
다음 글에서는 여러 Container로 들어오는 요청을 효율적으로 분배하는 Docker Compose Load Balancer 구성 방법을 알아보겠습니다.