TPS 지표 이해하기

스타트업이 TPS 지표를 보기 시작해야 하는 순간

많은 초창기 스타트업은 성능에 큰 관심을 두지 않습니다. 제품을 만드는 것만으로도 바쁜 상황에서 성능까지 신경 쓰기 어렵기 때문입니다. 사용자가 갑자기 몰리더라도 아마존 오토 스케일이 해결해 줄 것이라 생각하기 쉽습니다.

실제로 빠르게 가치를 증명해야 하는 스타트업이라면 서비스 초창기부터 성능에 집중할 필요는 없습니다.

하지만 한 달 아마존 인프라 비용이 천만 원을 넘어가기 시작하면 이야기가 달라집니다. 이때부터는 우리 서비스가 합리적으로 인프라를 사용하고 있는지, 그리고 비용의 근거를 어떻게 설명할 수 있는지 고민하게 됩니다. 시스템의 성능 지표를 확인하고 싶어지는 시점, 바로 그때가 TPS 지표를 보기 시작해야 할 순간입니다.

‍

TPS 계산 방법

Transaction Per Second(TPS)는 초당 트랜잭션의 개수입니다. 실제 계산하는 방식은 일정 기간 동안 실행된 트랜잭션의 개수를 구하고 다시 1초 구간에 대한 값으로 변경합니다. 와탭의 경우 5초 구간으로 값을 수집하기 때문에 단위시간 동안 집계된 트랜잭션의 수를 5로 나눈 값이 표시됩니다.

위에 그림에 두 번째 열을 보시면 5개의 트랜잭션이 실행 완료된 것을 볼 수 있습니다. 이런 경우 TPS를 구하는 방법은 5 transaction / 5 sec이므로 결과값은 1 TPS가 됩니다. (와탭의 TPS 지표는 좀 더 복잡하게 계산합니다. 와탭은 차트의 추세를 보여주기 위해 5초 간격으로 30초 평균 TPS를 보여주고 있습니다.)

‍

Saturation Point 와 TPS가 낮은 이유  

서비스에 사용자가 지속적으로 늘어나면 어느 순간부터 TPS가 더 이상 증가하지 않는 상황이 발생합니다. 이렇게 증가하지 않는 지점을 Saturation Point라고 합니다. 위 그림은 서비스가 이상적인 상황입니다. 제대로 튜닝이 되지 않은 서비스는 Saturation Point를 지나면 오히려 TPS가 떨어지기도 합니다. 위 글로 보면 서비스 사용자는 300명이 넘어가면 TPS가 고정되면서 상대적으로 트랜잭션의 응답시간이 길어질 것을 예상할 수 있습니다.

좀 더 스토리를 만들어보면 이렇게 이야기를 할 수 있습니다. 위 그림을 보면 동시 접속 사용자가 300명이 넘어가면 TPS는 더 이상 올라가지 않으므로 서비스의 정체 시간은 증가하기 시작할 것입니다. 300명의 요청사항에 대한 TPS가 50이라면 해당 요청 사항을 다 처리하는데 6초가 걸린다고 생각할 수 있습니다. 이렇게 TPS와 동시 접속자를 미리 선정해봄으로써 서비스의 성능을 상상해 볼 수 있습니다.

‍

TPS 요약  

• TPS는 초당 트랜잭션의 개수를 말합니다
• TPS는 서비스 성능의 기준이 됩니다.
• 평소 TPS 지표를 체크하세요. TPS를 통해 무슨 요일에 또는 몇시에 최대치가 되는지 확인하세요.
• 평소 TPS 지표를 체크하세요. TPS를 통해 무슨 요일에 또는 몇시에 최대치가 되는지 확인하세요.
• TPS가 더 이상 증가하지 않은 지점을 Saturation Point라고 합니다.
• Saturation Point가 넘으면서 사용자가 몰리면 TPS가 고정된 상태에서 응답시간이 길어지게 됩니다.

‍

합리적으로 시스템 성능을 확인하고 싶다면

서비스 트래픽이 증가하고 인프라 비용이 커지는 시점부터는 단순한 서버 증설이 아니라 성능 지표 기반 운영이 필요합니다. TPS 지표를 통해 서비스의 처리량과 성능 한계를 명확히 파악해 보세요.

와탭으로 지금 바로 시작할 수 있습니다.  와탭 도입 문의하기