MongoDB 감사 로그 정리·복구 워크플로우를 S3 백업으로 자동화

발행: (2026년 5월 27일 PM 06:24 GMT+9)
12 분 소요
원문: Dev.to

Source: Dev.to

데이터베이스 성장 관리

데이터베이스 성장 관리는 백엔드 인프라에서 가장 간과되기 쉬운 과제 중 하나입니다. 처음에는 모든 것이 원활하게 동작하지만, 시간이 지나면서 auditlogs 같은 컬렉션이 급격히 커집니다. 로그인 시도, API 요청, 상태 변경, 시스템 활동 등이 지속적으로 저장됩니다.

결국 데이터베이스가 커지고, 쿼리가 느려지며, 스토리지 사용량이 증가하고, 백업이 완료되는 데 더 오래 걸리게 됩니다. 바로 이런 종류의 운영 문제가 많은 프로덕션 시스템에서 발생합니다.

목표

프로덕션 환경에서의 목표는 간단했습니다:

  • 오래된 auditlogs 자동 정리
  • 삭제 전에 백업 보관
  • 백업을 Amazon S3에 안전하게 저장
  • 복구 워크플로우가 정상 작동하는지 확인
  • cron 으로 전체 프로세스 자동화

로그를 수동으로 내보내고 컬렉션을 반복적으로 정리하는 대신, Bash 스크립트, MongoDB 도구, AWS S3, cron 작업을 활용해 완전 자동화된 백업‑정리 워크플로우로 전환했습니다. 이 설정은 MongoDB 운영을 보다 안전하고 프로덕션에 적합한 유지보수 프로세스로 만들어 줍니다.


왜 Auditlogs는 별도 처리가 필요한가

감사 로그는 애플리케이션 내부에서 추적성을 제공하기 때문에 중요합니다. 팀은 이를 통해 다음을 수행합니다:

  • 사용자 활동 추적
  • 시스템 이벤트 모니터링
  • 사고 조사
  • 프로덕션 이슈 디버깅
  • 컴플라이언스 기록 유지

하지만 auditlogs는 대부분의 시스템에서 가장 빠르게 성장하는 컬렉션 중 하나입니다. userstransactions 와 같은 비즈니스 핵심 컬렉션과 달리, auditlogs는 보통 append‑only 데이터입니다. 새로운 레코드는 계속 삽입되지만, 오래된 레코드는 거의 접근되지 않습니다.

이 로그를 절대 정리하지 않으면:

  • 데이터베이스 크기가 지속적으로 증가
  • 디스크 사용량 증가
  • 백업 파일 크기 확대
  • 쿼리 성능 저하 가능성
  • 인프라 비용 상승

일반적인 완화 방안

  • 로그 보존 정책
  • 정기 정리 작업
  • 백업 아카이브 시스템

이 워크플로우에서는 MongoDB에서 auditlogs를 삭제하기 전에 장기 백업 저장소로 Amazon S3를 사용합니다.


백업 & 정리 워크플로우 설계

워크플로우는 한 가지 중요한 원칙을 중심으로 설계되었습니다:

복구 가능한 백업을 만든 뒤에만 데이터를 삭제한다.

프로세스 순서는 다음과 같습니다:

  1. auditlogs 컬렉션 덤프
  2. 백업 압축
  3. Amazon S3에 업로드
  4. 업로드 성공 여부 검증
  5. MongoDB에서 auditlogs 삭제
  6. 로컬 임시 파일 삭제

이렇게 하면 정리 작업이 진행된 뒤에도 백업을 복구할 수 있습니다. 자동화는 mongodb-testing 서버에서 안전하게 실행된 뒤 프로덕션에 적용됩니다.


Auditlogs 백업용 S3 버킷 만들기

첫 번째 단계는 Amazon S3 버킷을 준비하는 것입니다. 버킷은 압축된 MongoDB 백업을 위한 중앙 클라우드 스토리지 역할을 합니다.

예시 버킷

s3://incoming-auditlogs-backup

S3를 사용하면 다음과 같은 장점이 있습니다:

  • 내구성 높은 백업 스토리지
  • 저비용 아카이브
  • 손쉬운 복구 절차
  • 안전한 클라우드 기반 보존
  • 프로덕션 DB와 백업 스토리지 간 분리

백업을 서버 로컬에 저장하는 대신, EC2 인스턴스가 장애가 나도 백업이 보호됩니다.


Bash 자동화 스크립트 만들기

자동화의 핵심은 다음 경로에 위치한 Bash 스크립트입니다:

/home/ubuntu/auditlogs-dump.sh

이 스크립트는 전체 라이프사이클을 자동화합니다:

  • 백업
  • 압축
  • 업로드
  • 정리

설정 변수

MONGO_HOST="localhost"
MONGO_PORT="2707"
MONGO_DB="incoming"
MONGO_COLLECTION="auditlogs"

위 변수들은 MongoDB 호스트, 포트, 데이터베이스, 컬렉션을 정의해 스크립트를 재사용 가능하고 유지보수가 쉽도록 합니다.

S3 대상 & 백업 파일명

S3_BUCKET="s3://incoming-auditlogs-backup"
BACKUP_NAME="auditlogs_backup_$(date +%F_%H-%M-%S)"

파일명에 타임스탬프를 넣는 이유는:

  • 각 백업이 고유해짐
  • 오래된 백업이 보존됨
  • 복구가 쉬워짐
  • 연대기적 추적이 가능해짐

예시 백업 이름:

auditlogs_backup_2025-08-19_02-00-01

MongoDB 컬렉션 덤프

스크립트 내부 첫 번째 작업은 mongodump 를 이용해 MongoDB 덤프를 만드는 것입니다.

mongodump \
  --host "$MONGO_HOST" \
  --port "$MONGO_PORT" \
  --db "$MONGO_DB" \
  --collection "$MONGO_COLLECTION" \
  --out "$DUMP_PATH"

mongodump 는 컬렉션을 BSON 파일로 내보내며, 이후 mongorestore 로 복구할 수 있습니다. auditlogs 컬렉션만 백업하면 백업 크기가 작아지고, 업로드 속도가 빨라지며, 복구도 간편해집니다—특히 급격히 성장하는 컬렉션에 유리합니다.


백업 압축

덤프가 완료되면 백업을 .tar.gz 아카이브로 압축합니다.

tar -czf "$DUMP_PATH.tar.gz" -C /tmp "$BACKUP_NAME"

압축이 중요한 이유:

  • 스토리지 사용량 감소
  • 업로드 속도 향상
  • 전송 대역폭 절감

백업이 빈번히 발생하는 프로덕션 환경에서는 압축을 통해 장기적으로 인프라 비용을 크게 절감할 수 있습니다.


Amazon S3에 백업 업로드

압축이 끝나면 AWS CLI 로 S3에 업로드합니다.

aws s3 cp "$DUMP_PATH.tar.gz" "$S3_BUCKET/$BACKUP_NAME.tar.gz" --profile "$AWS_PROFILE"

이 단계는 정리 작업을 시작하기 전에 오프사이트 백업 복사본을 생성합니다. AWS CLI 프로파일을 사용하는 것은 자격 증명을 분리하고 관리하기 쉬워 좋은 운영 관행입니다.

프로파일 설정 예시

aws configure --profile s3

스크립트에 접근 키를 직접 하드코딩하지 않고도 안전하게 인증할 수 있습니다.


스크립트의 나머지 부분(업로드 검증, MongoDB 컬렉션 삭제, 임시 파일 정리)은 동일한 ‘안전 우선’ 패턴을 따르며, 데이터를 삭제하기 전에 유효한 백업이 존재함을 확인합니다.

스크립트

Auditlogs 컬렉션 정리

백업 업로드가 성공하면 스크립트는 MongoDB 컬렉션을 정리합니다.

mongosh --host $MONGO_HOST --port $MONGO_PORT $MONGO_DB \
  --eval "db.getCollection('$MONGO_COLLECTION').deleteMany({})"

이 명령은 auditlogs 컬렉션 안의 전체 문서를 삭제합니다.

이 단계에서의 결과

  • 백업은 이미 S3에 존재
  • 데이터는 복구 가능
  • 데이터베이스 크기가 감소

위와 같이 위험한 직접 삭제가 아니라 통제된 정리 워크플로우를 구현합니다.


임시 파일 삭제

마지막 단계에서는 로컬 서버에 남아 있는 임시 백업 파일을 삭제합니다.

rm -rf "$DUMP_PATH" "$DUMP_PATH.tar.gz"

이 작업이 중요한 이유:

  • 백업 파일이 서버 디스크를 크게 차지할 수 있음
  • 저장소 고갈 방지
  • 서버 청결 유지
  • 운영 위험 감소

정리를 통해:

  • 스토리지 고갈 방지
  • 서버 위생 유지
  • 운영 리스크 감소

스크립트는 성공 메시지를 출력하며 완료를 알립니다.


스크립트 실행 권한 부여

실행하기 전에 스크립트에 실행 권한을 부여해야 합니다.

sudo chmod +x /home/ubuntu/auditlogs-dump.sh

권한이 없으면 Linux에서 스크립트를 직접 실행할 수 없습니다.


자동화 전 수동 테스트

자동화를 스케줄링하기 전에 스크립트를 반드시 수동으로 테스트해야 합니다.

/home/ubuntu/auditlogs-dump.sh

수동 검증이 중요한 이유:

  • MongoDB 덤프가 정상 동작하는지 확인
  • 압축이 성공했는지 확인
  • S3 업로드가 정상인지 확인
  • 컬렉션 정리가 올바르게 수행되는지 확인
  • 임시 파일이 제대로 삭제되는지 확인

프로덕션 환경에서는 Cron 작업을 활성화하기 전에 수동 테스트를 반드시 수행하는 것이 핵심 베스트 프랙티스입니다.


Cron 으로 정리 자동화

검증이 끝나면 Cron 을 이용해 정기 실행을 스케줄링합니다.

요구 사항

  • 2일마다 실행
  • MMT 기준 새벽 2시 00분에 실행

Cron 설정

crontab -e

다음 라인을 추가합니다:

0 2 */
0 조회
Back to Blog

관련 글

더 보기 »