APM

"요즘 느려요" 라는 문의는 개발팀이 가장 손대기 어려운 종류의 문의였습니다. 서버의 자원 사용량 그래프를 열어 보면 CPU 는 30퍼센트, 메모리도 절반쯤 남아 있어 아무 문제가 없어 보입니다. 기계는 멀쩡한데 사용자는 8초를 기다리고 있는 상태입니다.

자원 그래프가 답하지 못하는 이유는 재는 자리가 다르기 때문입니다. 그 그래프는 기계가 얼마나 바쁜지를 재지, 사용자가 누른 버튼 하나가 응답을 돌려받기까지 몇 초가 걸렸는지를 재지 않습니다. 그래서 그다음 수단은 로깅이었습니다. 벌어진 일을 한 줄씩 글로 남기는 방식인데, 시작 시각과 끝 시각을 같이 남겨 두면 요청 하나가 걸린 시간을 알 수는 있습니다. 문제는 그 줄이 하루에 수백만 개씩 쌓인다는 점입니다. 어느 화면이 느린지 알려면 그 수백만 줄을 요청 종류별로 묶어 평균과 분포를 내야 하는데, 그 집계와 화면을 팀이 직접 만들어 쓰게 됩니다.

APM 은 그 집계와 화면을 제품으로 만들어 둔 것입니다. 애플리케이션 코드 안에 자리를 잡고 앉아 요청이 들어와서 나갈 때까지를 직접 재고, 그 값을 요청 종류별로 묶어 느린 순서대로 보여 줍니다. 기계가 아니라 요청을 재는 자리로 관점을 옮긴 것이 핵심 차이입니다.

가장 먼저 답하는 질문은 어느 요청이 느리냐입니다. 화면이나 주소별로 응답 시간을 묶어 느린 순서대로 세워 주므로, 문서 목록 화면이 0.3초인데 문서 저장 요청만 4.2초라는 사실이 목록 맨 위에 올라옵니다. 손댈 곳이 하나로 좁혀집니다.

두 번째는 그 느림이 몇 명에게 일어나는 일이냐입니다. 평균만 보면 1.2초로 멀쩡해 보이는 요청이, 상위 1퍼센트 구간에서는 9초가 걸리고 있을 수 있습니다. 백분위는 값을 작은 순서로 줄 세웠을 때 어느 위치에 있는 값인지를 가리키는 말이고, 성능에서는 보통 95번째나 99번째 자리를 봅니다. 사용자 100명 중 가장 오래 기다린 한 명이 얼마나 기다렸는지가 그 자리에 찍힙니다. 평균은 소수의 긴 요청을 다수의 짧은 요청이 덮어 버리기 때문에, 불만은 쌓이는데 숫자는 정상인 상태가 여기서 생깁니다.

세 번째는 그 요청 안에서 어느 단계가 느리냐입니다. 4.2초짜리 저장 요청을 열면 데이터베이스 조회에 3.1초, 권한 확인에 0.8초, 나머지에 0.3초 하는 식으로 쪼개 보여 줍니다. 데이터베이스 조회가 범인이면 그 조회문까지 짚어 주는 제품도 많습니다.

네 번째는 언제부터 느려졌느냐입니다. 응답 시간 그래프에 배포 시각을 같이 찍어 두면, 화요일 오후 4시 배포 직후부터 값이 0.4초에서 1.9초로 올라갔다는 사실이 눈으로 확인됩니다. 원인 후보가 그 배포에 들어간 변경으로 좁혀집니다.

APM 이 하는 일은 다른 방법으로도 나눠 할 수 있습니다. 무엇을 포기하는지가 다릅니다.

1. 로깅으로 직접 재기 — 요청마다 걸린 시간을 로그에 남기고 그 로그를 검색 도구에 넣어 집계합니다. 값이 적게 들고 남기는 항목을 마음대로 정할 수 있지만, 순위 화면과 백분위 계산을 팀이 만들어 유지해야 합니다.
2. 메트릭과 대시보드 — 분당 요청 수와 응답 시간 같은 값을 시간축에 쌓아 그래프로 봅니다. 언제부터 이상해졌는지는 1초 단위로 짚어 주지만, 어느 요청의 어느 단계가 느린지는 그래프에 없습니다.
3. 분산 추적 — 요청 하나가 여러 서비스를 거친 경로를 순서대로 이어 붙입니다. 서비스가 여럿으로 쪼개져 있을 때는 이쪽이 더 정확하고, 요즘 APM 제품은 대부분 추적 기능을 품고 있어 둘의 경계가 흐릿합니다.
4. 에러 트래킹 — 다루는 대상이 다릅니다. 이쪽은 터진 것을 모으고 APM 은 느린 것을 모읍니다. 둘 다 필요하고 서로를 대신하지 못합니다.

서비스가 하나뿐이고 사용자가 수백 명이면 1번으로 한동안 버팁니다. 화면이 수십 개로 늘고 어느 화면이 느린지 묻는 사람이 생기면 그때가 APM 을 붙일 때입니다.

"APM 보니까 저장 요청 95백분위가 어제 1.1초에서 오늘 4.8초로 튀었어요."

느려진 대상과 시점이 이미 특정됐으니 그 사이 배포를 보자는 말입니다.

"그 화면 평균은 괜찮은데 상위 구간이 나빠요. APM 에서 느린 요청만 골라 볼게요."

평균에 가려진 소수의 긴 요청을 따로 꺼내 보겠다는 뜻입니다.

"APM 에 그 단계가 안 잡혀요. 표식을 안 심어 뒀네요."

도구가 자동으로 재 주는 범위 밖이라 코드에 측정 지점을 추가해야 한다는 뜻입니다.

페이지덱에서 문서 저장이 느리다는 문의가 이틀 사이 열한 건 들어왔습니다. 태오가 APM 을 열어 보니 저장 요청의 95백분위가 1.1초에서 4.8초로 올라가 있었고, 그래프가 꺾인 자리는 지난 목요일 배포 시각과 겹쳤습니다. 요청 안을 쪼개 보니 늘어난 3.7초 가운데 3.4초가 권한 확인 단계에 몰려 있었습니다.

지현은 이 화면을 문의 대응에도 씁니다. 전체 사용자 중 몇 퍼센트가 그 구간에 들어가는지를 숫자로 확인한 뒤, 고객에게 원인과 예상 복구 시점을 적어 보냅니다. 느낌으로 "일부 사용자" 라고 적던 자리에 "저장 요청의 3퍼센트" 라고 적을 수 있게 된 것이 이 도구가 바꾼 부분입니다.

APM 을 붙이면 서비스가 빨라진다고 생각하는 경우가 있습니다. 성능이라는 이름이 붙어 있고 도입한 다음 달에 실제로 응답 시간이 좋아진 사례가 많아서 그렇게 보입니다. 하지만 좋아진 것은 도구가 아니라 그 도구가 짚어 준 곳을 팀이 고쳤기 때문입니다. 도구는 체온계이고 해열제가 아닙니다. 붙여만 두고 아무도 그 화면을 보지 않으면 응답 시간은 그대로이고, 도구 사용료만 매달 나갑니다.

자동으로 다 잡아 준다는 기대도 자주 어긋납니다. APM 은 웹 요청의 시작과 끝, 데이터베이스 조회, 외부 창구 호출처럼 널리 쓰이는 지점은 별도 작업 없이 잽니다. 그러나 팀이 직접 만든 계산 단계나 내부 작업 큐는 그 자리에 측정 표식을 심어 둔 만큼만 보입니다. 4.2초짜리 요청을 열었는데 "나머지 3.5초" 로만 뭉뚱그려 나오는 화면이 그래서 나옵니다. 표식을 심지 않은 채로 도입해 두면, 정작 급할 때 도구가 답하지 못하는 구간에서 시간을 씁니다.