[TroubleShooting] 다양한 장애유형 대처방안 (Hang Up 현상)

본 포스팅은 다양한 Exception Case를 살펴보고 1차 선 대응 방법에 대해 알아 보겠습니다.

---

본 포스팅은 모든 Exception Case를 살펴보는것에 의의가 있지는 않습니다. Exception은 워낙 많은 Case가 존재하고 이를 모두 살펴 보려면 100년이 걸려도 다 살펴보지는 못할 것이기 때문입니다. 그렇기 때문에 많은 분야의 전문가가 존재할 것입니다. 이번 시간에는 이런 문제가 발생했을 경우 어떻게 대응하고 해결해 나갈 것인지에 대한 개론적인 내용을 다루고자 합니다. 특히 그중 Hand Up에 의한 장애 처리에 대해 좀 더 중점적으로 확인 할 예정입니다. 이미 많은 사람에 의해 해결된 이슈들이므로 훓어보기 식으로 쭉 내려 보기를 추천합니다.

먼저 Hang Up에 대한 정의는 다음과 같습니다.

통상적으로 시스템이 느려지거나 멈추는 현상을 Hang up 이라고 합니다.
- Hang up이란 Server Instance는 실행되고 있으나, 아무런 응답이 없는 상황을 말합니다.
- 비슷한 의미로 Slowdown이 있는데 Server Instance의 response time이 아주 급격히 떨어지는 상태를 의미합니다.

Hang up이나 slowdown 현상은 대부분이 Network, User Application, WEB/WAS(Servlet Engine), JVM, RDBMS 다섯가지 요소 중 하나 이상의 병목으로 인해서 발생합니다.

실제 Hang up의 다양한 유형별 조치 방법을 하나씩 살펴보도록 하겠습니다.

먼저 Dead lock입니다.

Multi Thread 사용시 공유 영역을 보호하기 위해 Synchronized method를 사용합니다(통상 locking). 두 개 이상의 Thread가 서로 Lock을 잡고 기다리는 상태, 서로 Lock이 풀리지 않고 무한정 대기하는 상태를 말합니다.

이러한 문제의 유형은 대개 로드가 많은 경우에 나타나며 다음과 같은 경우가 있는지 살펴보아야 한다.

먼저 상호배제에 따른 문제입니다. 이는 프로세스 동기화랑 같은 맥락입니다.
프로세스 동기화란 프로세스에서 내부 Thread들에게 수행할 수 있는 권한을 부여하는 우선순위와 관련이 있습니다.
이를 문맥교환이라고 하는데 이로 인해 Thread들은 Lock을 잡는다고 표현합니다.
Lock을 주고 받는 과정에서 완전한 해제가 이루어 지지 않을 경우 DeadLock이 발생합니다.

두번째로 점유하며 대기하는 경우입니다. 내가 어떤 자원을 갖고있고, 이 프로그램을 끝내려면 다른 자원이 필요한데, 그  자원을 다른 프로세스가 쓰고 있는 중일 경우입니다.
그럼 난 그 프로세스가 끝날때 까지 어떤 자원을 계속 lock을 잡고 대기 하며 이를 기다리는 다른 Thread는 또 동일한 결과로 대기를 하게 됩니다.

세번째로 프로세스가 자발적으로 자원을 반환하지 않을 경우입니다.
java의 경우 GC라는 동작을 통해 참조하지 않는 객체를 해제해 주는 경우가 있지만, 이에 대한 문제가 완전히 해소되는 것은 아닙니다.
참조의 문제로 인해 사용하지 않는 오브젝트를 불필요하게 항상 유지하는 경우도 종종있으며, c의 경우는 이와 차원이 다른 문제가 발생하게 됩니다.

마지막으로 순환 대기입니다. 프로세스들끼리 순환적으로 상대가 가진 자원을 원할때 발생하게 되며 이는 Thread 레벨 보다 성능에 훨씬 큰 영향을 끼치게 됩니다.

 

두번째로 JDBC로 인한 Server Hang 현상입니다.

응용 프로그램 또는 JDBC Connection Pool을 사용할 경우 JDBC DeadLock 또는 JEUS인스턴스 Hang 상태를 초래하는 JDBC 호출이 발생할 수 있습니다.

- 동기화된 DriverManager.getConnection()을 사용하는 경우입니다.

이전의 JDBC 응용 프로그램에서는 특정 드라이버를 사용하는 Database Connection을 검사하기 위해 DriverManager.getConnection()을 사용을 했으나 이 방법은 Deadlock을 발생시키거나 Connection요청의 성능을 상대적으로 저하시킬수가 있으므로 사용하지 않는 것이 좋습니다.

- DataBase에 대한 SQL 쿼리 결과가 너무 오래 걸리는 경우입니다.

상황은 DB에 Query를 보내고 response를 Thread들이 기다리고 있는 상황입니다. AP에서 JDBC를 통해서 Query를 보내는데 Response가 오지 않으면 계속 기다리게 되고, 다른 Thread가 같은 DB로 보냈는데, Response가 오지 않고, 이런 것들이 중복돼서 결국은 사용할 수 있는 Thread가 없게 되어서 새로운 request를 처리하지 못하게 되고, 기존에 Query로 보낸 내용도 응답을 받지 못하는 상황입니다.

이런 현상은 주로 DB 사용시 대용량 Query를 보내거나, DB에 lock들에 의해서 발생하는 경우가 많습니다. 이문제를 해결하기 위해서는 Thread Dump에서 문제가 되는 부분을 발견하여 해당소스나 시스템에 접근하여 문제를 해결합니다.

- DeadLock으로 인해 모든 thread가 Hang인 경우입니다.

Database 및 Application에서의 Deadlock은 Hang(정지) 상태로 만들 수 있습니다. Deadlock이 있는지 알아보려면 Thread Dump를 확인해야 합니다. 일반적으로 Database에서 Deadlock이 발생하는 원인으로는 하나 이상의 트랜잭션을 Rollback하여 Deadlock을 해결하기까지는 다소 시간이 걸리기 때문에 롤백이 끝날 때까지 하나 이상의 thread가 차단될 수 있습니다.

- 느리거나 오버헤드 상태인 네트워크로 인해 Database 호출이 느리거나 Hang인 경우입니다.

JEUS와 Database 간의 통신이 이루어지고 적절한 시간 내에 요청이 처리되기 위해서는 네트워크가 정상적으로 작동하고 안정적이어야 합니다. 따라서 네트워크가 느리면 SQL쿼리 결과를 기다리는 worker thread가 Hang(정지)되거나 차단 될 수 있습니다. Thread dump만 분석해서는 SQL쿼리가 Hang(정지)되거나 느려지는 근본 원인을 알 수가 없습니다. Thread Dump는 SQL 호출의 성능에 문제가 있음을 파악 할 수 있는 초기 징후라 할 수 있습니다. SQL 호출 성능저하의 원인이 Database 문제인지 아니면 네트워크 문제인지 확인히 필요합니다.

세번째로 일반적인 Server Hang 현상입니다.

일반적으로 서버는 리소스 부족으로 인해 Hang이 발생합니다. 예를 들어, 교착 상태(dead lock)나 대량의 요청으로 인해 작업 수행에 사용할 수 있는 실행 스레드(execute thread)가 없을 수 있습니다. 즉, 모든 스레드가 요청을 처리하기 위해 바쁜 상태 일 경우 입니다.

일반적인 Server Hang인 경우는 다음과 같습니다.

- 가비지 콜렉션에 너무 많은 시간이 소요되는 경우를 말합니다. 이럴 경우 GC Policy 또는 GC Option을 튜닝하거나 단순히 메모리를 올려주거나 내려주는 것으로도 해결 방도가 생길수 있습니다.

- 스레드가 모두 사용되어 새 작업에 사용할 수 있는 스레드가 없는 경우를 뜻합니다.

- 응용 프로그램 교착상태(DeadLock)에 빠질 경우를 의미합니다.

- 과도한 JSP 컴파일 로드로 인한 Server Hang 현상을 의미합니다.

그럼 실제 분석 방법에 대해 알아보겠습니다.

먼저 Server log를 확인합니다.

Server 상태의 정확한 원인을 파악하기 위해서 Server log 및 access log를 점검해야 합니다. 만약 deadlock 이나 server hang 상태는 log가 없겠지만, 어떤 AP를 호출하다가 hang이 걸렸는지 유추할 수 있습니다.

다음으로 webadmin, dbpooladmin등 JEUS에서 Resource를 사용하는 요소들을 점검 합니다.

- Thread Hang 점검요소로 WebtoB의 Webadmin을 통해서 현재 상태의 thread를 점검합니다. thread의 idle 개수가 0에 가까운지, 비정상적으로 active 상태가 길게 가고 있는지, block 된 것은 없는지 확인합니다.

- DB 관련 Hang 점검요소로 JEUS의 Dbpooladmin 을 통해서 현재 상태의 thread를 점검한다. 역시 connectionPool의 idle 개수가 0에 가까운지, 비정상적으로 active 상태가 길게 가고 있는지, block 된 것은 없는지 확인합니다.

Thread Hang, DBPool Hang 현상은 매우 사이트에서 빈번하게 발생하는 또는 발생 가능성이 높은 장애 유형 중 하나입니다.

다음으로 Thread Dump 분석 방법입니다.

이미 많은 블로그를 통해 많은 량의 ThreadDump 분석 사례가 소개되고 있습니다.

이를 참고하여 Dump를 통해 주요 사항을 유추하고 함께 Heapdump 분석까지 병행한다면 보다 자세한 분석이 이루어 질 것입니다.

정확히 분석해 나가기 위해서는 위에서 정리한 내용들은 전체의 일부에 불가하다는 것을 말씀드립니다.
경험을 바탕으로 새로운 장애에 유연하게 대응할 수 있도록 항상 고민과 학습을 병행해야 할 것입니다.

누군가는 성능이 우선시 되는 사이트가 있고 누군가는 안전성에 우선권을 두는 사람도 있습니다. 두가지 토끼를 다 잡기위해서는 많은 경험과 노력이 필요하지만, 필자는 둘 중 선택해야 한다면 안전성에 표를 던지고 싶습니다.

이 밖에 다양한 파트의 장애 유형에 대해서는 앞으로도 지속적으로 포스팅할 예정이니 많은 관심 부탁합니다.

 

고맙습니다.