26시간 Blast 작업에서 24시간 DB 세션이 만료된 이유

문제의 출발점

공개 가능한 범위에서 작업 식별자와 서버 정보는 제거했습니다. 이 글은 확인된 장시간 Blast 장애 한 건과 그 개선 범위만 다루며, 모든 분석 모듈 장애를 예방했다는 의미가 아닙니다.

한 분석 작업에는 192개 반응이 등록돼 있었고, 이로부터 94개 contig가 생성됐다. contig마다 Blast가 약 15분씩 걸리면서 전체 작업 시간은 약 26시간까지 늘어났다.

Java 프로세스와 Blast 계산은 계속 진행됐지만 Oracle 세션은 계산 구간에서 유휴 상태가 길어졌다. Oracle의 24시간 세션 제한을 넘긴 뒤 기존 Connection을 다시 사용하자 ORA-01012가 발생하며 후속 처리가 중단됐다.

애플리케이션 안에 Connection 객체가 남아 있다는 사실은 서버 쪽 세션이 여전히 유효하다는 보장이 아니었다.

처음 확인해야 할 것은 “약 26시간 뒤 실패했다”는 시간 정보가 어느 자원의 수명과 맞닿는지였다.

Blast가 오래 걸린 사실과 DB 오류를 같은 원인으로 묶지 않았다. 긴 분석시간은 세션 만료 조건을 만들었고, 실제 중단은 유휴 만료된 세션을 후속 처리에서 다시 사용한 경로에서 발생했다.

DB의 세션 제한을 작업 최대시간보다 길게 늘리면 당장의 오류를 늦출 수 있다. 그러나 분석시간은 입력량과 contig 수에 따라 더 늘어날 수 있고, 하나의 장기 작업에 맞춰 공용 DB 정책을 계속 완화하면 유휴 세션 관리 기준도 흐려진다.

이번 작업에서는 Blast 실행시간 자체보다 장시간 작업 중 세션이 사용되지 않는 구간을 보완 대상으로 삼았다.

실제로 적용한 조치는 Connection을 반납했다가 후속 저장 전에 다시 확보하는 방식이 아니다. Bioinformatics 모듈에서 각 Blast 실행 전에 SELECT 1 FROM DUAL을 수행하도록 DB 접근과 Job 실행 흐름을 보완했다.

아래 코드는 문제 해결 구조를 설명하기 위한 pseudocode이며 실제 클래스·메서드명과는 무관합니다.

for contig in contigs:
    execute("SELECT 1 FROM DUAL")
    runBlast(contig)

이 Query는 Blast 성능을 높이기 위한 것이 아니다. 반복되는 Blast 사이에 DB 세션을 사용해 장시간 작업 중 유휴 만료되는 조건을 완화하고, 다음 처리에서 만료된 세션을 그대로 사용하는 경로를 막기 위한 조치였다.

분석 알고리즘이나 결과 생성 규칙을 바꾸지 않고 DB 연결 관리와 Job 실행 흐름에서 세션 확인 Query를 실행하도록 수정했다. 장애 원인이 된 세션 사용 시점만 보완해 기존 Blast 처리 결과에 미치는 영향을 제한했다.

동일한 장시간 작업 시나리오 한 개를 내부 검증과 사용자 검증 두 단계에서 각각 확인했고 모두 통과했다. DB 연결 관리와 Job 실행 흐름의 변경 이력, 최종 완료 상태도 함께 대조했다.

테스트 행 두 개를 서로 다른 두 시나리오로 세지 않았다. 같은 조건을 서로 다른 검증 단계에서 반복한 결과로 구분했다.

이 개선은 Blast 실행시간 자체를 줄이지 않았다. Oracle의 모든 세션 종료 원인을 없앤 것도 아니며, 개선 후 장애가 0건이라고 주장할 근거도 없다.

해결한 범위는 더 좁고 구체적이다. 약 26시간 작업에서 Oracle의 24시간 세션 제한을 넘긴 뒤 ORA-01012가 발생한 경로를 확인하고, 각 Blast 실행 전 세션 확인 Query를 수행해 유휴 만료 조건을 완화했다.

장기 실행 Job에서는 프로세스가 살아 있다는 사실만으로 내부 자원의 유효성을 가정할 수 없다. 장시간 계산과 DB 세션의 사용 간격을 함께 보고, 실제로 확인된 장애 경로에 맞춰 세션 유지·확인 지점을 설계해야 한다.