Production 환경에서 가장 중요한 목표 중 하나는 서비스 중단 시간을 최소화하는 것입니다.
기존 Active Passive 구조:
Primary Server
↓
Backup Server문제:
Backup Server
↓
대기 상태
↓
자원 활용 부족Active Active 구조에서는 여러 서버가 동시에 서비스를 처리합니다.
구조:
User
↓
Load Balancer
↓
Server A
Server B
Server C모든 서버가 동시에 요청을 처리하기 때문에 높은 처리량과 장애 대응 능력을 확보할 수 있습니다.
이번 글에서는 Docker Compose Active Active Architecture 개념부터 Load Balancing, Container 분산 운영, Database 구성, Session 관리, 장애 대응, Production 운영 구조까지 알아보겠습니다.
Active Active Architecture란 무엇인가?
Active Active Architecture는 여러 시스템이 동시에 활성 상태로 서비스를 제공하는 구조입니다.
기본 구조:
Request
↓
Server A 처리
Server B 처리특징:
- 모든 Node 사용
- Traffic 분산
- 장애 영향 감소
- 높은 가용성
Active Passive와 Active Active 비교
Active Passive:
Active Server
↓
Standby ServerActive Active:
Server A
+
Server B
↓
동시 서비스비교:
| 구분 | Active Passive | Active Active |
|---|---|---|
| 자원 활용 | 낮음 | 높음 |
| 장애 대응 | 전환 필요 | 즉시 처리 |
| 구성 난이도 | 낮음 | 높음 |
| 확장성 | 보통 | 높음 |
Docker Compose Active Active 기본 구조
구조:
User
↓
Load Balancer
↓
----------------
Container Group A
Container Group B
Container Group C
----------------
↓
Database Cluster여러 Container가 동시에 요청을 처리합니다.
Docker Compose Load Balancing 구성
Active Active의 핵심은 Traffic 분산입니다.
구조:
Client Request
↓
Load Balancer
↓
Container 1
Container 2
Container 3분산 방식:
- Round Robin
- Least Connection
- IP Hash
Docker Compose Container Scale 구성
여러 Container 실행:
docker compose up --scale app=3결과:
app-1
app-2
app-3Traffic:
Request
↓
app-1
app-2
app-3Docker Compose Stateless Application 구성
Active Active 환경에서는 Application이 Stateless 구조여야 합니다.
문제:
User Session
↓
Container A 저장다음 요청:
Container B 연결
↓
Session 없음해결:
외부 Session 저장소 사용
구조:
Container
↓
Redis Session Store
↓
공유 SessionDocker Compose Redis Session 관리
Active Active 환경에서 Redis는 자주 사용됩니다.
구조:
App A
↓
Redis
↓
App B효과:
- Session 공유
- Container 변경 대응
- Scale 가능
Docker Compose Database Active Active 구성
Database는 Application보다 복잡합니다.
구조:
Application
↓
Database Cluster방식:
Read Replica
Write
↓
Primary DB
Read
↓
Replica DBMulti Primary
DB A
↕
DB B데이터 충돌 관리가 필요합니다.
Docker Compose File Upload 관리
Active Active에서 파일 저장도 고려해야 합니다.
문제:
Container A
↓
Local File 저장Container B에서는:
파일 없음해결:
- Object Storage
- Shared Storage
구조:
Container
↓
Object Storage
↓
공유 데이터Docker Compose Health Check 기반 Traffic 제어
Active Active에서는 정상 Container만 사용해야 합니다.
구조:
Health Check
↓
정상 Container
↓
Traffic 전달장애:
Container 오류
↓
Load Balancer 제외Docker Compose Auto Scaling
Traffic 증가 시 Container 수를 늘립니다.
구조:
Traffic 증가
↓
Container 추가
↓
Load Balancer 연결효과:
- 처리량 증가
- 장애 분산
Docker Compose Monitoring Active Active
여러 Node를 관리해야 합니다.
확인:
- Container 상태
- CPU
- Memory
- Request 수
- Error Rate
구조:
Node A
Node B
Node C
↓
Central MonitoringDocker Compose Active Active 장애 처리
Server A 장애:
Server A Down기존:
서비스 중단Active Active:
Server B
Server C
↓
계속 처리Docker Compose Active Active 보안
관리:
- 인증 공유
- Secret 관리
- Network Isolation
- Audit Logging
구조:
Secret Manager
↓
Multiple Container
↓
Secure AccessDocker Compose Production Active Active 구조
기업 환경:
User
↓
Global Load Balancer
↓
---------------------
Container Cluster A
Container Cluster B
Container Cluster C
---------------------
↓
Redis Cluster
↓
Database Cluster
↓
Storage SystemActive Active 운영 Best Practice
추천:
Stateless 설계
Container 간 상태 공유 제거
중앙 Session 관리
Redis 사용
공유 Storage 사용
파일 동기화 문제 해결
Database 전략 설계
Replication 고려
장애 테스트
실제 Failover 확인
자주 묻는 질문
Active Active가 항상 좋은 구조인가요?
아닙니다. 서비스 규모와 데이터 구조에 따라 결정해야 합니다.
Docker Compose에서도 Active Active 운영이 가능한가요?
가능합니다. 여러 Container와 Load Balancer 구조로 구성할 수 있습니다.
Database도 완전 Active Active가 가능한가요?
가능하지만 데이터 충돌 관리가 중요합니다.
작은 서비스에도 필요한가요?
트래픽과 서비스 중요도가 높을 때 효과적입니다.
마무리
Docker Compose Active Active Architecture는 여러 Container와 Server가 동시에 서비스를 제공하여 높은 가용성과 안정성을 확보하는 운영 구조입니다.
최종 구조:
User
↓
Load Balancer
↓
Multiple Container
↓
Shared Session
↓
Database Cluster
↓
StorageProduction 환경에서는 하나의 Server에 의존하지 않고 여러 Instance가 함께 동작하는 구조를 설계하는 것이 중요합니다.
다음 글에서는 전 세계 사용자를 대상으로 Traffic을 효율적으로 분산하는 Docker Compose Global Load Balancing 운영 방법을 알아보겠습니다.