데브옵스
우당탕탕~ 영상 서비스 개발기 3탄 : 플레이어 백엔드 서버와 데이터 수집
두줄요약
영상 플레이어 API의 성능 요구에 맞춰 Cloud Run에서 GKE로 전환하고 SSE를 부하 테스트했습니다.\nVector·GCS·Dataflow·BigQuery 기반 로그 수집과 분석 파이프라인을 구축했습니다.
선택 이유
- Serverless 환경의 Spring Boot 콜드 스타트 부담으로 Go와 Gin 선택
- 문서·레퍼런스 접근성을 고려한 Gin·GORM 채택
- 단방향 실시간 응원 기능에 SSE 적용
구조와 흐름
- CMS 백엔드는 Cloud Run, 고성능 플레이어 API는 GKE 기반 구성
- Playback API 로그를 Vector로 GCS에 적재하고 Dataflow로 BigQuery 전송
- BigQuery 데이터의 Looker Studio 시각화 및 시청·동접·좋아요·응원 지표 활용
성능/운영 포인트
- Cloud Run 부하 테스트 결과 3,000~7,000 TPS로 목표치 미달, GKE 전환
- Gatling과 EKS Pod 확장으로 SSE 동시 접속 부하 테스트 수행
- 일반 API의 CPU 중심 사용량과 SSE Pod의 메모리 중심 사용량을 리소스 할당에 반영
트레이드오프
- GORM의 문자열 조건식·자동완성 부재와 ENTGO 코드 생성 설정 부담 사이의 선택
- GCS 파일 적재의 수집 지연과 Looker Studio 가공·커스터마이징 한계
- GKE의 IPVS least connection 미지원으로 여유 Pod 구성 및 유입 관찰 대응
