Scouter 설치와 톰캣 연동

[성능 개선 이야기] Scouter 설치와 톰캣 연동 — Java 1.8 + Tomcat 9 환경에서

안녕하세요, 가야태자 @talkit 입니다.

앞선 글에서 APM이 무엇이고 언어별로 어떻게 동작하는지 정리해 드렸는데요.

이번에는 실제로 Scouter를 설치하고 톰캣에 붙이는 과정을 적어보려고 합니다.

설치 절차 자체는 공식 위키에 잘 나와 있습니다. 그래서 이 글에서는 공식 문서를 그대로 옮기기보다는, 제가 실제로 하면서 정리해야 했던 것들 위주로 적겠습니다.

---

작업 환경

따라 하시는 분들을 위해 환경부터 밝혀둡니다. 버전이 다르면 결과도 다를 수 있습니다.

• Java 1.8
• Tomcat 9.0.120 — 서버 보안 점검 때문에 이 버전까지 올렸습니다
• Scouter 2.8.1 (scouter-all-2.8.1.tar.gz) — Java 1.8 환경에서 동작하는 버전으로 선택했습니다
• AWS 인스턴스
• 설치 경로: /usr/local/scouter

---

1. 먼저 Scouter의 구성부터 이해하고 가시죠

처음 설치할 때 제일 헷갈리는 부분이 여기입니다. Scouter는 하나의 프로그램이 아니라 세 덩어리로 되어 있습니다.

① 수집기 (Server / Collector)
에이전트들이 보내온 성능 데이터를 받아서 저장하고, 클라이언트에게 스트리밍해 주는 서버입니다. 이게 중심입니다.

② 호스트 에이전트 (Host Agent)
서버 장비 자체의 상태를 수집합니다. CPU, 메모리, 디스크 같은 OS 레벨 지표죠.

③ 자바 에이전트 (Java Agent)
톰캣 같은 WAS에 붙어서 애플리케이션 내부를 들여다봅니다. 앞 글에서 이야기한 바이트코드 조작이 여기서 일어납니다.

그리고 별도로 클라이언트(Viewer)가 있습니다. 이건 내 PC에 설치하는 프로그램이고, 수집기에 접속해서 화면을 보는 용도입니다.

정리하면 이렇습니다.

[톰캣 + 자바 에이전트] ─┐
                        ├─→ [수집기] ←─ [내 PC의 클라이언트]
[서버 + 호스트 에이전트] ┘

"수집기 하나에 에이전트 여럿이 붙고, 그걸 클라이언트로 본다"는 그림만 잡고 가시면 됩니다.

---

2. 파일을 서버에 올리기 (AWS 환경)

AWS 인스턴스라 파일 올리는 것부터가 일이었습니다.

저는 SSM 세션 포트포워딩을 걸고, 그 위로 SCP를 써서 올렸습니다. xxx-sftp 계정으로 접속해서 data 폴더에 업로드했습니다.

이 방식의 장점이 있습니다. 방화벽에 인바운드 포트를 열지 않아도 됩니다. 배스천 호스트를 따로 두지 않아도 되구요. AWS Systems Manager가 아웃바운드로 터널을 만들어 주기 때문입니다.

폐쇄적인 클라우드 환경에서 작업하실 일이 있으면 이 방법을 기억해 두시면 편합니다. (이 이야기는 다음 글에서 좀 더 자세히 다루겠습니다. 클라이언트 접속할 때 훨씬 더 중요해지거든요.)

---

3. 압축 풀기

/usr/local/scouter에 설치할 예정이었습니다.

tar xzvfp scouter-all-2.8.1.tar.gz

여기서 p 옵션을 눈여겨보시면 좋겠습니다. 권한(permission)을 원본 그대로 보존하라는 옵션입니다.

이걸 빼고 풀면 startup.sh, host.sh 같은 스크립트에 실행 권한이 안 붙는 경우가 있습니다. 그러면 chmod +x를 일일이 해줘야 하죠. 처음부터 p를 붙이는 게 편합니다.

압축을 풀면 이런 구조가 나옵니다.

/usr/local/scouter
├── server        ← 수집기
├── agent.host    ← 호스트 에이전트
└── agent.java    ← 자바 에이전트 (scouter.agent.jar)

앞에서 이야기한 세 덩어리가 그대로 폴더로 나뉘어 있습니다.

---

4. 수집기 실행

server 폴더로 가서 실행합니다.

cd /usr/local/scouter/server
./startup.sh

수집기는 기본 포트로 6100번을 씁니다. 그런데 여기서 주의하실 게 하나 있습니다.

TCP 6100과 UDP 6100을 둘 다 씁니다.

• UDP 6100 — 에이전트가 성능 데이터를 보내는 통로
• TCP 6100 — 클라이언트 통신과 에이전트 제어

방화벽을 열 때 TCP만 열고 UDP를 빠뜨리면, 접속은 되는데 데이터가 안 들어오는 상황이 생깁니다. 둘 다 확인하세요.

---

5. 호스트 에이전트 실행

cd /usr/local/scouter/agent.host
./host.sh

이걸 띄우면 서버 장비의 CPU, 메모리, 디스크 상태가 수집되기 시작합니다.

애플리케이션만 보면 되지 않나 싶을 수 있는데, 둘을 같이 봐야 판단이 됩니다. 응답이 느릴 때 그게 애플리케이션 문제인지 장비가 이미 한계인지 구분해야 하니까요.

---

6. 톰캣에 자바 에이전트 붙이기

이제 본론입니다. setenv.sh에 다음 내용을 넣었습니다.

# ---------------------------------------------------------------- SCOUTER APM
SCOUTER_AGENT_DIR=/usr/local/scouter/agent.java
JAVA_OPTS="$JAVA_OPTS -javaagent:${SCOUTER_AGENT_DIR}/scouter.agent.jar"
JAVA_OPTS="$JAVA_OPTS -Dscouter.config=${SCOUTER_AGENT_DIR}/conf/scouter.conf"
JAVA_OPTS="$JAVA_OPTS -Dobj_name=TomcatPrd01"

export JAVA_OPTS

한 줄씩 보겠습니다.

-javaagent:...scouter.agent.jar
JVM에게 "이 에이전트를 같이 띄워라"라고 알려주는 옵션입니다. 앞 글에서 이야기한 바이트코드 조작이 여기서 시작됩니다. 클래스가 로딩되는 순간 에이전트가 끼어들어 측정 코드를 넣습니다.

-Dscouter.config=...
에이전트 설정 파일 위치입니다. 수집기 주소 같은 것들이 여기 들어갑니다.

-Dobj_name=...
클라이언트 화면에 표시될 이름입니다. 이게 생각보다 중요합니다.

서버가 여러 대가 되면 화면에 이름만 잔뜩 뜨는데, 규칙 없이 지어 놓으면 나중에 어느 게 어느 건지 알 수가 없습니다. 저는 용도와 환경, 번호가 드러나게 짓는 편입니다. 장애가 났을 때 이름만 보고 바로 찾아갈 수 있어야 하니까요.

톰캣을 재시작하면 모니터링이 시작됩니다.

---

7. 왜 catalina.sh가 아니라 setenv.sh일까

이 부분은 꼭 짚고 싶습니다.

JVM 옵션을 추가할 자리는 catalina.sh에도 있습니다. 그런데 저는 setenv.sh에 넣기를 권합니다.

이유가 있습니다. 저는 이번에 서버 보안 점검 때문에 톰캣을 9.0.120까지 올렸습니다.

톰캣을 올린다는 건 배포판을 새로 받아서 교체한다는 뜻입니다. 그때 catalina.sh는 새 버전의 것으로 덮어씌워집니다. 거기에 설정을 넣어 뒀다면 그대로 날아갑니다.

반면 setenv.sh는 톰캣 배포판에 원래 들어 있지 않은 파일입니다. 사용자가 직접 만드는 파일이고, catalina.sh가 시작할 때 있으면 읽어가는 구조입니다. 그래서 업그레이드를 해도 살아남습니다.

요즘은 보안 취약점 때문에 톰캣을 자주 올리게 됩니다. 한 번 올릴 때마다 APM 설정이 사라진다면 그게 더 큰 문제죠. 처음부터 setenv.sh에 넣어 두시면 이 걱정이 없습니다.

---

정리

여기까지 하면 이렇게 됩니다.

• /usr/local/scouter/server — 수집기 실행 중 (6100 TCP/UDP)
• /usr/local/scouter/agent.host — 장비 상태 수집 중
• 톰캣 — 자바 에이전트가 붙어 애플리케이션 내부 수집 중

이제 남은 건 내 PC에서 클라이언트로 접속해서 보는 일입니다.

그런데 여기서 한 번 더 막혔습니다. 고객사 IP가 유동이라 방화벽에 열어 둔 IP가 바뀌어 버렸거든요 T.T

그 이야기는 다음 글에서 이어가겠습니다.

즐거운 하루 되십시오.