[성능 개선 이야기] 국산 APM 3종을 각각 다른 입장에서 써봤습니다 (Scouter / 제니퍼 / 와탭)

[성능 개선 이야기] 국산 APM 3종을 각각 다른 입장에서 써봤습니다 (Scouter / 제니퍼 / 와탭)

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

앞의 두 글에서 APM이 무엇인지, 시스템 모니터링 도구에는 어떤 것들이 있는지 소개해 드렸습니다.

• 👉 [성능 개선 이야기] APM이란 무엇인가? 철학과 기능, 언어별 동작 원리
• 👉 [DevOps] 시스템 모니터링 개념과 오픈소스 솔루션 비교 (nmon / Zabbix / Prometheus)

그런데 소개만 하고 넘어가면 좀 아쉽더라구요 ^^;;

그래서 오늘은 제가 실제로 써본 것들 이야기를 해보려고 합니다.

그런데 "써봤다"는 말이 다 같은 뜻은 아니더라구요

글을 쓰려고 정리를 하다 보니, 제가 이 도구들을 만난 방식이 제각각이었습니다.

도구	제가 한 일
Scouter, Zabbix, nmon	직접 설치하고, 직접 모니터링하고, 직접 분석까지
제니퍼	고객사에 이미 깔려 있는 것을 SI 하면서 사용
와탭	설치는 MSP와 벤더가 하고, 저는 대시보드를 설계

같은 APM인데 어떤 입장에서 만나느냐에 따라 보이는 게 완전히 달랐습니다.

그래서 오늘 글은 "어느 게 제일 좋은가"가 아니라, 입장별로 뭐가 보였는지에 대한 이야기입니다.

어차피 읽으시는 분들도 셋 중 하나의 입장에 계실 테니까요 ^^

---

1. Scouter — 직접 다 해보는 입장

오픈소스 APM입니다. 비용이 안 든다는 게 제일 큰 장점이죠.

설치부터 에이전트 붙이고, 수집기 띄우고, 분석하는 것까지 다 해봤습니다. 직접 하다 보니 내부 구조를 이해하게 되는 건 확실히 좋았습니다.

다만 불편했던 점이 두 가지 있었습니다.

프로시저 파싱

일반 SQL은 파싱이 그럭저럭 되는데, 프로시저는 파싱이 잘 안 되더라구요.

제니퍼는 모니터링 화면에서 SQL 버튼을 누르고 들어가면 파라미터 매핑과 파싱이 거의 완벽합니다. 그 차이가 꽤 크게 느껴졌습니다.

생각해 보면 이유가 있을 것 같습니다. JDBC를 후킹해서 SQL을 잡는 구조인데, 프로시저 호출은 {call proc(?, ?)} 형태에 OUT 파라미터까지 섞여 있어서 매핑이 훨씬 까다롭습니다. 일반 SQL과는 난이도가 다르죠.

그리고 국내 금융권이나 공공 시스템은 비즈니스 로직이 프로시저에 들어 있는 경우가 많습니다. 그러다 보니 이 부분이 실무에서는 생각보다 크게 다가옵니다. 국산 상용 APM들이 이쪽에 공을 들인 이유도 여기 있을 것 같구요.

아직 해보진 않았지만, 어차피 오픈소스니까 자바 소스를 고쳐서 해결할 수 있지 않을까 하는 고민은 해봤습니다 ^^;; 언젠가 시간이 되면 한번 들여다볼 생각입니다.

데스크톱 클라이언트

Scouter는 클라이언트가 Eclipse RCP 기반 데스크톱 프로그램입니다. TCP로 수집기에 붙는 방식이죠.

공식 문서를 보니 이건 의도적인 선택이라고 합니다. 웹 기반 뷰어보다 더 많은 성능 데이터를 다룰 수 있어서라고 되어 있더라구요. 실제로 데이터를 깊게 파고들 때는 편합니다.

그런데 저처럼 결과를 고객에게 보여줘야 하는 입장에서는 이야기가 좀 다릅니다.

폐쇄망 고객사에서 클라이언트를 PC마다 설치하고, 담당자분을 제 자리로 불러서 화면을 같이 들여다보고 있으면 ^^;;

요즘 나오는 도구들은 웹 쪽으로 많이 강화되어 있다고 하는데, 링크 하나 보내면 되는 게 참 부러웠습니다.

도구를 고를 때 "내가 분석하기 편한가"만 보게 되는데, "이 결과를 누구에게 어떻게 보여줄 것인가"도 같이 봐야 한다는 걸 그때 알았습니다.

클라우드에서는 접속부터가 문제였습니다

이번 프로젝트는 AWS 환경이었는데, 여기서 한 번 더 걸렸습니다.

고객사 IP가 유동이더라구요. 방화벽에 접속 IP를 열어 놨는데 그 IP가 바뀌어 버리니 접속이 안 됐습니다 T.T

이것도 결국 같은 뿌리입니다. 클라이언트가 TCP로 수집기에 직접 붙는 구조라, 클라이언트가 앉아 있는 IP를 방화벽에서 열어 줘야 하거든요. 웹이었으면 이런 고민 자체가 없었을 겁니다.

결국 AWS 리모트 터널링으로 풀었습니다. 방화벽에 인바운드를 여는 대신 터널을 통해 붙는 방식이죠. 지금은 그렇게 운영 중입니다.

혹시 비슷한 상황이신 분들을 위해 덧붙이면, AWS에는 Systems Manager의 Session Manager 포트 포워딩이라는 기능이 있습니다. 인바운드 포트를 열거나 배스천 호스트를 두지 않고도 원격 호스트의 포트에 연결할 수 있어서, 유동 IP 환경에서는 방화벽에 IP를 등록하는 방식보다 훨씬 편합니다.

그런데 운영에는 안 쓰는 곳이 많더라구요

여러 현장에 Scouter를 설치해 봤는데, 개발할 때만 쓰고 운영에는 안 붙이는 경우가 꽤 있었습니다.

이해는 갑니다. 운영 시스템에 에이전트를 붙이는 건 부담스러운 일이니까요. 변경 승인도 받아야 하고, 혹시라도 영향이 있으면 안 되구요.

그런데 좀 아쉽습니다. 성능 문제는 운영에서 나니까요.

개발 환경은 부하도 다르고, 데이터 양도 다르고, 동시 사용자도 없습니다. 거기서 안 보이던 게 운영에서 터지는 거죠. APM을 개발에만 붙여 놓으면 정작 봐야 할 곳을 못 보게 됩니다.

이번 프로젝트에서는 운영에도 붙여서 보고 있는데, 확실히 다릅니다.

---

2. 제니퍼 — 이미 깔려 있는 것을 쓰는 입장

공공기관에는 제니퍼가 깔려 있는 곳이 많습니다. SI로 들어가면 이미 운영 중인 경우가 대부분이었습니다.

그래서 저는 설치나 튜닝을 해본 입장은 아니고, 주어진 도구로 분석하는 사용자 입장이었습니다.

이 입장에서 좋았던 건 앞에서 말씀드린 SQL 부분입니다. 화면에서 SQL 버튼을 눌러 들어가면 파라미터가 매핑된 실제 쿼리가 거의 그대로 보입니다. 느린 쿼리를 찾아서 바로 DBA분께 들고 갈 수 있죠.

성능 분석을 할 때 "이 쿼리가 느립니다"까지 바로 갈 수 있느냐는 생각보다 큰 차이를 만듭니다. 거기서 막히면 로그를 뒤지거나 따로 추적을 걸어야 하니까요.

그리고 이미 깔려 있다는 것 자체가 장점이기도 합니다. 도입 협의도, 설치 일정도, 에이전트 붙이는 승인도 필요 없이 바로 분석부터 시작할 수 있으니까요.

---

3. 와탭 — 설계하고 넘기는 입장

이 프로젝트에서는 조금 다른 역할이었습니다.

설치와 운영은 MSP와 벤더 쪽에서 진행했고, 저는 대시보드를 설계하는 일을 맡았습니다. 설계한 내용을 넘기면 그쪽에서 구현하는 방식이었습니다.

처음엔 "설치를 안 하면 뭘 하지" 싶었는데, 해보니 이게 따로 있는 일이더라구요.

고객은 "기본적인 것만" 원했습니다

요구사항이 그랬습니다. 복잡한 건 필요 없고 기본적인 것만 보고 싶다고요.

그래서 이렇게 정했습니다.

• TPS — 초당 처리 건수
• EQ — 대기 중인 트랜잭션 수
• Users — 사용자 수
• Recent Errors — 최근 발생한 오류
• Server Status — 인프라 서버 상태
• WAS Status — WAS 상태

여섯 개입니다. 위에서부터 사용자 쪽이고, 아래로 내려갈수록 인프라 쪽입니다. 문제가 생기면 위에서 아래로 훑어 내려갈 수 있게 순서를 잡았습니다.

그리고 산점도를 하나 넣었습니다

Scouter의 XLog 같은 화면입니다. 개별 트랜잭션을 점으로 뿌려주는 그거요.

찾아보니 도구마다 이름이 다르더라구요.

도구	이름
Scouter	XLog
제니퍼	X-View
와탭	트랜잭션 맵 차트

부르는 이름은 달라도 개념은 같습니다. X축이 시간, Y축이 응답시간, 점 하나가 트랜잭션 하나입니다.

이걸 넣은 이유가 있습니다.

앞의 여섯 개는 전부 집계 지표입니다. TPS도, 사용자 수도, 서버 상태도 다 뭉쳐서 나온 숫자예요. 그런데 집계는 소수의 문제를 숨깁니다.

전체 요청의 99%가 정상 응답시간 안에 들어오는데 나머지 1%가 1분씩 걸리는 상황을 생각해 보시면 됩니다. 평균으로 보면 멀쩡합니다. TPS도 정상이구요. 그런데 그 1%에 걸린 사용자는 시스템이 멈춘 걸로 느낍니다.

산점도에서는 그게 그냥 보입니다. 저 위에 점 하나가 덩그러니 떠 있으니까요.

그래서 대시보드를 집계 지표 + 개별 트랜잭션 두 층으로 만들었습니다. 여섯 개로 전체 흐름을 보고, 산점도로 튀는 놈을 잡는 구조입니다.

그리고 각각을 어제와 오늘 비교하도록 했습니다

이게 제일 중요한 부분이었다고 생각합니다.

지표를 하나만 보여주면 그게 좋은 건지 나쁜 건지 알 수가 없습니다.

TPS가 300이라고 화면에 떠 있으면, 그게 높은 건가요 낮은 건가요? 저는 모르고, 운영 담당자분도 모릅니다.

임계값을 정하는 방법도 있는데, 임계값은 정하기가 어렵습니다. 시스템마다 다르고, 시간대마다 다르고, 한번 정해 놓으면 잘 안 고치게 되구요.

그런데 어제와 오늘을 나란히 놓으면 이야기가 달라집니다.

• "어제 이 시간엔 300이었는데 오늘은 600이네" → 뭔가 있다
• "어제도 300, 오늘도 300" → 정상이다

기준을 따로 정하지 않아도, 화면이 스스로 기준을 만들어 줍니다. 그리고 이건 교육이 필요 없습니다. "어제보다 두 배"는 누구나 바로 이해하니까요.

지표 개수를 줄이라는 요구를 받았을 때, 무엇을 뺄지보다 남긴 것을 어떻게 읽히게 할지가 더 중요했습니다.

정리하면 대시보드가 세 가지를 답하도록 만든 셈입니다.

• 지금 어떤가 → 여섯 개 지표
• 평소와 다른가 → 어제/오늘 비교
• 숨은 놈이 있는가 → 산점도

---

4. 인프라 쪽 — nmon과 Zabbix

이 둘은 직접 설치부터 분석까지 해봤습니다.

nmon은 정말 가볍습니다. 자기가 잡아먹는 자원이 거의 없어서, 성능을 재는 도구가 성능에 영향을 주는 상황을 걱정하지 않아도 됩니다. 서버 한 대를 집중적으로 들여다볼 때 편합니다.

Zabbix는 중앙에서 여러 장비를 한꺼번에 볼 때 씁니다. 서버뿐 아니라 네트워크 장비, 스토리지까지 묶을 수 있죠. 대신 구축과 운영에 손이 좀 갑니다.

정리하자면 nmon은 한 대를 깊게, Zabbix는 여러 대를 넓게 보는 도구입니다.

---

5. 그래서 어떤 걸 쓰면 되나

우열을 가리는 건 별 의미가 없는 것 같습니다. 상황이 다르니까요.

상황	추천
예산이 없다	Scouter — 오픈소스, 다만 운영 부담은 내 몫. 클라우드·유동 IP 환경이면 접속 경로를 먼저 확인하세요
폐쇄망이고 국내 SI 환경이다	제니퍼 — 프로시저·SQL 파싱이 강함
SaaS가 가능하고 운영을 맡기고 싶다	와탭 — 설치·운영을 넘기고 설계에 집중
서버 한 대를 깊게 보고 싶다	nmon
여러 장비를 한 화면에서 보고 싶다	Zabbix

특히 결과를 누구에게 보여줄 것인가를 꼭 같이 생각해 보시길 권합니다. 혼자 분석하고 끝나는 일이면 상관없지만, 보고를 해야 하는 상황이라면 웹으로 접근되는지가 생각보다 크게 작용합니다.

---

마무리

세 가지를 다른 입장에서 써보고 나니, 남는 생각은 도구 이야기가 아니었습니다.

무엇을 볼지 정하는 일이 따로 있다는 것이었습니다.

와탭 프로젝트에서 지표 여섯 개를 고르고 어제와 비교하게 만든 일은, 사실 도구를 다루는 일이 아니었습니다. 이 시스템에서 무엇이 중요한지를 정하는 일이었죠.

도구는 바뀝니다. Scouter도 계속 좋아지고 있고, 요즘 나오는 것들은 웹으로 많이 옮겨 갔습니다. 그런데 무엇을 봐야 하는지 정하는 일은 도구가 대신해 주지 않더라구요.

다음 글에서는 로그 이야기를 해볼까 합니다. 인프라를 보고, 애플리케이션을 봤으면, 남은 건 무슨 일이 있었는지니까요 ^^

즐거운 하루 되십시오.