모니터링을 통해 응답 시간이 가장 오래 걸리는 기준으로 2개의 핵심 기능을 선정하였습니다.
/api/v1/meeting/${UUID}/schedules
약속 현황 화면을 렌더링하기 위한 모든 참여자의 일정을 호출하는 API입니다.
다른 참여자들의 일정 확인, 필터링, 등록 등등 추가적으로 사용할 수 있는 기능이 많고 메인 페이지에 해당합니다. 가장 자주 호출되고, 중요한 API 입니다.
/api/v1/meeting/${UUID}/recommend-schedules?type=${TYPE}&attendees=${ATTENDEES}
약속 추천 화면을 위해 호출하는 추천 API 입니다.
핵심 기능임과 동시에 서버에서 많은 연산을 수행해야 하기 때문에 평균 응답 시간이 가장 깁니다. 다뤄야 하는 데이터가 많거나 동시 접속자가 많을 경우 병목 현상이 우려되는 API 입니다.
서비스 특성을 고려하여 TPS와 응답 시간을 측정할 2개의 Mock Data를 생성하였습니다.
서비스 특성상 한 약속에 포함된 사용자들끼리만 데이터를 공유하게 됩니다. 목표 TPS를 측정하기 위해서는 예측 불가능한 변인들을 최대한 통제할 필요가 있다고 판단했습니다. 그래서 공유 데이터 수가 다른 여러 약속에서 동시 다발적으로 요청을 하기 보다는 하나의 약속을 기준으로 두고 TPS를 측정하는 방식으로 진행했습니다. 이 과정에서 서비스 실사용자의 경험과 데이터를 기반으로 가장 흔하게 생성될 수 있는 약속 케이스 및 최악의 케이스를 분석하였습니다.
<aside> 💡
Case 1. 스터디 - https://momonow.kr/meeting/kMB1uAfA
참가자 4명 * 7일 * 12개의 시간 슬롯(30분 단위) = 336 개의 스케줄
Case 2. 최악 - https://momonow.kr/meeting/UyXZ43r6
참가자 20명 * 15일 * 48개의 시간 슬롯(30분 단위) = 14,400 개의 스케줄
</aside>
간편하고 빠르게 일정을 취합, 추천받을 수 있는 슬로건을 가진 서비스 특성상, API 요청 후 1.5초 이상 응답 지연을 겪게되면 사용자가 이탈할 가능성이 있다고 판단하였습니다.