SLI SLO 문서 - 100-hours-a-week/KTB4-17th-wiki GitHub Wiki
목차
1. CUJ 선정
서비스의 핵심 기능 및 서비스에 대한 사용자 여정을 CUJ(Critical User Journey)로 정의하고, 사용자 경험과 서비스의 핵심 가치를 기준으로 주요 사용자 여정을 선정하였다.
1-1. CUJ 1. 온보딩
사용자 여정
1. 온보딩 정보 입력
2. 프로필 생성
3. AI 페르소나 생성
4. 서비스 이용 시작
1-2. CUJ 2. 상대 탐색 및 호감 표현
사용자 여정
1. 추천 상대 조회
2. 상대 상세 프로필 조회
2-a[선택] AI 연습 대화 / 시뮬레이션
3. 상대 판단
4. 좋아요 전송
고려할 점
상대 조회와 AI 기능은 criticality가 다르다.
- 추천 상대 조회가 실패하면 AI 기능을 사용할 수 없다.
- AI 기능이 실패해도 추천 상대 조회와 좋아요 전송은 가능하다.
따라서 동일한 상위 CUJ에 포함하되, 장애 영향과 사용자 경험을 명확히 구분할 수 있도록 SLI는 각각 정의한다.
1-3. CUJ 3. 매칭 성립
사용자 여정
1. 상호 좋아요 성립
2. 매칭 생성
3. 채팅방 생성
1-4. CUJ 4. 실제 대화
사용자 여정
1. 채팅방 목록 조회
2. 채팅방 진입
3. 메시지 전송
4. 상대방 수신
2. SLI 선정
현재 팀 규모와 개발 일정을 고려하여, 초기 SLI는 별도의 RUM·Domain Event·로그 연동 제외, 부하 테스트에서 직접 확인할 수 있는 백엔드 API 지표로 정의한다.
2-1. 공통 계산식
Availability SLI = 성공한 요청 수 / 유효한 전체 요청 수 × 100
Latency SLI = 기준 시간 이내에 성공한 요청 수 / 유효한 전체 요청 수 × 100
2-2. 측정 대상 API
| CUJ | 측정 API | 측정 지표 | 성공 판정 |
|---|---|---|---|
| 온보딩 | PUT /api/v1/users/me/activation | Availability, p95·p99 Latency | 200 및 userStatus=ACTIVE |
| 상대 탐색 | GET /api/v1/recommendation-batches/active | Availability, p95·p99 Latency | 200 및 활성 Batch 또는 명세된 빈 상태 반환 |
| 상대 탐색 | GET /api/v1/recommendation-batches/{batchId}/items | Availability, p95·p99 Latency | 200 및 유효한 추천 목록 반환 |
| 호감 표현·매칭 | POST /api/v1/likes | Availability, p95·p99 Latency | 201 및 likeId와 유효한 상태 반환 |
| AI 연습 대화 | POST /api/v1/ai-practice/sessions/{sessionId}/chats | Availability, p95·p99 Latency | 성공 응답 및 ai_response 반환 |
| AI 시뮬레이션 | 시뮬레이션 생성·스트리밍 API | Availability, 첫 응답 p95·p99, 전체 완료 시간 | 첫 발화 수신 및 is_end=true 정상 종료 |
| 실제 대화 | GET /api/v1/chat-rooms | Availability, p95·p99 Latency | 200 및 유효한 채팅방 목록 반환 |
| 실제 대화 | POST /api/v1/chat-rooms/{chatRoomId}/messages | Availability, p95·p99 Latency | 201 및 messageId 반환 |
측정 시 주의사항
- 좋아요 API는 반대 방향의 좋아요가 존재할 때 매칭 생성까지 수행하므로, 일반 좋아요와 매칭 발생 요청을 나누어 테스트한다.
- AI API는 외부 AI 서비스의 응답시간과 비용 영향을 받으므로 일반 API와 별도의 부하 수준을 적용한다.
- AI 시뮬레이션 생성·스트리밍 API는 현재 명세에서 URL이 비어 있으므로, 엔드포인트 확정 후 테스트에 포함한다.
- 메시지 전송 API의 성공은 서버가 메시지를 접수한 것까지만 의미한다. 상대방의 실제 수신 여부는 현재 측정 범위에서 제외한다.
- 구체적인 시간 기준과 목표 성공률은 첫 기준 부하 테스트 결과를 확인한 뒤 SLO 선정 단계에서 확정한다.
3. SLO 선정
현재는 코드와 운영 환경이 완성되지 않아 실제 측정값이 없기 때문에, 공개된 사용자 반응시간 연구와 SLO 사례를 근거로 SLO 후보를 정의한다.
3-1. Rolling Window
초기 SLO
아직 사용자 반응이나 운영 후 충분한 기간을 확보하지 못하기 때문에 부하 테스트 후 현재 SLI를 기준으로 SLO를 선정한다.
이후 운영 단계
충분한 기간이 지나면 운영 계측이 가능해지면 Google의 SLO 사례를 참고해 최근 30일을 Rolling Window로 사용한다.
3-2. 초기 SLO
| CUJ | 측정 API | Availability | Latency 후보 | 근거 및 남은 판단 |
|---|---|---|---|---|
| 온보딩 | 회원 활성화 | 99.95 | p95 1초 이하 | 사용자 동작 흐름을 유지하는 1초 기준 참고. p95 적용은 기준 테스트 후 검증 필요 |
| 상대 탐색 | 활성 추천 Batch 조회 | 99.95 | p95 1초 이하 | 홈 진입을 막는 요청이므로 1초 기준 |
| 상대 탐색 | 추천 Item 목록 조회 | 99.95 | p95 1초 이하 | 전체 화면은 3초 이내가 참고 상한이며 API에는 1초 예산을 후보로 배정. 네트워크·렌더링 시간 검증 필요 |
| 호감 표현·매칭 | 좋아요 전송 | 99.95 | p95 1초 이하 | 직접 조작에 대한 결과이므로 1초 사용자 반응 기준 참고 |
| AI 연습 대화 | AI 답변 생성 | 99.9 | 첫 응답 p95 4초 미만 | 대화형 AI에서 4초 이상 지연 시 경험 저하 연구 참고. |
| AI 시뮬레이션 | 생성·스트리밍 | 99.9 | p95 9초 미만 | |
| 실제 대화 | 채팅방 목록 조회 | 99.95 | p95 1초 이하 | 대화 진입을 막는 요청이므로 1초 사용자 반응 기준 참고 |
| 실제 대화 | 메시지 전송 접수 | 99.95 | p95 1초 이하 | 메시지 전송 결과는 즉각적인 피드백이 필요한 직접 조작이므로 1초 기준 참고 |
근거 자료
- ACM CUI 2025 — Mitigating Response Delays in LLM-powered Intelligent Virtual Agents: 대화형 AI의 응답 지연이 4초 이상일 때 사용자 경험이 유의미하게 저하됐다고 보고한다.
- Nielsen Norman Group — Response Times: The 3 Important Limits: 약 0.1초는 즉각적인 반응, 1초는 사용자의 사고 흐름이 유지되는 한계, 10초는 주의가 유지되는 대략적인 한계로 설명한다.
- web.dev — RAIL Model: 사용자 동작에 100ms 안에 가시적 반응을 제공하고, 1초를 넘기면 사용자가 작업에 대한 집중을 잃기 시작한다고 설명한다.
- Google Cloud — Concepts in service monitoring: 사용자가 99%와 99.9%의 차이를 체감하지 못한다면 낮은 목표를 사용하라고 권고하며, Availability 목표가 사용자와 비용에 관한 결정임을 설명한다.
- Google SRE Workbook — Implementing SLOs: 최초 SLO는 완벽할 필요가 없지만 측정과 개선 루프가 필요하며, Availability와 Latency 목표는 사용자 만족과 비즈니스 판단을 바탕으로 정해야 한다. Latency는 단일 평균보다 여러 구간을 사용해 긴 꼬리 지연을 함께 보도록 권장한다.
4. Error Budget 정의
설정한 SLO를 기준으로 허용 가능한 서비스 신뢰성 저하 범위를 정의한다.
Error Budget 비율 = 100% - SLO
| 일반 백엔드 API | AI기능 API | |
|---|---|---|
| Avalibity | 0.05% | 0.1% |
| Latency | SLO를 초과한 요청 허용률 5% | SLO를 초과한 요청 허용률 5% |