성능 효율성

성능 효율성은 소프트웨어가 일을 제때 끝내는지, 그러는 데 기계를 얼마나 덜 쓰는지, 일이 몰려도 그 둘을 지키는지를 함께 따지는 잣대입니다. 빠르기만 보지 않고 그 빠르기를 내는 데 든 값까지 봅니다. 소프트웨어 품질을 나눠 보는 국제 표준에서 쓰는 이름입니다. 클라우드 설계를 점검하는 틀에서도 비슷한 뜻으로 씁니다.

쉽고 빠른 이해

무엇을 따지나 — 요청에 답이 제때 오는지, 그러는 동안 서버를 얼마나 쓰는지, 사람이 몰려도 버티는지 셋을 함께 봅니다. 서버 열 대로 0.2초 만에 답하는 서비스와 두 대로 0.2초 만에 답하는 서비스는 빠르기가 같습니다. 성능 효율성은 두 대 쪽이 높습니다.

왜 따로 보나 — 빠르기만 재면 서버를 늘려서 빨라진 것과 코드가 나아져서 빨라진 것이 똑같아 보입니다. 서버를 늘리는 데는 돈이 듭니다. 같은 빠르기를 더 적은 기계로 내는지를 봐야 그 차이가 드러납니다.

어떻게 보나

1. 몰리는 요청 수와 쌓인 데이터 양 같은 조건을 정합니다. 그 조건에서 지킬 기준을 숫자로 적습니다
2. 그 조건에서 걸린 시간, 서버를 쓴 정도, 버틴 사용자 수를 잽니다
3. 잰 값을 기준과 견줍니다

대가 — 셋은 서로 당깁니다. 자주 쓰는 값을 메모리에 올려 두면 답이 빨라집니다. 대신 메모리를 더 씁니다. 어느 쪽을 얼마나 지킬지는 먼저 정해야 합니다. 사용자가 기다리는 화면이면 시간이 먼저입니다. 밤새 도는 정산 작업이면 자원을 아끼는 쪽이 먼저일 수 있습니다.

상세

택배 회사를 평가한다고 해 봅시다. 물건이 하루 만에 오는지만 보면 트럭을 두 배로 늘린 회사도 합격입니다. 트럭 몇 대로 그 속도를 내는지, 명절에 물량이 몰려도 하루 배송을 지키는지까지 봐야 일을 잘하는 회사인지 알 수 있습니다.

소프트웨어가 일하는 동안 쓰는 기계의 몫을 자원이라고 부릅니다. CPU(Central Processing Unit, 중앙처리장치) · 메모리 · 디스크 · 네트워크가 흔히 꼽는 넷입니다. CPU 는 계산을 하는 칩입니다.

자원을 얼마나 쓰는지는 사용률로 잽니다. CPU 사용률은 그 칩이 쉬지 않고 일한 시간의 비율입니다. 메모리 · 디스크 · 네트워크도 같은 식으로 얼마나 찼는지를 잽니다.

성능 효율성은 정해 둔 조건에서 시간 기준을 맞추면서 자원을 얼마나 알뜰하게 쓰는지를 가리킵니다. 「주문 조회 요청의 95%가 200ms(밀리초) 안에 끝나고, 그동안 서버의 CPU 사용률은 70% 아래」가 그런 기준 하나입니다. 시간과 자원을 한 기준에 같이 적는 것이 이 낱말의 핵심입니다. 여기에 사람이 가장 몰리는 때에도 그 기준을 지키는지가 셋째 물음으로 붙습니다.

품질 특성의 하나

성능 효율성은 품질 특성의 하나입니다. 품질 특성은 소프트웨어의 품질을 몇 갈래로 나눠 볼 때 쓰는 항목입니다. 한데 뭉쳐 점수 하나로 매기면 무엇을 고칠지 모르기 때문에 항목을 나눠 따로 잽니다.

품질 특성 가운데에는 기능이 맞게 도는지를 묻는 것이 있습니다. 얼마나 잘 도는지를 묻는 것도 있습니다. 성능 효율성은 뒤쪽입니다. 이런 쪽의 기준을 요구사항으로 적으면 비기능 요구사항이 됩니다.

이 이름은 국제 표준 ISO/IEC 25010에서 왔습니다. 국제표준화기구(ISO, International Organization for Standardization)와 국제전기기술위원회(IEC, International Electrotechnical Commission)가 함께 낸 표준입니다. 소프트웨어 제품의 품질을 어떤 특성으로 나눌지를 정합니다. 이 문서에서는 이 표준이 세운 틀을 품질 모델이라고 부릅니다.

품질 모델은 제품 품질을 여러 특성으로 나눕니다. 성능 효율성은 기능 적합성 · 신뢰성 · 보안성 같은 특성과 나란히 놓입니다.

성능 효율성을 이루는 세 하위 특성

성능 효율성은 다시 셋으로 나뉩니다. 답이 제때 오는지를 보는 시간 동작, 자원을 얼마나 쓰는지를 보는 자원 사용, 상한에서도 버티는지를 보는 용량입니다. 아래 그림은 이 셋이 품질 모델 안에서 어디에 매달리는지를 보입니다.

flowchart TD
    Q["제품 품질"] --> F["기능 적합성"]
    Q --> P["성능 효율성"]
    Q --> R["신뢰성"]
    Q --> S["보안성"]
    Q --> O["그 밖의 특성"]
    P --> T["시간 동작"]
    P --> U["자원 사용"]
    P --> C["용량"]

셋을 재는 값도 갈립니다. 응답 시간은 요청을 보내고 답을 받기까지 걸린 시간입니다. 처리량은 정해진 시간 동안 끝낸 요청 수입니다. 흔히 초당 요청 수로 적습니다.

시간 동작은 셋 가운데 가장 흔히 보는 목표입니다. 사용자가 버튼을 누르고 답이 뜨기까지의 시간이 대표적인 예입니다. 서버 안에서 요청 하나를 처리하는 데 걸린 시간도 시간 동작에 듭니다.

자원 사용은 자원이 모자랄 위험이 있을 때 따로 봅니다. 메모리가 작게 정해진 서버라면 요청 하나가 메모리를 얼마나 잡는지가 동시에 몇 건을 받을 수 있는지를 정합니다.

용량은 상한을 묻습니다. 인기 공연 예매가 열리는 순간처럼 사람이 한꺼번에 몰릴 때 버티는지를 봅니다. 평소에는 제때 답하는 서비스도 상한 근처에서 무너지면 용량이 모자란 것입니다.

빠르기와 효율의 차이

이름에 「효율」이 붙은 까닭은 시간 동작 하나로 끝나지 않기 때문입니다. 응답 시간은 서버를 늘려서도 줄일 수 있습니다. 그러면 시간 기준은 맞습니다. 하지만 같은 일에 드는 자원이 늘어납니다.

숫자로 보겠습니다. 두 서비스가 모두 초당 1,000건을 200ms 안에 처리한다고 합시다. A 는 서버 열 대를 씁니다. B 는 두 대를 씁니다.

시간 기준만 보면 둘은 같습니다. 자원까지 보면 B 가 같은 일을 5분의 1 자원으로 해냅니다. 성능 효율성은 B 쪽이 높습니다. 서버 대수가 곧 운영비인 클라우드에서는 이 차이가 매달 내는 요금의 차이가 됩니다.

세 특성 사이의 맞바꿈

한 특성을 끌어올리는 손질이 다른 특성을 깎는 일이 흔합니다. 시간을 얻으려고 자원을 내주기도 합니다. 자원을 아끼려고 시간을 내주기도 합니다. 백엔드에서 자주 하는 손질을 표로 모았습니다.

표에서 볼 것은 「내주는 것」 칸이 빈 줄이 없다는 점입니다. 성능 효율성을 높인다는 말은 셋을 모두 최대로 만든다는 뜻이 아닙니다. 요구사항이 정한 시간 기준을 사람이 가장 몰리는 때까지 지키는 선에서 자원을 덜 쓰는 쪽을 고르는 일입니다.

어느 특성을 먼저 지킬지는 그 서비스에 무엇이 위험한지에 따라 갈립니다. 사용자가 기다리는 화면이면 시간 동작이 먼저입니다. 밤새 도는 정산 작업이면 정해진 시간 안에 끝나기만 하면 되므로 자원을 아끼는 쪽이 먼저일 수 있습니다.

조건과 함께 적는 기준

성능 효율성은 조건 없이 말할 수 없습니다. 같은 서비스도 요청이 열 건 몰릴 때와 만 건 몰릴 때 숫자가 다릅니다. 데이터가 천 행일 때와 천만 행일 때도 다릅니다.

그래서 기준은 조건과 한 묶음으로 적습니다. 조건에는 시스템에 한꺼번에 걸리는 일감의 양인 부하, 쌓여 있는 데이터의 양, 돌리는 기계의 사양이 들어갑니다.

응답 시간은 평균보다 백분위수로 적는 일이 많습니다. 백분위수는 값을 작은 것부터 줄 세웠을 때 몇 번째에 오는 값인지를 말합니다. 요청 백 건을 걸린 시간이 짧은 순으로 세웠을 때 95번째 요청이 걸린 시간이 95번째 백분위수입니다. 평균은 일부 요청만 크게 느려지면 조금밖에 안 움직여서 그 느려짐을 가립니다.

아래는 주문 조회 서비스 하나의 기준을 조건과 세 특성으로 나눠 적은 예입니다.

조건 칸이 비어 있으면 잰 숫자가 기준을 맞춘 것인지 가릴 수 없습니다. 「300ms 안에 답한다」는 사용자 한 명일 때의 말인지 오백 명일 때의 말인지에 따라 전혀 다른 약속입니다.

성능 효율성을 재고 높이는 활동

성능 효율성은 잣대입니다. 그 잣대를 들고 하는 활동은 저마다 따로 이름이 있습니다.

넷은 순서로 이어집니다. 성능 테스트로 지금 값을 압니다. 성능 튜닝으로 그 값을 높입니다. 성능 회귀를 막아 높인 값을 지킵니다. 용량 계획으로 앞날을 대비합니다.

클라우드 설계 점검 틀에서 쓰는 뜻

같은 이름이 클라우드에서도 쓰입니다. AWS(Amazon Web Services)는 클라우드 설계를 점검하는 틀인 Well-Architected Framework를 내놓고 있습니다. 이 틀은 설계를 여섯 기둥으로 나눠 봅니다. 성능 효율성은 그 가운데 하나입니다. 나머지 다섯은 운영 우수성 · 보안 · 신뢰성 · 비용 최적화 · 지속 가능성입니다.

뜻은 품질 모델의 것과 겹칩니다. 차이는 보는 대상에 있습니다. 품질 모델은 만들어진 소프트웨어를 재는 쪽입니다. 클라우드의 기둥은 그 성능을 오래 효율적으로 내도록 설계를 고르는 쪽입니다.

그래서 이 기둥은 고르는 문제를 묻습니다. 어떤 아키텍처를 고를지, 어떤 컴퓨팅 자원과 하드웨어를 쓸지, 데이터와 네트워크를 어떻게 둘지입니다.

관련 항목

성능 효율성을 이루는 하위 특성

시간 동작 · 자원 사용 · 용량

성능 효율성을 재는 지표

응답 시간 · 처리량 · 지연 · 백분위수 · 꼬리 지연 · 사용률 · 메모리 사용량 · 동시 사용자

성능 효율성과 나란히 놓이는 품질 특성

기능 적합성 · 신뢰성 · 보안성 · 사용성 · 호환성 · 유지보수성 · 이식성

성능 효율성을 정의하는 표준·설계 점검 틀

ISO 25010 · ISO 9126 · SQuaRE · Well-Architected Framework

성능 효율성이 속하는 상위 분류

성능 · 품질 특성 · 소프트웨어 품질 · 비기능 요구사항

성능 효율성을 재고 높이는 활동

성능 테스트 · 부하 테스트 · 스트레스 테스트 · 성능 회귀 · 성능 튜닝 · 용량 계획 · 프로파일링 · 성능 엔지니어링

세 특성을 맞바꾸는 기법

캐시 · 압축 · 스레드 풀 · 배치 처리 · 커넥션 풀 · 수평 확장 · 수직 확장

성능 효율성을 깎는 흔한 원인

병목 · N+1 문제 · 메모리 누수 · 락 경합 · 풀 테이블 스캔