M5 ‐ SLI SLO 설계 및 문서화 - 100-hours-a-week/KTB4-4th-wiki GitHub Wiki

Need U V1 SLI/SLO 설계

목차

  1. 설계 목적 및 범위
  2. SLI 선정
  3. SLO 및 수치 선정 근거
  4. 운영 지표
  5. 측정 및 검증

1. 설계 목적 및 범위

1.1 목적

Need U V1의 서비스 품질을 사용자 관점에서 측정하고, 이후 부하 테스트를 통해 현재 인프라가 SLO를 만족할 수 있는 트래픽 범위와 병목 지점을 확인하기 위해 SLI/SLO를 정의한다.

Need U는 사용자가 AI와 대화하며 취향을 분석하고, 이를 바탕으로 개인화된 선물을 추천받는 서비스이다.

따라서 단순히 서버가 실행 중인지를 확인하는 것이 아니라 사용자가 선물을 추천받기까지의 주요 기능을 정상적이고 적절한 시간 안에 이용할 수 있는지를 기준으로 서비스 품질을 측정한다.

Google SRE에서도 SLO 설계 시 인프라 지표보다 사용자가 실제로 중요하게 생각하는 Critical User Journey를 중심으로 SLI를 선정하는 방법을 제시한다.

근거

1.2 V1 아키텍처

User
 ↓
Nginx
 ├─ Next.js
 └─ Spring Boot
      ├─ MySQL
      └─ FastAPI
           ├─ PostgreSQL
           ├─ Redis
           └─ External AI

현재 V1의 주요 특징은 다음과 같다.

  • t3.medium Single EC2 / Single AZ
  • Load Balancer 및 Failover 없음
  • Next.js / Spring Boot / FastAPI / Redis는 Docker 기반
  • MySQL은 Spring Boot의 데이터 저장소
  • PostgreSQL은 AI 측 데이터 경로에서 사용
  • AI 기능은 External AI 의존성을 포함

1.3 Critical User Journey

Need U에서 사용자가 선물을 추천받는 주요 흐름은 다음과 같다.

서비스 접속
    ↓
로그인
    ↓
AI 대화
    ↓
취향 분석
    ↓
개인화 추천
    ↓
추천 결과 확인
    ↓
상품 확인

이 과정 중 하나가 실패하거나 지나치게 느려지면 사용자는 Need U의 핵심 목적인 개인화된 선물 추천까지 정상적으로 도달하기 어렵다.

따라서 위 사용자 흐름에서 발생할 수 있는 실패와 지연을 기준으로 SLI를 선정한다.

2. SLI 선정

2.1 서비스 도달 가능성

SLI

정상적으로 서비스에 접근 가능한 측정 구간
────────────────────────────
전체 측정 구간

선정 이유

Need U에서 AI 대화와 선물 추천을 이용하려면 우선 서비스 자체에 정상적으로 접속할 수 있어야 한다.

서비스에 접근하지 못하면 로그인, AI 대화, 추천 결과 확인 등 모든 기능을 시작할 수 없기 때문에 전체 사용자 흐름의 시작 가능 여부를 확인하기 위해 서비스 도달 가능성을 측정한다.

특히 V1은 Single EC2이며 별도의 Failover가 없어 하나의 장애가 서비스 전체 접근 실패로 이어질 수 있으므로 별도로 관리할 필요가 있다.

2.2 페이지 성공률

SLI

정상적으로 처리된 유효 Page Request
────────────────────────────
전체 유효 Page Request

선정 이유

Need U 사용자는 여러 화면을 이동하면서 선물 추천 과정을 진행한다.

특히 AI 대화 화면, 취향 분석 결과, 추천 결과, 상품 확인 화면은 사용자가 실제 추천을 받기 위해 반드시 이용하는 주요 화면이다.

Backend가 정상적으로 동작하더라도 이러한 화면에 진입하지 못하면 사용자는 해당 기능을 이용할 수 없다.

따라서 사용자가 선물 추천 과정에 필요한 주요 화면을 정상적으로 이용할 수 있는지를 확인하기 위해 Page 성공률을 측정한다.

2.3 페이지 응답 지연

SLI

Page Response Time
- p75

선정 이유

Need U에서는 사용자가 AI와 대화를 시작하고, 분석 결과를 확인하고, 최종 추천 결과와 상품을 확인하기까지 여러 화면을 거친다.

이 과정에서 페이지 응답이 반복적으로 느려지면 각 기능 자체는 정상적으로 동작하더라도 사용자가 선물 추천 결과에 도달하기까지의 전체 이용 시간이 길어진다.

특히 추천 결과와 상품을 확인하는 과정은 사용자가 Need U를 이용한 결과를 직접 확인하는 단계이므로 화면 진입이 지나치게 느리면 추천 기능의 사용 경험도 함께 저하된다.

따라서 Page 성공 여부뿐 아니라 사용자가 AI 대화와 추천 결과 등 주요 기능 화면에 적절한 시간 안에 진입할 수 있는지를 확인하기 위해 Page Latency를 측정한다.

단, 현재 Page Latency는 서버의 HTTP 응답시간을 대상으로 하며 브라우저 렌더링 성능은 별도의 측정 범위로 본다.

2.4 Backend API 성공률

SLI

정상적으로 처리된 유효 Backend Request
────────────────────────────────
전체 유효 Backend Request

다음은 서버 측 실패로 판단한다.

5xx
Timeout
Connection Failure

사용자 인증 실패나 잘못된 요청 등 4xx는 서버 장애와 구분하여 별도로 관측한다.

선정 이유

Need U에서는 사용자 정보, 친구 정보, 추천 결과, 상품 정보 등 선물 추천 과정에 필요한 주요 데이터를 Backend API를 통해 처리한다.

특히 AI를 통해 추천이 정상적으로 생성되더라도 추천 결과를 저장하거나 다시 조회하는 Backend 기능이 실패하면 사용자는 최종 추천 결과를 정상적으로 확인할 수 없다.

따라서 단순히 Spring Boot가 실행 중인지 확인하는 것이 아니라, 사용자가 실제로 사용하는 주요 기능이 정상적으로 처리되는지를 확인하기 위해 Backend API 성공률을 측정한다.

2.5 Backend API 응답 지연

SLI

Backend Response Time
- p95
- p99

선정 이유

Need U에서는 로그인 이후 사용자 정보 조회, 추천 정보 조회, 상품 정보 확인 등 여러 Backend 요청이 선물 추천 과정에서 사용된다.

이 요청들이 성공하더라도 응답시간이 길어지면 추천 결과를 불러오거나 상품 정보를 확인하는 과정에서 사용자가 계속 기다려야 한다.

또한 서비스 부하가 증가할 경우 요청 실패가 발생하기 전에 응답시간이 먼저 증가할 수 있으므로, 성공률만으로는 사용자가 이미 느끼고 있는 성능 저하를 확인하기 어렵다.

따라서 Backend API Latency를 통해:

  • 추천 결과와 상품 정보 등 주요 기능이 적절한 시간 안에 제공되는지
  • 부하 증가에 따라 사용자 기능이 느려지기 시작하는 시점이 언제인지

를 확인한다.

평균 응답시간은 일부 느린 요청을 가릴 수 있으므로 p95, p99를 함께 측정한다.

근거

2.6 AI API 성공률

SLI

정상적으로 완료된 유효 AI Request
────────────────────────────
전체 유효 AI Request

선정 이유

AI 대화와 취향 분석은 Need U에서 사용자에게 맞는 선물을 추천하기 위한 핵심 기능이다.

사용자는 AI와 대화를 통해 취향 정보를 제공하고, 분석된 결과를 기반으로 개인화된 추천을 받는다.

AI 대화
    ↓
취향 분석
    ↓
개인화 추천

따라서 AI 요청이 실패하면 단순히 하나의 API가 실패하는 것이 아니라 사용자가 Need U의 핵심 목적인 개인화 추천까지 진행하지 못할 수 있다.

일반적인 사용자·친구·상품 조회 기능과 중요도 및 요청 특성도 다르기 때문에 AI 기능의 성공 여부를 별도의 SLI로 관리한다.

2.7 AI API 응답 지연

SLI

AI Response Time

선정 이유

Need U의 AI 대화는 한 번의 요청으로 끝나는 것이 아니라 사용자와 AI가 여러 차례 대화를 주고받은 뒤 취향 분석과 추천으로 이어진다.

따라서 AI 응답 하나가 느려지면 매 대화마다 사용자의 대기시간이 발생하고, 여러 번 반복될 경우 취향 분석과 최종 추천까지 도달하는 전체 시간이 크게 증가할 수 있다.

사용자 메시지
→ AI 응답 대기
→ 사용자 메시지
→ AI 응답 대기
→ 취향 분석
→ 추천

즉, AI API에서는 요청이 최종적으로 성공했는지만으로는 실제 사용 경험을 충분히 판단하기 어렵다.

따라서 사용자가 AI와 자연스럽게 대화를 이어가고 추천 단계까지 진행할 수 있는지를 확인하기 위해 AI 응답시간을 별도로 측정한다.

AI 요청은 External AI 등 일반 Backend와 다른 의존성을 가지므로 Backend Latency와 분리하여 관리한다.

2.8 SLI 선정 결과

SLI Need U에서 확인하려는 것
서비스 도달 가능성 사용자가 선물 추천 과정을 시작할 수 있는가
페이지 성공률 AI 대화·추천 결과 등 주요 화면을 정상적으로 이용할 수 있는가
페이지 응답 지연 주요 화면에 적절한 시간 안에 진입할 수 있는가
Backend 성공률 추천 결과·사용자·상품 등의 기능이 정상적으로 처리되는가
Backend 응답 지연 추천 결과와 상품 정보 등을 적절한 시간 안에 제공하는가
AI 성공률 AI 대화와 취향 분석을 거쳐 개인화 추천까지 진행할 수 있는가
AI 응답 지연 사용자가 AI와 대화를 이어가는 과정에서 과도하게 기다리지 않는가

3. SLO 및 수치 선정 근거

3.1 초기 SLO

영역 SLI SLO
서비스 도달 가능성 ≥ 99.0%
Page 성공률 ≥ 99.0%
Page 응답 지연 p75 ≤ 800ms
Backend 성공률 ≥ 99.0%
Backend 응답 지연 p95 ≤ 500ms
Backend Tail Latency p99 ≤ 1,000ms
AI 성공률 ≥ 99.0%
AI 응답 지연 Backend와 분리 측정
평가 기간 Rolling Window 28일

SLO 수치는 외부 사례를 그대로 적용하는 것이 아니라 외부 Benchmark를 참고하여 Need U V1의 초기 목표로 설정한다.

3.2 성공률: 99.0%

SLO

서비스 도달 가능성 ≥ 99.0%
Page 성공률        ≥ 99.0%
Backend 성공률     ≥ 99.0%
AI 성공률          ≥ 99.0%

Google SRE Workbook의 HTTP Server SLO 예제에서는 99% Availability를 사용한다.

Need U에서는 사용자가 서비스 접속부터 AI 대화와 추천 결과 확인까지 주요 기능을 안정적으로 이용할 수 있도록 99.0%를 초기 Reliability 목표로 설정한다.

현재 V1은 Single EC2 / Single AZ이며 Load Balancer와 Failover가 없다는 점도 함께 고려하였다.

근거

AWS의 Single EC2 Instance-Level SLA 99.5%는 EC2 자체에 대한 SLA이며 Need U 전체 서비스의 가용성을 의미하지 않는다.

Error Budget

28일 기준 시간 기반 99% SLO의 Error Budget은 다음과 같다.

28일 = 40,320분

40,320 × 1%
= 403.2분
≈ 6시간 43분

요청 기반 성공률은 전체 유효 요청의 1%를 Error Budget으로 본다.

3.3 페이지 응답 지연: p75 ≤ 800ms

web.dev에서는 TTFB(Time to First Byte)에 대해 대부분의 사이트가 0.8초 이하를 목표로 할 것을 제시하며, 75번째 Percentile을 기준으로 평가한다.

Need U에서는 사용자가 AI 대화, 추천 결과, 상품 확인 등 주요 화면으로 이동할 때 지나치게 기다리지 않도록 이를 외부 Benchmark로 참고하여 다음 초기 목표를 설정한다.

p75 ≤ 800ms

근거

단, TTFB와 서버에서 측정하는 전체 HTTP Request Duration은 동일한 지표가 아니므로 800ms는 초기 목표 설정을 위한 외부 참고 기준으로 사용한다.

3.4 Backend 응답 지연: p95 ≤ 500ms

Google Cloud의 Request-based Latency SLO 예제에서는 다음 기준을 사용한다.

98% of Requests < 500ms

근거

Need U에서는 추천 결과 조회, 상품 정보 확인 등 일반 Backend 기능에서 대부분의 요청이 긴 대기 없이 처리되도록 500ms를 외부 Benchmark로 참고한다.

초기 V1 목표는 다음과 같이 설정한다.

p95 ≤ 500ms

Google Cloud 사례는 정확히 98% < 500ms이므로 p95 ≤ 500ms가 Google에서 제시한 표준이라는 의미는 아니다.

3.5 Backend Tail Latency: p99 ≤ 1,000ms

Google SRE Workbook의 HTTP Server SLO 예제에서는 다음과 같은 Latency 목표를 사용한다.

90% of Requests < 200ms
99% of Requests < 1,000ms

근거

Need U에서는 일부 사용자에게 추천 결과나 상품 정보 조회가 지나치게 늦어지는 경우까지 확인하기 위해 99% < 1,000ms를 Tail Latency 기준으로 참고한다.

p95 ≤ 500ms
→ 대부분의 Backend 요청 관리

p99 ≤ 1,000ms
→ 일부 느린 요청 관리

3.6 평가 기간: 28일 Rolling Window

SLO 평가 기간은 최근 28일(4주) Rolling Window로 설정한다.

Google SRE에서는 Rolling Window에서 정수 주 단위의 기간을 사용하면 각 평가 구간에 동일한 수의 주말이 포함되는 장점이 있다고 설명한다.

Need U에서도 최근 서비스 품질을 지속적으로 반영하면서 요일 구성을 일정하게 유지하기 위해 28일을 사용한다.

근거

3.7 AI SLO

AI API의 초기 성공률 목표는 다음과 같다.

AI Success Rate ≥ 99%

AI 대화와 취향 분석이 실패하면 개인화 추천까지 진행하기 어렵기 때문에 일반 Backend와 별도로 성공률을 관리한다.

반면 AI 응답시간에는 일반 Backend의 다음 기준을 그대로 적용하지 않는다.

p95 ≤ 500ms
p99 ≤ 1,000ms

AI는 여러 번의 대화와 External AI 호출을 포함하여 일반적인 Backend API와 응답 특성이 다르기 때문이다.

따라서 AI Latency는 Backend와 분리하여 측정한다.

4. 운영 지표

CPU, Memory, DB Connection 등은 사용자가 직접 경험하는 서비스 수준이 아니므로 SLO가 아니라 SLO 위반 원인을 분석하기 위한 운영 지표로 사용한다.

4.1 현재 V1 Baseline

구분 지표 측정값
EC2 CPU 사용률 약 9.7%
EC2 Available Memory 약 1.0 GiB
EC2 Swap 0
Backend Memory 약 1.10 GiB
Frontend Memory 약 124.5 MiB
AI Memory 약 60 MiB
Redis Memory 약 3.7 MiB
MySQL Connections 11 / 151
MySQL Running Threads 2
PostgreSQL Server Connections 9 / 100
PostgreSQL Lock Wait 0
PostgreSQL Buffer Cache Hit Ratio 약 99.95%

위 값은 특정 시점에서 확인한 Snapshot이며 장기간 평균값을 의미하지 않는다.

4.2 주요 운영 지표

구분 관측 지표 용도
EC2 CPU, Memory, Load Average 서버 전체 자원 포화 여부 확인
Spring Boot CPU, Memory, JVM Heap, GC, Thread Backend 성능 저하 원인 확인
MySQL Connection, Running Thread, Query Latency, Lock 일반 Backend DB 병목 확인
FastAPI CPU, Memory, Request 상태 AI 서버 병목 확인
PostgreSQL Connection, Query Latency, Lock AI 측 DB 병목 확인
Redis Memory, Client, Eviction, Command Latency AI 측 Redis 상태 확인

MySQL은 Spring Boot 일반 Backend의 데이터 저장소이므로 Backend SLI와 함께 확인한다.

PostgreSQL과 Redis는 AI 측 데이터 경로에서 사용되므로 해당 의존성을 사용하는 AI 기능의 SLI가 악화될 때 원인 분석에 활용한다.

5. 측정 및 검증

5.1 최종 SLO

SLI SLO 근거
서비스 도달 가능성 ≥ 99.0% Google SRE Availability 사례 + V1 구조
페이지 성공률 ≥ 99.0% Need U 주요 화면의 안정적인 이용
페이지 응답 지연 p75 ≤ 800ms web.dev TTFB 기준 참고
Backend 성공률 ≥ 99.0% 추천·상품 등 주요 기능의 안정적인 처리
Backend 응답 지연 p95 ≤ 500ms Google Cloud 500ms 사례 참고
Backend Tail Latency p99 ≤ 1,000ms Google SRE HTTP Server 사례
AI 성공률 ≥ 99.0% AI 대화·취향 분석·추천 흐름 유지
AI 응답 지연 Backend와 분리 측정 AI 대화 특성 및 External AI 의존성
평가 기간 28일 Rolling Google SRE Rolling Window 참고

5.2 부하 테스트 검증

부하 테스트에서는 SLO를 새로 정하는 것이 아니라 현재 V1이 설정한 SLO를 어느 수준의 트래픽까지 만족할 수 있는지 확인한다.

k6에서는 다음을 측정한다.

Traffic
- RPS
- VU

Backend
- Success Rate
- p50
- p95
- p99

동시에 다음 운영 지표를 확인한다.

EC2
- CPU
- Memory

Spring Boot
- CPU
- Memory
- JVM / GC

MySQL
- Connection
- Query
- Lock

Backend에서는 다음 중 하나가 발생하면 SLO 위반으로 판단한다.

Success Rate < 99%

또는

p95 > 500ms

또는

p99 > 1,000ms

부하를 단계적으로 증가시키면서 SLO가 처음 위반되는 RPS와 같은 시점의 운영 지표를 비교하여 병목을 확인한다.

이를 통해 다음을 확인한다.

  • V1이 SLO를 만족할 수 있는 트래픽 범위
  • SLO가 처음 깨지는 지점
  • 해당 시점의 주요 병목
  • V2 확장 설계에 사용할 Capacity 근거

참고 자료