성능 — 유미위키

어떤 시스템이 일을 얼마나 잘 해내는지를 다루는 자리입니다. 무엇을 재느냐가 하나로 정해지지 않습니다. 재는 잣대가 여럿입니다. 그래서 성능이 무엇이냐는 물음에 한 문장으로 답하기 어렵습니다.

쉽고 빠른 이해

어떤 시스템이 일을 얼마나 잘 해내는지 다루는 자리입니다. 서버가 요청 하나를 처리하는 데 걸린 시간을 재는 일도, 사용자가 화면을 보며 느끼는 속도를 다루는 일도 여기에 듭니다.

한 문장 정의가 안 서는 까닭은 잣대가 하나가 아니어서입니다. 무엇을 재는지 먼저 정해야 잘 해내고 있는지를 말할 수 있는데, 그 무엇이 여럿입니다. 어디를 보느냐에 따라 셋으로 갈립니다.

사용자를 마주하는 쪽을 볼 때
잰 값을 하나의 수로 낼 때 — 평균으로 낼지, 오래 걸린 쪽 끝을 따로 볼지
서버를 이루는 부품 하나하나를 볼 때

갈래마다 볼 것에 이름이 따로 붙어 있고, 그 이름들이 서로 당깁니다. 하나만 보려 해도 다른 잣대가 따라 들어오고, 평균만 내면 오래 걸린 쪽 끝이 나빠지는 것을 놓칩니다.

그래서 이 자리의 일도 하나로 끝나지 않습니다. 무엇을 어떤 잣대로 잴지 정하고, 병목이 어디인지 찾고, 고치고, 고친 상태가 유지되는지 지켜봅니다.

상세

성능은 무엇을 만드는 일이 아니라 무엇을 재는가로 갈리는 구역입니다. 잣대가 하나였다면 한 문장 정의가 섰을 것입니다. 잣대마다 세는 대상이 다릅니다. 한 잣대를 밀면 다른 잣대가 딸려 움직입니다. 잣대를 갈라 적은 자리는 Google SRE Book(Site Reliability Engineering, 사이트 신뢰성 공학)과 Brendan Gregg 의 글입니다.

어디를 보나	갈라 놓은 이름	그렇게 적은 곳
사용자를 마주하는 시스템	지연 · 트래픽 · 오류 · 포화	Google SRE Book, Monitoring Distributed Systems
값의 분포	평균 · 중앙값 · 높은 분위수 · 꼬리 지연	Google SRE Book, Service Level Objectives
자원 하나하나	사용률 · 포화 · 오류	Brendan Gregg, USE 방법(Utilization Saturation and Errors, 사용률 포화 오류)

잣대를 가른 세 자리

Google SRE Book 의 「Monitoring Distributed Systems」 장은 사용자를 마주하는 시스템에서 네 가지 잣대만 잴 수 있다면 이 넷에 집중하라고 적습니다. 지연과 트래픽과 오류와 포화입니다. 각각이 무엇을 세는지는 그 이름들이 갖습니다.

같은 책의 「Service Level Objectives」 장은 잰 값을 하나의 수로 내는 방식을 다시 가릅니다. 요청 지연을 평균 내는 것이 매력적으로 보일 수 있지만 중요한 세부를 가린다고 적습니다. 대부분의 잣대는 평균보다 분포로 생각하는 편이 낫다고 적습니다. 그래서 평균과 중앙값과 높은 분위수가 따로 이름을 얻습니다.

Brendan Gregg 은 자원 쪽에서 다시 셋으로 가릅니다. USE 방법을 어떤 시스템의 성능이든 분석하는 방법론이라고 적습니다. 모든 자원마다 사용률과 포화와 오류를 확인하라는 것입니다. 여기서 자원은 서버의 물리적 기능 구성 요소 전부입니다. CPU(Central Processing Unit, 중앙처리장치)와 디스크와 버스가 그 안에 듭니다.

잣대끼리 당기는 자리

이름이 여럿인 것으로 끝나지 않습니다. 같은 문서들이 잣대 사이에 걸린 관계도 적습니다. Google SRE Book 은 많은 시스템이 사용률을 다 채우기 전에 성능이 떨어진다고 적습니다. 그래서 사용률 목표를 두는 것이 필수라고 덧붙입니다. 지연 증가는 흔히 포화의 선행 지표라고도 적습니다. 한 잣대를 보려 해도 다른 잣대의 이름이 따라 들어옵니다.

이 구역에서 마주치는 일

그래서 이 자리에서 하는 일도 목록으로 열립니다. 무엇을 어떤 잣대로 잴지 정하는 일이 있습니다. 재둔 것에서 병목을 찾는 일이 있습니다. 찾은 자리를 고치는 일이 있습니다. 고쳐 놓은 상태가 유지되는지 지켜보는 일이 있습니다. Gregg 은 USE 방법을 성능 조사 초기에 시스템 차원의 병목을 가려내는 데 쓰라고 적습니다. 잣대를 고르는 일과 병목을 찾는 일이 같은 문장 안에 붙어 있는 자리입니다.

경계

사용자가 느끼는 속도

사용자가 화면을 보며 느끼는 속도를 다루는 일도 이 구역인가. 맞습니다.

web.dev 의 Web Vitals 문서는 Web Vitals 를 웹에서 사용자 경험을 전하는 데 핵심이 되는 품질 신호에 통일된 지침을 주려는 Google 의 시도라고 적습니다. 사이트 소유자가 자기 사용자에게 전하고 있는 경험의 품질을 알기 위해 성능 전문가가 되어야 하는 것은 아니어야 한다고 적습니다. Core Web Vitals 는 모든 웹 페이지에 적용되는 Web Vitals 의 부분집합입니다. 현재 묶음은 로딩과 상호작용성과 시각적 안정성이라는 사용자 경험의 세 측면에 초점을 둡니다.

판정의 근거는 그 문서가 각 잣대를 무엇으로 부르는가에 있습니다. LCP(Largest Contentful Paint, 최대 콘텐츠 페인트)를 로딩 성능을 재는 것이라고 적습니다. INP(Interaction to Next Paint, 다음 페인트까지의 상호작용)를 상호작용성을 재는 것이라고 적습니다. CLS(Cumulative Layout Shift, 누적 레이아웃 이동)를 시각적 안정성을 재는 것이라고 적습니다. 사용자 쪽에서 재는 잣대를 그 문서가 스스로 성능을 재는 것이라고 적으므로 이 구역 밖으로 밀어낼 근거가 없습니다.

재는 방식도 서버 쪽과 같은 자리에 놓입니다. web.dev 는 권장 목표에 대부분의 사용자가 닿는지 확인하려면 페이지 로드 분포의 한 지점을 재는 것이 좋은 기준이라고 적습니다. 모바일과 데스크톱 기기로 나눠 봅니다. 평균이 아니라 분포에서 한 지점을 골라 본다는 점에서 앞 절의 꼬리 분위수와 같은 어휘입니다.

여담

「성급한 최적화는 만악의 근원이다」라는 말은 Donald E. Knuth 가 1974년 Computing Surveys 에 실은 논문 「Structured Programming with go to Statements」 268쪽에 나옵니다. 그 문장 앞뒤에는 조건이 붙어 있습니다. 작은 효율은 대략 97 퍼센트의 경우에 잊어버리자고 적은 다음에 이 문장이 옵니다. 바로 뒤 문장에서 그러나 그 결정적인 3 퍼센트에서는 기회를 놓치지 말아야 한다고 적습니다.

성능

상세

잣대를 가른 세 자리

잣대끼리 당기는 자리

이 구역에서 마주치는 일

경계

사용자가 느끼는 속도

여담

관련 항목

재는 잣대

성능을 분석하는 방법

분석에 쓰는 도구

성능 유지를 확인하는 수단

사용률·포화·오류를 재는 자원

자원 포화·오류의 신호