Tech Docker

Tech Docker

📌 기술 스택 - Docker & Docker Compose

✅ 사용 이유

• 서비스 격리: 각 서비스를 독립적인 컨테이너로 운영하여 의존성 충돌 방지
• 개발-운영 환경 일치: 개발자 로컬 환경과 프로덕션 서버의 동일한 실행 환경 보장
• 빠른 배포: 이미지 기반 배포로 CI/CD 파이프라인 자동화
• 리소스 효율성: VM 대비 가벼운 가상화로 메모리 및 CPU 효율적 사용
• 스케일링 용이성: 컨테이너 단위로 수평 확장 가능

🔁 대안 기술

• VM (Virtual Machine): 완전한 격리 제공하지만 리소스 오버헤드 큰 편
• Kubernetes: 대규모 오케스트레이션에 적합하지만 프로젝트 규모 대비 과도함
• 직접 설치: 의존성 관리와 환경 일치 문제로 운영 복잡도 증가
• Podman: Docker 대안이지만 생태계와 레퍼런스 부족

📈 장점 및 단점

구분	내용
✅ 장점	• 개발-운영 환경 일치로 "내 컴퓨터에서는 됐는데" 문제 해결 • 마이크로서비스 아키텍처 구현에 최적 • CI/CD 파이프라인과 완벽 통합 • 이미지 레이어 캐싱으로 빌드 속도 향상
⚠️ 단점	• 초기 학습 곡선 존재 • 볼륨 관리 복잡성 (데이터 영속성) • 네트워크 설정의 복잡성 • 로그 및 모니터링 설정 필요

🔧 사용 방식 및 로직 구조

컨테이너 아키텍처

┌─────────────────────┐    ┌─────────────────────┐
│   Spring Boot       │    │   Elasticsearch     │
│   (8080:8080)       │◄──►│   (9200:9200)       │
│   - API 서버        │    │   - 뉴스 검색        │
│   - JWT 인증        │    │   - Nori 분석기      │
└─────────────────────┘    └─────────────────────┘
           ▲                          ▲
           │                          │
┌─────────────────────┐    ┌─────────────────────┐
│   Redis Session     │    │   Prometheus        │
│   - session1:6380   │    │   (9090:9090)       │
│   - session2:6381   │    │   - 메트릭 수집      │
│   - JWT 토큰 저장    │    │   - 모니터링        │
└─────────────────────┘    └─────────────────────┘

주요 컨테이너 역할

1. SpringBoot 컨테이너 (메인 애플리케이션)

# Multi-stage 빌드로 이미지 크기 최적화
FROM gradle:8.4.0-jdk17 AS build
WORKDIR /app
COPY build.gradle settings.gradle ./
RUN gradle dependencies || true  # 의존성 캐시

COPY . .
RUN gradle clean build -x test

FROM amazoncorretto:17-alpine
WORKDIR /app
COPY --from=build /app/build/libs/*.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

2. Redis 이중화 구조 (JWT 토큰)

redis-session1:
  image: redis:7.2
  container_name: redis-session1
  ports: ["6380:6379"]
  volumes:
    - redis-session1-data:/data
    - ./redis/redis-session1.conf:/usr/local/etc/redis/redis.conf

redis-session2:
  image: redis:7.2
  container_name: redis-session2
  ports: ["6381:6379"]
  volumes:
    - redis-session2-data:/data
    - ./redis/redis-session2.conf:/usr/local/etc/redis/redis.conf

3. Elasticsearch (뉴스 검색 엔진)

elasticsearch:
  image: docker.elastic.co/elasticsearch/elasticsearch:8.13.0
  environment:
    - discovery.type=single-node
    - xpack.security.enabled=false
    - ES_JAVA_OPTS=-Xms512m -Xmx512m
  volumes:
    - es-data:/usr/share/elasticsearch/data
    - es-plugins:/usr/share/elasticsearch/plugins

Docker Compose 네트워킹

networks:
  backend:
    driver: bridge

# 모든 서비스가 backend 네트워크에 속해 서로 통신

볼륨 관리 전략

volumes:
  # 데이터 영속성 보장
  redis-session1-data:
  redis-session2-data:
  es-data:             # Elasticsearch 인덱스 데이터
  es-plugins:          # Nori 플러그인 등
  prometheus-data:     # 메트릭 데이터

🛠 개선 사항 또는 한계점

현재 구조의 장점

• 볼륨 보존 배포: docker-compose down 시에도 데이터 안전하게 보존
• 자동 플러그인 관리: Elasticsearch Nori 플러그인 자동 설치 및 확인
• 헬스체크 자동화: 각 컨테이너의 상태 자동 점검
• 로그 관리: JSON 드라이버로 구조화된 로그 수집

CI/CD 통합

# GitHub Actions에서 자동 배포
- name: 프로덕션 서버에 배포
  run: |
    # 안전한 컨테이너 정리 (볼륨 보존)
    docker-compose down --remove-orphans --timeout 30
    
    # 선택적 정리 (볼륨은 절대 건드리지 않음)
    docker container prune -f
    docker image prune -f
    
    # 새 컨테이너 시작
    docker-compose up -d --build

한계점

• 단일 서버 의존: 현재는 단일 EC2에서 모든 컨테이너 실행
• 메모리 제약: Prometheus 등으로 인한 메모리 부하
• 네트워크 복잡성: 다중 Redis와 서비스 간 통신 복잡도
• 로그 중앙화 부족: 각 컨테이너 로그의 통합 관리 필요

향후 개선 방향

• 하이브리드 아키텍처: 중요 서비스는 AWS 관리형으로 이전 (RDS, ElastiCache)
• 모니터링 간소화: Prometheus 제거 후 CloudWatch 통합
• 이미지 최적화:
  • Multi-stage 빌드 고도화
  • 베이스 이미지 경량화 (Alpine Linux)
  • 의존성 캐시 레이어 최적화
• 컨테이너 오케스트레이션: 트래픽 증가 시 Docker Swarm 또는 ECS 도입

성능 최적화

# 로그 최적화
logging:
  driver: "json-file"
  options:
    max-size: "10m"    # 로그 파일 크기 제한
    max-file: "3"      # 로그 파일 개수 제한
    compress: "true"   # 압축으로 디스크 절약

# 헬스체크 설정
healthcheck:
  test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
  interval: 10s
  timeout: 5s
  retries: 5

마이그레이션 로드맵

현재: Docker Compose (All-in-One)
   ↓
1단계: DB 분리 (RDS) ✅ 완료
   ↓  
2단계: 캐시 분리 (ElastiCache) 🔄 진행중
   ↓
3단계: 모니터링 이전 (CloudWatch)
   ↓
4단계: 컨테이너 최적화 (ECS/Fargate)