USE 방법

USE 방법은 서버가 느릴 때 어디가 막혔는지를 빠짐없이 찾는 점검법입니다. 서버를 이루는 자원을 하나씩 꼽습니다. 그리고 자원마다 같은 세 가지를 물어봅니다. 짐작으로 한 곳만 파다가 진짜 원인을 놓치는 일을 줄여 줍니다.

쉽고 빠른 이해

USE 방법은 서버의 부품마다 같은 질문 셋을 던지는 점검표입니다. 프로세서에게도, 디스크에게도, 네트워크에게도 똑같이 묻습니다. 얼마나 바빴나, 못 받은 일이 줄을 섰나, 고장 신호가 났나입니다.

이렇게 하는 까닭은 짐작이 자주 빗나가서입니다. 느리다는 말을 들으면 보통 제일 의심 가는 곳부터 봅니다. 거기가 멀쩡하면 다음 짐작으로 넘어가다가 시간을 다 씁니다.

순서는 이렇습니다.

1. 서버에 있는 부품의 목록을 먼저 만듭니다
2. 부품 하나마다 질문 셋을 차례로 확인합니다
3. 이상한 답이 나온 부품을 더 깊이 파고듭니다

대가도 있습니다. 부품 목록을 미리 만들어 둬야 합니다. 줄을 섰는지는 재기 어려운 부품이 많습니다. 부품이 한가해도 느린 경우는 이 점검표로 안 보입니다.

상세

이 절은 USE 방법이 무엇을 묻고, 어떤 순서로 묻고, 무엇을 놓치는지를 다룹니다.

정비소에 차를 맡기면 정비사는 먼저 점검표를 폅니다. 엔진, 브레이크, 타이어를 차례로 짚으며 칸마다 표시를 합니다. 주인이 브레이크가 이상하다고 했어도 표에 있는 칸은 전부 봅니다.

이름과 세 질문

USE 방법은 서버에 그런 점검표를 두는 일입니다. USE 는 Utilization(사용률), Saturation(포화), Errors(오류)의 머리글자입니다. 성능 엔지니어 브렌던 그레그(Brendan Gregg)가 이 점검법을 정리하고 이름을 붙였습니다. 한 줄로 줄이면 「모든 자원마다 사용률, 포화, 오류를 확인하라」입니다.

여기서 자원은 일을 받아 처리하는 서버의 부품입니다. CPU(Central Processing Unit, 중앙처리장치), 메모리, 디스크, 네트워크 같은 것들입니다.

자원 하나가 한계에 닿으면 그 자원을 거치는 요청이 모두 느려집니다. 이렇게 전체 속도를 붙잡는 한 곳을 병목이라고 부릅니다.

세 질문은 각각 다른 것을 봅니다. 셋을 나란히 놓으면 이렇습니다.

표의 셋째 열처럼 질문 셋은 자원마다 구체적인 값으로 바뀝니다. 자원 목록을 만들었으면 다음 준비는 그 값을 무엇으로 잴지 정하는 것입니다.

사용률과 포화를 따로 보는 까닭

사용률은 자원이 얼마나 바빴는지를 말해 줍니다. 100퍼센트에 가까우면 그 자원이 병목일 가능성이 큽니다. 하지만 사용률만으로는 요청이 기다리고 있는지까지는 알 수 없습니다.

포화가 그 빈칸을 채웁니다. 자원이 쉴 틈 없이 일해도 뒤에 줄이 없으면 요청은 아직 기다리지 않습니다. 줄이 생기기 시작하면 그때부터 요청마다 기다리는 시간이 붙습니다. 줄은 대개 큐로 나타나므로 포화는 큐에 쌓인 일의 양으로 재는 경우가 많습니다.

자원의 오류와 요청의 오류

오류는 앞의 둘과 성격이 다릅니다. 한가한 디스크도 읽기에 실패할 수 있습니다. 그러면 그 읽기를 기다리던 요청은 실패하거나 늦어집니다. 사용률과 포화만 봐서는 이 일이 안 보입니다.

USE 방법의 오류는 자원이 낸 오류입니다. 디스크 읽기 실패, 네트워크에서 사라진 패킷, 메모리를 받지 못한 할당이 그렇습니다.

요청 쪽에서 세는 오류율과는 다른 값입니다. 오류율은 사용자가 보낸 요청 가운데 실패로 끝난 비율입니다. 자원의 오류가 요청의 실패로 이어질 수는 있습니다. 그래도 둘을 같은 값으로 섞어 세지 않습니다.

자원에서 출발하는 목록

USE 방법은 지표가 아니라 자원에서 출발합니다. 모니터링 화면에 떠 있는 그래프만 보면 화면에 없는 자원은 아예 안 보입니다. 자원 목록부터 만들어 칸마다 값을 채웁니다. 그러면 빈칸이 곧 아직 안 잰 곳이 됩니다.

자원에는 부품만 드는 것이 아닙니다. 소프트웨어가 나눠 주는 것도 자원입니다. 개수가 정해져 있어서 다 쓰면 기다려야 하는 것에도 같은 세 질문이 통합니다.

백엔드 서버에서 자주 만나는 것으로 셋을 꼽습니다.

• 스레드 풀: 스레드를 미리 만들어 두고 작업을 나눠 맡기는 묶음
• 커넥션 풀: 데이터베이스 연결을 미리 열어 두고 빌려 쓰는 묶음
• 락: 한 번에 한 스레드만 들어가게 막는 잠금

아래 표는 하드웨어 부품 셋과 이 소프트웨어 자원 셋에 세 질문의 값을 채운 것입니다.

소프트웨어 자원도 부품처럼 세 칸이 다 찹니다. 그래서 같은 목록에 넣어 함께 훑습니다.

점검 순서

자원 하나를 볼 때 질문 셋의 순서는 대개 오류가 먼저입니다. 오류는 났거나 안 났거나로 읽혀서 해석이 빠릅니다. 사용률과 포화는 얼마면 높은지를 판단해야 하므로 그다음에 봅니다.

flowchart TD
    A["자원 목록에서 하나를 고른다"] --> B{"오류가 났나"}
    B -->|예| X["그 자원을 더 깊이 조사한다"]
    B -->|아니오| C{"사용률이 높나"}
    C -->|예| X
    C -->|아니오| D{"포화가 있나"}
    D -->|예| X
    D -->|아니오| E["목록의 다음 자원으로"]
    E --> A

그림의 고리를 따라 목록을 끝까지 돌아도 걸린 자원이 없을 수 있습니다. 그러면 병목은 목록의 자원 밖에 있을 가능성이 큽니다. 원격 서비스의 응답을 기다리는 시간처럼 서버의 부품이 쉬는 동안 흐르는 시간이 그렇습니다.

평균이 가리는 순간

사용률은 보통 일정 시간 동안의 평균으로 봅니다. 평균을 내는 구간이 길면 짧게 꽉 찼던 순간이 묻힙니다. 1분 평균이 50퍼센트여도 그 가운데 30초는 100퍼센트였을 수 있습니다.

꽉 찬 30초 동안 들어온 요청은 줄을 섰습니다. 그래서 평균 사용률이 낮아 보여도 포화 값을 같이 봅니다. 줄이 한 번이라도 생겼다면 자원이 짧게라도 꽉 찼다는 신호입니다.

찾는 것과 못 찾는 것

USE 방법이 찾는 것은 자원의 병목과 자원의 오류입니다. 서버가 전체적으로 굼떠서 어디부터 봐야 할지 모를 때 특히 쓸모가 있습니다. 성능 조사를 시작할 때 먼저 한 바퀴 돌리는 점검으로 씁니다.

자원이 모두 한가해도 느린 경우는 못 찾습니다. 요청 하나가 원격 서비스를 차례로 열 번 부른다면 서버의 부품은 쉬고 있어도 응답은 늦습니다. 이런 느림은 요청이 어디서 시간을 썼는지 따라가는 트레이스로 찾습니다.

그래서 USE 방법은 요청 쪽에서 출발하는 방법과 짝을 이룹니다. RED 방법(Rate Errors Duration, 요청 수·오류·걸린 시간)이 그 짝입니다. 자원 대신 요청을 세어 같은 꼴의 세 값을 봅니다.

골든 시그널은 서비스 상태를 네 값으로 봅니다. 지연 시간, 트래픽, 오류, 포화입니다. 요청 쪽에서 재는 셋에 포화를 더한 묶음입니다.

관련 항목

USE 방법이 묻는 세 값

사용률 · 포화 · 오류 · 오류율 · 큐 길이

USE 방법이 훑는 하드웨어 자원

CPU · 메모리 · 디스크 · 네트워크 · 네트워크 인터페이스 · 버스 · 스왑

USE 방법이 훑는 소프트웨어 자원

스레드 풀 · 커넥션 풀 · 락 · 락 경합 · 파일 디스크립터 · 뮤텍스

USE 방법과 짝을 이루는 점검법

RED 방법 · 골든 시그널 · 드릴다운 분석 · 워크로드 특성화 · 지연 분석

USE 방법으로 얻은 값을 파고드는 도구

트레이스 · 프로파일링 · 플레임 그래프 · 모니터링 · 메트릭

USE 방법의 바탕을 이루는 이론

큐잉 이론 · 큐 · 평균 · 백분위수 · 리틀의 법칙

USE 방법이 속하는 상위 분야

성능 · 성능 분석 · 병목 · 용량 계획 · 관측성