채점 서비스의 성능 측정에 대한 고민.

<aside> 🤔 채점 서비스의 성능을 어떤 방식으로 측정해야 정확하고 객관적일 수 있을까?

</aside>

채점 서비스 구조에 대한 고민의 시작은 안정적이고 빠른 채점을 위해서였습니다.

빠른 채점에 대한 기준을 사용자 입장에서 생각해봤을 때, 사용자가 코드를 제출하고 해당 제출에 대해 사용자에게 다시 채점 결과가 보이기까지의 시간이 곧 ‘채점까지 걸리는 시간’이라고 생각했습니다.

저희가 정의한 채점까지 걸리는 시간에 대해 최대한 가깝고 정확하게 측정할 수 있는 방법은 무엇일지 고민했고,

채점까지 걸리는 시간 = 채점 요청이 DB에 기록되고, 채점 결과가 DB에 기록되기까지의 시간 으로 측정하면 되겠다고 판단하였고 pgAdmin4의 graph visualizer로 시각화하였습니다.

성능 측정 방식 : 20개의 요청을 한 번에 보냈을 때, 채점까지 걸리는 평균 시간과 채점하는데 걸린 총 시간

(채점 시간 측정은 문제의 코드 길이, 테스트 케이스 개수 등에 영향을 받기 때문에 모든 측정에서 동일한 서버 사양, 문제와 테스트 케이스, 코드를 사용했습니다.)

첫 번째 고민.

<aside> 🤔 물리적으로 분리된 서버 간의 통신을 어떻게 진행할까?

</aside>

저희 서비스는 DB 서버, API 서버, 채점 서버 총 3개의 서버가 물리적으로 분리되어있기 때문에 채점을 진행하기 위해서는 API 서버와 채점 서버 의 통신이 이루어져야 했습니다.

이렇게 물리적으로 분리된 서버 간에 어떤 방식으로 통신을 진행할까 고민하다가 가장 먼저 생각해낸 방법은 제일 일반적인 API 통신 이었습니다.

Untitled