[APM/제니퍼,스카우터 등] Class Redefine 으로 인한

1. 개요

1. JAVA 기반 JVM 환경을 모니터링하기 위해 APM (Scouter, Whatab, Jennifer, Openmaru) 등을 고객사에서 운영하고 있었습니다.

2. 그러나 서비스 중 HotDeploy, HotSwap을 주력으로 사용하는 상용 솔루션(티xx) 플랫폼에서 다음과 같은 이슈가 발생했습니다:

   • 상용 솔루션 프레임워크: Classes 및 하위 Library Jar 전체 포함
   • 고객사 개발자들이 생산한 Business BackEnd Source
   • 그 외 솔루션 연계 라이브러리

   이로 인해 Class의 수가 10만 개 이상으로 추정됩니다.

2. 원인

1. APM은 Java 소스를 분석하기 위해 로드와 동시에 전체 Class를 스캔합니다. 하지만 운영 중 HotSwap, HotDeploy를 수행할 경우 Java Agent는 이를 감지하고 추적하기 위해 다음 코드를 수행합니다:

    Instrumentation inst = ByteBuddyAgent.install();
    Class[] loadedClasses = inst.getAllLoadedClasses();

   

   
   문제는 이 코드가 자주 호출되면, JVM은 많은 클래스를 로딩하고, HotDeploy 및 HotSwap에 따라 추가 로딩하게 되어 "서비스 지연"과 GC 과부하를 유발합니다.

2. 또한, 여기서 핵심은 요즘 HTTP 등 네트워크 통신 기술 중 "HTTP SSE (Server Send EventStream)" 비동기 통신 방법입니다. 많은 업체들 중 "티맥스 - ProObject" 솔루션은 다음과 같은 구성임을 알 수 있었습니다.

sendToEventLoopThread 생성

3. 구성 및 비교

[Spring] MVC 구조

• HttpServletRequest → Controller → Service → Dao 또는 Mapper 또는 Repository

[Spring WebFlux / ProObject] 구조

• HttpServletRequest → ServiceObject
  • DuplexPipeHandler(sendToEventLoopThread): Thread가 Wait 상태이며, ServiceObject 종료를 모니터링합니다.
    (Subcribe 이벤트 구독 형태의 Reactive 통신 방법에 가깝습니다.)

Spring 구조의 경우 Transaction Connection이 강제 종료되면 서비스가 자동으로 DOWN 상태로 변하지만, "Spring WebFlux / ProObject" 구조에서는 모니터링 Thread가 "ServiceObject"가 종료되기 전까지 무한 대기하기 때문에 "느려짐", "장애" 등을 유발하는 작업이 발생했을 때 매우 위험합니다.

4. 결론 및 추가 정보

• 위의 문제를 해결하기 위해서는 APM 도구의 성능 최적화가 필요합니다.
• HotDeploy, HotSwap 과정에서 JVM 성능 저하를 최소화하기 위한 대책 마련이 필요합니다.
• HTTP SSE와 같은 비동기 통신 방법의 특성을 고려하여 시스템 아키텍처를 설계해야 합니다.

추가적인 정보와 정확한 분석을 통해 문제를 해결하고 시스템의 안정성을 높이는 방안을 계속 모색해야 합니다.