많은 초창기 스타트업들은 성능에 관심이 없습니다. 제품 만들기도 바쁜데 성능이 무슨 의미가 있을까 생각이 들죠. 당장 서비스에 사용자가 몰리면 아마존 오토 스케일이 해결해줄 테니까요. 맞습니다. 빠르게 가치를 증명하는 스타트업이라면 서비스 초창기부터 성능에 관심을 가질 필요는 없습니다.
하지만 한 달에 아마존 서비스 비용이 천만 원이 넘어가기 시작하면 슬슬 우리 서비스가 합리적으로 인프라를 사용하고 있는지 고민하게 됩니다. 인프라 비용의 근거도 만들고 싶어지기 시작하죠. 시스템의 성능 지표를 확인하고 싶어진다면 지금이 TPS 지표를 보실 때입니다.
Transaction Per Second(TPS)는 초당 트랜잭션의 개수입니다. 실제 계산하는 방식은 일정 기간 동안 실행된 트랜잭션의 개수를 구하고 다시 1초 구간에 대한 값으로 변경합니다. 와탭의 경우 5초 구간으로 값을 수집하기 때문에 단위시간 동안 집계된 트랜잭션의 수를 5로 나눈 값이 표시됩니다.
위에 그림에 두 번째 열을 보시면 5개의 트랜잭션이 실행 완료된 것을 볼 수 있습니다. 이런 경우 TPS를 구하는 방법은 5 transaction / 5 sec이므로 결과값은 1 TPS가 됩니다. (와탭의 TPS 지표는 좀 더 복잡하게 계산합니다. 와탭은 차트의 추세를 보여주기 위해 5초 간격으로 30초 평균 TPS를 보여주고 있습니다.)
서비스에 사용자가 지속적으로 늘어나면 어느 순간부터 TPS가 더 이상 증가하지 않는 상황이 발생합니다. 이렇게 증가하지 않는 지점을 Saturation Point라고 합니다. 위 그림은 서비스가 이상적인 상황입니다. 제대로 튜닝이 되지 않은 서비스는 Saturation Point를 지나면 오히려 TPS가 떨어지기도 합니다. 위 글로 보면 서비스 사용자는 300명이 넘어가면 TPS가 고정되면서 상대적으로 트랜잭션의 응답시간이 길어질 것을 예상할 수 있습니다.
좀 더 스토리를 만들어보면 이렇게 이야기를 할 수 있습니다. 위 그림을 보면 동시 접속 사용자가 300명이 넘어가면 TPS는 더 이상 올라가지 않으므로 서비스의 정체 시간은 증가하기 시작할 것입니다. 300명의 요청사항에 대한 TPS가 50이라면 해당 요청 사항을 다 처리하는데 6초가 걸린다고 생각할 수 있습니다. 이렇게 TPS와 동시 접속자를 미리 선정해봄으로써 서비스의 성능을 상상해 볼 수 있습니다.