Docker - 100-hours-a-week/9-team-Devths-WIKI GitHub Wiki

💡 컨테이너란? 애플리케이션을 주변 환경에 상관없이 어디서든 똑같이 실행할 수 있도록 패키징하는 도구입니다.

Devths는 AI 알림 및 취업 지원 서비스를 제공하며, 이력서와 포트폴리오 같은 사용자의 민감한 데이터를 다룸. 따라서 인프라 설계 시 안정성(배포·복구·확장)과 보안을 최우선 가치로 설정하여 구축함.

서비스 장애가 발생하면 취업 준비 상태를 제때 확인·수정하기 어렵고, 이력서·포트폴리오에는 개인정보뿐 아니라 대외비 수준의 내용이 포함될 수 있어 무단 접근과 유출을 방지하는 보안이 필수임.

현재 서비스의 성장세가 가파르지만, 장애가 반복되면 사용자는 서비스 신뢰를 잃고 빠르게 이탈할 수 있음.

• 단일 인스턴스 및 다중 언어 스택(Sprint Boot + Python AI + Next.js)으로 구성됨.
• AI 분석 기능은 CPU/RAM을 집중적으로 사용하여 리소스 독점 위험이 존재함.
• 외부 API(OAuth, LLM) 의존도가 높아 외부 지연이 시스템 전체로 전이될 수 있음.
• 채팅 기능은 WebSocket 기반 장기 연결을 사용하며, 연결 수 증가에 따라 메모리/네트워크/CPU 증가량이 선형적으로 증가함.

현재 서비스는 MAU가 30만으로 이용자 수가 급격하게 증가 중이기에, 서비스 확장이 필요한 상황

• 문제 1 (채팅 트래픽의 확장 요구)

  WebSocket 기반 채팅은 연결이 오래 유지되는 특성상 사용자가 늘어날수록 동시 연결만큼 메모리 점유가 누적됨.

  단일 서버/단일 프로세스 구조에서는 동시접속 요청 증가 시 메모리 한계로 성능 저하나 연결 끊김이 발생할 수 있으며, 이는 채팅 품질 저하로 직결됨.

  따라서 채팅은 사용량 증가에 맞춰 수평 확장(Scale-out)을 전제로 설계할 필요가 있음.

• 문제 2 (단일 서버 구조에서의 연쇄 장애 위험)

  AI 분석 요청은 CPU/RAM을 집중적으로 사용하므로 트래픽이 몰리면 동일 서버에서 동작하는 다른 기능(이력서 조회/저장 등)까지 응답 지연·타임아웃이 발생할 수 있음.

  특정 기능의 부하가 전체 사용자 경험을 무너뜨리는 연쇄 장애로 확장될 위험이 존재함.

• 문제 3(배포 예측 불가)

  현재 GitHub Actions(CI) + AWS CodeDeploy(CD)로 자동화는 갖춰져 있음.

  다만 배포 결과물이 서버 환경(JDK/OS 라이브러리/설정)에 영향을 받는 구조이기에, 동일 리비전이라도 서버 상태에 따라 배포는 성공했지만 실행이 실패하는 문제가 발생할 수 있음.

단순 인스턴스 확장이 아닌, 왜 컨테이너여야 하는가?

• Devths 인프라 확장 전제 조건은 안정성과 보안 임. 컨테이너 도입은 1-3에서 정의한 문제를 해결하기 위한 방법

Devths가 개발 단계에서는 단일 인스턴스로 구성하기에 기능별 자원의 분리가 필요함.

1. 기능별 격리 및 자원 간섭 최소화가 필요함
   Devths는 AI(VLLM) 고부하와 채팅(WebSocket) 장기 연결이 공존하므로, 한 기능의 폭주가 다른 기능(BE API 등)으로 전이되지 않도록 실행 단위를 분리하고 자원 사용을 제어해야 함. 서비스별 컨테이너로 실행/재기동 단위를 분리하고, 필요 시 CPU·메모리 상한을 설정해 장애 전파와 성능 저하를 완화함. 프로세스에도 cgroup 기반 자원 제한은 가능하지만, Docker는 프로세스·파일시스템·네트워크까지 서비스 단위로 묶어 격리하므로 운영 복잡도와 장애 전파를 함께 낮출 수 있음.

2. 장애 복구를 서비스 단위로 단순화해야 함
   단일 노드에서 문제가 생기면 전체 재시작이 아니라, 영향 받은 컨테이너만 재기동/교체하는 방식이 운영적으로 안전함

Devths는 MAU가 폭발적으로 증가할 경우 단일 인스턴스만으로는 채팅(WebSocket) 동시 연결과 AI(VLLM) 요청량을 감당하기 어려워, 멀티 인스턴스(수평 확장) 전환을 고려해야 함.

1. Scale-out은 ‘동일한 실행 단위 복제’가 전제임
   인스턴스가 늘어날수록 수동으로 런타임을 설치하고 설정하는 방식은 서버별 편차를 발생시키며, 장애 원인을 분산시킴. Docker 이미지는 모든 서버에 동일한 실행 단위를 제공하여, 서버 수가 늘어나더라도 전체 시스템의 결과가 균일하게 유지되도록 보장함.

2. ASG(Auto Scaling Group)에서는 부팅 이후 절차가 짧아야 함
   새 인스턴스가 생성될 때마다 매번 설치와 구성 작업이 길어지면 확장(Scaling) 속도가 저하되고 실패 지점이 늘어남. 컨테이너 기반의 이미지 방식을 채택하면 복잡한 초기화 과정이 생략되어 인스턴스 확장 흐름이 단순해지고 빨라짐.

3. 보안 및 안정성을 위한 운영 표준을 일관되게 적용함
   Devths는 민감 데이터를 다루는 서비스이므로 실행 권한 최소화, 이미지 경량화, 네트워크 분리와 같은 운영 원칙을 모든 환경에 동일하게 적용해야 함. Docker는 이러한 원칙을 이미지 자체와 실행 설정으로 표준화함. 이를 통해 단일 인스턴스부터 멀티 인스턴스 환경까지 동일한 수준의 보안 및 안정성 기준을 유지할 수 있음.

• 운영 접근은 SSM을 기본으로 하여 인바운드 포트 노출을 최소화함.
• 백엔드 및 데이터 계층은 프라이빗 서브넷에 배치하여 외부 직접 접근을 차단함.
• 환경별로 VPC를 분리하여 운영 데이터 보호 및 사고 전파 범위를 제한함.

컨테이너 런타임 및 실행 환경 후보를 daemon/daemon-less, 애플리케이션/시스템 컨테이너 관점에서 비교함. 기술 선택 기준은 보안, 안정성, 비용, 호환성

2025년 스택오버플로우 설문조사 - Cloud 관련 인기 있는 도구

• LXD는 시스템 컨테이너이기에, 경량화된 컨테이너를 쓰는 의미가 퇴색되어 배제함.
• podman의 경우에, 명령어 치환 (alias docker=podman) 하는 것으로 대부분의 작업 수행 가능하는 등 편의성도 높지만, Docker-compose 및 네트워크의 호환성 부족.
• Docker 생태계에서 발생한 보안 사고들이 Docker 데몬의 루트 권한 실행 방식에 의해서 발생하는 잠재적 위험 존재. 참고링크(한국정보기술진흥원)
  • 하지만, 외부에서 노출 자체가 되지않는 프라이빗 서브넷으로 이전한다면, 포트가 열리지않도록 보안 문제 극복 가능
• Docker는 문서·레퍼런스·트러블슈팅 사례·CI/CD 연동이 가장 풍부해, 장애 발생 시 해결 경로가 빠르고 운영 표준화가 쉬워 소규모 팀에서 안정적으로 운영하기에 유리함.

⇒ 인원이 적은 소규모 팀이라는 상황과 프라이빗 서브넷 도입을 통한 보안 보완, 호환성을 고려하여 도커로 최종 선택함

우리 서비스의 컨테이너 저장소 선정 기준은 보안, 안정성, 비용, 호환성 입니다.

• Docker Hub를 프라이빗 서브넷에서 쓰려면 NAT Gateway를 통한 아웃바운드 인터넷 경로가 필요하지만, 외부망을 타는 것에 보안적인 이슈가 발생할 가능성 존재.
• PrivateLink를 통해 데이터가 인터넷을 절대 타지 않고 내부망으로만 통신되기에, 보안성을 높일 수 있음.
• Docker Hub 방식보다 약 3배 저렴함.
• 보안성(폐쇄망), 비용(NAT 대비 60% 절감), 관리 편의성, AWS호환성을 모두 고려하여 AWS ECR을 선택함.

4-3-1. 왜 멀티스테이징 빌드를 써야하는지 (백엔드 예시)

• 우리 서비스의 경우에는, private 컨테이너 저장소를 사용하기에 이미지가 커질수록 더 많은 비용이 청구됨. 그렇기에 더 가벼운 크기의 이미지 제작이 필수
  • Alpine 기반의 경량 베이스 이미지를 표준으로 채택
• 따라서 멀티스테이징 기반의 경량 이미지를 표준으로 채택하는 것이 비용과 운영 효율 측면에서 유리함.

4-3-2. BE Dockerfile

# ====== Build Stage ======
FROM eclipse-temurin:21-jdk AS builder
# 작업 디렉토리를 /build로 설정합니다.
WORKDIR /build
# 파일을 이동시킵니다.
COPY . .
# 실행 가능한 Jar를 만듭니다.
RUN ./gradlew bootJar

# ====== Runtime Stage ======
FROM eclipse-temurin:21-jre-alpine
# 실행 파일 이동
WORKDIR /app
# 빌드한 jar 파일 가져오기
COPY --from=builder /build/build/libs/*.jar app.jar
# 노출할 포트
EXPOSE 8080
# 실행할 환경 설정
ENV SPRING_PROFILES_ACTIVE=prod
# 실행하기
CMD ["java", "-Dspring.profiles.active=${SPRING_PROFILES_ACTIVE}", "-jar", "app.jar"]

• 실행활 환경에 따라서 마지막 profile을 수정하여 실행합니다.

4-3-3. AI Dockerfile

# ====== Build Stage ======
FROM python:3.11-slim AS builder
WORKDIR /build

# 빌드에 필요한 최소 패키지
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential gcc \
  && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --no-cache-dir --upgrade pip \
 && pip wheel --no-cache-dir --wheel-dir /wheels -r requirements.txt

# ====== Runtime Stage ======
FROM python:3.11-slim
WORKDIR /app

# 보안: non-root 유저 권장
RUN useradd -m appuser
USER appuser

COPY --from=builder /wheels /wheels
RUN pip install --no-cache-dir --no-index --find-links=/wheels /wheels/*

COPY . .

EXPOSE 8000
ENV APP_ENV=prod
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

• 어떤 서비스까지 컨테이너화 하여 배포할 것 인지 결정
• 대상: 서비스(FE, BE, AI), DB(PostgreSQL, NoSQL DB, VectorDB), MQ 등 서비스 운영을 위한 전체 배포 대상 검토 필요
• 인프라 구조, 네트워크 설계, 성능, 배포 방식의 확장성 등 다양한 부분을 고려하여 컨테이너화 여부 선택

1. FE (Next.js)

   • 요구사항
     • 정적 콘텐츠 위주: CSR로 구성, 랜딩 페이지는 SSG. 브라우저에서 렌더링 진행
     • 정적 빌드 및 배포 확정. 서버 필요 없음
   • 문제 상황 예측
     • 불필요한 리소스 낭비: 정적 파일 서빙을 위해 EC2, Nginx 등 웹 서버를 실행하거나, 컨테이너화 하여 실행하면 컴퓨팅 자원 추가 소모 필요
     • 관리 요소 증가: 트래픽 증가 시 정적 파일 서빙을 위한 서버도 스케일링 필요
   • 결론: 컨테이너화X, S3 + Cloud Front
     • 서버가 필요 없는 아키텍처이므로 S3 + CF 적용하여 Serverless 구조로 진행
     • 컴퓨팅 자원 항시 실행이 필요 없으므로 비용 절감
     • CDN을 통한 캐싱과 서빙으로 빠른 속도 보장
   
   

2. DB

   • PostgreSQL

     • 요구사항
       • 안정성 및 데이터 영속성: 사용자 데이터는 절대 유실되면 안됨
       • 고가용성: 서버 장애 시에도 즉시 복구 필요, 롤백 백업 기능 필요
     • 문제 상황 예측
       • DB를 컨테이너에 담을 경우 컨테이너 문제 및 볼륨 마운트 설정 등 문제로 데이터 유실 문제 발생 가능성
       • Failover(multi-AZ, 롤백 등)가 없다면 단일 장애 지점
     • 결론: RDS 선택
       • EC2 위에서 직접 운영하는 경우 RDS 대비 15% 가량 비용 절감 가능 (t3.medium, 100GB 용량 gp2, multi-AZ 기준 / EC2: $208.69, RDS: $245.15)
       • 안정성을 위한 기능 직접 구현, 수동 운영 위한 리소스 소모
       • 한정된 운영 인력 및 환경에서 리소스 절감을 위해 RDS 선택
     
     

   • Redis

     • 요구사항
       • 멀티 인스턴스 간 정보 공유(로그인 정보, 채팅 기능 등)를 위해 사용
       • 고가용성 필요
     • 문제 상황 예측
       • 별도 EC2에서 실행 할 경우, 해당 서버가 죽으면 단일 장애지점(인증 오류)
       • 장애 발생시 로그인/인증 장애로 인한 심각한 UX 저하 발생
       • 장애 발생시 다중 서버간 채팅 단절 및 메시지 유실 가능성
       • Redis 장애 →BE 연결 재시도 → 스레드 풀 고갈 → 시스템 전체로 장애 전파
       • 고가용성을 위해 다중 클러스터 설정 시 정합성 문제, 슬롯 할당 문제 발생 가능성
       • EC2에서 직접 운영하는 경우 ElastiCache 대비 약 47% 비용 절감 가능 (t3.small, 1GB 용량 / EC2: 약 $15 , ElastiCache: 약 $28)
       • 운영을 위한 리소스 소모 발생(클러스터링 시 Failover, Master 변경에따른 대응)
     • 결론: ElastiCache(primary-Replica)
       • 채팅 Pub/Sub 및 세션 안정성 보장
       • primary 장애시 자동으로 Replica로 전환하여 최소한의 failover

   • VectorDB

     • AI 서비스에 활용될 Vector DB 미정으로 설계 보류

3. MQ (Apache Kafka): AWS MSK

   • 요구사항
     • 데이터 무결성 보장 및 순서 보장: 채팅 메시지의 안전한 저장과, 저장 순서 보장을 위한 역할
     • 비동기 처리: 쓰기 지연, 알림 발송 등의 부가적 로직으로 인한 채팅 프로세스 지연 방지
   • 문제 상황 예측
     • 운영 복잡도: 직접 구축 할 경우 복잡한 설정 및 브로커 간의 연결 관리, 파티션 리밸런싱 등 직접 설정
     • 스토리지 관리의 어려움: 로그가 쌓일 경우 Kafka 실행 중단. 운영 중 디스크 증설의 어려움
   • 결론
     • 성능 및 안정성, 순서 보장을 위해 kafka 선택 됨
     • Kafka 클러스터 구축과 운영을 직접 하기 위해서는 과도한 리소스 소모
     • MSK 사용으로 인프라 관리 부담을 AWS 위임, 토픽 설계 및 모니터링에 집중

1. BE 서비스 (Spring Boot)
   • 요구사항
     • 핵심 비즈니스 로직을 실행. 안정성 필요
     • 운영 시 기능 추가와 잦은 버그 수정으로 빈번한 배포와 트래픽에 따른 확장 발생
     • 다른 프로세스와 자원 경합 시 어려운 제어, 복잡한 설정
   • 문제 상황 예측
     • 스케일 아웃 지연: 트래픽 폭증 상황 시 EC2를 새로 실행하고 환경 설정 후 서버를 실행하는 방식은 오랜 시간 소요
     • 환경 불일치 문제: 개발자 로컬에서는 실행되는 로직이 서버 환경에서는 실행되지 않을 수 있음
   • 결론: 컨테이너화
     • 불변 인프라 구축: OS, JDK, 라이브러리를 이미지로 패킹하여 환경 일관성 확보
     • 빠른 확장: 빌드된 이미지 Pull, 실행을 통해 빠른 확장 실행 가능
2. AI (FastAPI)
   • 요구사항
     • 파이썬 라이브러리 의존성 복잡
     • 분석 요청에 따른 CPU, 메모리 부하 급증
   • 문제 상황 예측
     • 트래픽 증가로 인한 AI 분석 요청 증가
     • AI 서버의 자원 증가로 인한 동일 인스턴스 내 BE까지 같이 느려지는 자원 간섭 문제 발생 예상
     • 서버 OS 레벨의 라이브러리 버전 차이로 인한 실행 문제 발생 가능성
   • 결론: 컨테이너화
     • AI 서버를 별도의 컨테이너로 격리하여 자원을 제한, 타 서비스의 안정적 실행 보장
     • 확장성 및 이식성 확보: 트래픽 증가 등 필요시 컨테이너만 고사양 노드로 옮기거나 확장 위해 컨테이너화 필수, 마이그레이션 비용 절약

1. API와 Chat의 분리

• 채팅 서버를 독립적인 ASG로 분리하여 메인 API의 배포나 부하가 실시간 채팅 연결에 영향을 주지 않도록 격리하였기에 인스턴스의 스펙을 낮춰서 진행.
• 채팅 서버는 유저가 메시지를 안 보낼 때는 CPU를 거의 쓰지 않고 메모리만 점유하기에, 비싼 CPU 성능 대신 4기가 메모리 확보하는 t3 사용함.

2. 채팅 서버 인스턴스 타입 (t3 vs c5)

• 채팅 서버는 연산 부하보다 대량의 유휴 연결을 유지하는 것이 핵심이므로, 비용 효율적인 t3.medium을 우선 채택함. 단, 동시 접속자 수가 급증할 경우 메모리 사양에 따라 t3.large로 스케일 업 검토.
• • 채팅 웹소켓의 부하는 메모리뿐 아니라, 해당 내용을 전체에게 복사하면서 발생하는 CPU도 존재.
• [참고 링크]

3. AI 노드의 ASG 및 Warm Pool (아직 미정)

• LLM 모델은 인스턴스 부팅 후 모델 로딩에만 수 분이 소요
• 인스턴스를 미리 모델이 로드된 정지 상태(Stopped)로 유지했다가, 트래픽 증가 시 즉시 실행 상태(Running)로 전환하여 확장 지연 시간(Scale-out Latency)을 80% 이상 단축

운영 환경은 민감 데이터가 존재하고 장애 영향 범위가 크기 때문에, 개발/스테이징과 네트워크 경계를 분리하여 안정성과 보안을 동시에 확보함.

1. 단일 VPC 사용 시 발생하는 문제

• 운영 데이터는 엄격히 보호되어야 하지만, 단일 VPC 내에서는 내부 네트워크 스캐닝을 통해 개발 환경에서 운영 환경으로의 접근 가능성 존재
• 개발자가 테스트 및 개발 과정에서 라우팅 테이블 또는 보안 그룹 변경 실수가 운영 환경까지 영향을 줄 수 있음.

• PROD환경에서는 외부 API(OAuth, Gemini, OpenAPI, Google Calendar) 호출이 많은 서비스 특성을 고려하여 병목이 발생하지 않도록, 안전하게 NAT Gateway를 Prod VPC에 설정함.
• 프라이빗 서브넷의 인스턴스가 외부로 나갈 때만 NAT를 통해 통신하도록 구성하여 프라이빗 서브넷의 노출을 차단함.
• NON-PROD는 트래픽이 일정하지 않고 개발 및 배포 직전에만 주로 쓰임. NAT Gateway의 높은 고정비를 지불하는 대신, EC2(t3.micro 등)를 활용하여 개발자가 테스트를 통해 유동적으로 NAT 성능을 조절함.

2. PrivateLink와 Nat Gateway를 모두 사용하는 이유

• 인바운드는 ALB로 단일화하여 보안을 강화하고, 아웃바운드는 목적지에 따라 내부망(PrivateLink)과 외부망(NAT Gateway)으로 분리해 효율성과 안전성을 동시에 확보함.

3. 모든 환경 VPC에 PrivateLink를 구성한 이유

• PrivateLink를 사용하면 트래픽이 VPC 내부에서 AWS 백본 네트워크로 직접 연결되어, 인터넷 노출이 줄어들고 경로가 단순해져 장애 원인과 영향 범위를 통제하기 쉬움
• 또한, 모든 VPC에 동일하게 적용하면 환경별 보안 수준과 배포 안정성을 일관되게 유지할 수 있음

• 프라이빗 서브넷에는 백엔드 및 데이터 계층을 배치하여 외부 직접 접근을 차단함.
• 보안 그룹은 컨테이너 및 인스턴스 간 필요한 포트만 최소 범위로 허용하여 네트워크 계층 보안을 강화함.

• Devths는 사용자가 이력서·포트폴리오·지원 현황·면접 일정처럼 취업 준비에 직접 영향을 주는 정보를 상시 관리하는 서비스이므로, 인프라는 중단에 민감함.
• 서비스 장애가 발생하면 단순 접속 불가를 넘어 마감 직전 지원 현황 확인 실패, 면접 일정 확인 실패로 이어져 사용자 행동에 즉시 피해를 발생시킴.
• Standby를 통해, 운영적인 속도를 보장하면서 비용을 최적화하는 방식으로 설정함.

선택 기준은 보안, 비용, 개발의 편의을 바탕으로 비교함.

SSM은 인바운드 포트 노출 없이 접근할 수 있고 IAM으로 접근 통제가 가능하므로 프라이빗 서브넷 보안성을 극대화할 수 있음. 따라서 SSM 기반 접근을 채택함.

• 단일 노드 내의 통신은 Docker Bridge Network를 사용하여 서비스 간 통신을 단순화함.
• 외부 통신은 NAT Gateway를 통해 수행하며, OAuth 등 외부 의존 호출의 안정성과 운영 일관성을 확보함.

• 컨테이너 로그는 호스트에 영구 저장하지 않고 stdout/stderr 기반으로 출력하며, 각 인스턴스에 promtail을 배치하여 로그를 중앙 로그 스토어(Loki)로 수집함.
• 우리 서비스는 수평 확장이 중요하기에 사라질 수도 있지만,, 인스턴스가 교체되더라도 로그가 중앙에 남아 장애 분석과 추적이 가능하도록 설계함.

• 기존 서비스 기반의 Artifact 배포 방식 CI/CD 파이프라인을 컨테이너 방식 CI/CD 파이프라인으로 변경 설계

• 무중단 배포: 사용자가 서비스를 이용하는 도중 중단이 발생하면 응답 및 채팅의 유실등으로 UX가 저하될 우려 있음.
• 환경 일치: 개발, 스테이징, 운영 환경간의 라이브러리 및 런타임 환경을 일치시켜야 함.
• 빠른 롤백: 배포 후 실행 실패 및 치명적 오류 발생 시, 서비스 복구를 우선적으로 수행하여 서비스의 Down time을 최소화 필요함. Down Time이 길어질 경우, 사용자 경험의 저하, 서비스 신뢰도 하락으로 인한 사용자 이탈우려 있음.
• 리소스 효율적 사용: 배포 과정에서 운영 서버의 리소스를 소모하지 않아야 함.

• 방식: B/G 배포 방식 유지
• 선정 근거
  • 완전한 리소스 격리로 인한 서비스 보호 가능
  • ASG와 연동하여 트래픽 폭증에 대비한 스케일링 과정 쉬움
  • AWS가 관리해주는 롤백 로직으로, 예외 상황에 대한 대비 가능
• 구현 방식
  • Docker-compose 파일을 활용하여 인스턴스 단위로 생성 후 트래픽 전환 가능

• 이미지 이름은 [저장소 주소]/[프로젝트]/[이미지명]:[태그] 구조를 따르며, 소문자 및 하이픈만 사용하여 일관성을 유지함.
• 규칙: [AWS_Account_ID].dkr.ecr.[Region].amazonaws.com/[Service_Name]/[App_Name]:[Tag]

• latest 태그는 가독성을 위해 병행 사용하되, 운영 배포는 반드시 커밋 SHA 등 불변 태그를 사용하여 재현성과 롤백 안정성을 확보함.

• Devths는 현재 CI는 GitHub Actions, CD는 AWS CodeDeploy로 운영함.
• 따라서, Docker 도입은 CodeDeploy를 제거하는 방식이 아니라, CodeDeploy가 다루는 배포 단위를 파일/프로세스에서 불변 이미지로 전환하여 배포의 재현성과 복구 가능성을 높이는 방향으로 설계함.

1. 빌드 (GitHub Actions)
   • GitHub에서 Code Checkout
   • Multi-stage Build: 실행 가능한 경량 이미지 생성
   • 이미지 태그 생성 및 ECR로 Push
2. 배포 트리거
   • appspec.yml과 배포 스크립트만 S3에 업로드(deploy.sh, docker-compose.yml )
   • AWS CodeDeploy에 배포 명령 전달
3. 배포(EC2 내부)
   • ECR에서 이미지 Pull
     • docker pull [이미지주소]:[태그] 실행
   • 컨테이너 교체 및 실행
     • docker-compose up -d
   • 불필요한 구 버전 이미지 삭제
     • docker image prune

• .env 파일을 호스트 디스크에 생성하여 주입하는 방식은 기록을 남겨 추후 보안 사고 시 탈취 위험이 있음
• 호스트에서 도커 실행 시점에 주입 하는 경우 역시 쉘 히스토리로 남을 수 있음
• ps 명령어(프로세스 리스트)를 통해 환경변수를 확인 할 수 있는 경우 있음
• 보안상 취약점을 만들지 않기 위해 기존 설계와 동일하게 앱 실행을 위한 환경변수 제외, AWS SDK를 통해 가져옴
• 앱 실행을 위한 필수 정보 일부는 deploy.sh 를 통해 주입하여 쉘 히스토리를 남기지 않고 주입 (SPRING_PROFILES_ACTIVE , AWS_REGION , SERVER_PORT 등 )

• 즉시 롤백: CodeDeploy의 ‘배포 실패 시 롤백’ 옵션 활성화
• 수동 롤백 기능 추가
  • 배포 성공 시점의 이미지 태그를 확인
  • CodeDeploy에서 해당 버전 재배포 트리거(이미지가 캐시 되어있어 빠른 복구 가능)
  • 이미지 Pull 후 즉시 복구 가능

컨테이너 환경의 동적 특성을 고려하여 리소스 낭비, 장애 감지를 할 수 있는 시스템 구축 필요

• AI 서비스(FastAPI)

  • cpus: "1:0" : CPU 1코어 이상 점유 금지하여 타 서비스의 리소스 고갈 방지

  • mem_limit: "2g" : 메모리 누수시의 OOM 유도하여 전체 시스템 다운 방지

  • GPU 사용 시 docker-compose.yml 파일 내부에 자원을 명시하여 연결

    services:
      ai-service:
        image: devths/ai-service:v1
        deploy:
          resources:
            reservations:
              devices:
                - driver: nvidia
                  count: 1 
                  capabilities: [gpu]

• BE 서비스(Spring Boot)

  • mem_limit: "1g" : JVM Heap Size 고려하여 설정 필요

• gpu 설정

• 일시적 오류, OOM Kill로 인한 컨테이너 종료 발생시, 빠른 재시작으로 복구하여 가용성 유지 필요
• restart: always 옵션 설정 필요

• 매 배포 시점마다 새로운 이미지를 Pull 해오면 이미지 누적으로 디스크 공간을 차지하게 됨
• 배포 스크립트 마지막에 누적 이미지 pruning 스크립트를 추가하여 Disk Full 장애 방지
• docker system prune -a -f --volumes

• 컨테이너 복구, 배포 후 트래픽 전달을 위해 각각 다른 헬스 체크 방식을 사용

컨테이너가 종료되면 내부 데이터는 함께 사라지게 됨.

로그의 분석및 디버깅을 위한 로그 영속화 전략이 필요

• PLG 스택을 통해 모니터링 하지만, Loki 서버 에러 발생 시 문제 발생 가능성 (로그 전송 대기, 로그 유실)
• 모니터링 툴 장애 발생 시 로그 확인 불가하면 디버깅 및 장애 대응 불가
• 컨테이너 내부 /logs 디렉토리를 호스트 인스턴스의 /var/log/apps/{BE/AI} 에 마운트하여 저장
• 이후 로그 수집기(Promtail)이 파일을 읽어 Loki로 전송

• 호스트 인스턴스 EC2의 logrotate 유틸을 사용하여 일별 압축 및 14일 경과 시 삭제.

• 로그 로테이트 설정 스크립트 /ect/logrotate.d/devth-apps

  #경로내 모든 로그 파일 대상
  /home/ubuntu/logs/**/*.log {
      daily             # 매일 실행
      rotate 14         # 14일치 보관
      missingok         # 파일 없어도 에러 무시
      notifempty        # 빈 파일은 로테이션 안 함
      compress          # 압축 (gzip)
      delaycompress     # 압축을 하루 미룸 (현재 쓰고 있는 파일 보호)
      copytruncate      # 파일을 복사 후 원본을 비움 (앱 재시작 없이 로그 분리)
      create 0644 ubuntu ubuntu
  }

• 제한 된 인프라 리소스 내에서 여러 서비스가 자원 간섭을 일으키지 않고, 정상적으로 응답하여 UX를 보장해야함.
• 애플리케이션 성능 모니터링 필요(API 응답, 에러율, 응답 시간 등)
• 비즈니스 로직 및 데이터 무결성에 대한 모니터 ( 요청 대비 성공률, 추후 MQ 도입 시 쌓인 메시지 수, DLQ 수)
• 운영 효율성 및 비용 (로그 관리 중앙화, 비용 모니터링)

• PLG(Prometheus + Loki + Grafana)
• ELK 대비 적은 리소스 사용으로 모니터링 위한 리소스 최소화

1. 인프라: EC2 인스턴스 별 CPU, Memory, Disk I/O 사용량 , Network 송수신등 메트릭
2. 컨테이너
   • 컨테이너별 CPU/메모리 사용량 시각화
   • 지표: AI CPU%, AI RSS, BE P95 latency, WS 동시 연결 수, OOM Kill 횟수, 컨테이너 재시작 횟수
3. 애플리케이션
   • 지표: API 응답 속도, HTTP P95 Latency , Error Rate(5xx) 횟수 및 비율 , DB 연결 수

• 임계치 초과 시 Discord Webhook으로 즉시 통보(운영자가 “지금 뭐가 문제인지” 바로 판단)
• 장애 발생 후에만 알림을 보내는 것이 아니라, 장애 징후 발견 시 미리 알림
• 다양한 지표 알림을 통해 오류 대비 및 Failover를 할 수 있도록 함
• 메모리 80%도달시 경고, 90% 도달시 Critical 알림

• 가용성
  • 재시작 횟수: 1시간 내 재시작 3회 이상시 알림
  • HealthCheck: unhealthy 상태 지속 1분 이상 시 알림
• 성능
  • API 응답 속도: 2초 이상 시 알림(시스템 과부하 경고)
  • CPU 사용률 80% 이상 5분 이상 지속 (스케일 아웃 대비)
• 에러
  • HTTP 5xx: 1분간 에러율 1% 이상 시 알림 (서비스 장애, 외부 API 장애, DB 장애 가능성)
  • 특정 Log KeyWord: 즉시 대응 필요한 로그 알림 키워드 설정 (OutOfMemory , Deadlock 등)

컨테이너화 계층이 추가된 만큼, 추가적인 보안 사고 방지를 위한 방안 필요

• Non-root User로 실행: 잘못된 보안 설정으로 컨테이너 탈출을 통해 호스트 인스턴스의 루트 권한 획득을 방지해야 함
• 이미지 스캔: ECR의 Basic Scanning 기능을 활성화 하여 이미지 Push 시점에 OS 패키지 취약점 점검

각종 컨테이너, 서비스, DB의 데이터를 백업하여 안정성 확보

• 결론적으로 Docker는 Devths에서 단순 편의가 아니라, 트래픽 급증 시에도 핵심 기능을 안정적으로 제공하고 운영 보안을 강화하기 위한 실행 단위 표준화 전략으로 정의함.