[AWS] EMR JVM 모니터링

EMR JVM 모니터링

Amazon EMR 클러스터에서 Spark, Hadoop, YARN 등과 같은 JVM 기반 프로세스를 실시간으로 모니터링하기 위해서는 크게 다음과 같은 방법이 있음.

 

1. JMX 기반의 직접 모니터링

2. Ganglia, CloudWatch, Datadog 등 외부 툴/에이전트를 통한 모니터링

3. Spark UI, YARN UI와 같은 내장 모니터링 인터페이스를 혼합하여 사용하는 방법

 

JMX 기반 실시간 모니터링 : JMX 개요

JVM 내부 Heap 사용량, GC(가비지 컬렉션) 이벤트, 스레드 정보 등 다양한 메트릭을 실시간으로 노출하는 표준 인터페이스.

com.sun.management.jmxremote 등의 JVM 옵션을 통해 원격에서 모니터링 도구(VisualVM, JConsole, Mission Control 등)로 접속 가능.

Spark/Hadoop/YARN 프로세스(예: Spark Driver, NameNode, ResourceManager 등)를 JMX로 노출하면, 원하는 정보를 세밀하게 관측할 수 있음.

 

JMX 기반 실시간 모니터링 : Spark/Hadoop 프로세스에서 JMX 설정

1. 부트스트랩 액션(Bootstrap Action) 또는 클러스터 구성 수정

EMR 클러스터 생성 시, 각 노드(마스터/코어/태스크)에 대해 /etc/spark/conf/spark-env.sh, /etc/hadoop/conf/hadoop-env.sh 등에 JVM 옵션을 추가할 수 있음.

Spark의 경우 예시:

# spark-env.sh 내 예시
export SPARK_DAEMON_JAVA_OPTS="$SPARK_DAEMON_JAVA_OPTS \
  -Dcom.sun.management.jmxremote \
  -Dcom.sun.management.jmxremote.port=9090 \
  -Dcom.sun.management.jmxremote.ssl=false \
  -Dcom.sun.management.jmxremote.authenticate=false \
  -Djava.rmi.server.hostname=<해당 노드의 호스트/IP>"

 

Hadoop(HDFS, YARN 등)은 /etc/hadoop/conf/hadoop-env.sh 또는 /etc/hadoop/conf/yarn-env.sh에 비슷한 설정을 추가할 수 있음.

 

2. 보안 설정 주의

프로덕션 환경에서는 -Dcom.sun.management.jmxremote.authenticate=true 및 SSL 인증서 설정을 통해 인증·암호화를 반드시 고려해야 함.

보안 그룹(Security Group) 또는 방화벽에서 JMX 포트를 개방해야 하며, 내부망에서만 접근하도록 제한하는 것이 일반적임.

 

3. SSH 포트 포워딩

VPC 내부 사설 IP로만 접근 가능하도록 구성한 경우, 로컬 머신에서 SSH 터널링(포트 포워딩)을 통해 JMX 포트에 접속하는 방식을 사용할 수 있음.

ssh -i <pem키> -L 9090:localhost:9090 hadoop@<Master Public DNS>

이후 로컬에서 JConsole/VisualVM을 실행해 localhost:9090 으로 JMX 연결을 맺음.

 

JMX 기반 실시간 모니터링 : 도구(VisualVM, JConsole, Mission Control 등) 활용

1. VisualVM: GC, Heap, 스레드 정보 시각화가 편리

2. JConsole: 기본적인 JMX 모니터링 제공

3. Java Mission Control(JMC): 대규모 애플리케이션 프로파일링, Flight Recorder 기능 제공

4. Prometheus JMX Exporter: JMX를 Prometheus 포맷으로 변환해 scrape 가능(추후 Grafana에서 시각화)

 

장점 : JVM 내부 상태를 직접 파악 가능(Heap/GC/Thread/클래스 로드/등등).
단점 : 보안 설정, 네트워크 설정, 인증·암호화 등이 까다롭고, 포트 개방 및 SSH 터널링이 필요.

 

외부 툴로 실시간 모니터링 : Ganglia(EMR 내장 옵션)

EMR 클러스터 생성 시, Ganglia 애플리케이션을 함께 설치(EMR 콘솔 → “Add Applications”)하면, 각 노드의 CPU, 메모리, 네트워크, Hadoop 지표 등을 시각화 가능.

다만 Ganglia 기본 설정으로는 JVM 내부 Heap/GC 같은 세부 정보는 제한적이며, 추가 플러그인 설정 혹은 Spark/Hadoop 메트릭 설정을 수정해야 더 세밀한 JVM 지표를 볼 수 있음.

 

외부 툴로 실시간 모니터링 : Amazon CloudWatch

1. CloudWatch Agent + JMX

EC2에 CloudWatch Agent를 설치하고, JMX Metric을 긁어다가 CloudWatch 커스텀 지표로 전송 가능.

CloudWatch 콘솔에서 그래프·알람을 설정해 실시간 모니터링.

정확히는 1분 단위, 고급 설정 시 1초~10초 단위로도 가능함.

예를 들면, cloudwatch-agent-config.json 파일에 JMX 설정 추가.

{
  "metrics": {
    "jmx": {
      "service_address": "service:jmx:rmi:///jndi/rmi://127.0.0.1:9090/jmxrmi",
      "metric_patterns": {
        "java.lang:type=Memory": {
          "HeapMemoryUsage.used": "UsedMemory",
          "NonHeapMemoryUsage.used": "UsedNonHeapMemory"
        }
      }
    }
  }
}

 

2. CloudWatch Container Insights

EMR on EKS처럼 컨테이너 환경에서 Spark를 구동한다면, Container Insights를 통해 JVM 메트릭(메모리, CPU 등) 모니터링 가능.

 

외부 툴로 실시간 모니터링 : Datadog, Dynatrace, New Relic 등 APM/모니터링 서비스

에이전트(Agent)가 JMX를 통해 JVM 정보를 수집 후, 대시보드·알람·이상 징후 분석 기능을 제공

 

구성 과정은 다음과 같음.

1. EMR 클러스터 부트스트랩 액션에서 Datadog Agent 설치(또는 Dynatrace OneAgent 등)

2. Spark/Hadoop 프로세스에 JMX를 활성화해 에이전트가 수집

3. Datadog/Dynatrace SaaS 플랫폼에서 대시보드, 임계값 알림, 히트맵 등을 구성

 

장점: 설정이 간단하고(에이전트 설치) 전문 APM 기능 제공(예: 트랜잭션 추적, 프로파일링 등)

 

Spark UI, YARN UI, ResourceManager UI 등 내부 인터페이스

EMR에 기본적으로 제공되는 Spark UI(4040/4041 포트), YARN ResourceManager UI(8088 포트), HDFS NameNode UI(9870 포트) 등을 통해서도 일부 JVM 메트릭이 간접적으로 노출됨.

 

1. Spark UI

실행 중인 Spark 애플리케이션의 Stage/Task/메모리 사용량, 스토리지 메모리, Executor별 GC 시간, 셔플 읽기/쓰기 등 폭넓은 정보 제공.

다만, JVM Heap 상세 정보는 제공되지 않고, Executor/Driver가 OOM(OutOfMemory)일 때 GC 비율, Task 실패 등 간접 지표만 확인 가능.

 

2. YARN ResourceManager UI

각 Container(Executor, Driver 등)의 메모리·CPU 사용량을 관찰.

JVM 내부 상태라기보다 YARN에서 할당한 리소스 대비 실제 사용량을 확인하는 지표.

 

장점: EMR에서 기본 제공, 별도 설정이 적음
단점: JVM Heap, GC 로그, 스레드덤프 등은 제한적으로만 관찰 가능

 

설정/운영시 모범 사례

1. JMX 포트 보안

프로덕션 환경에서는 반드시 보안 그룹 규칙으로 외부 접근을 막고, SSH 터널링 혹은 VPC 내부 제한망에서만 모니터링.

필요하다면 SSL, 인증(Password File) 설정을 통해 접근 제어.

 

2. 리소스 오버헤드 주의

실시간 JMX 모니터링, VisualVM 프로파일링 등은 JVM에 추가 부하를 줄 수 있음.

대규모 트래픽이 발생하거나 GC가 빈번한 순간에 모니터링 툴이 오히려 장애를 유발하지 않도록 신중히 사용.

 

3. 자동화 & 알람 설정

CloudWatch/Dynatrace/Datadog을 이용해 “JVM Heap Usage가 80% 이상 오래 지속됨”, “GC Time이 일정 임계치 이상” 등 임계값을 정의하고 알람(Email, Slack, PagerDuty 등) 발송.

CPU/메모리/디스크 지표와 함께, Spark UI/YARN UI에서 나타나는 Executor Failures, Long GC Pauses 등을 종합적으로 모니터링.

 

4. 부트스트랩 액션으로 에이전트 자동 설치

EMR 클러스터 생성 시, Bash 스크립트(bootstrap script)를 통해 JMX 포트, CloudWatch Agent, Datadog Agent 등의 설정을 자동화.

클러스터가 매번 새로 생성되더라도 동일 환경을 재현 가능

 

5. Ganglia / CloudWatch Logs / CloudWatch Metrics 병행 사용

Ganglia를 통해 클러스터 수준 자원 사용을 한눈에, JMX/CloudWatch Agent 등을 통해 JVM 상세 지표를 모니터링

EMR 클러스터 종료 후에도 CloudWatch나 S3에 로그·메트릭이 남아야 추후 장애 분석 가능.

 

정리

EMR 클러스터의 JVM을 실시간으로 모니터링하는 방법에는 직접 JMX를 활성화하고 VisualVM/JConsole 같은 도구로 연결하는 방식부터, Ganglia/CloudWatch/Datadog 등 외부 모니터링 솔루션으로 JVM 메트릭을 수집하는 방식까지 다양함.

 

1. JMX 직접 모니터링

JVM 내부 상태를 가장 세밀하게 확인할 수 있지만, 보안·설정·포트포워딩이 까다롭고, 실시간 상호 작용 시 부하가 증가할 수 있음.

 

2. Ganglia/CloudWatch

EMR에서 기본 제공되거나 간단히 설정 가능하며, 대시보드·알람 등에 유리.

 

3. Datadog/Dynatrace 등 APM

에이전트 기반으로 JVM 내부 지표와 더불어 애플리케이션 성능 분석까지 가능.

 

실제 운영에서는 JMX + (에이전트 또는 CloudWatch/Ganglia/Datadog 등)을 병행하여, JVM의 세부 Heap/GC 상황과 클러스터 전체 자원 사용량을 종합적으로 파악함.

또한, 알람 설정, 로그·메트릭의 S3/CloudWatch 영구 보존, 보안 그룹 및 IAM 정책을 통한 접근 제어 등도 함께 고려해야 안정적이고 확장성 있는 실시간 모니터링 환경을 구축할 수 있음.