모니터링
많은 초창기 스타트업들은 성능에 관심이 없습니다. 제품 만들기도 바쁜데 성능이 무슨 의미가 있을까 생각이 들죠. 당장 서비스에 사용자가 몰리면 아마존 오토스케일이 해결해 줄테니까요. 맞습니다. 빠르게 가치를 증명하는 스타트업이라면 서비스 초창기부터 성능에 관심을 가질 필요는 없습니다.
하지만 한달에 아마존 서비스 비용이 천만원이 넘어가기 시작하면 슬슬 우리 서비스가 합리적으로 인프라를 사용하고 있는지 고민하게 됩니다. 인프라 비용의 근거도 만들고 싶어지기 시작하죠. 시스템의 성능 지표를 확인 하고 싶어진다면 지금이 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와 동시접속자를 미리 선정해봄으로써 서비스의 성능을 상상해 볼 수 있습니다.
TPS는 초당 트랜잭션의 갯수를 말합니다.
TPS는 서비스 성능의 기준이 됩니다.
평소 TPS 지표를 체그하세요. TPS를 통해 무슨 요일에 또는 몇시에 최대치가 되는지 확인하세요.
TPS가 더 이상 증가하지 않은 지점을 Saturation Point라고 합니다.
Satuartio Point가 넘으면서 사용자가 몰리면 TPS가 고정된 상태에서 응답시간이 길어지게 됩니다.