V1의 주요 기능이 정상적으로 동작하는지 같은 기준으로 판단하기 위해 SLI/SLO를 구성했습니다. 운영 로그와 부하 테스트 결과를 이 기준에 맞춰 확인하고, 측정 결과가 쌓이면 목표값을 조정합니다.

현재 목표값은 운영 데이터가 충분히 쌓이기 전에 정한 초기 기준입니다.

다음 데이터가 CloudWatch에 수집됩니다.

flowchart LR
  subgraph APP["App EC2"]
    NG["Nginx<br/>Access, Error Log"] --> AG["CloudWatch Agent"]
    HOST["메모리, 디스크, 프로세스"] --> AG
    BE["Backend 컨테이너<br/>stdout JSON"]
  end
  subgraph WK["Worker EC2"]
    AI["AI 컨테이너<br/>stdout JSON"]
  end
  AWS["EC2 기본 지표<br/>CPU, 네트워크, 상태 검사"]
 
  AG -- "로그" --> CWL[("CloudWatch Logs")]
  AG -- "지표" --> CWM[("CloudWatch Metrics")]
  BE -- "awslogs 드라이버" --> CWL
  AI -- "awslogs 드라이버" --> CWL
  AWS --> CWM
 
  CWL --> Q["Logs Insights<br/>request_id, trip_id, job_id"]
  CWL --> D["Dashboard<br/>yeodam-v1-operations"]
  CWM --> D

Dashboard yeodam-v1-operations에서 요청 현황, Backend와 AI의 결과와 지연시간, 최근 실패와 Host 상태를 한 화면에서 봅니다.

개별 요청이나 작업의 원인은 Logs Insights에서 request_id, trip_id, job_id로 검색합니다.

started 로그는 작업 시작을 추적하는 보조 이벤트입니다. 성공률에는 success, failure처럼 결과가 확정된 종료 이벤트만 사용합니다.

Backend의 auth_login 이벤트로 서버 처리 결과와 시간을 측정합니다. 브라우저 Redirect와 화면 진입까지 포함한 전체 흐름은 FE E2E 테스트로 확인합니다.

원본 사진 유실은 허용 실패율과 관계없이 바로 확인해야 하는 데이터 무결성 문제로 봅니다.

FE는 사진을 최대 10장 단위로 나눠 보냅니다. BE는 중간 Batch에서는 사진을 저장한 뒤 바로 응답하고, 마지막 Batch에서는 전체 저장을 확인한 뒤 AI 분석과 결과 저장까지 끝내고 응답합니다.

sequenceDiagram
  participant FE
  participant BE as Backend
  participant S3
  participant AI as AI Worker

  loop 중간 Batch (최대 10장씩)
    FE->>BE: 사진 업로드
    BE->>S3: 원본 저장
    BE-->>FE: 204
  end
  FE->>BE: 마지막 Batch
  BE->>S3: 원본 저장, 전체 수 확인
  BE->>AI: 분석 요청
  AI-->>BE: 분석 결과
  BE-->>FE: 200

그래서 사진 업로드 시간과 AI 처리 시간은 나눠서 측정합니다.

Worker EC2 시작과 컨테이너 준비 시간도 사용자가 기다리는 AI 처리 시간에 포함합니다. 단계별 병목은 ai_pipeline_step으로 따로 봅니다.

성공률만 보지 않고 전체 건수를 같이 봅니다. V1처럼 요청이 적을 때는 한두 건의 실패가 비율을 크게 바꾸기 때문입니다.

Nginx와 애플리케이션 로그의 시간은 재는 구간이 다릅니다.

Client ── Request Body 전송 ──▶ Nginx ──▶ Backend ──▶ (MySQL, S3, AI) ──▶ 응답

|◀─────────────────────── request_time ───────────────────────▶|
                                 |◀──── upstream_response_time ────▶|
                                           |◀─ duration_ms ─▶|

업로드가 느릴 때 request_time만 길면 Client 네트워크나 파일 전송부터 확인합니다.

upstream_response_time과 Backend duration_ms도 같이 길면 App, MySQL, S3 처리 구간을 확인합니다.

아래 항목은 SLO 계산에 들어가지 않고, 실패 원인과 자원 한계를 찾을 때 씁니다.

요청이 적으면 비율만 보지 않고 실패 건수와 주간 추세를 같이 봅니다.

⚠️ 원본 사진 유실, 복구할 수 없는 데이터 불일치, 보안 문제는 Error Budget으로 허용하지 않습니다.

flowchart LR
  B["Baseline<br/>기능, 측정 경로 확인"] --> P["Peak<br/>예상 최대 부하"]
  P --> S["Spike<br/>급증 후 회복"]
  S --> A["AI 처리량<br/>처리 경계 확인"]

테스트마다 시작과 종료 시각, 동시 사용자 수, 사진 수와 크기, Cloud Commit, FE/BE/AI Release를 기록해서 같은 조건끼리 비교합니다.

실제 사용자나 팀원의 디버깅과 겹칠 수 있으면 별도 Runtime과 Test Data를 씁니다. Subdomain만 나눠서는 부하가 분리되지 않습니다.

실행 결과는 부하 테스트에 있습니다.