스트리밍서버 구축
1. 스트리밍 서버의 기본구조
스트리밍 서비스는 사용자가 실시간으로 동영상이나 음악 같은 미디어 콘텐츠를 재생할 수 있게 해주는 시스템이다. 사용자는 파일을 다운로드할 필요 없이 바로 콘텐츠를 시청할 수 있다. 스트리밍은 ‘온디맨드(On-Demand)’ 방식으로, 사용자가 특정 시점에 원하는 콘텐츠를 실시간으로 요청하고 바로 재생하는 형태이다.
• 사용자의 요청 흐름:
1. 동영상 요청: 사용자가 웹사이트 또는 애플리케이션에서 동영상 콘텐츠를 선택하면, 해당 요청이 서버로 전달된다.
2. 서버 응답: 서버는 요청을 받아 동영상 파일을 찾은 후, 이를 클라이언트(사용자)에게 스트리밍 방식으로 전달한다.
3. 실시간 전송: 사용자는 전체 파일이 다운로드되기 전에 일부 데이터를 먼저 수신받아, 곧바로 재생할 수 있다. 이 과정에서 서버는 사용자 네트워크 상태에 따라 품질을 조정하거나, 적절한 양의 데이터를 꾸준히 공급하는 역할을 한다.
중요한 부분은 데이터를 실시간으로 작은 조각들로 나누어 전송하는 방식입니다. 사용자는 파일을 한 번에 전부 받지 않고, 순차적으로 재생하면서 필요한 데이터만 수신받기 때문에 대기 시간이 줄어든다.
동영상 파일의 전송 방식: HLS와 DASH
스트리밍을 위해서는 적절한 전송 프로토콜이 필요합니다. 가장 널리 사용되는 프로토콜은 HLS(HTTP Live Streaming)와 DASH(Dynamic Adaptive Streaming over HTTP)이다.
HLS (HTTP Live Streaming):
• 애플에서 개발한 스트리밍 프로토콜로, 기본적으로 동영상을 작은 조각(세그먼트)으로 나누어 전송.
• 각각의 세그먼트는 짧은 길이(보통 5-10초)로 구성되며, 사용자에게 차례대로 전송.
• 적응형 스트리밍: 네트워크 속도에 따라 동영상 품질을 동적으로 조정할 수 있어, 사용자의 환경에 맞춰 최적의 화질을 제공.
• HLS는 HTTP를 기반으로 하기 때문에, 기존의 웹 서버 인프라와 잘 연동.
DASH (Dynamic Adaptive Streaming over HTTP):
• HLS와 비슷하게, DASH는 적응형 스트리밍 프로토콜입니다. 네트워크 상태에 따라 비트레이트를 조정하여 동영상 품질을 최적화.
• 다양한 미디어 포맷과 코덱을 지원하며, 오픈 표준 기반으로 다양한 플랫폼에서 사용 가능.
• 주로 YouTube와 같은 대형 스트리밍 서비스에서 사용.
서버 아키텍처: 웹 서버와 미디어 서버의 차이
스트리밍 서비스는 웹 서버와 미디어 서버가 상호작용하여 콘텐츠를 제공합니다. 이 두 서버의 역할이 다르므로, 아키텍처의 차이를 이해하는 것이 중요하다.
1. 웹 서버:
• 역할: 주로 사용자의 요청을 받아들이고, 웹 페이지를 렌더링하거나 HTML, CSS, JavaScript 같은 정적 콘텐츠를 제공하는 역할.
• 예시: Apache, Nginx와 같은 서버는 웹 서버로 사용.
• 스트리밍에서의 역할: 동영상 재생 페이지나 플레이어 인터페이스를 제공하고, 사용자의 동영상 재생 요청을 처리하여 미디어 서버에 전달하는 역할.
2. 미디어 서버:
• 역할: 주된 역할은 고용량의 동영상 파일을 처리하고 실시간 스트리밍 서비스를 제공하는 것.
• 특징: 실시간 트랜스코딩(다양한 포맷과 해상도로 동영상을 변환) 기능을 제공하고, 동영상 파일을 다양한 품질로 나누어 실시간 전송할 수 있다.
• 예시: Wowza, Nginx RTMP, Red5 등은 미디어 서버로 사용.
• 스트리밍에서의 역할: 웹 서버와 달리 대용량 미디어 콘텐츠를 처리하고, 사용자가 요청한 콘텐츠를 다양한 장치와 네트워크 상태에 맞게 제공하는 데 집중.
1. 일반 서버(웹 서버) vs. 스트리밍 서버
• 일반 서버(웹 서버)는 주로 웹페이지를 렌더링하거나, 정적 파일(CSS, HTML, JavaScript 등)을 제공하는 역할을 한다. 사용자 요청을 받아, 해당 데이터를 직접 처리하고 응답하는 형태이다.
• 스트리밍 서버는 실시간으로 동영상이나 오디오 데이터를 제공하는 서버로, 미디어 파일을 작은 조각으로 나누어 사용자에게 실시간으로 전송한다. 동영상이나 음악 같은 고용량의 파일을 효율적으로 처리하고, 네트워크 상태에 따라 품질을 조정하는 역할을 한다.
2. AWS S3와 서버의 차이점
• AWS S3는 일반적으로 ‘서버’라고 불리는 것과 다르게, 스토리지 역할을 한다. 즉, 데이터를 저장하고 관리하는 기능을 제공합니다. S3는 파일을 직접 처리하거나 응답을 주는 서버가 아닌, 데이터를 효율적으로 저장하고 요청에 따라 제공하는 역할을 한다.
• S3는 파일 저장소로 사용되며, 동영상 파일이나 이미지, 문서 같은 데이터를 저장하고, 필요할 때 이를 전달해 주는 서비스이다.
• S3 자체는 사용자가 직접 동영상을 스트리밍할 수 있는 기능을 제공하지는 않으며, 그저 파일을 저장하고 제공할 뿐이다. 실제로 S3에 저장된 파일을 스트리밍하기 위해서는 CloudFront 같은 CDN이나 스트리밍 서버가 중간에 필요하다.
3. S3와 스트리밍 서버의 연계
• AWS S3는 데이터를 저장하는 장소이고, 스트리밍 서버는 이 데이터를 실제로 스트리밍할 수 있게 사용자에게 전달하는 서버이다. 예를 들어, S3에 동영상을 저장한 뒤, 이를 스트리밍 서버 또는 CDN(Content Delivery Network)와 연결하면 사용자는 실시간으로 해당 동영상을 시청할 수 있다.
• 예를 들어, S3에 저장된 동영상을 CloudFront(CDN)와 연동하면, 사용자 위치에 따라 가까운 CDN 노드에서 동영상이 제공되므로 빠르게 스트리밍할 수 있다.
4. S3와 웹 서버의 역할 차이
• 웹 서버는 사용자가 요청한 데이터를 제공하고, 이를 통해 웹사이트를 보여주는 역할.
• AWS S3는 웹 서버처럼 사용자에게 웹페이지나 정적 파일을 처리해 제공하는 것이 아니라, 데이터를 저장하고 관리하는 역할만을 수행한다. 웹 서버는 S3에서 필요한 파일을 가져오거나, S3의 파일 URL을 사용자에게 제공하는 형태로 사용.
AWS S3 저장소를 이용하기위한 스트리밍서버가 필요한데 주로 사용되는것은
Amazon CloudFront (CDN 기반 스트리밍)
• CloudFront는 AWS의 콘텐츠 전송 네트워크(CDN) 서비스로, S3와 직접 연동하여 **HLS(HTTP Live Streaming)**나 DASH(Dynamic Adaptive Streaming over HTTP) 프로토콜을 통해 스트리밍을 제공합니다.
• 특징:
• S3에서 동영상을 가져와 전 세계 엣지 서버에 분산 저장해 사용자에게 빠르게 콘텐츠를 전달.
• 동영상 스트리밍 서버를 별도로 구축할 필요가 없으며, S3에 저장된 파일을 CDN을 통해 스트리밍할 수 있음.
Redis
는 인메모리 데이터베이스로, 주로 데이터 캐싱, 세션 관리, 빠른 데이터 조회 및 저장 등을 처리하는 데 사용됩니다. 스트리밍 서버와는 역할이 완전히 다름.
Redis의 역할:
• 데이터 캐싱: 자주 조회되는 데이터를 메모리에 저장해 빠르게 접근할 수 있게 한다.
• 세션 관리: 사용자가 언제 어디서 동영상을 중단했는지 기록해 이어서 보기 같은 기능을 지원한다.
• 데이터 처리: 실시간으로 처리해야 하는 데이터를 빠르게 처리한다.
스트리밍 서버의 역할:
• 동영상 전송: 동영상을 실시간으로 사용자에게 전달한다. 동영상을 작은 조각으로 나누어 네트워크 상태에 맞게 전송하는 역할을 한다.
• 프로토콜 관리: HLS나 DASH 같은 스트리밍 프로토콜을 사용해 동영상을 전송한다.
• 미디어 파일 처리: 실시간 트랜스코딩(동영상을 다양한 해상도와 형식으로 변환) 등의 역할을 담당한다.
Redis와 스트리밍 서버의 차이:
• Redis는 데이터를 저장하고 빠르게 제공하는 역할을 하며, 실제로 동영상을 스트리밍하지 않는다.
• 스트리밍 서버는 동영상을 사용자에게 실시간으로 전송하는 것이 주 역할이다.
따라서 Redis는 스트리밍 서버와 연계되어 동영상 스트리밍 서비스의 성능을 높이는 보조적인 역할을 한다고 볼 수 있다.
그러나 Redis가 이어보기 기능이나 캐싱을 통해 빠르게 데이터를 제공하더라도, 데이터베이스(DB)에서 마지막 시청 기록 등 영구 저장소로서의 역할은 여전히 중요하다. Redis는 주로 임시 저장과 빠른 조회를 위한 캐시로 사용되지만, 영구적인 데이터 저장과 복구를 위해서는 여전히 DB가 필요하다. 즉 Redis와 DB는 각자의 역할이 있기 때문에 상호 보완적으로 사용된다.
Redis와 DB의 역할 비교
1. Redis의 역할 (임시 저장 및 캐싱)
• 빠른 접근: Redis는 인메모리 데이터베이스로 동작하므로, 매우 빠르게 데이터를 읽고 쓸 수 있습니다. 사용자 경험을 향상시키기 위해, 이어보기 기능이나 자주 접근되는 데이터를 캐시로 관리.
• 예: 사용자가 동영상을 시청하다가 중단했을 때, 마지막 시청 지점을 Redis에 저장하여 빠르게 이어보기를 제공.
• 임시 저장소: Redis는 주로 임시 데이터를 저장하는 용도로 사용되며, 시스템이 재시작되거나 Redis 인스턴스가 실패할 경우 데이터가 손실될 수 있음(물론 Redis는 지속성 옵션도 제공하지만, 캐시로 사용할 때는 주로 임시 저장 용도로 쓰입니다).
• 세션 관리: 이어보기와 같은 기능에서 사용자의 세션 정보(예: 마지막 시청 지점)를 임시로 저장하고, 필요할 때 빠르게 조회하여 사용자에게 응답.
2. 데이터베이스(DB)의 역할 (영구 저장)
• 영구 데이터 저장: 데이터베이스는 영구적인 저장소로, 시스템이 재시작되거나 문제가 생기더라도 데이터를 안전하게 보존합니다. Redis와 달리 DB는 영구성을 보장하는 시스템.
• 예: 사용자가 로그아웃하거나 장기간 다시 접속하지 않더라도, 마지막 시청 지점이나 시청 기록을 DB에서 안전하게 보관.
• 장기 저장 및 분석: 데이터베이스는 장기적인 데이터 저장과 분석을 위한 데이터를 보관하는 역할을 합니다. 예를 들어, 사용자의 시청 기록을 기반으로 추천 시스템을 구현하거나, 장기적인 통계를 위해 시청 기록을 보관하는 것이 필요.
• 시청 기록, 사용자의 활동 데이터 등을 장기적으로 관리하고, 분석 목적으로 활용.
• 데이터 복구: Redis 캐시가 만료되거나 재시작으로 인해 세션 데이터가 사라지더라도, 데이터베이스에 저장된 정보를 바탕으로 다시 복구 가능.
해야할 일
1. 데이터베이스 설계 및 구축
2. AWS S3와 스트리밍 서버 연동
• S3에 동영상 파일 저장 및 URL 관리:
• 동영상 업로드 API 개발: 사용자가 동영상을 업로드하면, 이를 AWS S3 버킷에 저장하고 해당 URL을 DB에 기록하는 API를 구현.
• 파일 URL 관리: S3 버킷에 저장된 동영상 파일의 URL을 데이터베이스에서 관리.
• 스트리밍 서버 연동:
3. Redis를 통한 세션 관리 및 캐싱 구현
• 세션 관리 구현:
• 사용자가 동영상을 시청하다 중단했을 때, 중단된 지점을 Redis에 저장하고 나중에 이어서 볼 수 있도록 세션 관리 기능을 개발합니다.
• Redis에 사용자 세션 정보(중단 시간, 시청 기록 등)를 저장하고, 이를 조회할 수 있는 API를 구현합니다.
• 캐싱:
• 자주 요청되는 동영상 메타데이터나 시청 기록을 Redis에 캐시하여 DB 부하를 줄이고, 빠르게 데이터를 제공할 수 있도록 캐싱 전략을 설정합니다.
• 캐시 만료 정책 설정 및 Redis를 이용한 조회 속도 최적화를 위한 로직 구현.
4. API 개발
5. 스트리밍 서버 설정 및 최적화
• 스트리밍 서버 선택 및 설정: Nginx RTMP, Wowza, 또는 AWS Elemental Media Services 같은 스트리밍 서버를 설정하고, 이를 백엔드 서비스와 연동.
• HLS/DASH 프로토콜 설정: 스트리밍 서버가 AWS S3에 저장된 동영상 파일을 적절히 나누어(세그먼트로) 사용자에게 전송할 수 있도록 프로토콜을 설정.
• 비트레이트 전환 및 네트워크 최적화: 네트워크 상태에 맞춰 스트리밍 품질을 자동으로 조정하는 기능을 스트리밍 서버와 연동.
6. CDN 설정 (CloudFront 연동)
• CloudFront CDN 설정: AWS CloudFront를 사용해 글로벌 사용자에게 빠르게 동영상을 전달할 수 있도록 CDN 설정.
• 캐싱 정책 설정: CDN이 S3에서 동영상을 캐싱하여 사용자에게 더 빠르게 제공할 수 있도록 설정하고, 캐시 만료 정책을 구성.
7. 확장성 및 트래픽 관리
• 트레픽 관리: 로드밸런싱, 오토스케일링, Redis를 이용한 트래픽관리 필요.