[Review] 시스템 디자인 스터디 7주차 후기

안녕하세요!

K-DEVCON (이하 “데브콘”) 그로스 매니저 박종훈입니다.

 

이 글에서는 10/30 (목)에 진행된 스터디에서 나눈 이야기를 정리합니다.

 

이번 시간에는 “유튜브 시스템 설계”에 대한 이야기를 나눴습니다.

 

---

 

유튜브는 많은 사람들이 사용하는 서비스입니다. 유튜브와 같은 서비스에서는 영상을 어떻게 효율적으로, 그리고 안정적으로 제공 해줄 수 있을지에 대한 많은 고민이 필요합니다.

[0] 기본 개념 설명

코덱(codec)은 어떠한 데이터 스트림이나 신호에 대해, 인코딩이나 디코딩, 혹은 둘 다를 할 수 있는 하드웨어나 소프트웨어를 일컫습니다. (위키) 우리가 컴퓨터(PC, 스마트폰 등)에서 다루는 영상은 다양한 형태(포맷)로 저장이되어 관리됩니다.

따라서 한 기기에서 사용한 포맷이 다른 기기에서는 지원되지 않는 호환성 문제가 발생되기도 합니다.

 

이러한 호환성 문제를 해결하기 위해 트랜스 코딩이 필요합니다. 트랜스 코딩은 하나의 인코딩을 다른 인코딩으로 직접 변환하는 과정을 의미합니다. 다양한 사용자를 대상으로 서비스를 하기 위해서는 표준화된 포맷으로 변환해서 제공해줘야 합니다. 트랜스 코딩를 통해 다양한 포맷, 화질, 비트레이트(1초당 처리되는 데이터의 양) 을 변경하여 저장합니다. 이를 통해 영상을 누구나, 어디서나, 어떤 환경에서도 원활하게 볼 수 있도록 돕습니다.

[1] 기본적인 시스템 설계

우리 주변에는 영상과 관련된 서비스가 많이 있습니다. 하지만 각 서비스가 목표로 하는 부분은 차이가 있는데요. 다음과 같이 세 분류로 나눠서 생각해보았습니다.

• Youtube, SNS
  • 사용자가 직접 업로드 할 수 있습니다.
    
  • 영상의 종류와 길이가 다양합니다. 따라서 트랜스코딩 처리 과정이 중요합니다.
    
• Netflix (OTT)
  • 사용자가 직접 업로드 할 수 없습니다.
  • 어떻게 하면 안정적으로 서빙할까가 중요합니다.
• Live Streaming
  • 실시간성이 중요합니다. 지연이 최소화 되어야 합니다.
  • 라이브 도중 놓친 데이터를 당장 다시 처리하지 않아도 됩니다.

각 상황에 맞게 적절한 설계 범위를 설정하는 것이 중요하겠습니다.

 

유튜브의 개략적인 설계는 다음과 같습니다.

 

 

여기서 트랜스 코딩 서버는 다음과 같은 플로우로 작업을 처리합니다.

 

 

[2] DAG (유향 비순환 그래프, Directed Acyclic Graph)

DAG 는 이번 장의 핵심 키워드 였다고 생각됩니다. DAG 를 쉽게 설명하자면, “정해진 방향으로만 실행 가능한 파이프라인” 이라고 생각해주시면 됩니다.

DAG 로 정의된 작업은 반드시 유한한 단계를 거쳐 끝에 도달합니다. 이는 유연성과 병렬성을 높이기 위한 추상화 단계입니다.
실제로 페이스북이 도입한 개념입니다. 다른 영상 관련 기업들도, DAG 라는 표현을 쓰지는 않더라도, 병렬로 처리하기 위해 비슷한 개념들을 도입하여 처리하고 있습니다.
SVE: Distributed Video Processing at Facebook Scale 논문에서는 DAG 를 사용하여 시스템을 개선한 사례를 소개하고 있습니다.

페이스북의 초기 영상 처리 시스템 아키텍처는 Monolithic 한 인코더를 사용하였습니다. 이는 영상 전체가 다 처리될 때까지 기다려야 하기 때문에, 처리속도와 확장성에 한계가 있었습니다.

 

페이스북의 초기 ‘영상 처리 시스템’ 아키텍처. (출처: SVE: Distributed Video Processing at Facebook Scale)

 

영상 처리는 다양한 단계에서 다양한 이유로 실패하기 쉽습니다. 이를 개선하기 위해 아래과 같이 DAG 기반으로 파이프라인을 구성하도록 변경되었습니다.

페이스북의 개선된 ‘영상 처리 시스템’ 아키텍처. (출처: SVE: Distributed Video Processing at Facebook Scale)

 

개선된 페이스북 영상 처리 시스템에서는 처음 업로드 시점부터 파일을 나누어 처리합니다. 영상은 용량이 큽니다. 파일과 처리 단계를 분할하여, 효율적으로 여러번 시도할 수 있도록 하는 것이 중요하였습니다.

 

위 논문에 따르면 개선된 시스템에서는 다음과 같은 재시도 로직을 사용하고 있다고 합니다.

- 복구 가능/불확실한 경우: 작업은 로컬에서 최대 2회 재시도. 

- 지속적 실패 시: 스케줄러가 다른 워커에서 최대 6회 재스케줄링.

이를 통해 최대 21회 실행을 하여 처리 성공률을 99.995% 까지 끌어올렸다고 합니다.

 

각 단계를 큐로 관리하여 유연하게 관리할 수 있게 된 부분도 이러한 설계를 통해 얻은 장점이라고 생각됩니다.

 

[3] GOP (Group Of Pictures)

책에서는 GOP를 병렬적으로 업로드 하여 최적화 하는 방식에 대해서 설명되어 있습니다. 그러면 GOP가 무엇일까요?

 

영상은 사실 수많은 프레임으로 구성되어 있습니다. 프레임은 동영상을 구성하는 수많은 정지 이미지 입니다.

이 많은 이미지를 원본 데이터로 보관하면 엄청난 공간을 차지하게 되기 때문에, 압축하는 방법을 고민하였고, 그 중 대표적인 것이 GOP 입니다.

 

GOP는 다음과 같이 구성되어 있습니다.

 

• I-frame: 일반적인 frame (Keyframe)
• P-frame: I-frame 을 기준으로 벡터를 사용해 무엇이 바뀌었는지 예측합니다.
• B-frame: 이전 프레임 과 다음 프레임 사이에서 두 프레임 정보를 사용하여 예측합니다.

이 세가지 종류의 frame을 활용하여 모든 프레임을 직접 저장하지 않고, 변경된 부분만 저장하여 적절히 압축할 수 있습니다.

(더 자세한 내용은 Back to basics: GOPs explained 를 참고하세요.)

 

GOP는 매우 작은 단위입니다. 따라서 책에서 설명한대로 GOP 자체를 업로드 하게 되면, 매우 많은 양의 업로드를 진행해야 합니다.

페이스북의 논문에서는 다음과 같이 설명하고 있습니다.
가능하다면 클라이언트에서 GOP 로 구성된 세그먼트로 분할하여 업로드 합니다. 세그먼트는 독립적인 작은 동영상의 형태를 띄게 됩니다. 따라서 독립적으로 처리될 수 있으며, 이는 영상 처리를 더 빠르게 진행될 수 있도록 돕습니다.
따라서 특정 세그먼트 단위로 업로드 한다고 보는 것이 더 맞는 방향으로 보입니다.

 

[4] DRM (Digital Rights Management)

이 부분은 사실 책에서도 간단하게만 넘어갔습니다. 하지만 스터디 중 이에 대한 내용이 나왔고, 재밌는 주제라고 생각되어 정리해봅니다.

넷플릭스에서 영상을 보다가 마음에 드는 장면을 캡처하려고 하면, 화면이 검정색으로 바뀌면서 캡처가 되지 않는 경험을 해보신 적이 있으실 수 있습니다. 이는 단순히 브라우저 차원의 기능이 아니라, DRM의 한 형태로서 HDCP 라는 기술이 동작하기 때문입니다.

저는 처음에는 이 기능이 브라우저에서 구현된 것이라고 생각했지만, 이번 스터디를 통해 브라우저가 아닌 하드웨어(예: 그래픽 카드, 모니터) 수준에서 지원되는 기술이라는 것을 알게 되었습니다.

즉, 영상이 재생될 때 송출 장치와 출력 장치 간의 암호화된 통신을 통해 콘텐츠가 보호되며, 만약 이 보호 체계가 깨지거나 호환되지 않으면 영상이 재생되지 않거나 캡처가 차단됩니다.

 

---

오늘 후기글은 여기까지 입니다.
저희는 이 외에도 다양한 이야기를 나눠보았습니다. (동영상 CDN 비용 최적화, 그리드 시스템 등...)

우리 스터디에서는 실제 사례들을 통해 문제를 어떻게 해결해 나갔을까 많은 고민을 해보고 이야기를 나눠보고 있습니다. 이번주도 다들 열심히 참여해주셔서 더 풍성한 스터디가 될 수 있었습니다.

 

✅ 직접 스터디를 개설해보고 싶은 분이 계시다면, K-DEVCON에서 운영을  도와드리겠습니다. 데브콘의 '랩짱'에 도전하여 커뮤니티 성장을 함께 이끌어주세요! 슬랙을 통해 운영진에게 DM 부탁드리겠습니다😉