004 사용자 상황과 행동 기반 RPS 가정 - 100-hours-a-week/KTB4-3rd-CLOUD GitHub Wiki
이 문서는 사용자가 어떤 상황에서 모여타를 이용하고, 서비스 안에서 어떤 행동을 수행하는지 정의하는 것을 목적으로 한다. 사용자 행동을 기반으로 다음 내용을 결정한다.
- 핵심 사용자 플로우
- 기능별 읽기·쓰기 요청
- 실시간 통신이 필요한 구간
- 사용자 행동 기반 트래픽
- 초기 RPS 산출 기준
사용자 상황
상황 1. 출퇴근·통학 중 교통 장애
사용자는 평소 이용하던 대중교통이 다음과 같은 이유로 불편해졌을 때 모여타를 이용한다고 가정한다.
- 출퇴근 시간대 혼잡
- 폭우·폭설 등 기상 악화
- 지하철 또는 버스 파업
- 교통사고 및 도로 정체
- 행사로 인한 일시적인 교통량 증가
- 환승 지연 또는 운행 중단
사용자는 지도나 교통 앱으로 현재 상황을 확인한 뒤, 같은 방향으로 이동하는 사람을 찾아 대체 이동수단을 확보하려고 한다.
상황 2. 심야·교대 근무 후 이동
사용자는 늦은 시간에 대중교통 이용이 어렵거나 중단되었을 때 모여타를 이용한다고 가정한다.
- 심야 대중교통 운행 종료
- 교대 근무 후 귀가
- 늦은 시간의 행사·모임 종료
- 혼자 택시를 이용하기에는 비용 부담이 큰 상황
이 경우 사용자는 비용을 줄이면서도 출발지와 목적지가 유사한 동승자를 찾는 것을 중요하게 생각한다.
핵심 사용자 플로우
예외 플로우
| 상황 | 사용자 대응 | 서비스 처리 |
|---|---|---|
| 로그인 실패 | 다시 로그인 시도 | 오류 메시지 및 재시도 제공 |
| 위치 권한 거부 | 지역 직접 입력 | 수동 지역 검색 제공 |
| 주변 팟 없음 | 검색 범위나 시간 조건 완화 | 조건 변경 및 재검색 제공 |
| 참여 요청 거절·만료 | 다른 팟 탐색 | 유사 팟 추천 또는 재검색 |
| 팟 좌석 마감 | 다른 팟 선택 | 좌석 마감 상태 표시 |
| 팟 삭제·권한 없음 | 목록으로 돌아감 | 안내 메시지 및 최신 정보 재조회 |
| 채팅 연결 끊김 | 재접속 | 메시지 이력 및 최신 팟 상태 복구 |
| 이동 중 문제 발생 | 신고 또는 문의 | 신고 접수 및 기록 저장 |
사용자 행동 분류
| 사용자 행동 | 요청 유형 | 데이터 특성 |
|---|---|---|
| 지도 이동·확대·축소 | 조회 | 읽기 중심 |
| 주변 팟 조회 | 조회 | 읽기 중심, 빈번한 요청 |
| 팟 상세 확인 | 조회 | 읽기 중심 |
| 커뮤니티 정보 확인 | 조회 | 읽기 중심 |
| 팟 생성 | 쓰기 | 데이터 정합성 필요 |
| 참여 요청 | 쓰기 | 좌석 수 동시성 제어 필요 |
| 참여 승인·거절 | 쓰기 | 참여 상태 정합성 필요 |
| 참여 취소 | 쓰기 | 좌석 복원 및 상태 변경 필요 |
| 팟 확정 | 쓰기 | 참여자 목록 고정 필요 |
| 채팅 메시지 전송 | 실시간 | WebSocket 및 메시지 저장 필요 |
| 채팅방 재접속 | 실시간·조회 | 이전 메시지와 최신 상태 필요 |
| 탑승·이동 상태 변경 | 쓰기 | 상태 변경 이력 필요 |
| 정산 | 쓰기 | 참여자·금액 정합성 필요 |
| 평가·신고 | 쓰기 | 이용 완료 후 기록 보존 필요 |
핵심 사용자 행동별 시스템 요구사항
팟 조회
사용자는 자신의 위치와 목적지에 가까운 팟을 확인한다. 팟 목록에는 다음 정보가 필요하다.
- 출발지
- 목적지
- 출발 예정 시간
- 현재 참여자 수
- 남은 좌석 수
- 예상 비용
- 팟 생성 시간
- 팟 상태
- 모집자 정보
팟 참여
사용자는 팟의 상세 정보를 확인한 후 참여를 요청한다. 참여 처리에서는 다음 문제가 발생하지 않아야 한다.
- 좌석 수보다 많은 인원이 승인되는 문제
- 동시에 참여 요청한 사용자의 상태 불일치
- 참여 승인 이후 팟 정보가 사라지는 문제
- 취소한 좌석이 복구되지 않는 문제
채팅
매칭된 사용자는 팟별 채팅방에서 다음을 조율한다.
- 만남 장소
- 출발 시간
- 택시 탑승 위치
- 탑승자 도착 여부
- 이동 중 변경 사항
채팅은 일시적인 실시간 전송뿐 아니라, 재접속 후 이전 메시지를 확인할 수 있어야 한다.
정산
이동이 완료된 후 참여자와 금액을 기준으로 정산한다. 정산 정보는 다음 조건을 만족해야 한다.
- 실제 팟 참여자와 정산 대상자가 일치해야 한다.
- 참여자별 금액을 확인할 수 있어야 한다.
- 정산 완료 여부가 저장되어야 한다.
- 새로고침이나 재접속 이후에도 정산 상태가 유지되어야 한다.
사용자 행동 기반 트래픽 분류
서비스 트래픽은 다음 세 가지로 구분한다.
정보 조회 트래픽
- 홈 화면 진입
- 지도 및 주변 팟 조회
- 팟 상세 확인
- 커뮤니티 정보 조회
특징:
- 읽기 요청 비중이 높음
- 반복 요청이 많음
- 위치와 시간대에 따라 특정 구간에 집중될 수 있음
거래성 쓰기 트래픽
- 팟 생성
- 참여 요청
- 참여 승인·거절
- 참여 취소
- 팟 확정
- 탑승·이동 상태 변경
- 정산
- 평가·신고
특징:
- 요청량은 조회보다 적음
- 데이터 정합성과 멱등성이 중요함
- 실패 시 사용자 경험과 실제 매칭 결과에 직접적인 영향을 줌
실시간 채팅 트래픽
- WebSocket 연결
- 메시지 전송
- 메시지 수신
- 재접속
- 이전 메시지 조회
WebSocket은 HTTP 요청 수인 RPS만으로 용량을 산정할 수 없다. 다음 값을 별도로 확인해야 한다.
- 동시 연결 수
- 사용자당 메시지 수
- 초당 메시지 수
- 재접속 빈도
- 메시지 저장량
- 연결이 유지되는 시간
초기 RPS 산출 가정
현재 초기 DAU는 약 1,500명으로 가정한다.
커뮤니티·정보 조회 트래픽
가정:
- DAU: 1,500명
- 사용자 1명당 하루 커뮤니티 이용: 4회
- 이용 1회당 API 요청: 3회
- 집중 이용 시간: 하루 4시간
- 집중 시간: 14,400초
일일 요청 수
= 1,500명 × 4회 × 3건
= 18,000건/일
피크 RPS
= 18,000건 ÷ 14,400초
= 1.25 RPS
24시간 전체 평균 RPS는 다음과 같다.
평균 RPS
= 18,000건 ÷ 86,400초
≈ 0.21 RPS
매칭·정산 트래픽
가정:
- DAU: 1,500명
- 매칭 기능을 이용하는 사용자 비율: 30%
- 해당 사용자의 매칭·정산 흐름: 주 3회
- 하나의 흐름에서 발생하는 쓰기 API 요청: 6건
- 집중 시간: 하루 4시간
일일 매칭 흐름 수
= 1,500명 × 30% × (3회 ÷ 7일)
≈ 643회/일
일일 쓰기 요청 수
= 643회 × 6건
≈ 3,858건/일
피크 RPS
= 3,858건 ÷ 14,400초
≈ 0.27 RPS
다만 실제 요청 수는 API를 어떻게 설계하느냐에 따라 달라진다. 예를 들어 참여 요청과 좌석 확인을 하나의 API로 처리하는지, 여러 API로 분리하는지에 따라 결과가 달라진다. 따라서 현재 값은 초기 추정치이며, 실제 핵심 유저 플로우를 기준으로 엔드포인트별 요청 수를 다시 계산해야 한다.
초기 HTTP 트래픽 요약
| 구분 | 예상 피크 RPS |
|---|---|
| 커뮤니티·정보 조회 | 약 1.25 RPS |
| 매칭·정산 쓰기 | 약 0.27 RPS |
| 합계 | 약 1.52 RPS |
이 값은 HTTP 요청 기준이며, WebSocket 연결 수와 메시지량은 별도로 산정한다.