운영 로그 관리 실전

1. 개요

서비스 운영 중 장애가 발생하면 가장 먼저 해야 할 일은 관련 로그를 빠르고 정확하게 확인하는 것입니다.

실패한 거래가 언제 발생했는지, 어떤 요청과 응답이 오갔는지, 내부 어느 처리 단계에서 오류나 지연이 시작됐는지를 확인할 수 있어야 장애 원인을 빠르게 좁히고 적절한 조치를 결정할 수 있습니다.

문제는 장애가 발생했을 때 필요한 로그를 바로 확인하기 어려운 경우가 적지 않다는 점입니다. 요청·응답 정보와 내부 처리 흐름을 하나의 기준으로 연결해 볼 수 없거나, 로그 설정과 보관 정책이 일관되지 않으면 오류 원인과 영향 범위를 파악하는 데 많은 시간이 소요될 수 있습니다.

결국 운영 로그의 핵심은 필요한 로그를 적절한 수준으로 남기고 필요한 순간에 빠르게 확인할 수 있도록 관리하는 것입니다.

2. 로그 분석 시 가장 먼저 확인해야 할 사항

장애가 발생하면 운영자는 아래와 같은 질문에 답할 수 있어야 합니다.

어떤 거래가 언제 발생했는가?
거래를 식별할 수 있는 거래 ID, GUID 등의 값은 무엇인가?
요청과 응답 데이터는 무엇이었으며 오류 반환 코드는 무엇인가?
어느 서버·인스턴스·Pod에서 처리되었는가?
내부 어느 계층 또는 어느 처리 지점에서 오류나 지연이 발생했는가?
동일한 문제가 특정 거래, 특정 시간대, 특정 서버·인스턴스·Pod에서 반복되는가?
현재 기록된 로그만으로 원인 분석이 가능한가, 아니면 로그 레벨을 일시적으로 조정해 추가 정보를 확보해야 하는가?

이 질문에 빠르게 답하지 못하면 장애 대응은 경험이나 추측에 의존하게 됩니다. 특히 온라인 서비스에서는 요청·응답 정보와 내부 처리 흐름을 하나의 기준으로 연결하여 확인할 수 있어야 장애 원인을 빠르게 좁힐 수 있습니다.

3. DevOn Framework 기반 온라인 거래의 로그 저장 및 조회 흐름

DevOn Framework는 온라인 거래 과정에서 생성되는 로그를 체계적으로 저장하고, 거래 식별정보를 통해 관련 로그를 한 흐름으로 조회할 수 있도록 하여 장애 원인 분석을 용이하게 합니다.

DevOn Framework 기반 온라인 거래의 로그 저장·조회 구조

3.1 로그 저장

온라인 거래가 수행되면 입력 전문과 출력 전문의 원문 데이터를 거래로그 파일에 기록합니다. 이를 통해 장애 발생 시 실제 요청·응답 내용을 확인할 수 있습니다.
거래 검색에 필요한 거래 ID, GUID, 발생 시각, 처리 결과, 성공·실패 여부, 처리 서버 등의 메타 정보는 DB에 저장합니다. 검색을 위한 메타 정보와 거래 원문을 분리하여 저장함으로써 빠른 검색과 효율적인 원문 저장을 동시에 지원합니다.
주요 처리 지점의 내부 흐름은 Trace 로그로 기록하고, 애플리케이션과 프레임워크의 오류·경고·디버깅 정보는 시스템 로그로 기록합니다.

3.2 로그 조회

DevOn 운영관리의 로그조회 화면에서 거래로그 목록과 거래 ID, GUID, 발생 시각, 성공·실패 여부 등 검색용 메타 정보를 우선 조회합니다.
조회 결과에서 대상 거래를 식별한 뒤, 입력·출력 전문의 상세 원문이 필요한 경우 로그 Agent를 통해 해당 거래의 거래로그 파일을 조회합니다.
내부 처리 과정과 오류 발생 지점 분석이 필요한 경우 로그 Agent를 통해 해당 거래의 Trace 로그와 시스템 로그를 조회합니다.

이와 같은 로그 저장 및 조회 체계를 통해 운영자는 필요한 로그를 신속하게 확인하고, 장애 원인을 보다 정확하게 분석할 수 있습니다.

4. 운영 로그 관리 시 고려사항

운영 로그는 장애 분석에 필요한 정보를 충분히 제공해야 하지만, 과도하게 기록하면 저장 공간과 검색 부하가 증가하고 온라인 서비스 성능에도 영향을 줄 수 있습니다. 따라서 운영 환경에서는 로그의 기록 범위, 저장 방식, 보관 정책을 시스템 특성에 맞게 관리해야 합니다.

4.1 운영 환경의 로그 설정 정책

운영 환경에서는 평상시 필요한 로그만 기록하고, 상세 분석이 필요한 경우 대상 거래에 한해 일시적으로 로그 설정을 변경하는 방식이 효율적입니다.

기본 운영 원칙

입력·출력 전문: 장애 발생 시 실제 요청과 응답 내용을 확인할 수 있도록 기본적으로 기록합니다.
시스템 로그: 평상시에는 Error 레벨로 설정하고, 원인 분석에 추가 정보가 필요한 경우 일시적으로 Debug 등으로 조정합니다.
Trace 로그: 평상시에는 비활성화하고, 상세한 처리 과정 확인이 필요한 경우에만 제한적으로 활성화합니다.
운영 중 로그 설정 변경: 평상시에는 기본 로그 설정으로 운영하고, 장애 분석이 필요한 경우에만 대상 거래의 로그 설정을 일시적으로 변경하여 필요한 정보를 수집한 후 즉시 기본 설정으로 복원합니다.

DevOn 지원 기능

DevOn에서는 운영 중에도 다음 항목을 거래별로 변경할 수 있습니다.

입력 전문 저장 여부
출력 전문 저장 여부
시스템 로그 레벨
Trace 범위

애플리케이션 재배포나 서버 재기동 없이 변경 사항이 즉시 반영되므로, 평상시에는 최소한의 로그만 유지하고 필요한 경우에만 대상 거래의 로그를 상세하게 수집할 수 있습니다.

4.2 온라인 성능을 고려한 로그 운영

온라인 거래 처리 Thread가 로그 저장까지 수행하면 DB 또는 파일 저장 지연이 서비스 응답시간 증가로 이어질 수 있습니다. TPS가 높은 시스템일수록 온라인 거래 처리와 로그 저장을 분리하는 것이 중요합니다.

온라인 성능 영향 최소화 방안

메타 정보의 DB 저장은 별도 Thread의 Async 방식으로 처리하여 DB 저장 지연이 온라인 거래 응답시간에 미치는 영향을 줄이는 것이 좋습니다.
파일 로그의 기록 부하가 큰 경우에는 Async Appender 적용을 검토하여 파일 쓰기 작업을 온라인 거래 처리 Thread와 분리할 수 있습니다.

DevOn 지원 기능

DevOn에서는 필요에 따라 설정만 변경하면 메타 정보 저장을 별도 Thread의 Async 방식으로 적용할 수 있어, 온라인 거래 처리와 로그 저장을 분리하고 TPS가 높은 환경에서도 서비스 응답 성능에 미치는 영향을 최소화할 수 있습니다.

Async 방식 설정 예시

devon:
  compose:
    journal:
      pool:
        enabled: true
        core-size: 10
        max-size: 50
        queue-capacity: 10000
        keep-alive: 60
        allow-core-thread-timeout: true
        await-termination: true
        await-termination-period: 60
        rejection-policy: DISCARD

참고

파일 로그에 Async Appender를 적용하는 경우에는 Queue 포화 시 처리 방식, 로그 누락 가능성, 애플리케이션 종료 시 잔여 로그 처리 등을 고려해야 합니다. 또한 운영 환경과 동일한 조건에서 충분한 성능 테스트를 통해 응답 성능과 로그 기록의 안정성을 확인한 후 적용하는 것이 좋습니다.

4.3 On-Premise 환경 고려사항

On-Premise 환경에서는 로그 저장 공간을 운영자가 직접 관리해야 하므로 적절한 로그 보관 정책이 중요합니다. Rolling이나 보관 정책이 적절하지 않으면 저장 공간 부족으로 인해 애플리케이션 오류나 서비스 장애가 발생할 수 있습니다.

주요 관리 항목

관리 항목	점검 내용
저장 공간	로그 증가량 및 디스크 사용률 모니터링
Rolling 정책	파일 크기 또는 날짜 기준 Rolling 적용
보관 기간	로그 유형별 보관 기간 관리
삭제 정책	DB 메타 정보 및 로그 파일 주기적 삭제
접근 권한	로그 디렉터리 읽기·쓰기 권한 확인

DevOn 지원 기능

DevOn에서는 다음 기능을 지원합니다.

로그 Rolling 기준 설정
로그 보관 기간 설정
Batch Job을 이용한 오래된 로그 파일 및 DB 로그데이터 자동 삭제

이를 통해 저장 공간 부족으로 인한 운영 리스크를 줄일 수 있으며, 로그 디렉터리 접근 권한 점검 등 운영 절차를 함께 관리하여 안정적인 로그 운영 환경을 유지할 수 있습니다.

참고

DB 메타 정보는 남아 있는데 로그 파일이 삭제되면 운영관리 화면에서는 검색되지만 원문 조회가 불가능할 수 있으므로 보관 정책을 함께 관리해야 합니다.

4.4 Cloud 환경 고려사항

Cloud 환경에서는 Pod가 재생성되는 경우, 컨테이너 내부에 저장된 로그 파일은 Pod 종료와 함께 사라지게 됩니다. 이러한 특성 때문에 로그 파일을 유지해야 하는 경우에는 PVC/PV와 같은 영속 스토리지를 사용하거나, 별도의 로그 수집 체계를 통해 외부 저장소로 전달하는 구성이 일반적으로 고려됩니다.

로그 보관 방식

방식	특징
PVC/PV 사용	기존 파일 기반 조회 방식 유지
로그 수집 Agent	외부 저장소로 로그 전송

DevOn 지원 기능

DevOn은 운영 환경에 따라 다음과 같은 로그 관리 방식을 지원합니다.

PVC/PV 기반 로그 관리
- 거래로그와 Trace 로그 등의 로그 파일을 영속 스토리지(PVC/PV)에 저장합니다.
- 운영관리 화면을 통해 거래로그와 Trace 로그를 조회할 수 있습니다.
중앙 로그 관리 시스템 연계
- DevOn에서 생성한 로그를 다양한 로그 수집 Agent와 연계할 수 있습니다.
- 중앙 로그 관리 시스템(예: ELK, OpenSearch 등)과 연계하여 로그를 통합 관리할 수 있습니다.

이를 통해 Cloud 환경에서도 운영 방식에 따라 DevOn 운영관리 화면 또는 중앙 로그 관리 시스템을 활용하여 로그를 안정적으로 보관하고 조회할 수 있습니다.

5. 마무리

운영 로그 관리의 핵심은 필요한 로그를 적절한 수준으로 기록하고, 필요한 순간에 신속하게 확인하여 장애 원인을 정확하게 분석할 수 있도록 운영하는 것입니다.

평상시에는 거래로그와 Error 수준의 시스템 로그를 기본으로 운영하고, 장애 분석이 필요한 경우에만 대상 거래의 로그 설정을 일시적으로 변경하여 필요한 정보를 확보한 뒤 기본 설정으로 복원하는 것이 운영 효율성과 온라인 성능을 함께 고려하는 현실적인 운영 방식입니다.

DevOn은 거래로그, 시스템 로그, Trace 로그를 목적에 따라 구분하여 저장하고, 운영관리 화면을 통해 거래 검색부터 원문 조회, Trace 조회, 로그 설정 변경까지 일관된 운영 흐름을 제공합니다. 또한 거래별 로그 설정, 로그 Rolling, Async 저장 기능 등을 통해 안정적인 로그 운영 환경을 구현할 수 있습니다.

※ 본 게시글의 이미지는 AI를 활용해 제작되었습니다.