아키텍처의 결정에는 성능과 관련된 것이 많다.
일반적으로 성능의 경우, 먼저 시스템을 실행 가능한 상태로 만들고, 성능을 측정한 후, 측정 데이터를 바탕으로 체계적인 절차를 이용한다.
그런데 일부 아키텍처 결정은 나중에 최적화를 통해 해결하기 어려운 성능상의 영향을 미치는 경우가 있다.
그렇다고 성능 상의 결정 방식을 글로 표현하기는 매우 어려운데, 모든 상황과 환경에 따라 그 결정의 옳고 그름이 완전히 달라질 수 있기 때문이다.
하지만 적어도 용어를 정리해두면, 성능과 관련된 논의를 시작할 수는 있다.
따라서 아래 용어들의 정의를 살펴보며, 각각이 어떤 의미를 갖는지 알아보자.
- 응답 시간(response time)
- 응답성(responsiveness)
- 대기 시간(latency)
- 처리량(throughput)
- 성능(performance)
- 부하(load)
- 부하 민감도(load sensitivity)
- 효율(efficiency)
- 용량(capacity)
- 확장성(scalability)
응답 시간(response time)
응답시간은 시스템이 외부에서 받은 요청을 처리하는 데 걸리는 시간이다.
요청은 버튼 누르기와 같은 UI 동작일 수도 있고 서버 API 호출일 수도 있다.
응답성(responsiveness)
응답성은 시스템이 요청을 얼마나 신속하게 인식하느냐다.
요청을 처리하는 시간이 짧더라도 요청을 인식하는 데 오래 걸리면 사용자가 답답하게 느끼기 때문에 응답성은 여러 시스템에서 중요한 요소다.
- 요청을 처리하는 동안 시스템이 대기한다면 응답성과 응답시간은 동일하다.
- 반면, 요청이 완료되기 전에 요청을 인식했음을 사용자에게 알리면 응답성이 개선된다.
예시로, 파일을 복사하는 동안 사용자에게 상태표시줄을 보여주면 응답 시간이 개선되지는 않지만 사용자 인터페이스의 응답성이 개선된다.
대기 시간(latency)
레이턴시는 수행할 작업의 존재 여부와 상관없이 모든 유형의 응답을 받는 데 걸리는 시간이다.
레이턴시는 일반적으로 원격 시스템과 관계가 깊다.
예를 들어, 필자의 노트북에서 실행 중인 프로그램에 대해 실제로는 아무 작업도 하지 않지만 언제 작업이 완료되는지를 보고하게 되면 당연히 거의 즉시 응답을 받는다.
그런데 프로그램이 원격 컴퓨터에서 실행 중인 경우 요청과 응답이 네트워크를 통해 전달되는 시간 때문에 몇 초의 시간 지연이 발생할 수 있다.
애플리케이션 개발자가 레이턴시를 줄이기 위해 할 수 있는 일은 아무것도 없다.
지연 시간은 원격 호출을 최소화해야 하는 이유이기도 하다.
처리량(throughput)
쓰루풋은 일정한 시간 동안 얼마나 많은 일을 할 수 있는지 측정한 것이다.
파일 복사 성능을 측정하는 경우 초당 바이트 단위로 처리량을 측정할 수 있다.
엔터프라이즈 애플리케이션에서 일반적인 측정치는 TPS(초당 트랜잭션)이지만 이 값은 트랜잭션의 복잡도에 따라 다른 의미를 가진다.
따라서 자신의 특정 시스템에 맞는 공통 트랜잭션 집합을 선택해야 한다.
성능(performance)
"성능"은 처리량이나 응답 시간 중 당신에게 더 중요한 항목을 의미한다.
기법에 따라 처리량은 향상되지만 응답 시간은 악화시키는 것도 있기 때문에 성능이라는 용어가 부정확한 경우에는 더 정확한 용어를 사용하는 것이 좋다.
사용자 관점에서는 응답성이 응답 시간보다 중요할 수 있으므로 응답 시간이나 처리량을 희생하고 응답성을 개선하면 성능이 향상된다.
부하(load)
부하는 시스템이 현재 처리하고 있는 작업량을 의미하고 현재 연결된 사용자 수로 측정할 수 있다.
일반적으로 부하는 응답 시간 등의 다른 측정치의 맥락에서 사용된다.
예를 들어, 어떤 요청의 응답 시간이 사용자가 10명일 때 0.5초이고 20명일 때 2초라고 이야기할 수 있다.
부하 민감도(load sensitivity)
부하 민감도는 부하에 따른 응답 시간의 변화를 나타내는 말이다.
예를 들어
- 시스템 A는 사용자가 10명 범위에서 응답 시간이 0.5초로 변함이 없다.
- 시스템 B는 사용자가 10명일 때 응답시간이 0.2초지만 사용자가 20명일때는 응답 시간이 2초로 증가한다.
이 경우, 시스템 A는 시스템 B보다 부하 민감도가 낮다.
효율(efficiency)
효율은 성능을 자원으로 나눈 것이다.
CPU 2개에서 30TPS를 내는 시스템은 동일한 CPU 4개에서 40TPS를 내는 시스템보다 효율이 좋다.
용량(capacity)
시스템의 용량은 최대 유효 처리량 또는 부하를 의미한다.
이 값은 절대 최댓값이거나 성능이 허용 가능한 임계값 미만으로 떨어지는 지점일 수 있다.
확장성(scalability)
확장성은 리소스(주로 하드웨어)를 추가했을 때 성능에 미치는 영향을 의미한다.
- 수직 확장: 단일 서버에 CPU/메모리와 같은 능력을 추가
- 비용이 기하급수적으로 증가
- 수평 확장: 서버를 여러대 추가하는 것
- 비용이 선형적으로 증가
시스템은 이왕이면 수평 확장이 가능하도록 설계하는 것이 좋다.
- 비용이 선형적으로 증가
만약 성능이 뛰어나지만 수직 확장만 가능하다면, 금방 한계에 부딪칠 것이다.
더 좋은 성능을 내는 소프트웨어를 만들기엔, 차라리 하드웨어의 비용(서버를 추가하는 비용)이 프로그래머 인건비보다 저렴할 수 있다.
본 내용은 마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처 패턴 도서를 참고하여 작성되었습니다.
엔터프라이즈 애플리케이션 아키텍처 패턴 - 예스24
이 책은 『엔터프라이즈 애플리케이션 아키텍처 패턴』의 재출간판이다. 『리팩토링』의 저자로도 잘 알려진 마틴 파울러는 이 책에서 기업용 애플리케이션을 개발할 때 직면하는 갖가지 까다
www.yes24.com
'CS Repository > 엔터프라이즈 애플리케이션 아키텍처 패턴' 카테고리의 다른 글
[PoEAA] 서비스 계층의 역할 (0) | 2025.09.02 |
---|---|
[PoEAA] 백엔드 개발자의 역할 - 소프트웨어 아키텍처와 엔터프라이즈 애플리케이션의 의미 (0) | 2025.08.29 |