모니터링 스택을 구성하는 여러 서비스에 `restart: always` 정책을 추가했습니다. 이를 통해 컨테이너가 예기치 않게 종료되었을 때 자동으로 재시작되도록 하여 시스템의 안정성을 높였습니다.

monitoring: Prometheus 및 Grafana 관련 서비스 재시작 정책 설정

이번 커밋은 docker-compose.yml 파일을 수정하여 Prometheus, Node Exporter, Loki, Promtail, Grafana 등 모니터링 스택을 구성하는 여러 서비스에 restart: always 정책을 추가했습니다. 이를 통해 컨테이너가 예기치 않게 종료되었을 때 자동으로 재시작되도록 하여 시스템의 안정성을 높였습니다.

요약

이번 작업은 docker-compose.yml 파일에 restart: always 설정을 추가하여 모니터링 스택의 서비스들이 예기치 않게 중단되었을 때 자동으로 재시작되도록 구성했습니다. 이를 통해 시스템의 가용성과 안정성을 향상시킬 수 있습니다. 작업은 2026년 2월 5일에 완료되었습니다.

배경 및 목적

현재 운영 중인 모니터링 스택은 Docker Compose를 통해 관리되고 있습니다. 그러나 특정 서비스의 장애나 서버 재부팅과 같은 예기치 못한 상황 발생 시, 해당 서비스가 자동으로 복구되지 않는 문제가 있었습니다. 이는 모니터링 시스템의 가용성에 직접적인 영향을 미치며, 데이터 손실이나 장애 감지 지연으로 이어질 수 있습니다.

이러한 문제를 해결하기 위해, 본 작업은 각 모니터링 서비스 컨테이너에 restart: always 정책을 적용하여, 컨테이너가 중단될 경우 Docker 데몬이 자동으로 해당 컨테이너를 재시작하도록 설정하는 것을 목표로 합니다. 이를 통해 모니터링 시스템의 안정성과 가용성을 크게 향상시킬 수 있습니다.

구현 내용

이번 작업은 docker-compose.yml 파일 하나만을 수정했습니다. 총 5줄의 코드가 추가되었으며, 삭제된 코드는 없습니다.

변경된 파일 목록

docker-compose.yml

추가/삭제 라인 수

추가 라인: 5
삭제 라인: 0

핵심 코드 설명

docker-compose.yml 파일의 각 서비스 정의 부분에 restart: always 라인이 추가되었습니다. 예를 들어, Prometheus 서비스의 경우 다음과 같이 수정되었습니다.

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    volumes:
      - ./prometheus:/etc/prometheus/
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
    networks:
      - monitoring
    restart: always # 이 라인이 추가되었습니다.

  node-exporter:
    image: prom/node-exporter:latest
    container_name: node-exporter
    volumes:
      - /:/host:ro
    command:
      - '--path.procfs=/host/proc'
      - '--path.sysfs=/host/sys'
      - '--web.listen-address=0.0.0.0:9100'
      - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
    networks:
      - monitoring
    restart: always # 이 라인이 추가되었습니다.

  loki:
    image: grafana/loki:latest
    container_name: loki
    ports:
      - "3100:3100"
    volumes:
      - ./loki:/etc/loki/
      - loki_data:/loki
    command: -config.file=/etc/loki/local-config.yaml
    networks:
      - monitoring
    restart: always # 이 라인이 추가되었습니다.

  promtail:
    image: grafana/promtail:latest
    container_name: promtail
    volumes:
      - ./promtail:/etc/promtail/
    depends_on:
      - loki
    networks:
      - monitoring
    restart: always # 이 라인이 추가되었습니다.

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    depends_on:
      - prometheus
      - loki
    networks:
      - monitoring
    restart: always # 이 라인이 추가되었습니다.

networks:
  monitoring:
    driver: bridge

위와 같이 Prometheus, Node Exporter, Loki, Promtail, Grafana 총 5개의 서비스에 restart: always 옵션이 적용되었습니다.

기술적 의사결정

이번 작업에서 restart: always 정책을 선택한 이유는 Docker Compose가 제공하는 가장 직관적이고 강력한 컨테이너 재시작 전략이기 때문입니다.

기술/라이브러리 선택

Docker Compose restart 정책: Docker Compose 설정 파일(docker-compose.yml) 내에서 각 서비스에 적용할 수 있는 옵션입니다.

선택 이유

restart: always는 컨테이너가 시작된 후 어떤 이유로든 종료되면 Docker 데몬이 항상 컨테이너를 다시 시작하도록 지시합니다. 이는 모니터링 시스템과 같이 지속적으로 실행되어야 하는 서비스에 매우 적합합니다.

다른 대안 및 비교

Docker Compose는 다음과 같은 다른 restart 정책도 제공합니다.

no (기본값): 컨테이너가 종료되면 자동으로 재시작하지 않습니다.
on-failure: 컨테이너가 비정상 종료 코드(0이 아닌 종료 코드)로 종료될 때만 재시작합니다.
unless-stopped: 컨테이너가 수동으로 중지되지 않는 한, 종료 시 항상 재시작합니다. Docker 데몬이 재시작되어도 컨테이너는 다시 시작됩니다.

always vs unless-stopped:
unless-stopped는 컨테이너를 수동으로 docker-compose stop 등으로 중지시킨 경우에는 재시작하지 않습니다. 하지만 always는 수동 중지 이후에도 Docker 데몬이 재시작되면 컨테이너를 재시작합니다. 모니터링 시스템의 경우, 운영자의 실수로 인한 중단 후에도 자동으로 복구되는 것이 더 안정적일 수 있다고 판단하여 always를 선택했습니다. 만약 특정 상황에서 수동 중지를 유지해야 한다면 unless-stopped도 좋은 대안이 될 수 있습니다.

always vs on-failure:
on-failure는 정상적인 종료(종료 코드 0)에는 재시작하지 않습니다. 예를 들어, 애플리케이션 자체에서 정상적으로 종료 명령을 받았을 경우입니다. 하지만 모니터링 시스템에서는 예상치 못한 오류로 인한 중단이 더 큰 문제이므로, 오류 발생 시 무조건 재시작하는 always가 더 강력한 복구 기능을 제공합니다.

장단점 분석

장점:
- 높은 가용성: 컨테이너 중단 시 자동 재시작으로 시스템의 지속적인 운영 보장
- 간편한 설정: docker-compose.yml 파일에 한 줄만 추가하면 됨
- 안정성 증대: 예기치 못한 오류나 서버 재부팅 시 자동으로 복구
단점:
- 무한 루프 가능성: 만약 컨테이너가 시작되자마자 계속해서 오류를 발생시키며 종료되는 경우, 무한 재시작 루프에 빠질 수 있습니다. 이는 시스템 자원을 소모하거나 다른 문제를 야기할 수 있습니다. (이 경우, 각 서비스의 로그를 면밀히 모니터링하고 근본적인 원인을 파악하여 해결해야 합니다.)

배운 점 및 개선점

이번 작업을 통해 Docker Compose의 restart 정책의 중요성과 always 옵션이 시스템 안정성에 얼마나 기여할 수 있는지 다시 한번 깨달았습니다. 단순히 컨테이너를 띄우는 것을 넘어, 안정적인 운영을 위한 이러한 설정이 필수적임을 배웠습니다.

앞으로 개선할 점

모니터링 강화: restart: always 설정만으로는 완벽하지 않습니다. 컨테이너가 실제로 계속해서 정상 작동하는지, 아니면 재시작 루프에 빠지지는 않는지를 감지하고 알림을 주는 별도의 모니터링 시스템을 구축하는 것이 필요합니다.
재시작 횟수 제한: always 옵션은 무한 재시작을 보장하지만, 너무 잦은 재시작은 오히려 좋지 않을 수 있습니다. Docker Compose 또는 Docker 자체에서 재시작 횟수를 제한하거나 딜레이를 주는 옵션(예: max_retries 등, Docker Swarm 등 고급 기능에서 제공)을 고려해볼 수 있습니다. (현재 Docker Compose 단일 환경에서는 이러한 세밀한 제어가 제한적입니다.)
개별 서비스별 정책: 모든 서비스에 동일한 restart 정책을 적용하기보다, 서비스의 중요도나 특성에 따라 다른 정책을 적용하는 것을 고려할 수 있습니다. (예: 중요도가 낮은 서비스는 on-failure 적용)

다음 단계 계획

로그 분석 시스템 구축: Prometheus, Loki, Grafana를 활용하여 각 컨테이너의 로그를 중앙 집중식으로 수집하고 분석하는 시스템을 더욱 강화할 계획입니다. 이를 통해 재시작 원인을 신속하게 파악할 수 있습니다.
알림 시스템 연동: 이상 징후(예: 잦은 재시작, 에러 로그 증가) 발생 시 관리자에게 알림을 보내는 시스템(예: Alertmanager)을 구축하여 선제적으로 대응할 것입니다.
헬스 체크 도입: 각 서비스에 대한 헬스 체크 API를 구현하고, 이를 Docker Compose 또는 별도 모니터링 도구에서 주기적으로 확인하여 서비스의 정상 작동 여부를 판단하도록 개선할 예정입니다.

참고 자료

Docker Compose documentation - restart policies