[Playback Gate #1] 프로젝트 소개와 학습 목표

[Playback Gate #1] 프로젝트 소개와 학습 목표

1. 시작하며

백엔드 개발을 하다 보면 Redis, Connection Pool, Lock, p99, 부하 테스트 같은 용어를 자주 접하게 된다.

각 기술의 개념 자체를 이해하는 것은 어렵지 않지만, 실제로는 다음과 같은 부분이 더 중요하다고 생각했다.

• 언제 이런 기술이 필요한가?
• 어떤 문제가 발생했을 때 적용해야 하는가?
• 적용하기 전과 후에 실제로 성능 차이가 있는가?
• 서버가 느려졌을 때 원인을 어떻게 찾아야 하는가?

단순히 여러 기술을 한 프로젝트에 적용해보는 것보다는, 성능 문제가 발생할 수 있는 작은 서비스를 직접 만들고 문제를 재현한 뒤 하나씩 개선해보는 방식이 더 도움이 될 것 같았다.

그래서 시작하게 된 프로젝트가 Playback Gate다.

---

2. Playback Gate란?

Playback Gate는 OTT 서비스에서 사용자가 콘텐츠의 재생 버튼을 눌렀을 때 재생 가능 여부를 판단하는 백엔드 서비스다.

실제 영상을 전송하거나 스트리밍하는 서버를 구현하는 것이 목적은 아니다.

사용자가 재생을 요청하면 서버에서는 대략 다음과 같은 과정을 거친다고 가정한다.

사용자 재생 요청
        ↓
회원 상태 확인
        ↓
이용권 확인
        ↓
콘텐츠 상태 확인
        ↓
이용권 등급 확인
        ↓
연령 제한 확인
        ↓
동시 재생 제한 확인
        ↓
재생 허용
        ↓
Playback Session 생성
        ↓
Playback Token 발급

예를 들어 특정 이용권에서 동시에 한 개의 기기만 재생할 수 있다면, 현재 해당 사용자가 다른 기기에서 콘텐츠를 재생하고 있는지도 확인해야 한다.

기능만 놓고 보면 복잡한 서비스는 아니다.

하지만 바로 이 점 때문에 백엔드 성능과 동시성 문제를 실험하기 좋은 소재라고 생각했다.

---

3. 이 프로젝트에서 중요한 것

Playback Gate의 목표는 OTT 서비스를 완성하는 것이 아니다.

핵심은 다음 과정이다.

기본 기능 구현
      ↓
성능 측정
      ↓
문제 재현
      ↓
병목 분석
      ↓
개선
      ↓
다시 측정

처음부터 Redis나 각종 최적화 기법을 적용하지 않을 예정이다.

우선 최대한 단순한 Spring Boot + MySQL 구조로 서비스를 구현하고, 실제로 부하를 발생시켜 어떤 문제가 발생하는지 확인한다.

그 후 문제가 확인될 때마다 필요한 기술을 도입한다.

예를 들어 DB 조회가 병목이라면 쿼리와 인덱스를 확인하고, 반복적으로 조회되는 데이터 때문에 DB 부하가 크다면 Redis Cache를 고려한다.

동시에 여러 재생 요청이 들어오면서 동시 재생 제한이 깨진다면 Lock이나 Atomic 연산과 같은 동시성 제어 방식을 비교해본다.

즉, 기술을 먼저 정하고 사용하는 것이 아니라 문제가 생기면 그 문제를 해결하기 위해 기술을 사용하는 방식으로 진행할 예정이다.

---

4. 학습 목표

4.1 대규모 트래픽 처리 이해

사용자가 적을 때 정상적으로 동작하는 API가 사용자가 많아졌을 때도 동일하게 동작하는지 확인한다.

트래픽을 단계적으로 증가시키면서 서버의 처리량과 응답시간이 어떻게 변화하는지 관찰하고, 어느 지점부터 성능이 급격하게 저하되는지 확인한다.

---

4.2 부하 테스트 경험

k6를 사용하여 실제 사용자 대신 가상의 사용자 요청을 발생시킨다.

단순히 요청을 많이 보내는 것에 그치지 않고 다음과 같은 트래픽 상황을 직접 만들어볼 예정이다.

• 일반적인 부하 상황
• 서버의 한계를 확인하는 Stress Test
• 특정 시점에 요청이 갑자기 증가하는 Spike Test

OTT 서비스에서 스포츠 생중계가 시작되는 순간처럼 짧은 시간에 사용자가 몰리는 상황도 재현해본다.

---

4.3 성능 지표 이해

서버 성능을 단순히 평균 응답시간으로 판단하지 않고 여러 지표를 이용해 분석한다.

주요하게 확인할 지표는 다음과 같다.

• RPS
• p50
• p95
• p99
• Error Rate

특히 일부 사용자의 응답시간이 급격하게 느려지는 상황을 확인하기 위해 p95와 p99를 중심으로 살펴볼 예정이다.

---

4.4 DB 병목 분석 및 최적화

재생 요청 한 번을 처리하기 위해 어떤 SQL이 실행되는지 확인한다.

트래픽이 증가했을 때 DB가 병목이 되는 상황을 만들어보고 다음 내용을 직접 다뤄본다.

• Query 실행 계획
• Index
• Composite Index
• Slow Query
• Connection Pool
• Transaction 범위

단순히 Index를 추가하는 것이 아니라 왜 해당 Index가 필요한지와 실제로 성능이 개선됐는지를 측정하는 것을 목표로 한다.

---

4.5 Cache 전략 이해

반복적으로 조회되는 데이터 때문에 DB 부하가 증가한다면 Redis를 이용해 Cache를 적용한다.

이 과정에서 다음 내용을 학습한다.

• Cache Hit / Miss
• Cache Aside
• TTL
• Cache Invalidation
• Local Cache와 Redis의 차이

모든 데이터를 무조건 Cache에 넣는 것이 아니라 어떤 데이터가 Cache에 적합한지 판단하는 것을 목표로 한다.

---

4.6 동시성 문제 이해 및 해결

Playback Gate에서 가장 중요하게 다뤄볼 문제 중 하나다.

예를 들어 동시 재생이 1대만 허용된 이용권에 두 개의 재생 요청이 거의 동시에 들어오면 다음과 같은 상황이 발생할 수 있다.

요청 A                     요청 B

현재 재생 수 = 0          현재 재생 수 = 0

재생 가능                 재생 가능

Session 생성              Session 생성

동시 재생은 한 대만 가능해야 하지만 두 개의 Session이 생성되는 문제가 발생한다.

이러한 Race Condition을 직접 재현하고 다음 방식들을 비교해볼 예정이다.

• DB Lock
• Redis Distributed Lock
• Atomic Operation

각 방식이 문제를 해결하는지만 보는 것이 아니라 정확성, 성능, 구현 복잡도 측면에서 어떤 차이가 있는지 비교한다.

---

4.7 Low Latency API 설계

Playback Gate는 사용자가 재생 버튼을 누른 직후 호출되는 API이기 때문에 응답시간이 사용자 경험에 직접적인 영향을 준다.

따라서 단순히 처리량을 높이는 것뿐만 아니라 많은 요청이 발생하는 상황에서도 응답시간을 안정적으로 유지하는 방법을 고민해본다.

DB 접근, Cache, 동시성 제어 방식 등이 응답시간에 어떤 영향을 주는지도 직접 측정할 예정이다.

---

4.8 서버 상태 모니터링

서버가 느려졌을 때 감으로 원인을 추측하지 않고 지표를 통해 문제를 찾는 방법을 익힌다.

다음 도구들을 활용할 예정이다.

• Spring Actuator
• Micrometer
• Prometheus
• Grafana

그리고 다음과 같은 지표를 관찰한다.

• CPU
• Memory
• JVM
• GC
• API Latency
• Error Rate
• DB Connection Pool
• Redis 상태

최종적으로는 트래픽 증가와 각 시스템 지표의 변화를 함께 보면서 실제 병목이 어디서 발생했는지 추적할 수 있는 수준을 목표로 한다.

---

4.9 성능 개선을 수치로 증명

이 프로젝트에서 가장 중요하게 생각하는 부분이다.

단순히

Redis를 적용했다.
Index를 추가했다.
성능을 개선했다.

로 끝내지 않는다.

모든 주요 변경사항에 대해 같은 조건에서 다시 부하 테스트를 수행한다.

Baseline 측정
      ↓
문제 분석
      ↓
개선
      ↓
동일한 조건으로 재측정
      ↓
Before / After 비교

최종적으로는 다음과 같은 데이터를 근거로 개선 효과를 설명할 수 있도록 한다.

• 처리 가능한 RPS 변화
• p95 변화
• p99 변화
• Error Rate 변화
• DB Query 감소
• DB Connection 사용량 변화

---

5. 최종 목표

Playback Gate 프로젝트를 통해 단순히 여러 기술을 사용해보는 것이 아니라,

대규모 동시 요청이 발생하는 API의 성능 문제를 직접 재현하고, 부하 테스트와 모니터링을 이용해 병목 원인을 찾은 뒤 DB 최적화, Cache, 동시성 제어 등을 적용하여 개선하고 그 결과를 실제 측정값으로 설명할 수 있는 경험

을 만드는 것이 최종 목표다.

다음 글에서는 Playback Gate가 실제로 어떤 기능을 제공해야 하는지 정리하기 위해 기능 요구사항과 비기능 요구사항을 정의해보려고 한다.