E2. 핵심 개념과 데이터 흐름
이 문서는 OPENMARU APM을 쓰는 동안 계속 마주치는 세 가지 골격 개념 — 무엇을 보는가(그룹·인스턴스·에이전트), 무엇을 추적하는가(트랜잭션), 그 데이터가 어떻게 화면에 오는가 — 를 설명합니다. 조작법이 아니라 개념이므로, 화면을 열기 전에 한 번 읽어 두면 이후 모든 메뉴가 쉽게 이해됩니다.
용어의 짧은 정의만 필요하면 R8. 용어집을, 지표(TPS·APDEX 등)의 의미는 E3. 지표의 의미를 보세요.
E2.1 애플리케이션 그룹 · 인스턴스 · 에이전트
OPENMARU APM의 모든 화면은 결국 "어떤 대상의 데이터를 보여줄 것인가" 로 귀결됩니다. 그 대상은 세 층으로 이루어져 있습니다.
| 개념 | 무엇인가 | 비유 |
|---|---|---|
| 에이전트 | 인스턴스에 붙어 성능 데이터를 모아 APM 서버로 보내는 수집기 | 버스에 단 운행기록계(센서) — 속도·위치를 관제센터로 전송 |
| 인스턴스 | 실제로 돌고 있는 프로세스 하나 (WAS 한 대, DB 브로커 하나 등) | 버스 한 대 |
| 애플리케이션 그룹 | 함께 봐야 의미 있는 인스턴스들을 묶은 단위 (보통 하나의 서비스) | 같은 노선을 함께 운행하는 버스들 |
위 비유로 보면 APM 서버는 관제센터입니다 — 모든 버스(인스턴스)의 운행기 록계(에이전트)가 보내는 데이터를 모아 노선 전체(애플리케이션 그룹)의 상태를 한 화면에서 봅니다.
왜 "그룹"으로 묶는가
서비스 하나는 보통 여러 인스턴스로 돌아갑니다(부하 분산을 위해 WAS를 여러 대 띄우는 식 — 승객이 몰리는 노선에 버스를 여러 대 투입하는 것과 같습니다). 인스턴스를 하나씩 따로 보면 "이 서비스 전체가 괜찮은가"를 판단하기 어렵습니다. 그래서 관련 인스턴스를 애플리케이션 그룹으로 묶어, 합계·평균을 한눈에 보고 필요하면 인스턴스 하나로 좁혀 들어갑니다.
이 "전체 → 하나로 좁히기"가 화면 상단 컨텍스트 셀렉터(그룹 → 호스트 → 인스턴스)의 동작 원리입니다. 대상을 좁히는 방법은 H1. 모니터링 대상 좁히기, 그룹을 직접 만드는 방법은 H19. 애플리케이션 그룹에서 다룹니다.
참고 커스텀 그룹: 부서·점검 목적 등 자유로운 기준으로 인스턴스를 묶는 별도 그룹도 있습니다. 애플리케이션 그룹이 "서비스 단위"라면, 커스텀 그룹은 "보고 싶은 대로 묶는 단위"입니다.
주의 화면에 데이터가 비어 있다면, 대개 대상이 선택되지 않았거나 그 대상에 에이전트가 연결되지 않은 경우입니다. 에이전트 연결 상태는 H20. 에이전트 상태 점검에서 확인합니다.
E2.2 트랜잭션이란 — 요청 한 건의 처리 흐름
트랜잭션은 사용자 요청 하나가 처리되는 전체 흐름입니다. 버튼 한 번 클릭이 서버 안에서 어떻게 처리되는지를 하나로 묶은 단위라고 보면 됩니다.
하나의 트랜잭션은 여러 스팬(span) — SQL 한 번, 외부 호출 한 번, 메소드 한 번 — 으로 이루어집니다. OPENMARU APM은 이 스팬들을 시간 순서와 길이로 그려, 요청 한 건이 어디서 시간을 썼는지를 한눈에 보여 줍니다. 이 그림이 워터폴(waterfall) 입니다.