Hello, FabriCache (패브리캐시) :

Open in app Sign up Sign in Write Sign up Sign in Catenoid TechBlog · Follow publication Welcome to Tech Blog of Catenoid, a global VTaaS (Video Technology as a Service) provider. Follow publication Hello, FabriCache (패브리캐시) SeongBong An · Subscribe Published in Catenoid TechBlog · 8 min read · Jan 3, 2024 -- Share FabriCache(패브리캐시)란? 당사가 자체 개발한 VOD 서비스를 위한 클라우드 스토리지 동영상 파일을 나누어서 블럭단위로 저장하는 효율적인 캐시 시스템 오리진 장애시에도 서비스가 가능한 안정적인 캐시 시스템 (다양한 페일오버 기능 제공) 들어가며 FabriCache(패브리캐시)는 당사의 Kollus VOD 서비스를 위해 만들어진 클라우드 스토리지 서비스로, 당사가 자체 개발하여 특허받은 기술입니다. 동영상 서비스가 이루어질 때 원본 파일을 가진 오리진 서버로부터 사용자가 직접 데이터를 요청해서 받을 경우, 과도한 네트워크 통신이 일어나고 느려질 수 있습니다. 이때 중간에 스토리지를 가진 캐시(Cache)가 사용자의 응답에 반응하고 동일한 파일을 사용자가 요청할 경우, 캐싱된 파일을 넘겨주면 되기 때문에 오리진 서버의 트래픽을 줄일 수 있습니다. 자주 사용하는 파일의 경우에는 반응시간도 더 좋아질 수 있습니다. 패브리캐시의 기본 컨셉은 이러한 캐시를 존(zone)으로 그루핑하는 것입니다. 시스템의 최전방에 위치한 캐시 서버를 존 단위로 그루핑하고, 캐시 서버는 존안에서 동영상 파일을 각자 나누어서 저장하게 됩니다. 사용자가 해당 캐시 서버가 보관하고 있는 않은 부분을 요청하면, 동일한 존안의 다른 캐시 서버에 저장되어 있는 파일을 받아서 서비스하는 방식입니다. FabriCache 기본개념 아래는 CDN을 사용하지 않는 경우의 그림입니다. CDN을 사용하지 않는 경우 사용자의 모든 요청이 매번 오리진 서버로 가게 되어 서버부하가 증가하고 오리진 서버의 응답이 느려지는 문제가 발생하게 됩니다. 이러한 문제점을 해소하기 위해서 아래의 그림에서와 같이 CDN을 사용하게 됩니다. 중간에 스토리지 를 가진 캐시가 사용자의 응답에 반응하면, 동일한 파일을 사용자가 요청할 경우, 캐싱된 파일을 넘겨주면 되기 때문에 오리진 서버로부터의 트래픽을 줄일 수 있고, 자주 사용하는 파일의 경우 반응 시간이 좋아집니다. 패브리캐시의 기본 개념은 이러한 캐시를 존으로 묶어 주는 것입니다. 기본 가정은 존안의 내부 네트워크 속도는 충분히 빠르다는 것입니다. (10G 또는 그 이상의 로컬 네트워크로 연결) 위 가정을 바탕으로 기본 알고리즘은 아래와 같이 설명할 수 있습니다. 존안의 캐시는 모든 파일을 가지지 않고, 파일의 일부만 가집니다. (만일 존안에 2개의 캐시가 있다면, 1번 캐시가 파일의 50% 를 담당하고, 2번 캐시가 나머지 50%를 담당합니다.) 내가 담당하지 않은 영역(Content Block)이 필요할 때는 내부 네트워크를 통해서 존안의 다른 캐시에게 요청해서 데이터를 받아온 후 사용자에게 전달합니다. 다른 캐시로부터 받은 데이터를 따로 저장하지는 않습니다. 각자 담당한 것만 저장하게 되며 소유자(Owner)라는 것은 파일의 일부를 저장하고 있는 캐시 서버를 의미합니다. 파일의 컨텐츠 블럭별로 소유자(Owner)가 지정되는 구조이며, 알고리즘에 의해 소유자를 지정하게 됩니다. FabriCache 특징 다양한 컨텐츠 블럭 사이즈 지원: 128KB, 512KB, 4MB 패브리캐시는 서비스용 웹 서버에 의존성이 없고 FUSE(FUSE — The Linux Kernel documentation )를 이용한 파일시스템 모듈로 개발이 되어 웹 서버 업그레이드에 따른 사이드 이펙트가 전혀 없습니다. 오리진 페일오버 기본적으로 패브리캐시는 로컬 캐시를 우선적으로 사용합니다. 오리진 서버 장애시에도 로컬 캐시를 통해 지속적인 서비스가 가능합니다. 카테마 알고리즘 적용 존 안에 서버가 추가되거나, 장애로 인해 서버가 제외되는 상황에서도 기존 저장되어 있는 로컬 캐시의 변경을 최소화하는 알고리즘을 적용하였기 때문에 컨텐츠 블럭에 대한 재배치 측면에서 우수하다고 볼 수 있습니다. 컨텐츠 블럭별로 소유자를 지정하는 구조이기 때문에 기존에 저장되어 있는 로컬 캐시의 변경을 최소화하면서 컨텐츠 블럭에 대한 재배치 작업이 일어납니다. 멀티 오리진 서버 지원 요청 URI내 경로에 따라 오리진 서버를 다르게 지정할 수 있습니다. 아래 그림에서 보면, 프로그레시브 다운로드 영상 파일과 HLS 영상 파일처리를 위한 서버들을 분리해서 운영할 수 있습니다. - 프로그레시브 다운로드 : VOD Edge 서버에서 처리 - HLS : VOD Relay 서버에서 처리 FabriCache 동작방식 아래의 가정을 통해 패브리캐시의 동작방식에 대해서 설명드리도록 하겠습니다. 캐시 서버 : 3대 (Edge A, Edge B, Edge C) video.mp4 : 4개의 컨텐츠 블럭으로 구성 (1번, 2번, 3번, 4번) 컨텐츠 블럭별 Owner(소유자) 1번 : Edge A 2번 : Edge B 3번 : Edge C 4번 : Edge B 캐시 서버가 3대 있고, 미디어 플레이어를 통해 사용자가 video.mp4 파일을 재생하는 경우의 시나리오를 보면 아래 그림과 같습니다. 미디어 플레이어가 video.mp4 파일을 Edge A에 요청합니다. Edge A는 오리진 서버로부터 video.mp4파일의 1번 컨텐츠 블럭에 해당하는 데이터를 받아와서 미디어 플레이어로 전달하고 로컬 캐시에 저장합니다. (1번 컨텐츠 블럭의 소유자는 Edge A) Edge A는 video.mp4파일의 2번 컨텐츠 블럭에 해당하는 데이터를 Edge B로부터 받아와 미디어 플레이어로 전달합니다. 2번 컨텐츠 블럭의 소유자는 Edge B이기 때문에 Edge A는 2번 컨텐츠 블럭을 따로 저장하지는 않습니다. Edge A는 video.mp4파일의 3번 컨텐츠 블럭에 해당하는 데이터를 Edge C로부터 받아와 미디어 플레이어로 전달합니다. (3번 컨텐츠 블럭의 소유자는 Edge C) Edge A는 video.mp4파일의 4번 컨텐츠 블럭에 해당하는 데이터를 Edge B로부터 받아와 미디어 플레이어로 전달합니다. (4번 컨텐츠 블럭의 소유자는 Edge B) 이미 캐싱된 파일을 전달할 때 패브리캐시는 존간의 통신을 통해서 데이터를 취합해서 전달해야 하므로, 존내부에서 추가 트래픽이 발생하는 단점이 있습니다. 하지만, 일반적으로는 Range request 를 통해서 일정 부분만을 받아가기 때문에 트래픽이 아주 많이 발생하는 건 아닙니다. 기본 전제로, 내부 네트워크는 충분히 빠르고 비용은 저렴하기 때문입니다. FabriCache 장점 존 안의 캐시들을 그루핑해서 관리하기 때문에, 일반적인 캐시 시스템의 가장 큰 문제인 Purge 회수를 대폭 줄일 수 있습니다. 극단적으로, 존안의 캐시 사이즈를 모두 합한 것이, 오리진 서버의 용량과 같다면, Purge는 전혀 일어나지 않습니다. 일반 캐시 알고리즘에서는 캐시의 용량에 따라 지속적인 Purge가 일어납니다. 특히, 사이가 큰 미디어파일의 경우는 아래와 같은 강점을 가지게 됩니다. 일반적으로 사이즈가 큰 미디어파일은 Range request 를 통해 요청이 됩니다. 일반 캐시 알고리즘은 “Range” 를 캐싱하는 개념이 없으며 큰 사이즈의 미디어파일이 통째로 캐싱되는 개념입니다. 큰 사이즈의 파일을 Chunk 로 어떻게 관리할지는 CDN 에서 중요한 이슈 중에 하나로 다양한 알고리즘이 내부적으로 있을 것으로 보여지지만, 기본적으로는 캐시관리가 용이하지 않습니다. 패브리캐시는 기본 디자인상 이미 큰 파일을 컨텐츠 블럭 단위로 나누어서 관리하기 때문에, 컨텐츠 블럭 단위로 효과적으로 캐싱하게 됩니다. 아키텍처상의 장점 일반적인 캐싱서비스는, 웹 서버 (nginx or apache) 와 의존성을 가지는 어플리케이션 형태로 구현되어 있습니다. 이 때문에, 웹 서버 자체의 버전 업그레이드시 유지 보수를 위한 비용이 대단히 높습니다. 패브리캐시는 웹 서버와의 의존성없이, File I/O 레벨에서 구현이 이루어졌기 때문에, 웹 서버 업그레이드에 따른 사이드 이펙트가 전혀 없습니다. 유연성 2에서 n 개까지 자유롭게 그루핑이 가능합니다. 패브리캐시에서 캐시 하나 하나를 피어라고 지칭하는데, 어떤 피어가 무엇을 저장할지에 대한 다양한 알고리즘을 설정할 수 있습니다. 또한, 피어에 대한 페일오버 방식이 다양하게 제공되고, 설정할 수 있으며 다양한 업스트림 설정 방식을 지원합니다. Follow Published in Catenoid TechBlog 8 Followers ·Last published Jan 10, 2025 Welcome to Tech Blog of Catenoid, a global VTaaS (Video Technology as a Service) provider. Follow Subscribe Written by SeongBong An 1 Follower ·7 Following Subscribe No responses yet Help Status About Careers Press Blog Privacy Rules Terms Text to speech