전산장애 후기: ORA-3136 연쇄 차단 현상 해결기

💻 평온한 일상을 뒤흔든 접속 장애

2023년 3월의 어느 평온한 오후였습니다. 갑작스럽게 제가 담당하는 서비스의 접속이 원활하지 않다는 긴급 연락을 받았습니다. 평소라면 WAS(Web Application Server)의 일시적인 현상으로 보고 단순 재부팅만으로도 해결될 사소한 문제였지만, 이번에는 상황이 달랐습니다.

“WAS를 재시작해도 장애 증상이 해결되지 않고 지속되었습니다.”

---

🔍 초기 증상 및 현상 파악

개발팀과 함께 상황을 긴밀히 모니터링한 결과, 다음과 같은 심각한 증상들이 관찰되었습니다.

1. DB 세션 포화: WAS에서 데이터베이스로 연결되는 세션이 순식간에 가득 찼습니다.
2. 자원 고갈: CPU 점유율이 99%까지 치솟으며 서버가 정상적으로 응답하지 못하는 상태가 반복되었습니다.
3. 간헐적 다운: 서비스가 잠시 정상화되는 듯하다가도, 5분 혹은 1시간 간격으로 다시 멈추는 불규칙한 양상을 보였습니다.

장애 당시 시스템 로그 분석 및 모니터링 상황

---

🛠️ 1차 대응: 임시 조치와 한계

초기에는 단순한 트래픽 증가로 판단하고 즉각적인 자원 확충을 시도했습니다.

• 세션 수 증설: 부족한 세션 수를 확보하기 위해 설정값을 상향 조정했습니다.
• CPU 리소스 추가: 서버 부하를 견디기 위해 할당된 CPU 자원을 늘렸습니다.

그러나 이러한 조치에도 불구하고 장애는 해결되지 않았습니다. 근본적인 원인이 다른 곳에 있다는 확신이 들었고, 이용자들에게 장애 안내를 게시한 뒤 본격적인 심층 분석에 돌입했습니다.

---

🎯 핵심 원인 발견: ORA-3136와 Inbound Ready

WAS 로그만으로는 한계가 있어 데이터베이스 로그(Alert Log)를 정밀 분석하던 중, 결정적인 실마리를 발견했습니다.

ORA-3136: inbound connection timed out

DB 엔지니어와의 논의 결과, 이는 클라이언트가 데이터베이스에 연결을 시도할 때 정해진 시간 내에 인증을 완료하지 못해 발생하는 타임아웃 오류였습니다. 네트워크 방화벽 설정 등을 점검했으나 특별한 문제가 없던 상황에서, 관련 기술 문서를 통해 Java 보안 설정이 병목의 원인일 수 있다는 점을 확인했습니다.

문제의 핵심: /dev/random vs /dev/urandom

특정 JDBC 버전 이상에서 보안 통신(SSL/TLS)이나 인증 과정 중 난수 생성기가 차단(Blocking)되는 현상이 발생할 수 있습니다. 리눅스의 /dev/random은 난수가 부족할 경우 대기하게 되어 인증 과정에서 지연을 유발하고, 이것이 ORA-3136 에러로 이어져 전체 세션을 고갈시키는 연쇄 장애를 일으킨 것입니다.

---

✅ 조치 및 최종 결과

문제 해결을 위해 서버의 Java 보안 설정 파일을 수정하였습니다.

1. 경로: $JAVA_HOME/jre/lib/security/java.security
2. 변경 내용:
   • 수정 전: securerandom.source=file:/dev/random
   • 수정 후: securerandom.source=file:/dev/urandom

설정 변경 후 WAS를 재기동하자, 그동안 우리를 괴롭혔던 세션 포화 현상과 CPU 과부하가 즉시 사라졌습니다.

마무리하며

이번 장애는 겉으로는 DB 세션이나 CPU 문제처럼 보였으나, 실제로는 WAS 내부의 Java 보안 설정 하나가 전체 연쇄 장애를 일으킨 케이스였습니다. 잘 작동하던 시스템에서 왜 갑자기 발생했는지는 여전히 의문으로 남지만, 복잡한 인프라 환경에서 아주 작은 설정값이 시스템 전체의 신뢰성에 얼마나 큰 영향을 주는지 다시금 깨닫는 계기가 되었습니다.

[!TIP] 유사한 증상이 발생한다면 DB 내부 로그뿐만 아니라 WAS의 난수 생성 방식 설정도 반드시 확인해 보시기 바랍니다.