14장 넷플릭스 서비스 설계

[jongfeel]

14장 넷플릭스 서비스 설계

14.1 기능적 요구 사항

• 사용자 등록 및 인증
• 콘텐츠 탐색 및 검색
• 비디오 재생 및 스트리밍
  • 최소한의 버퍼링과 고품질 스트리밍 환경을 제공
  • 다양한 해상도를 지원하고 네트워크 대역폭에 맞춰 자동을 화질을 조정
• 사용자 프로필 및 개인 맞춤 설정
  • 하나의 계정에서 프로필을 여러 개 생성
  • 자녀 보호 기능
• 추천 및 개인화
• 시청 목록 및 시청 기록
  • 나중에 볼 콘텐츠를 시청 목록에 추가하고, 이전에 본 콘텐츠를 쉽게 확인할 수 있어야 함
  • 시청 목록과 시청 기록은 여러 기기에서 동기화
• 오프라인 환경에서 비디오 시청

14.2 비기능적 요구 사항

• 확장성 및 성능
• 가용성 및 안정성
• 콘텐츠 전달 및 스트리밍 품질
  • 기기 성능과 네트워크 환경을 고려하여 적응형 비트레이트(adaptive bitrate) 스트리밍을 지원

14.3 데이터 모델

• User
• Profile:
• Movie
• TVShow
• Episode
• WatchHistory
• Watchlist
• Rating
• ContentMetadata

Figure 14.1: An overview of the entity relationship diagram for Netflix

14.3.1 1:N 엔티티 관계

• User -> Profile
• Movie -> ContentMetadata
• TVShow -> Episode
• TVShow -> ContentMetadata
• Episode -> ContentMetadata
• Profile -> WatchHIstory
• Profile -> Watchlist
• Profile -> Rating

14.4 시스템 규모 산정

14.4.1 가정 상황

• 전체 사용자 수: 5000만 명
• 하루 평균 활성 사용자 수: 1000만 명
• 사용자 1인당 시청하는 하루 평균 비디오 수: 3편
• 비디오 한 편의 평균 길이: 1.5시간
• 비디오 한 편당 평균 파일 크기(HD 화질 기준): 3GB

14.4.2 저장소 규모

• 비디오 저장 공간
  • 영화 수: 1만 편
  • TV 프로그램 수: 5000개
  • TV 프로그램별 평균 에피소드 수: 30편
  • 전체 에피소드 수: 5000개×30편 = 15만 편
  • 전체 비디오 파일 수: 영화 1만 편 + 에피소드 15만 편 = 총 16만 편
  • 전체 비디오 파일 크기: 16만 편×3GB = 총 480PB
• 사용자 데이터 및 메타데이터 저장 공간
  • 사용자 기본 정보: 5000만 명×1KB = 50GB
  • 프로필 데이터: 5000만 명×프로필 5개×1KB = 250GB
  • 시청 기록 및 평점 데이터: 5000만 명×프로필 5개×1MB = 250TB
  • 콘텐츠 메타데이터: 16만 편×10KB = 1.6GB
  • 총합: 비디오 480PB + 사용자 및 메타데이터 약 250TB ≈ 약 480PB

14.4.3 대역폭

• 일일 비디오 스트리밍 대역폭
  • 평균 비디오 파일 크기: 3GB
  • 일평균 스트리밍 횟수: 일일 활성 사용자 1000만 명×1인당 3편 = 3000만 회
  • 일일 전체 스트리밍 대역폭: 3000만 회×3GB = 약 90PB/일
• 피크 시간대의 최대 대역폭
  • 동시 접속 사용자 수(최대치): 100만 명
  • 피크 시간대 대역폭 계산: 100만 명×3GB ÷ 1.5시간 ≈ 2TB/초

14.4.4 처리량

• 비디오 인코딩 및 트랜스코딩
  • 하루에 새로 추가되는 비디오 수: 100편
  • 비디오 평균 길이: 1.5시간
  • 인코딩 시간: 1.5시간(비디오 길이)×5가지 비트레이트 = 비디오당 7.5시간
  • 일일 총 인코딩 처리 시간: 100편×7.5시간 = 총 750시간
• 추천 서비스 처리
  • 하루 활성 사용자 수: 1000만 명
  • 사용자당 하루 추천 요청 수: 평균 10회
  • 하루 총 추천 요청 수: 1000만 명×10회 = 1억 회
  • 요청당 처리 시간: 평균 100ms
  • 일일 추천 처리 시간: 1억 회×100ms = 총 약 2.7시간

서비스 확장을 생각한다면 반드시 고려해야 하는 중요한 포인트

• 수평 확장
  • 로드 밸런서
  • 오토스케일링
• 캐싱
  • CDN, 애플리케이션 서버, 데이터베이스 등 여러 계층에 캐싱을 적용
  • 인기 비디오, 사용자 프로필, 추천 데이터 등 빈번하게 접근하는 데이터를 캐시에 미리 저장
• 콘텐츠 전송 네트워크
• 데이터베이스 샤딩과 복제

14.5 고수준 설계

Figure 14.2: The Netflix architecture diagram

14.6 서비스 세부 설계

14.6.1 Video Service

Figure 14.3: The Video Service architecture

• POST /videos: Upload a new video file:
  • Request body: The video file and metadata (title, description, duration, etc.).
  • Response: The video ID and status.
• GET /videos/{videoId}: Retrieve video metadata:
  • Response: Video metadata (title, description, duration, etc.).
• GET /videos/{videoId}/stream: Stream the video content:
  • Request parameters: Video ID, quality/bitrate, offset.
  • Response: Video chunk or segment.

Video upload and storage

Figure 14.4: Video upload and storage

Video encoding and transcoding

Figure 14.5: Video encoding and transcoding

Video streaming

Figure 14.6: The video streaming sequence diagram

Caching and content delivery

Figure 14.7: The content delivery sequence diagram

14.6.2 User Service

Figure 14.8: The User service

• POST /users: Create a new user account:
  • Request body: User information (email, password, name, etc.)
  • Response: User ID and authentication token
• POST /users/login: User login:
  • Request body: User credentials (email and password)
  • Response: An authentication token
• GET /users/{userId}: Retrieve user profile information:
  • Response: User profile data (name, email, profile picture, etc.)
• PUT /users/{userId}: Update user profile information:
  • Request body: Updated user profile data
    Response: Updated user profile
• POST /users/{userId}/profiles: Create a new profile for a user:
  • Request body: Profile information (name, avatar, preferences, etc.)
  • Response: A profile ID
• GET /users/{userId}/profiles: Retrieve all profiles of a user:
  • Response: A list of user profiles
• PUT /users/{userId}/profiles/{profileId}: Update a user profile:
  • Request body: Updated profile information
  • Response: An updated profile

User authentication and authorization

Figure 14.9: Authentication and authorization flow

User profile management

Figure 14.10: The user profile management sequence diagram

14.6.3 Database and caching

사용자 서비스는 사용자 정보나 프로필 데이터를 저장할 때 주로 PostgreSQL이나 MySQL 같은 관계형 데이터베이스를 씁니다.
데이터베이스에는 사용자, 프로필, 개인별 설정, 인증 토큰 같은 정보를 담는 테이블이 들어갑니다.
자주 사용하는 사용자 및 프로필 정보는 레디스나 맴캐시드 같은 캐시를 활용해서 서비스 응답 속도를 높이고 데이터베이스 부하를 줄일 수 있습니다.

Security and privacy

사용자 비밀번호는 절대 그대로 저장하지 않고 암호화(해싱 및 솔트)를 거쳐 저장합니다. 또 GDPR(유럽 일반 데이터 보호 규정)이나 CCPA(캘리포니아 소비자 개인 정보 보호법) 같은 데이터 보호 법률을 철저히 지켜 사용자의 개인 정보를 안전하게 보호합니다.

14.6.4 Recommendation Service

Figure 14.11: The Recommendation service high-level diagram

• GET /recommendations/{userId}: Retrieve personalized video recommendations for a user:
  • Request parameters: The user ID, number of recommendations, and filters (e.g., genre or language)
  • Response: A list of recommended videos with metadata
• POST /events: Record user events for recommendation purposes:
  • Request body: The user ID, event type (e.g., the video watched, rated, and searched), and event data
  • Response: Success status

The recommendation generation flow

Figure 14.12: The recommendation generation flow

The user event recording flow

Figure 14.13: The user event recording flow

The model training and deployment process

Figure 14.14: The model training and deployment process

Scalability and performance

서버 여러 대에 추천 서비스를 설치하고, 로드 밸런서로 요청을 적절히 분산시켜 처리량을 늘립니다.
자주 요청하는 추천 결과는 레디스나 맴캐시드 같은 캐싱 시스템에 저장하여 응답 속도를 높일 수 있습니다.
또 아파치 스파크나 텐서플로 서빙(TensorFlow Serving) 같은 확장성이 좋은 인프라에 추천 모델을 배포하면 대량의 요청도 효율적으로 처리할 수 있습니다.

Monitoring and evaluation

추천 서비스는 주요 지표와 성능을 지속적으로 모니터링하여 서비스가 제대로 작동하는지 관리합니다.
예를 들어 추천 요청 처리 속도, 캐시 적중률, 모델 정확도 같은 지표를 꾸준히 확인하여 서비스가 얼마나 효과적으로 작동하고 있는지 체크합니다.
또 여러 가지 추천 알고리즘이나 설정 값을 적용한 후 A/B 테스트로 사용자 행동 패턴을 수집해서 사용자 참여도와 만족도가 얼마나 개선되었는지도 측정할 수 있습니다.
이외에도 사용자 피드백이나 평가 점수를 수집하고 분석하여 추천 품질을 점차적으로 높여 나갑니다.

14.7 CDN

Figure 14.15: The CDN architecture

14.7.1 CDN architecture and content distribution

Figure 14.16: The content distribution sequence diagram

14.7.2 Request routing and video streaming

Figure 14.17: The request routing and video streaming workflow

14.7.3 Adaptive bitrate streaming

• 비디오를 여러 비트레이트로 인코딩한 후 작은 세그먼트 단위로 나누어 저장합니다.
• 비디오가 재생되는 동안 네트워크 상태를 지속적으로 모니터링합니다.
• 상황에 따라 비트레이트를 조절하여 다음 세그먼트를 에지 서버에 요청합니다.
• 에지 서버는 해당 요청에 맞는 비디오 세그먼트를 클라이언트로 전달합니다.
• 이처럼 비트레이트를 실시간으로 조절하는 방식 덕분에 네트워크 환경이나 기기 성능이 다르더라도 끊김 없는 시청 경험을 유지할 수 있습니다.

14.7.4 Content security and DRM

CDN은 콘텐츠 보안을 위해 DRM(Digital Rights Management)서비스와 통합하기도 합니다.

• 비디오 콘텐츠는 마이크로소프트 플레이레디(PlayReady)나 구글 와이드바인(Widevine) 등 DRM 시스템을 사용하여 암호화합니다.
• CDN은 DRM 서비스와 연동하여 콘텐츠를 암호화 상태로 안전하게 전달하고, 정식 사용자만 콘텐츠를 재생할 수 있도록 라이선스를 검증합니다.
• 유효한 DRM 라이선스를 인증한 사용자만 비디오 콘텐츠에 접근하고 재생할 수 있도록 처리합니다.

이렇게 연동하여 콘텐츠에 무단으로 접근하거나 복제하는 일을 막고, 라이선스 조건과 지역 제한 같은 규정을 지킬 수 있도록 합니다.