[DevOps] 로그 Logrotate 관리

JUNYOUNG·2024년 11월 27일

실무 Spring, Python, DB, 인프라

목록 보기

4/15

Uvicorn과 FastAPI를 기반으로 서비스를 개발하면서, 서비스 운영에 있어 중요한 부분 중 하나인 로그 관리에 대해 깊이 고민했다. 특히, WAS(Web Application Server) 로그와 애플리케이션 로그를 어떻게 분리하고 관리할지에 대해 많은 시도를 했다. 처음에는 각 로그를 개별적으로 분리해서 관리하려 했지만, 실제로 운영 환경에서 로그를 분석하고 문제를 디버깅하는 과정을 시뮬레이션해본 결과, 로그를 통합 관리하는 것이 더 효율적이라는 결론에 도달했다.

로그 통합 관리의 필요성

로그를 통합 관리하기로 결정한 이유는 다음과 같다:

1. 문제 추적의 일원화

WAS 로그(Uvicorn)와 애플리케이션 로그를 별도로 관리하면, 문제가 발생했을 때 관련 로그를 각각 찾아 확인해야 한다. 예를 들어, 특정 요청에서 발생한 오류를 추적하려면 WAS 로그에서 요청 ID를 찾고, 다시 애플리케이션 로그에서 해당 ID와 관련된 에러를 찾아야 한다.

반면, 통합 로그 관리를 적용하면 요청부터 응답까지의 모든 흐름과 관련 오류를 한 파일에서 바로 확인할 수 있다. 이는 디버깅 시간 단축에 크게 기여하며, 특히 긴급 장애 상황에서 신속한 원인 파악이 가능하다.

2. 로그 분석의 편리성

운영 중에는 로그 데이터를 활용한 분석 작업이 자주 필요하다. 분리된 로그는 데이터를 결합하거나 상호 참조하는 추가 작업이 필요하며, 이 과정에서 불필요한 시간과 리소스가 낭비된다.

반면, 통합 로그는 단일 파일로 제공되므로 분석 도구나 스크립트를 사용해 효율적으로 데이터를 처리할 수 있다. 이는 특히 SLA(Service Level Agreement) 보고서 작성이나 성능 최적화 작업에서 큰 장점으로 작용한다.

3. 디스크 사용량 최적화

별도로 관리되는 로그는 중복 데이터가 포함되거나, 필요하지 않은 정보까지 저장되는 경우가 많다. 이는 디스크 사용량 증가와 함께 운영 비용 상승으로 이어진다.

통합 로그를 적용하면 중복 데이터를 제거하고, 필요한 데이터만 저장할 수 있어 디스크 사용량이 최적화된다. 특히 대규모 트래픽을 처리하는 서비스에서는 이런 최적화가 비용 절감으로 직결된다.

4. 운영 환경 단순화

분리된 로그를 관리하려면 각 로그의 설정, 파일 경로, 회전 주기, 압축 정책 등을 따로 관리해야 한다. 이는 설정 과정뿐만 아니라 유지보수 시에도 복잡성을 증가시킨다.

통합 로그 관리는 구성 및 유지보수를 단순화하며, 설정 변경 시 한 곳에서 관리가 가능하다. 이는 운영 부담을 줄이고, 변경 사항 적용 속도를 높인다.

실제 적용한 Logrotate 설정

로그를 통합 관리하되, 에러 로그는 별도로 관리할 수 있도록 설정했다. 아래는 현재 적용 중인 logrotate 설정 파일이다:

/home/ubuntu/<project>/backend/log/uvicorn/*.log
/home/ubuntu/<project>/backend/log/application/*.log {
    # 로그를 매일 분리
    daily

    # 로그 파일 이름에 날짜 추가
    dateext

    # 날짜 형식 지정 (예: YYYY-MM-DD)
    dateformat -%Y-%m-%d

    # 최근 7일치 로그만 유지
    rotate 7

    # 오래된 로그를 gzip으로 압축
    compress

    # 파일이 없어도 에러를 내지 않음
    missingok

    # 로그 파일이 비어 있으면 처리하지 않음
    notifempty

    # 새 로그 파일 생성 시 권한과 소유자 설정
    create 0644 ubuntu ubuntu

    # Uvicorn 로그 파일을 분리 후 서비스 재시작
    postrotate
        systemctl restart lemon.service
    endscript
}

이 설정은 다음과 같은 특징을 가진다:

일일 로그 회전(daily): 하루 단위로 로그를 분리하여 관리.
로그 보존 기간(rotate 7): 최근 7일치 로그만 유지하여 디스크 공간을 효율적으로 사용.
압축(compress): 오래된 로그를 gzip으로 압축하여 저장 공간 절약.
파일 존재 유무 확인(missingok): 로그 파일이 없을 경우 에러 없이 건너뜀.
로그 파일 권한 설정(create): 새로운 로그 파일 생성 시 소유자와 권한을 지정.

최종 로그 관리 구조

현재 서비스의 로그 파일 구조는 다음과 같다:


/home/ubuntu/<project>/backend/log/
├── application/
│   ├── application.log       # WAS(Uvicorn)와 애플리케이션 로그 통합
│   ├── error.log             # 애플리케이션에서 발생한 에러 로그
├── uvicorn/
│   ├── uvicorn_access.log    # WAS 요청/응답 로그
│   ├── uvicorn_error.log     # WAS에서 발생한 에러 로그

이 구조의 장점은 다음과 같다:

통합 관리: application.log는 Uvicorn과 애플리케이션 로그를 통합하여 디버깅과 분석 작업을 간소화.
유연성: 특정 로그만 필요할 경우, error.log나 uvicorn_access.log처럼 개별 로그 파일에서 필요한 정보를 확인 가능.
확장성: 서비스 규모가 커지더라도 새로운 로그를 추가하거나 디렉토리 구조를 확장하기 쉽다.