로그 데이터 통합 관리: ELK 스택 구축 및 Kibana 시각화로 로그 지옥 탈출하기

JavaScript AWS Database 로그 데이터 통합 관리: ELK 스택 구축 및 Kibana 시각화로 로그 지옥 탈출하기 ⏱️ 읽는 시간: 약 8분 | 📊 3,807자 📑 목차 1. 개발자의 악몽, 분산된 로그의 늪에서 우아하게 탈출하기 2. 1. ELK Stack: 왜 하필 이 조합인가? (아키텍처의 미학) 3. 2. 로그스태시(Logstash) 심층 분석: 비정형 로그를 정복하라 개발자의 악몽, 분산된 로그의 늪에서 우아하게 탈출하기 안녕하세요. 15년 차 백엔드 개발자이자, 여러분과 함께 밤새워 코드를 고민하는 멘토입니다. 오늘은 조금 무거운 주제일 수도 있지만, 실무에서 가장 중요한 '생존 기술' 중 하나인 로그 관리에 대해 깊이 있게 이야기해 보려 합니다. 혹시 이런 경험 없으신가요? 금요일 오후 5시, 퇴근을 준비하는데 고객센터에서 "결제가 안 돼요!"라는 긴급 클레임이 들어옵니다. 식은땀을 흘리며 서버에 접속합니다. 그런데 서버가 10대네요? 터미널 창을 10개 띄워놓고 tail -f catalina.out 을 치며 눈이 빠져라 에러 로그를 찾습니다. 텍스트가 폭포수처럼 흘러가고, "이 서버가 아닌가? 저 서버인가?" 하다가 결국 30분이 지나서야 겨우 로그 한 줄을 발견합니다. "NullPointerException". 허탈하죠. 원인을 찾았을 때는 이미 고객들의 불만이 폭주한 뒤입니다. 저는 주니어 시절, 이 '로그 찾아 삼만리' 때문에 여자친구와의 기념일 저녁 약속을 세 번이나 어겼던 뼈아픈 기억이 있습니다. ☕ 커피를 아무리 마셔도 해결되지 않는 피로감과 자괴감은 덤이었...

도커 컨테이너 로그 용량 계속 늘어날 때 용량 제한 설정하는 방법으로 디스크 부족 해결하고 서버 지키기

도커 컨테이너 로그 용량 계속 늘어날 때 용량 제한 설정하는 방법으로 디스크 부족 해결하고 서버 지키기

도커 로그가 디스크를 다 먹어치웠던 그날 밤의 악몽

혹시 새벽 3시에 모니터링 알람 소리에 깨보신 적 있으신가요? 저는 10년 차가 된 지금도 그 소리만 들으면 심장이 덜컥 내려앉습니다. 몇 년 전, 정말 황당하면서도 부끄러운 경험을 한 적이 있어요. 잘 돌아가던 서비스가 갑자기 500 에러를 뿜어내며 멈춰버린 거죠. 급하게 SSH로 서버에 접속하려고 했는데, 접속조차 되지 않았습니다. 겨우겨우 콘솔로 접근해서 확인해보니 원인은 너무나 허무하게도 'Disk Full'이었습니다.

"아니, 데이터베이스 서버도 아니고 웹 애플리케이션 서버가 왜 디스크가 꽉 차지?"라고 생각하며 du -sh * 명령어로 범인을 찾아 나섰죠. 범인은 바로 /var/lib/docker 디렉터리였습니다. 그중에서도 컨테이너 로그 파일 하나가 무려 80GB를 차지하고 있더군요. 개발 단계에서 디버깅하려고 찍어뒀던 무수한 로그들이 운영 환경에서도 그대로 출력되고 있었고, 도커는 그걸 아무런 제한 없이 파일로 저장하고 있었던 겁니다. 오늘은 저처럼 이런 황당한 사고를 겪지 않도록, 도커 컨테이너 로그 용량을 제한하는 방법에 대해 아주 상세하게, 그리고 동료에게 이야기하듯 풀어보려 합니다.

도대체 왜 도커는 로그를 무한정 저장하는 걸까요?

기본 로깅 드라이버 json-file의 비밀

우리가 도커를 처음 설치하고 아무런 설정을 건드리지 않으면, 도커는 기본적으로 json-file이라는 로깅 드라이버를 사용합니다. 이게 무슨 말이냐면, 컨테이너 내부에서 발생하는 표준 출력(STDOUT)과 표준 에러(STDERR)를 도커 데몬이 낚아채서 호스트 머신의 어딘가에 JSON 형태의 파일로 차곡차곡 쌓아둔다는 뜻입니다.

문제는 이 '차곡차곡'이 끝이 없다는 점입니다. 리눅스 시스템의 logrotate 같은 기능이 도커 내부적으로 기본 활성화되어 있지 않기 때문이죠. 개발자가 명시적으로 "이만큼만 저장해!"라고 말해주지 않으면, 도커는 디스크가 터질 때까지 충직하게 로그를 기록합니다. 특히 console.log()System.out.println()을 남발하는 애플리케이션이라면, 텍스트 파일 하나가 기가바이트 단위로 커지는 건 순식간입니다.

컨테이너는 사라져도 로그 파일은 남을까?

많은 분들이 오해하는 것 중 하나가 "컨테이너를 재시작하면 로그도 초기화되겠지?"라는 생각입니다. 반은 맞고 반은 틀립니다. 컨테이너를 완전히 삭제(rm)하고 다시 실행(run)하면 새로운 로그 파일이 생성되지만, 단순히 docker restart를 하거나 컨테이너가 멈춰있는 상태라면 그 거대한 로그 파일은 디스크에 그대로 남아있습니다.

실제로 제가 겪었던 프로젝트에서는 무한 루프에 빠진 로직이 1초에 수십 번씩 에러 로그를 뱉어내고 있었습니다. 주말 동안 아무도 모르게 로그 파일은 100GB를 넘겨버렸고, 월요일 아침에 출근해보니 서버는 응답 불능 상태였죠. 이처럼 로그 용량 제한은 '하면 좋은 옵션'이 아니라 운영 환경에서는 '필수 생존 전략'입니다.

방법 1: 컨테이너 실행할 때 옵션으로 제한하기 (일회성)

가장 직관적이고 빠르게 적용할 수 있는 방법부터 알아볼까요? 바로 docker run 명령어를 실행할 때 로그 옵션을 같이 주는 겁니다. 테스트 용도나 일회성 컨테이너를 띄울 때 유용합니다.

--log-opt 옵션의 마법

우리가 사용해야 할 핵심 옵션은 두 가지입니다. 바로 max-sizemax-file입니다. 이 두 가지는 바늘과 실처럼 항상 같이 다녀야 효과가 좋습니다.

docker run -d \
--log-driver json-file \
--log-opt max-size=10m \
--log-opt max-file=3 \
--name my-app \
my-image:latest

위 명령어가 무슨 뜻인지 하나씩 뜯어볼까요?

  • max-size=10m: 로그 파일 하나의 크기가 10MB를 넘지 못하게 합니다. 10MB가 되면 도커는 파일을 닫고 새로운 파일을 준비합니다. 단위는 k(킬로바이트), m(메가바이트), g(기가바이트)를 사용할 수 있습니다.
  • max-file=3: 로그 파일을 최대 3개까지만 보관하라는 뜻입니다. 이게 정말 중요합니다.

로그 로테이션(Rotation)의 원리

🔎 관련 상품 추천

아래 링크를 통해 구매 시 운영자에게 일정 수수료가 발생할 수 있습니다.

도커 컨테이너 로그 용량 계속 늘어날 때 용량 제한 설정하는 방법

'도커 컨테이너 로그 용량 계속 늘어날 때 용량 제한 설정하는 방법' 관련 상품을 쿠팡에서 확인해 보세요.

상품 보러가기 →

댓글

이 블로그의 인기 게시물

VS Code에 GitHub Copilot 연동해서 코딩 생산성 높이는 설정 가이드 완벽 정복

Kubernetes란 무엇인가?

해외여행 이심 데이터 안 터질 때 데이터 로밍 차단과 APN 설정 점검으로 네트워크 연결 완벽 해결