400 TPS인 줄 알았는데 40이었습니다

[성능 개선 이야기] 400 TPS인 줄 알았는데 40이었습니다 — 씽크 타임 이야기

안녕하세요, 가야태자 @talkit 입니다.

성능 테스트를 이야기할 때 대개 어떻게 부하를 거는지부터 이야기합니다. 그런데 그보다 먼저 정해야 하는 게 있습니다.

목표를 얼마로 잡을 것인가.

오늘은 어느 공공기관 업무 시스템 성능 테스트에서, 목표를 400 TPS로 잡을 뻔했다가 40 TPS로 내린 이야기를 해보려고 합니다.

10분의 1입니다. 그리고 이게 실수를 줄인 게 아니라, 오히려 제대로 된 진단을 가능하게 했습니다.

---

처음엔 400 TPS인 줄 알았습니다

목표 TPS를 정하는 방법은 간단해 보입니다. 동시 사용자가 몇 명인지 알면 되니까요.

동시 사용자가 400명이고 응답 시간이 1초라면, 400명이 1초에 한 번씩 요청을 던지니까 초당 400건. 이렇게 계산했습니다.

그런데 이 계산에는 빠진 게 있었습니다.

---

사람은 그렇게 안 씁니다

씽크 타임(Think Time) 이라는 걸 이때 처음 알았습니다.

실제 사용자는 요청을 던지고 응답을 받은 다음, 바로 다음 요청을 던지지 않습니다.

• 화면에 뜬 목록을 읽고
• 어떤 걸 클릭할지 판단하고
• 입력할 게 있으면 입력하고
• 그러다 전화도 받고 ^^;;

이 시간이 씽크 타임입니다. 사용자가 "생각하는" 시간이죠.

성능 테스트에서 이걸 넣지 않으면, 가상 사용자가 응답을 받자마자 즉시 다음 요청을 던지는 상태가 됩니다. 사람이 아니라 기계죠.

---

계산해 보면 이렇게 됩니다

동시 사용자 수와 TPS는 이런 관계입니다.

동시 사용자 수 = TPS × (응답 시간 + 씽크 타임)

이걸 TPS 기준으로 바꾸면,

TPS = 동시 사용자 수 ÷ (응답 시간 + 씽크 타임)

숫자를 넣어 보겠습니다. 동시 사용자 400명, 응답 시간 1초 기준입니다.

씽크 타임을 0으로 두면

400 ÷ (1 + 0) = 400 TPS

씽크 타임을 9초로 두면

400 ÷ (1 + 9) = 40 TPS

정확히 10분의 1이 됩니다.

그리고 업무 시스템에서 화면 하나 보고 다음 동작까지 10초 정도 걸리는 건 전혀 이상한 일이 아닙니다. 오히려 짧은 편이죠.

이 계산을 하고 나서 목표를 40 TPS로 잡았습니다.

---

만약 400으로 갔다면

목표를 잘못 잡으면 두 가지가 나빠집니다. 그리고 두 번째가 훨씬 무섭습니다.

① 필요 없는 돈을 씁니다

400 TPS를 못 맞추면 어떻게 될까요? 튜닝을 하고, 그래도 안 되면 장비를 늘립니다.

실제로는 40이면 충분한 시스템에 열 배의 용량을 맞추려고 서버를 사는 겁니다. 그리고 그렇게 늘린 장비는 영원히 놀게 됩니다.

성능 목표는 그냥 숫자가 아닙니다. 예산 결정입니다.

② 진단이 안 됩니다

이게 더 중요합니다.

과도한 부하를 걸면 모든 게 다 느려집니다. 그러면 화면도 느리고, 조회도 느리고, 등록도 느립니다.

전부 느리면 어디가 진짜 문제인지 알 수가 없습니다.

성능 테스트의 목적은 "느린가 안 느린가"를 확인하는 게 아니라 "어디가 먼저 무너지는가"를 찾는 것입니다. 그런데 감당 못 할 부하를 걸면 전부 무너지고, 그 안에서 순서를 가릴 수가 없습니다.

적정한 목표를 잡아야 진짜 병목이 드러납니다.

---

그래서 이렇게 테스트했습니다

목표를 40 TPS로 잡고, 이렇게 진행했습니다.

① 개발한 모든 프로그램을 녹화했습니다

JMeter의 HTTP(S) Test Script Recorder를 써서 대상 메뉴 전체를 녹화했습니다. 시나리오를 손으로 하나하나 만들면 시간도 오래 걸리고 실제 요청과 달라지기 쉽습니다.

② 부하를 단계적으로 올렸습니다

한 번에 40으로 가지 않고 이렇게 올렸습니다.

1 TPS → 10 TPS → 20 TPS → 40 TPS

이유는 어디서 꺾이는지 보기 위해서입니다. 처음부터 목표 부하를 걸면 통과인지 실패인지만 알 수 있는데, 단계를 올리면 어느 지점부터 무너지기 시작하는지가 보입니다.

20 TPS까지는 전 구간이 3초 이내로 잘 나왔습니다.

---

그런데 40에서만 드러나는 게 있었습니다

동시 접속이 40에 도달하기 전에는 멀쩡하던 것이 있었습니다.

부하가 낮을 때는 아무 문제가 없다가, 목표 부하에 닿으니 그제야 문제를 드러낸 부분이었죠.

이걸 찾아서 수정하고 반영했습니다.

여기서 다시 한번 느낀 게 있습니다. 목표를 40으로 제대로 잡았기 때문에 40에서 터지는 문제를 찾을 수 있었습니다.

만약 400을 목표로 잡았다면 어땠을까요? 아마 400이라는 부하를 만드는 것부터 고생했을 테고, 만들었다 해도 모든 게 다 느려져서 이 문제 하나를 골라내지 못했을 겁니다.

이 부분은 이야기가 길어져서 다음 글에서 따로 다루겠습니다. 전체 요청의 99%가 기준을 만족했는데도 문제가 있었던 이야기입니다.

---

씽크 타임은 어떻게 정하나

그럼 씽크 타임을 몇 초로 잡아야 할까요? 임의로 정하면 안 됩니다.

너무 짧게 잡으면 목표가 과대 산정되고, 너무 길게 잡으면 과소 산정되어 실제 피크를 못 견디는 시스템이 됩니다. 이건 더 위험하죠.

실제로 쓸 수 있는 방법은 이 정도입니다.

• 기존 시스템의 접속 로그에서 요청 간격을 뽑아 보기 — 가장 정확합니다
• 현업 담당자께 여쭤보기 — "이 화면 보시고 다음 버튼 누르실 때까지 보통 얼마나 걸리세요?"
• 업무 성격으로 가늠하기 — 조회하고 판단하는 업무는 길고, 반복 입력 업무는 짧습니다

그리고 JMeter에서는 Timer로 넣습니다. 이때 상수 타이머보다 랜덤 타이머를 권합니다. 실제 사용자들이 모두 똑같이 9초씩 기다리지는 않으니까요. 어떤 사람은 3초, 어떤 사람은 20초입니다.

---

마무리

성능 테스트를 처음 할 때는 어떻게 부하를 거는지에 집중하게 됩니다. 도구를 익히는 게 급하니까요.

그런데 몇 번 해보고 나니, 얼마를 목표로 잡을 것인가가 더 어렵고 더 중요한 문제였습니다.

목표를 잘못 잡으면 없어도 될 장비를 사게 되고, 무엇보다 찾아야 할 병목을 못 찾습니다.

씽크 타임은 그 목표를 현실에 맞추는 장치입니다. 사람이 기계가 아니라는 걸 계산에 넣는 일이죠 ^^

즐거운 하루 되십시오.

---

Tags 성능테스트, JMeter, 씽크타임, ThinkTime, TPS, 동시사용자, 부하테스트, 성능개선, 가야태자, talkit