프로세스는 살아 있었지만 결과 업로드가 멈췄다
분석 모듈의 결과 업로드가 지연됐지만 Java 프로세스는 종료되지 않았다. 모듈을 재기동하면 밀린 처리가 다시 진행됐으므로, 재기동과 함께 초기화되는 파일 자원과 프로세스 상태를 조사했다.
공란 로그를 먼저 보완했다
장애 시간대에는 파일 처리 오류가 반복됐지만 예외 타입과 Stack Trace가 남지 않아 발생 지점과 제어 흐름을 확정하기 어려웠다. 실제 로그 메시지와 처리기 이름은 공개하지 않고 흐름만 일반화한다.
아래 코드는 문제 해결 구조를 설명하기 위한 pseudocode이며 실제 클래스·테이블·설정 이름과는 무관합니다.
[정상 주기] 결과 처리 완료
[다음 주기] 처리 시작
[이후] 원인을 식별하기 어려운 파일 처리 오류 반복예외 메시지만 남기던 경로에서 예외 객체 전체와 Stack Trace를 기록하도록 로깅을 보완했다. 이 변경은 당시 장애의 원인을 자동으로 해결한 것이 아니라, 후속 장애에서 어느 처리 단계가 실패했는지 확인할 수 있게 한 진단 개선이었다.
OS 증거로 열린 파일을 확인했다
작업 경로에는 .nfs... 형태의 파일이 남아 있었고 프로세스를 종료하면 함께 사라졌다. 파일 내용만의 문제라면 프로세스 종료와 동시에 정리되는 현상을 설명하기 어렵다. 반대로 프로세스가 열린 파일 핸들을 유지했다면 종료 시 핸들이 반환되면서 임시 파일이 사라지는 흐름을 설명할 수 있었다.
ulimit -a로 open-file 제한이 1024인 환경임을 확인하고, ps와 lsof로 해당 프로세스가 .nfs 파일 핸들을 열린 상태로 유지하는지 대조했다.
ulimit -a
lsof -p <PROCESS_ID> | grep '\.nfs'모듈 재기동 전후의 .nfs 파일과 결과 업로드 상태도 함께 비교했다. 재기동 뒤 .nfs 파일이 정리되고 밀린 결과 업로드가 다시 진행된 사실은 열린 파일 자원과 장애 상태의 연관성을 좁히는 근거가 됐다.
.nfs는 열린 파일 상태를 보여 주는 단서였다
NFS에서는 프로세스가 아직 열고 있는 파일을 삭제하면 파일 핸들을 유지하기 위해 임시 이름으로 바꿔 둘 수 있다. 마지막 핸들이 닫히면 해당 임시 파일을 정리할 수 있다.
따라서 .nfs 파일 자체를 독립 원인으로 단정하지 않았다. 확인한 것은 분석 모듈이 여러 .nfs 파일을 열린 상태로 유지하고 있었고, open-file 제한과 함께 결과 업로드 지연의 유력 원인 범위를 형성했다는 점이다.
초기 정상화와 후속 진단 기반을 마련했다
당시 운영 대응은 두 단계였다.
- 모듈을 재기동해 열린 자원을 초기화하고 결과 업로드를 정상화했다.
- 공란으로 끝나던 예외 로그에 Stack Trace가 남도록 보완했다.
재기동은 업무를 우선 복구하기 위한 초기 대응이었다. 로깅 보완은 같은 현상이 다시 발생했을 때 OS 상태와 소스 실행 경로를 함께 대조할 수 있게 한 후속 조치였다.
확정한 범위와 남은 한계
확정 가능한 결론은 .nfs 열린 파일 핸들 누적과 open-file 제한이 결과 업로드 지연에 연결된 유력 원인이라는 점이다. 당시 자료는 모듈 재기동을 통한 초기 정상화와 Stack Trace 로깅 보완까지 뒷받침한다.
반면 파손된 AB1 파일을 단일 원인으로 특정하거나, try-finally 또는 특정 자원 해제 메서드를 직접 구현해 영구 수정·배포했다고 볼 근거는 확인되지 않는다. 따라서 이 사례를 소스 수준의 영구 해결 완료로 확대하지 않는다.
정리
프로세스 생존과 업무 진행은 같은 상태가 아니다. 공란 로그만으로 결론 내리지 않고 OS의 열린 파일 상태와 재기동 전후를 교차 확인해 원인 범위를 좁혔다. 이 사례의 완료 범위는 영구 해결이 아니라 초기 정상화와 후속 진단 가능성 개선까지다.