[컴] wowza media cache 동작

캐쉬 동작 / 미디어 캐쉬 동작 / 동작 방법 /


그냥 참고로 media cache 동작 방식에 대한 글을 번역해 놓는다.

Wowza Media Cache

미디어 캐쉬(Mediacache) 는 streaming 에 인지할 수 있는 수준의 delay 를 만들지 않는다. 처음으로 어떤 video 를 request 할 때, 먼저, 그 video 의 metadata 를 보게 된다. 그리고 나서 cache 는 video file 크기 의 0 으로 채워진 파일(zero filled file)을 만들어서 그 video file 크기 만큼의 공간을 미리 잡아놓는다.

실제로 request 됐을 때 실제 file data 를 remote source 에서 가져온다. 그리고 그것을 local file 에 저장한다. 만약 다른 player 가 같은 video 를 request 하면, 먼저, chunk 들이 local 에 있는지 또는 지금 request 되고 있는지 를 확인하고 없으면 remote file 로 부터 그것들을 요청한다.

remote chunk 들을 가져오는것에 대한 delay 는 remote server 의 request 를 서비스하는데 걸리는 시간이 될 것이다. 만약 server 가 같은 network 에 있다면 눈에띄는 delay 는 없을 것이다. request chunk size 는 storage system 과 network 에 맞게 조절할 수 있다.

content 추가시 동작

content 가 cache 에 추가될 때 아래와 같은 일을 하게 된다.
cache 가 최근에 access 되지 않은 old file 을 flush 하려고 시도한다. 관련해서 2개의 TTL setting 이 있다.

• MaxTimeToLive
• MinTimeToLive

보통의 동작에서, 마지막으로 access 된 때 부터 max TTL setting 을 기준으로 오래된 content 는 제거된다.

새로운 content 의 조각이 cache 에 추가될 필요가 있을 때, 먼저 공간이 충분히 있는지 살피는 데, 이 때 공간이 충분하지 않으면 old content 를 제거해서 공간을 확보한 후 더하게 된다. 이때 old content 를 제거할 때 Min TTL setting 을 기준으로 충분한 공간이 확보될 때까지 제거하게 된다.


새로운 content 를 위한 충분한 공간이 확보될 수 없으면, 새로운 content 는 cache 에 추가되지 않는다. 대신, 그 file 에 대해서 cache 는 bypass 되어지고 , 대신에, player 에서 오는 request 는 source 로 바로 가게 된다. 이 request 들은 player 가 request 하는 size 가 되는데, 대체로 cache 가 request 는 하는 size 보다는 작다.

storage server 가 Wowza 가 직접 access 하는 networked partition 처럼 set 되어 있으면, storage server 관점에서 보게되는 것은 크게 다르지 않다.

어떤 여분의 delay 가 추가되지 않겠지만 storage server와 network 에 부하가 좀 더 걸릴 지도 모른다.

MediaCacheStores 의 size

생산환경에서, 동시에 service 될 것으로 생각되는 unique content 의 양에 근거해서 MediaCacheStores 의 size 를 잡아야 한다.

만약 100 개의 1GB 파일들을 가지고 있고, 그중에 50개가 동시에 시청될 것이라고 생각된다면 적어도 cache 사이즈를 50GB 로 잡아야 한다. 만약 10개만 동시에 시청될 것 이라고 예상된다면 10GB 만 잡아도 된다.

이것은 이론적인 값이고, 실제로는 cache 장치가 item 에 대한 cache 관련 정보를 저장해야 해서 item 당 몇 KB 가 추가적으로 필요하다.

파일시스템이 configuration 에 설정된 store size 보다 더 많은 가용 공간을 가지고 있다면 서버를 restart 를 할 필요없이 JMX interface 를 사용해서 server 가 running 중에도 store size 를 조정하는 것이 가능하다. 새로운 setting 은 Mediacache.xml 파일에도 넣어놔야만 한다. 그래야 restart 할 때 다시 적용되기 때문이다.

SSD, memory tmpfs

많은 사람들이 사용하는 방법은 분리된 SSD drive 모두를 cache 로 사용하는 것이다.
다른 방법은 만약 충분한 free memory 가 있다면, memory 를 이용한 tmpfs partition 을 사용하는 것이다. 이것은 SSD drive 보다 빠를 것이다.
Tmpfs 는 swap space 를 이용한다. 그래서 swap space 가 충분히 큰 상태인 경우에는 memory allocation 과 관련된 문제들이 없다.

tmpfs 파티션과 함께 swap 으로 설정된 SSD drive 를  사용하면 최고의 Mediacache store 가 될 것이다.

Sources (file based or http-based)

Mediacache 의 다른 중요한 점은 어떻게 source 들이 access 되는 가 이다.
Mediacache 는 file 을 기반으로 source 들 에서 읽어드릴 것이다. (local file system, NFS, CIFS 등) 또는 Apache 또는 IIS web server 또는 Amazon S3 또는 OpenStack 같은 HTTP 를 기반으로 한 source 들에서 읽어드릴 것이다.

만약 storage server 가 wowza server 의 local 이라 하더라도, storage server 가 networked file system 보다 HTTP 를 사용하도록 설정하는 것을 추천한다. 왜냐하면 network problem 에 비해 좀 더 회복력이 좋기 때문이다. NFS 는 link 가 down 된다면 server lockup 들을 유발할 수 있다. 그러나 HTTP 를 이용하면 connection 이 몇 초 후 그냥 timeout 될 것이다.

원본

출처 : http://www.wowza.com/forums/content.php?121-How-to-get-MediaCache-AddOn-(scale-video-on-demand-streaming)&page=2#comments

1) Mediacache should not add any perceivable delays to the streaming. When a video is first requested, the video metadata (size etc) is grabbed first and then the cache reserves that amount of space for the file by creating a zero filled file of the same size. It only gets the actual file data from the remote source at the time it is actually requested and saves it in the local file. If another player requests the same video, it first looks to see if the chunks are already local or currently being requested and if not then requests them from the remote file. The delay in getting the remote chunks would be the time it takes to service the request to the remote server. If the server is on the same network then there should be no noticeable delay. The request chunk size can be tuned to suit your storage system and network.
2) When content is added to the cache, the following will happen.
The cache will attempt to flush old files that have not been accessed recently. There are two TTL settings, MaxTimeToLive and MinTimeToLive. In normal operation, the old content is removed based on the Max TTL setting from when it was last accessed. When a new piece of content needs to be added to the cache, it first checks if there is enough space. If not then it will attempt to flush old content based on the Min TTL setting until there is enough space freed up and then it will be added.
If enough space cannot be freed for the new content then it is not added to the cache. Instead, the cache is bypassed for the entire file and instead, the requests from the players go directly to the source. These requests are at the size that the player requests and are normally a lot smaller than the cache requests. From your storage server perspective, it would be no different to what you would see if the storage server was set as a networked partition that Wowza accesses directly. Existing content in the cache would still make requests as normal.
It shouldn't add any extra delays but it may put more load on your storage server and network.
In a production environment, you should size the MediaCacheStores based on the amount of unique content you expect to be serving at the same time. If you have 100 1GB files and you expect that 50 of them may be watched at the same time then you would set your cache to be at least 50GB. If you only expect 10 to watched at the same time then you could set the cache size to 10GB. These are theoretical figures. The cache mechanism does add a few extra KB per item to store it's own information about the item.
If the file system has more space available that the store size set in the configuration then it is possible adjust the store size while the server is running without having to restart by using the JMX interface. The new setting should be put into the Mediacache.xml file so that it will be used on restart.
What a lot of people do though is use a separate SSD drive and set the cache to use the entire partition. Another suggestion, if there is enough free memory, is to use a memory based tmpfs partition which would be even faster than an SSD drive. Tmpfs uses swap space so there shouldn't have problems with memory allocation, as long as the swap space is large enough. Having an SSD drive configured for swap along with a tmpfs partition would make an excellent Mediacache store.
Another important aspect with Mediacache is how the sources are accessed. MediaCache will read from file based sources (local file system or NFS, CIFS etc) or from HTTP based sources such as an Apache or IIS web server or Amazon S3 or OpenStack. Even if the storage server local to the wowza servers, we recommend configuring your storage server to use HTTP rather than a networked file system as it is more resilient to network problems. NFS can cause server lockups if the link goes down but with HTTP, the connection will just timeout after a few seconds.