WO2019088721A1 - 오픈형 생중계 플랫폼 - Google Patents

오픈형 생중계 플랫폼 Download PDF

Info

Publication number
WO2019088721A1
WO2019088721A1 PCT/KR2018/013152 KR2018013152W WO2019088721A1 WO 2019088721 A1 WO2019088721 A1 WO 2019088721A1 KR 2018013152 W KR2018013152 W KR 2018013152W WO 2019088721 A1 WO2019088721 A1 WO 2019088721A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
pool
streaming data
allocated
broadcast
Prior art date
Application number
PCT/KR2018/013152
Other languages
English (en)
French (fr)
Inventor
오재원
윤병조
박기영
양승관
노혜성
김종주
Original Assignee
네이버 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 네이버 주식회사 filed Critical 네이버 주식회사
Publication of WO2019088721A1 publication Critical patent/WO2019088721A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
    • H04N21/2225—Local VOD servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation

Definitions

  • the following description relates to open live live platform technology, and more particularly to a system for an open live live platform and a method for operating the live live live platform.
  • Korean Patent Laid-Open Publication No. 10-2014-0115661 discloses a method, a server, and a system for providing a bi-directional live streaming service to a plurality of user terminals.
  • a live broadcast platform for relaying various viewers who wish to view live broadcasts of various senders and senders who want to broadcast the broadcast, such as a personal broadcast live broadcast service that enables a person to broadcast a video.
  • each sender transmits its own streaming data to a relay server assigned to the sender, and the assigned relay server can encode the received streaming data and send it to viewers.
  • a relay server for transmitters when transmitters register broadcasts, a relay server for transmitters must be allocated, and transmit addresses for the assigned relay servers are provided to senders. In this case, the relay server must be prepared in a state in which the resources are allocated to process broadcast transmission irrespective of whether or not the transmission is performed.
  • the time occupied by the resources of the relay server by registering the broadcasts of the senders does not coincide with the time when the broadcasts of the actual senders are transmitted, the resources of the relay server in which the broadcast is registered even when the actual broadcast is not transmitted.
  • the resources allocated for the broadcast are wasted. For example, if it is assumed that ten relay servers can be allocated for registering three broadcasts each, the number of registers that can be registered is fixed to 30. At this time, even if all 30 broadcasts are not broadcasting, a new relay server is required to register a new broadcast.
  • Such a live streaming platform of the related art is not suitable for an open live streaming service in which arbitrary broadcasts can be generated, not a fixed number of broadcasts, and even if a service is provided, the relay servers are inefficiently used, There is a problem.
  • such a live streaming platform of the related art has a problem that it is difficult to cope with a failure of a relay server.
  • a failure occurs in the relay server 1
  • all the broadcasts assigned to the relay server 1 are not transmitted.
  • the time for resolving the failure will be longer.
  • a complicated process is required to notify the senders of the failure of the relay server 1 and register the broadcast again to notify the sender of the address of the new relay server.
  • the processing time for such a failure recovery becomes longer, There is a possibility of causing a serious problem that the live broadcast can not be transmitted in time.
  • a live streaming platform system capable of dynamically allocating resources at the time of actual broadcast transmission through a logical streaming cloud, and a method of operating the open live streaming platform.
  • the present invention provides a system of an open live streaming platform and a method of operating the open live streaming platform in which all servers can be efficiently utilized without having to wait for a predetermined broadcast state in advance in accordance with the allocation.
  • a live streaming platform system capable of automatically restoring a new publishing point server or an encoding server in a pool of servers in case of a failure of a publishing point server or an encoding server, and a method of operating the open live streaming platform.
  • a logical streaming cloud can be implemented for each region or region separated by a country or region and servers of a logical streaming cloud can be managed through a coordination system. Also, when broadcasting and viewing are performed between different regions, A system of an open live streaming platform capable of minimizing a user interval with a slow network speed through acceleration, and a method of operating the open live streaming platform.
  • the open-type live-broadcast platform can provide a plurality of broadcasts to the viewers of the service.
  • a system for an open-ended live-broadcast platform comprising: a first server pool for managing at least one first server for receiving streaming data sent from a sender terminal; A second server pool for managing at least one second server for receiving and encoding the streaming data from a first server allocated in the first server pool; And a coordinator for managing the statuses of the servers of the first server pool and the second server pool and dynamically allocating a second server in the second server pool according to a request of the first server allocated in the first server pool, In response to the streaming data being transmitted from the terminal of the sender, dynamically allocates an arbitrary first server in the first server pool, and receives the streaming data through the allocated first server And a system for an open-type live-broadcast platform.
  • a method of operating an open live streaming platform comprising: receiving an allocation request for a second server for encoding the streaming data from any first server assigned in a first server pool in response to streaming data being sent from a sender terminal ; And dynamically allocating an arbitrary second server in a second server pool according to the received allocation request, wherein the dynamically allocated second server receives the streaming data from the first server and encodes
  • the method comprising the steps of:
  • a computer readable recording medium having recorded thereon a program for causing a computer to execute the operation method.
  • Logical streaming Clouds can dynamically allocate resources at the point in time when broadcasts actually occur.
  • coordinator dynamic and autonomous coordination system
  • a new publishing point server or an encoding server is reallocated from a pool of servers, thereby automatically recovering a failed server.
  • a logical streaming cloud can be implemented for each region or region separated by a country or region and servers of a logical streaming cloud can be managed through a coordination system. Also, when broadcasting and viewing are performed between different regions, Acceleration can minimize the user interval with slow network speed.
  • the physical machine can be used stably and efficiently by dynamically adjusting the number of encoding servers to be operated on one physical machine according to the encoding performance of the physical machine.
  • Priority can be assigned to each channel, and broadcasting of the important channel can be guaranteed by using the assigned wire rank.
  • FIG. 1 is a view showing an example of the overall configuration of an open type live broadcast platform according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of a configuration of a live streaming farm according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating an example of load balancing of an L4 switch according to an embodiment of the present invention.
  • FIG. 4 is a diagram showing an example of the configuration of an encoder server pool according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating an example of a configuration of a VOD farm according to an embodiment of the present invention.
  • 6 to 8 are views showing an example of a method of operating an open-type live broadcast platform according to an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating an example of a broadcast address and a viewing address for live broadcast in an embodiment of the present invention.
  • FIG. 10 is a diagram illustrating an example of a process of processing a broadcast transmission request according to an embodiment of the present invention.
  • FIG. 11 is a diagram illustrating an example of an encoding process in an embodiment of the present invention.
  • FIG. 12 is a diagram illustrating an example of a process in which each server is dynamically allocated in an embodiment of the present invention.
  • FIG. 13 and 14 are views showing an example of an autonomous failure recovery process for a publishing point server in an embodiment of the present invention.
  • 15 and 16 are diagrams showing an example of a process of autonomous failure recovery for an encoder server in an embodiment of the present invention.
  • FIG. 17 is a diagram illustrating an embodiment of an open type live broadcast platform according to an embodiment of the present invention.
  • 18 is a diagram for explaining an example of proxy acceleration in an embodiment of the present invention.
  • 19 is a diagram for explaining the concept of a multi-tenant of an open-type live streaming platform in an embodiment of the present invention.
  • FIG. 20 is a flowchart illustrating an example of an operation method of an open type live broadcast platform according to an embodiment of the present invention.
  • FIG. 21 is a flowchart illustrating an example of a failure recovery method of an open type live broadcast platform according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating an example of the configuration of a live streaming farm according to an embodiment of the present invention.
  • FIG. 2 is a view showing an example of a configuration of a live streaming farm according to an embodiment of the present invention.
  • 3 is a diagram illustrating an example of load balancing of an L4 switch according to an embodiment of the present invention
  • FIG. 4 is a diagram illustrating an example of a configuration of an encoder server pool according to an embodiment of the present invention.
  • 5 is a diagram illustrating an example of the configuration of a VOD farm according to an embodiment of the present invention.
  • the open live streaming platform 100 includes a live streaming farm 110, a coordinator 120 and a video on demand (VOD) farm 130 as shown in FIG. can do.
  • VOD video on demand
  • the live streaming palm 110 may process the streaming data transmitted from the sender 140 and relay the streaming data to the viewer 150.
  • the live streaming palm 110 includes a first L4 switch 210, a publishing point server pool 220, an encoder server pool 230, A Distributed File System 240, a Proxy Server Pool 250, and a second L4 switch 260.
  • the sender 140 and the viewer 150 may refer to a plurality of senders and a plurality of viewers, Quot; may mean a terminal of a sender for transmitting a broadcast and a terminal of a viewer for receiving a broadcast.
  • the first L4 switch 210 may be utilized for load balancing of a plurality of publishing point servers 310 included in the publishing point server pool 220, as shown in FIG. For example, the first L4 switch 210 may determine which of a plurality of publishing point servers 310 transmits the streaming data sent from the sender 140 to the publishing point server.
  • the publishing point server pool 220 is a pool of a plurality of publishing point servers 310, and each of the publishing point servers is connected to a sender (not shown) via the first L4 switch 210 140 and may transmit streaming data to an encoder server included in the encoder server pool 230.
  • one publishing point server can process a plurality of transmission requests.
  • one publishing point server may be implemented as one physical machine, but a plurality of publishing point servers may be implemented on one physical machine. For example, if three physical machines are each implemented to include three publishing point servers, a total of nine publishing point servers may be included in the publishing point server pool 220.
  • the publishing point server pool 220 includes three publishing point servers in FIG. 3, the publishing point server may be freely added to the publishing point server pool 220 or the publishing point server pool 220, .
  • the encoder server pool 230 may be a pool including a plurality of encoder servers 410 as shown in FIG. 4, the encoder server may be freely added to the encoder server pool 230 as needed or may be added to the encoder server pool 230 ). Also, each of the plurality of encoder servers 410 may be implemented as one physical machine as described above, but may be implemented to include a plurality of encoder servers on one physical machine. For example, if three physical machines each include four encoder servers, then a total of twelve encoder servers may be included in the encoder server pool 220.
  • one physical machine may be implemented to include at least one publishing point server and at least one encoder server.
  • the publishing point server, the encoder server, and the proxy server which will be described later, may be implemented in the form of separate physical machines, or a plurality of servers may be included in one physical machine .
  • Each of the plurality of encoder servers 410 may be implemented as a pair of one encoder server and one uploader.
  • FIG. 4 shows an example in which one encoder server is implemented as a pair of encoder server 1 (411) and uploader 1 (412).
  • the encoder server may encode the streaming data received from the publishing point server into a predetermined profile. For example, when providing a live broadcast to the viewer 150 using an HTTP Live Streaming (HLS) algorithm, the encoder server may encode the streaming data received from the publishing point server to generate a Transport Segment have.
  • HLS HTTP Live Streaming
  • the uploader uploads the TS files generated as a result of the encoding to the distributed file system 240 included in the live streaming farm 110 and the distributed file system 520 included in the VOD farm 130 shown in FIG. can do.
  • the uploader stores the reproduction information file (for example, m3u8 file in the HLS (HTTP Live Streaming) algorithm) as the file storing the information on how to play back what kind of media and how to reproduce And upload it to the distributed file system 240 included in the live streaming farm 110.
  • the reproduction information file for example, m3u8 file in the HLS (HTTP Live Streaming) algorithm
  • the playback information file according to the service type includes a playback information file (for example, m3u8 file for time machine) for providing time machine function, a playback information file (for example, m3u8 file for live) and / (For example, a m3u8 file for VOD) for the playback apparatus.
  • a playback information file for example, m3u8 file for time machine
  • a playback information file for example, m3u8 file for live
  • / For example, a m3u8 file for VOD
  • Distributed file system 240 may store and provide encoded files (e.g., TS files) and playback information files (e. G., M3u8 files) for streaming to viewer 150.
  • encoded files e.g., TS files
  • playback information files e.g., M3u8 files
  • the proxy server pool 250 may include a plurality of proxy servers.
  • the proxy server selected through the second L4 switch 260 receives an external streaming request and delivers the streaming request to the distributed file system 240 can do.
  • the distributed file system 240 may forward stored files (e.g., encoded files (e.g., TS files) and playback information files (e.g., m3u8 files)) in accordance with the delivered external streaming request
  • stored files e.g., encoded files (e.g., TS files) and playback information files (e.g., m3u8 files)
  • a live broadcast service can be provided to the viewer 150.
  • the coordinator 120 manages the statuses of servers included in the open-type live-broadcast platform 100, allocates an encoder server, and manages the overall status and settings of the open-live live-broadcast platform 100, .
  • the servers included in the open-type live broadcast platform 100 may register themselves in the run-time coordinator 120, and the coordinator 120 may manage the registered servers.
  • the coordinator 120 may allocate an encoder server at the request of the publishing point server.
  • the coordinator 120 may be implemented using a Zookeeper system, which is a framework for providing auxiliary functions such as information sharing, lock, and event among nodes in a distributed environment.
  • the VOD palm 130 may include a VOD generation pool 510, a distributed file system 520, and a VOD file generation unit 520.
  • the VOD generation unit 520 may generate and store a VOD file of a live video image and provide a VOD service.
  • the VOD generation pool 510 can download the encoded files (for example, TS files) from the distributed file system 520 to generate a VOD file (for example, an MP4 file) have. In addition, the VOD generation pool 510 can upload the generated VOD file back to the distributed file system 520.
  • the VOD generation pool 510 may include a plurality of VOD generation servers.
  • the distributed file system 520 may store and provide the encoded files for the VOD file and the VOD file generated by the VOD generation pool 510.
  • the proxy server pool 530 may include a plurality of proxy servers.
  • the third L4 switch 540 may select one of the plurality of proxy servers included in the proxy server pool 530 to transmit an external VOD file request,
  • the proxy server can forward an external VOD file request to the distributed file system 520.
  • the distributed file system 520 can externally provide the requested VOD file through the proxy server.
  • 6 to 8 are views showing an example of a method of operating an open-type live broadcast platform according to an embodiment of the present invention.
  • the process (1-1) may be an example of a process in which the sender 140 transmits streaming data to the first L4 switch 210.
  • the first L4 switch 210 selects any of the publishing point servers 610 included in the publishing point server pool 220 and transmits the transmission request to the selected publishing point server 610 It can be an example of a process.
  • the process (1-3) may be an example of a process in which the publishing point server 610 requests the coordinator 120 to allocate any one of the encoder servers included in the encoder server pool 230 for streaming.
  • Processes 1-4 illustrate that the coordinator 120 selects any encoder server 620 to be used for streaming in the encoder server pool 230 and sends information about the publishing point server 610 along with the streaming start event to the selected encoder To the server 620. [0060] FIG.
  • the process 1-5 is an example of a process in which the encoder server 620 selected by the coordinator 120 accesses the publishing point server 610 to receive streaming data and encodes the received streaming data into a predetermined profile have.
  • the process (1-6) is a process in which the encoder server 620 stores the encoded data (for example, the TS files generated according to the encoding) in a specified path (for example, the temporary storage 630 shown in FIG. 6) Yes.
  • the encoder server 620 stores the encoded data (for example, the TS files generated according to the encoding) in a specified path (for example, the temporary storage 630 shown in FIG. 6) Yes.
  • FIG. 7 shows steps (1-7) to (1-10) of the entire processes (processes (1-1) to (1-10) for live streaming.
  • the processes (1-6) and (1-7) may be connected through (A) shown in FIG. 6 and FIG.
  • the process 1-7 is a process in which the uploader 710 obtains the encoded data (TS files) from the temporary storage 630 shown in Fig. 6, and reproduces the reproduction information file corresponding to the encoded data (m3u8 Files) in the file system. As previously described, the uploader 710 may pair with the encoder server 620.
  • the uploader 710 uploads the encoded data to the distributed file system 240 of the live streaming farm 110 and the distributed file system 520 of the VOD farm 130, respectively, And may be an example of a process of uploading the playback information file to the distributed file system 240 of the live streaming farm 110.
  • the process of uploading the encoded data to the distributed file system 520 of the VOD farm 130 may be connected through (C) shown in FIG. 7 and FIG.
  • the proxy server 720 which is a selected one of the proxy servers included in the proxy server pool 250, transmits the encoded data from the distributed file system 240 of the live streaming farm 110, And receiving the request.
  • the process (1-10) may be an example of a process of delivering the encoded data and the playback information file received by the proxy server 720 to the viewer 150 and proceeding to live streaming.
  • FIG. 8 shows the entire processes (processes (2-1) to (2-5)) for generating a VOD file and providing a VOD service.
  • This Fig. 8 can be connected to Fig. 6 and Fig. 7 through (B) and (C).
  • the VOD generation server 810 which is one of the VOD generation servers included in the VOD generation pool 510, may receive a VOD generation request from the coordinator 120.
  • the process 2-2 may be an example of a process in which the VOD creation server 810 downloads encoded data to generate a VOD file from the distributed file system 520 included in the VOD farm 130.
  • the encoded data may be data stored in the distributed file system 520 by the uploader 710 through the process (1-8) of FIG.
  • the process (2-3) may be an example of a process of creating a VOD file using the downloaded data by the VOD creation server 810 and uploading the created VOD file to the distributed file system 520.
  • the proxy server 820 which is one of the proxy servers included in the proxy server pool 530, downloads the VOD file from the distributed file system 520 at the request of the VOD requester 830 .
  • the process (2-5) may be an example of a process in which the proxy server 820 provides the VOD file downloaded to the VOD requester 830.
  • a VOD file for live streaming broadcasting can be generated and provided through the processes (2-1) to (2-5).
  • the open-loop live-broadcast system according to embodiments of the present invention has the following features 1 through 6.
  • the sender 140 In order to transmit a broadcast using the open type live broadcast system 100 according to the embodiments of the present invention, the sender 140 must register the broadcast. At this time, when a broadcast is registered, one channel can be created, and a stream key necessary for broadcasting can be provided to the generated channel. The sender 140 can always send a broadcast to the same address using this stream key and the open live streaming system 100 can always provide the viewer 150 with a broadcast of the corresponding channel at the same address. In other words, the sender 140 can always broadcast the same address, and the viewer 150 can always watch the specific broadcast of the sender 140 at the same address.
  • FIG. 9 is a diagram illustrating an example of a broadcast address and a viewing address for live broadcast in an embodiment of the present invention.
  • 9 is a diagram illustrating an example of a broadcast address 'rtmp: //' generated using a stream key 'xyzc123' assigned to a sender 140 when a sender 140 transmits a broadcast using RTMP (Real Time Messaging Protocol) tv.bbb.com/xyzc123 "
  • 9 is a view showing the viewing address 'http: // streamfarm.' Generated using the name 'aaa' of the sender 140 when the viewer 150 watches the broadcast using the HLS (HTTP Live Streaming) protocol. quot; bbb.com/aaa.m3u8 ". Accordingly, the viewer 150 can access a specific broadcast in a concept similar to the concept of viewing a broadcast of a specific broadcast station of the TV on a specific channel.
  • HLS HTTP Live Streaming
  • the channel generated at the time of broadcast registration only generates information about the broadcast and is not connected to the physical server, there is no limit to the number of generations, and the increase in the number of generations does not affect the system at all. In other words, even if a channel is created, resources of the open-type live-broadcast platform 100 are not allocated for the channel.
  • the time at which resources of the open-type live broadcast platform 100 are used is a time point when broadcast transmission occurs. This structure is very suitable for an open-type live service structure in which a plurality of transmitters register a plurality of broadcasts and have a short actual broadcast time Do.
  • the servers of the open type live broadcast platform 100 are dynamically allocated at the time of transmission and remain in a standby state in the pool until transmission occurs.
  • any publishing point server is selected in the publishing point server pool 220 by the L4 switch (first L4 switch 210) and the encoding server pool 230 is selected by the coordination 120.
  • An encoder server may be selected in accordance with an encoder server selection algorithm.
  • the encoder server selection algorithm is shown in (a), (b), and (c) below.
  • an encoder server that is transmitting a broadcast of a channel having a lower priority than the channel requesting broadcast transmission is selected.
  • the selected encoder server classifies the operation of the channel currently being processed and processes the transmission request of the newly requested broadcast.
  • the open-type live-broadcast platform 100 can autonomously process a broadcast transmission request at each step without centralized control.
  • FIG. 10 is a diagram illustrating an example of a process of processing a broadcast transmission request according to an embodiment of the present invention.
  • the embodiment of FIG. 10 is similar to the embodiment of FIG. 10 except that the first L4 switch 210 selects the publishing point server 1 1010 according to a broadcast transmission request from the sender 140, As shown in Fig.
  • the broadcasting point server 1 1010 selected in the embodiment of FIG. 10 notifies the coordinator 120 of the requested broadcast and confirms whether the requested broadcast is a normal broadcast registered through the coordinator 120, 140 of the broadcast stream.
  • the coordinator 120 may allocate an encoder server for the publishing point server 1 1010 in response to a broadcasting transmission request for normal broadcasting.
  • 11 is a diagram illustrating an example of an encoding process in an embodiment of the present invention.
  • the coordinator 120 selects an encoder server in response to a broadcast transmission request for normal broadcasting (in the embodiment of FIG. 11, the encoder server 1 1110), and the operation list of the selected encoder server 1 1110
  • An example of registering a broadcast transmission job is shown.
  • each of the encoder servers in the standby state can monitor their task list.
  • the encoder server 1 1110 monitors the 'operation list 1 of the encoder server 1' 1120, which is its own operation list, and uses the registered information as the broadcast transmission job is registered by the coordinator 120 To receive the streaming data, and to perform an encoding operation on the received streaming data.
  • the encoder server 1 1110 can identify the publishing point server 1 1010 through the registered information, and can request the streaming data to the identified publishing point server 1 1010.
  • the publishing point server 1 1010 may transmit the streaming data received from the sender 140 via the first L4 switch 210 to the encoder server 1 1110 according to a request from the encoder server 1 1110.
  • the encoder server 1 1110 can encode the streaming data received from the publishing point server 1 1010.
  • FIG. 12 is a diagram illustrating an example of a process in which each server is dynamically allocated in an embodiment of the present invention.
  • the processes (1), (2), (3), (4) and (5) shown in FIG. 12 may correspond to the processes (1-1) to (1-5) described above with reference to FIG.
  • the process (1) may be an example of a process in which the sender 140 attempts to broadcast.
  • the process (2) may be an example of a process in which the first L4 switch 210 selects a publishing point server 1210, which is one of the publishing point servers included in the publishing point server pool 220, and transmits a transmission request.
  • the process 3 may be an example of a process in which the publishing point server 1210 receiving the transmission request requests allocation of the encoding server while registering the broadcast transmission request to the coordinator 120.
  • the process 4 may be an example of a process in which the coordinator 120 selects one of the encoder servers included in the encoder server pool 230 and registers the streaming request information.
  • registering the streaming request information may correspond to registering a broadcasting transmission job in the job list of the selected encoder server 1220 as described with reference to FIG.
  • the process (5) is a process in which the encoder server 1220 accesses the publishing point server 1210 to request streaming data, receives the requested streaming data from the publishing point server 1210, and encodes the streaming data according to a preset profile . At this time, the encoder server 1220 can generate a TS file for each image quality.
  • the assigned publishing point server 1210 and the encoder server 1220 wait in the publishing point server pool 220 and the encoder server pool 230 in a standby state, which is available again.
  • the publishing point server and the encoder server are dynamically allocated only when broadcast transmission actually occurs, the server for a specific broadcast needs to wait in a pre-reserved state So all servers can be used efficiently.
  • the capacity of the open live live platform 100 can be increased by adding the server to each server pool, the capacity of the open live live platform 100 can be easily increased.
  • the publishing point server and the encoder server are separated from each other, and since the server is not associated with a specific channel, the abnormal operation can be quickly recovered.
  • FIG. 13 and 14 are views showing an example of an autonomous failure recovery process for a publishing point server in an embodiment of the present invention.
  • FIG. 13 shows a processing of a situation in which the publishing point server 1210 described above with reference to FIG. 12 abnormally terminates. If the publishing point server 1210 is abnormally terminated, the coordinator 120 can detect the abnormal termination of the publishing point server 1210 and transmit the same to the encoder server 1220 allocated to the publishing point server 1210 You can pass an end event. In this case, the encoder server 1220 can be switched to a standby state for another broadcast (streaming).
  • FIG. 14 shows that when the sender is retried by the sender 140, another publishing point server 1410 is selected by the first L4 switch 210 and the coordinator 1410 is requested by another publishing point server 1410 The streaming is resumed by the publishing point server 1410 and the encoder server 1420 according to the allocation of the new encoder server 1420.
  • the same process as that of the first transmission request is performed according to the transmission re-transmission, thereby enabling the failure recovery.
  • 15 and 16 are diagrams showing an example of a process of autonomous failure recovery for an encoder server in an embodiment of the present invention.
  • FIG. 15 shows processing in a situation where the encoder server 1220 described in FIG. 12 has abnormally terminated.
  • the coordinator 120 can detect the abnormal termination of the encoder server 1220 and try to allocate another encoder server that is currently assignable.
  • 16 shows that the dispatch is resumed through the publishing point server 1210 and the new encoder server 1420 as the coordinator 120 assigns a new encoder server 1420 to the publishing point server 1210, It can be recovered.
  • the streaming method between the publishing point server and the encoder server is a method (Pull method) in which the assigned encoder server accesses the corresponding publishing point server and receives the streaming data. Therefore, And it is not required to perform the same operation as the dispatch retry.
  • an uploader for example, an uploader paired with the encoder server 1420 in Fig. 16
  • the open-type live-broadcast platform 100 can identify a country or region unit as a region, and configure live streaming farms according to the region.
  • FIG. 17 is a diagram illustrating an embodiment of an open type live broadcast platform according to an embodiment of the present invention.
  • 17 shows a first live streaming farm 1710 and a first VOD farm 1720 implemented in a zone of a first country and a second live streaming farm 1730 implemented in a zone of a second country, 1720 are connected to the coordinator 120, respectively.
  • broadcasting and viewing can be performed in different areas.
  • the concept of proxy acceleration may be used for fast broadcast streaming.
  • Proxy acceleration is a method of providing a streaming service by minimizing a slow user interval when a transmission and viewing area are different from each other, and by using a high-speed server-dedicated line section.
  • 18 is a diagram for explaining an example of proxy acceleration in an embodiment of the present invention.
  • 18 shows a broadcast of a sender 1810 of a first country via a publishing point server pool 1820, an encoder server pool 1830, a distributed file system 1840 and a proxy server 1850 implemented in the first country To the first viewer 1860 located in the first country.
  • a white arrow indicates a user network section
  • a gray arrow indicates a server-to-server network section
  • a black arrow indicates a server-dedicated network section between regions.
  • the first viewer 1860 Since the first viewer 1860 is located in the first country, the first viewer 1860 can be provided with a fast broadcast stream through the proxy server 1850 as well.
  • the proxy server 1850 implemented in the first country quickly transmits the broadcast stream to the proxy server 1880 implemented in the second country through a dedicated line segment for proxy acceleration indicated by a black arrow,
  • the second viewer 1870 located in the second country can be provided with streaming service through the proxy server 1880 implemented in the second country.
  • the second viewer 1870 located in the second country can also quickly serve the broadcast stream of the sender 1810 of the first country.
  • the number of encoder servers that can operate in one physical machine can be set according to the encoding performance of the physical machine responsible for encoding. For example, assume that one physical machine can simultaneously encode 5 streaming data with 720p resolution, and that streaming data with 1080p resolution can encode only one at a time. In this case, in the open live streaming platform 100, five encoder servers are installed in the physical machine, and when streaming data having a resolution of 720p is encoded, the encoder servers can be allocated so that all five installed encoder servers operate . If one encoder server encodes the streaming data having a resolution of 1080p, the remaining four encoder servers can be controlled not to be allocated by the coordinator 120. [
  • the open type live broadcast platform 100 can be used simultaneously in different services, and each channel can belong to a specific service category at the time of creation. However, since the open-type live-broadcast platform 100 independently manages the streaming data irrespective of the service belonging to the channel, the open-live live-broadcast platform 100 can be used stably without interfering with each other at the same time.
  • FIG. 19 is a diagram for explaining the concept of a multi-tenant of an open-type live streaming platform in an embodiment of the present invention.
  • FIG. 19 shows that the senders of different services, such as the first service 1910, the second service 1920 and the third service 1930, are not broadcasting different senders using the same service, .
  • the live streaming farm 1940 according to the embodiments of the present invention independently manages each channel independently of the service (as described above, the sender is generated using a stream key allocated for one broadcast Broadcasts are transmitted through the same address, and viewers watch the broadcast through the same address assigned to view the broadcast), so that the broadcast can be relayed without interference between services.
  • the first service viewer 1950, the second service viewer 1960, and the third service viewer 1970 can receive broadcast streams of respective different services.
  • the open-type live-broadcast platform 100 can assign 'priority' to a channel in order to enable broadcasting of important broadcasts at any time while efficiently using servers.
  • the priority of a channel can be set at the time of channel creation and does not affect broadcast transmission at all under normal circumstances. However, in the absence of resources (servers) that can be used for broadcast transmission, it is possible to guarantee the transmission of the important broadcast by using the 'priority' assigned to the channel.
  • the open-live live-broadcast platform 100 transmits the new broadcast-
  • the user can terminate the transmission and service the broadcast transmission of the newly requested channel. This operation can guarantee broadcast transmission of important broadcasts even when all the resources (servers) of the present system are in use.
  • Priorities can be classified into a plurality of levels such as "Super”, “High”, “Low”, “Zero”
  • the open-type live-broadcast platform 100 includes a first server pool for managing at least one first server for receiving streaming data transmitted from a sender terminal, a first server pool A second server pool managing at least one second server for receiving and encoding the streaming data, and a second server pool managing the statuses of the servers of the first server pool and the second server pool, And a coordinator for dynamically allocating a second server in the second server pool according to a request from the first server.
  • the sender terminal corresponds to the sender 140
  • the first server pool corresponds to the publishing point server pool 220
  • the second server pool corresponds to the encoder server pool 230
  • the coordinator corresponds to the coordinator 120 have.
  • the open type live broadcasting platform 100 dynamically allocates an arbitrary first server in the first server pool, It is possible to receive streaming data.
  • the open-type live-broadcast platform 100 can dynamically allocate servers at the time of broadcast transmission of the sender, thereby efficiently utilizing the resources.
  • the coordinator generates a channel for broadcasting when the sender's broadcast is registered, and generates an outgoing address for transmitting streaming data of the broadcast using a unique key assigned to the channel
  • the open type live broadcast platform 100 can dynamically allocate any first server in the first server pool in response to the streaming data of the broadcast being transmitted through the broadcast address.
  • the streaming data can be always transmitted to the same transmission address for a specific broadcast.
  • a service may be provided so that viewers can always watch a specific broadcast through the same viewing address using the generated viewing address using information on the sender.
  • the coordinator may register a broadcast transmission job in the assigned list of tasks of the second server.
  • each of the at least one second server managed in the second server pool may monitor its own task list, and the second server, whose broadcast job is registered in its task list, Can identify the first server assigned in the first server pool and receive and encode the streaming data from the assigned first server.
  • the open-type live-broadcast platform 100 in response to the streaming data being transmitted from the terminal of the sender, dynamically selects an arbitrary first server in the first server pool and transmits the selected first server from the terminal of the sender And a switch for transmitting the streaming data to the selected first server.
  • a switch may correspond to the first L4 switch 210 described above.
  • At least one first server managed in the first server pool and at least one second server managed in the second server pool may be registered in the coordinator upon execution.
  • the coordinator may monitor the status of the registered at least one first server and at least one second server. This monitoring can be used to detect failures of the assigned first server or the assigned second server.
  • the coordinator when detecting the failure of the assigned first server, transmits a streaming end event to the allocated second server to switch the allocated second server to a standby state, As the streaming data is resent from the sender's terminal, a new second server can be allocated in the second server pool in response to a request from another first server assigned in the first server pool. In this case, because the streaming data is received and encoded through the other first server and the new second server, it is possible to cope with the failure of the existing first server.
  • the coordinator can allocate a new second server in the second server pool when detecting the failure of the second server.
  • the allocated new second server can access the allocated first server, receive the streaming data from the allocated first server, and encode the received streaming data.
  • the streaming data is received and encoded through the existing first server and the new second server allocated, it is possible to cope with the failure of the existing first server.
  • the assigned new server requests the streaming data in the pull method to the first server, the publishing point server as the first server does not need to consider failure or failure recovery of the encoder server as the second server do.
  • the open-type live-broadcast platform 100 includes a distributed file system for storing streaming data encoded by the dynamically allocated second server and a broadcast viewing request for the viewer terminal, And a third server pool for managing at least one third server for providing the streaming data to the viewer terminal.
  • the third server pool is connected to the proxy server pool 250 described with reference to FIG. 2
  • the viewer terminal is connected to the viewer 150 described with reference to FIG. 1 in the distributed file system 240, Can respond.
  • an arbitrary third server is dynamically allocated in the third server pool, and the encoded streaming data is distributed in the distributed file system through the allocated third server To the viewer terminal.
  • the open-type live-broadcast platform 100 dynamically selects an arbitrary third server in the third server pool in response to a broadcast viewing request of the viewer terminal and transmits the broadcast viewing request to the selected third server And a switch for transmitting the signal.
  • the switch may correspond to the second L4 switch 260 described with reference to FIG.
  • the first server pool, the second server pool, the distributed file system, and the third server pool may be configured for each region defined by at least one of a country and a region. This configuration allows to reduce user intervals with slow network speed for each zone.
  • dedicated lines may be connected between third servers in different zones.
  • the streaming data transmitted in the first zone is delivered to the first server in the first zone and encoded by the second server in the first zone, and the viewer, who is located in the first zone through the third server in the first zone Lt; / RTI > Further, the streaming data transmitted from the first zone may be further provided to the viewer located in the second zone via the third server in the second zone connected to the third server in the first zone with a dedicated line. Therefore, even when a viewer located in the second zone views a broadcast transmitted from the first zone, the user interval with a slow network speed can be minimized.
  • the open-type live broadcast platform 100 may include at least one fourth server for generating a VOD file using the streaming data encoded through the allocated second server in response to a VOD file creation request from the coordinator, And a fifth server pool for managing at least one fifth server for receiving a request for the VOD file from the requestor terminal and providing the generated VOD file to the requestor terminal in response to the request,
  • the fourth server pool may correspond to the VOD generation server pool 510 described above
  • the fifth server pool may correspond to the proxy server pool 540, respectively.
  • FIG. 20 is a flowchart illustrating an example of an operation method of an open type live broadcast platform according to an embodiment of the present invention.
  • the operation method according to the present embodiment may be performed by the coordinator 120 included in the open-type live-broadcast platform 100.
  • Coordinator 120 may be implemented by a physical machine that includes at least one processor and at least one memory.
  • step 2010 when the sender's broadcast is registered, the coordinator 120 generates a channel for broadcasting and generates an outgoing address for transmitting streaming data of the broadcast using a unique key allocated for the channel have.
  • step 2020 in response to the streaming data being transmitted from the sender terminal through the transmission address, the coordinator 120 transmits an allocation request of a second server for encoding the streaming data from any first server allocated in the first server pool Lt; / RTI >
  • the coordinator 120 may dynamically allocate an arbitrary second server in the second server pool according to the received allocation request.
  • the dynamically allocated second server can receive and encode the streaming data from the first server.
  • the coordinator 120 may register a broadcast transmission job for the streaming data to the job list of any second server in step 2030.
  • At least one second server managed by the second server pool can monitor its own task list.
  • the second server whose broadcast job is registered in its task list, To identify the first server assigned in the first server pool and to receive and encode the streaming data from the assigned first server.
  • the encoded streaming data may be stored in the distributed file system.
  • the encoded streaming data stored in the distributed file system may be downloaded from the third server dynamically allocated in the third server pool to the viewer terminal at the request of the viewer terminal .
  • the coordinator 120 may allocate any fourth server for generating a VOD file in the fourth server pool.
  • the allocated fourth server can generate the VOD file using the encoded streaming data.
  • FIG. 21 is a flowchart illustrating an example of a failure recovery method of an open type live broadcast platform according to an embodiment of the present invention.
  • the failure recovery method of FIG. 21 may be included in the method of operation of FIG. 20 and may be executed in parallel with the method of operation of FIG.
  • the coordinator 120 may monitor at least one first server managed in the first server pool and at least one second server managed in the second server pool. As described above, the coordinator 120 can manage the status of all the servers of the open-type live broadcast platform 100.
  • step 2120 the coordinator 120 may detect a failure of the first server. If a failure of the first server is detected, step 2130 is performed. If failure of the first server is not detected, step 2150 is performed .
  • the coordinator 120 may transmit a streaming end event to the allocated second server to switch the assigned second server to a standby state.
  • the second server in the standby state can wait for the encoding of another broadcast.
  • the coordinator 120 may allocate a new second server in the second server pool according to a request from another first server that is allocated in the first server pool as the streaming data is resent from the sender terminal .
  • the new second server may be an existing second server that has been switched to the standby state earlier, or may be a second server different from the existing second server.
  • the coordinator 120 may again perform step 2110 to monitor the status of the servers.
  • step 2150 the coordinator 120 may detect a failure of the second server. In this case, if a failure of the second server is detected, the coordinator 120 may perform step 2160, and if the failure of the second server is not detected, step 2110 may be performed again to monitor the status of the servers .
  • the coordinator 120 may assign a new second server in the second server pool.
  • the allocated new second server can access the allocated first server, receive the streaming data from the allocated first server, and encode the received streaming data.
  • the coordinator 120 may again perform step 2110 to monitor the status of the servers.
  • resources can be dynamically allocated at the time of actual broadcast transmission through the logical streaming cloud.
  • a publishing point server for processing an outgoing request at the time of occurrence of broadcast transmission without centralized control through a dynamic and autonomous coordination system (coordinator), and an encoding server for encoding streaming data of broadcasting are separately and It is possible to utilize all the servers efficiently without having to wait for the server in a reserved state in advance for a specific broadcast.
  • a new publishing point server or an encoding server is automatically reassigned from a pool of servers, thereby automatically recovering a failed server.
  • a logical streaming cloud can be implemented for each region divided by country or region, and servers of a logical streaming cloud of each country can be managed through a coordination system.
  • proxy acceleration can minimize the period of users with slow network speeds.
  • the coordination system the number of encoding servers to be operated on one physical machine is dynamically adjusted according to the encoding performance of the physical machine, so that the physical machine can be used stably and efficiently.
  • channels are independently managed for each broadcast independently of services, And provide each of the plurality of broadcasts provided by the respective users to the viewers of the corresponding service.
  • priority can be given to each channel, and broadcasting of the important channel can be guaranteed using the assigned wire rank.
  • the system or apparatus described above may be implemented as a hardware component, or a combination of hardware components and software components.
  • the apparatus and components described in the embodiments may be implemented within a computer system, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA) , A programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions.
  • the processing device may execute an operating system (OS) and one or more software applications running on the operating system.
  • the processing device may also access, store, manipulate, process, and generate data in response to execution of the software.
  • the processing apparatus may be described as being used singly, but those skilled in the art will recognize that the processing apparatus may have a plurality of processing elements and / As shown in FIG.
  • the processing unit may comprise a plurality of processors or one processor and one controller.
  • Other processing configurations are also possible, such as a parallel processor.
  • the software may include a computer program, code, instructions, or a combination of one or more of the foregoing, and may be configured to configure the processing device to operate as desired or to process it collectively or collectively Device can be commanded.
  • the software and / or data may be in the form of any type of machine, component, physical device, virtual equipment, computer storage media, or device As shown in FIG.
  • the software may be distributed over a networked computer system and stored or executed in a distributed manner.
  • the software and data may be stored on one or more computer readable recording media.
  • the method according to an embodiment may be implemented in the form of a program command that can be executed through various computer means and recorded in a computer-readable medium.
  • the computer-readable medium may include program instructions, data files, data structures, and the like, alone or in combination.
  • the medium may be one that continues to store computer executable programs, or temporarily store them for execution or download.
  • the medium may be a variety of recording means or storage means in the form of a combination of a single hardware or a plurality of hardware, but is not limited to a medium directly connected to a computer system, but may be dispersed on a network.
  • Examples of the medium include a magnetic medium such as a hard disk, a floppy disk and a magnetic tape, an optical recording medium such as CD-ROM and DVD, a magneto-optical medium such as a floptical disk, And program instructions including ROM, RAM, flash memory, and the like.
  • a recording medium or a storage medium managed by a site or a server that supplies or distributes an application store or various other software to distribute the application may be mentioned.
  • Examples of program instructions include machine language code such as those produced by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

오픈형 생중계 플랫폼 기술을 제공한다. 본 발명의 실시예들에 따른 오픈형 생중계 플랫폼을 위한 시스템은 논리적 스트리밍 클라우드를 통해 실제로 방송의 송출이 발생하는 시점에 동적으로 리소스를 할당할 수 있다.

Description

오픈형 생중계 플랫폼
아래의 설명은 오픈형 생중계 플랫폼 기술에 관한 것으로, 보다 자세하게는 오픈형 생중계 플랫폼을 위한 시스템 및 상기 오픈형 생중계 플랫폼의 동작 방법에 관한 것이다.
생중계는 실황을 동시적으로 중계 방송하는 일로서, 예를 들어, 한국공개특허 제10-2014-0115661호는 복수의 사용자 단말기에 양방향 현장 생중계 서비스를 제공하는 방법, 서버 및 시스템을 개시하고 있다.
또한, 누구나 방송국이 되어 영상을 송출할 수 있는 개인 방송 생중계 서비스와 같이, 방송의 송출을 원하는 다양한 송출자들과 송출자들의 생중계 방송들을 시청하고자 하는 다양한 시청자들을 중계하기 위한 생중계 플랫폼이 존재한다.
이러한 종래기술의 생중계 플랫폼에서는 송출자들 각각이 각자의 스트리밍 데이터를 해당 송출자에게 할당된 중계 서버로 전송하고, 할당된 중계 서버는 수신한 스트리밍 데이터를 인코딩하여 시청자들에게 송출할 수 있다. 이를 위해, 생중계 플랫폼에서는 송출자들이 방송을 등록할 때, 송출자들을 위한 중계 서버를 할당해야 하며, 할당된 중계 서버를 위한 송출 주소를 송출자들에게 제공한다. 이 경우, 중계 서버는 송출 여부와 상관없이 방송 송출을 처리하기 위해 리소스가 할당된 상태로 준비되어 있어야만 한다. 그러나, 송출자들의 방송을 등록하여 중계 서버의 리소스를 점유하는 시간과 실제 송출자들의 방송이 송출되는 시간이 일치하지 않기 때문에, 실제 방송이 송출되지 않는 동안에도 방송이 등록된 중계 서버의 리소스가 해당 방송을 위해 할당되어 있는 자원이 낭비가 발생한다. 예를 들어, 10 대의 중계 서버가 각각 3개의 방송의 등록을 위해 할당될 수 있다고 가정하면, 등록 가능한 방송의 개수는 30개로 고정된다. 이때, 30 개의 방송들이 모두가 방송을 송출하고 있지 않다고 하더라도, 새로운 방송을 등록하기 위해서는 새로운 중계 서버가 요구된다.
또한, 중계 서버들에 할당된 방송들에 대한 정보들을 중앙에서 별도로 계속 관리해줘야만 하기 때문에 시스템 전반을 관리하기 위한 부담이 크다는 문제점이 있다.
이러한 종래기술의 생중계 플랫폼은 고정된 수의 방송들이 아니라, 임의의 방송들이 생성될 수 있는 오픈형의 생중계 서비스에는 적합하지 않으며, 서비스를 제공한다 하더라도 중계 서버들이 비효율적으로 사용되기 때문에 비용이 많이 들게 되는 문제점이 있다.
또한, 이러한 종래기술의 생중계 플랫폼은 중계 서버의 장애에 대응하기 어렵다는 문제점이 있다. 예를 들어, 중계 서버 1에 장애가 발생하게 되면, 중계 서버 1에 할당된 모든 방송이 송출되지 않게 된다. 만약, 중계 서버 1이 구현되어 있는 물리적 머신의 장애라면 장애를 해결하기 위한 시간은 더욱 길어지게 될 것이다. 송출자들에게 중계 서버 1의 장애를 알리고, 다시 방송을 등록하여 새로운 중계 서버의 주소를 송출자에게 알려주는 등 복잡한 과정이 요구되며, 이러한 장애 복구를 위한 처리 시간이 길어짐에 따라 송출자들이 원하는 시간에 생중계 방송을 송출하지 못하는 심각한 문제점까지 발생할 가능성이 존재한다.
논리적 스트리밍 클라우드를 통해 실제로 방송의 송출이 발생하는 시점에 동적으로 리소스를 할당할 수 있는 오픈형 생중계 플랫폼의 시스템 및 상기 오픈형 생중계 플랫폼의 동작 방법을 제공한다.
동적이고 자율적인 코디네이션 시스템(코디네이터)을 통해 중앙 집중적인 제어 없이 방송 송출이 발생하는 시점에 송출 요청을 처리하기 위한 퍼블리싱 포인트 서버와 방송의 스트리밍 데이터를 인코딩하기 위한 인코딩 서버를 개별적으로, 그리고 동적으로 할당함에 따라 미리 특정 방송을 위해 서버가 예약된 상태로 대기할 필요 없이 모든 서버들을 효율적으로 활용할 수 있는 오픈형 생중계 플랫폼의 시스템 및 상기 오픈형 생중계 플랫폼의 동작 방법을 제공한다.
퍼블리싱 포인트 서버나 인코딩 서버의 장애 시 서버들의 풀에서 새로운 퍼블리싱 포인트 서버나 인코딩 서버를 재할당함에 따라 자동적인 장애복구가 가능한 오픈형 생중계 플랫폼의 시스템 및 상기 오픈형 생중계 플랫폼의 동작 방법을 제공한다.
국가나 지역 단위로 구별되는 구역(region)별로 논리적 스트리밍 클라우드를 구현하고, 국가별 논리적 스트리밍 클라우드의 서버들을 코디네이션 시스템을 통해 관리할 수 있으며, 서로 다른 구역간에 방송의 송출과 시청이 이루어지는 경우, 프록시 가속을 통해 네트워크 속도가 느린 사용자 구간을 최소화할 수 있는 오픈형 생중계 플랫폼의 시스템 및 상기 오픈형 생중계 플랫폼의 동작 방법을 제공한다.
코디네이션 시스템을 통해 물리적 머신의 인코딩 성능에 따라 하나의 물리적 머신에서 동작될 인코딩 서버의 수를 동적으로 조절함으로써 물리적 머신을 안정적이고 효율적으로 사용할 수 있는 오픈형 생중계 플랫폼의 시스템 및 상기 오픈형 생중계 플랫폼의 동작 방법을 제공한다.
스트리밍을 위한 서로 다른 복수의 서비스들 각각에서 제공되는 복수의 방송들에 대해서도 각각의 방송들에 대해 서비스와 상관 없이 독립적으로 채널을 관리함에 따라 서로 다른 서비스에서의 간섭 없이 안정적으로 서로 다른 서비스들 각각에서 제공되는 복수의 방송들 각각을 해당 서비스의 시청자들에게 제공할 수 있는 오픈형 생중계 플랫폼의 시스템 및 상기 오픈형 생중계 플랫폼의 동작 방법을 제공한다.
채널별로 우선순위를 부여하고, 부여된 유선순위를 이용하여 중요 채널의 방송 송출을 보장할 수 있는 오픈형 생중계 플랫폼의 시스템 및 상기 오픈형 생중계 플랫폼의 동작 방법을 제공한다.
오픈형 생중계 플랫폼을 위한 시스템에 있어서, 송출자의 단말로부터 송출되는 스트리밍 데이터를 수신하기 위한 적어도 하나의 제1 서버를 관리하는 제1 서버 풀; 상기 제1 서버 풀에서 할당된 제1 서버로부터 상기 스트리밍 데이터를 전달받아 인코딩하기 위한 적어도 하나의 제2 서버를 관리하는 제2 서버풀; 및 상기 제1 서버 풀 및 상기 제2 서버 풀의 서버들의 상태를 관리하고, 상기 제1 서버 풀에서 할당된 제1 서버의 요청에 따라 상기 제2 서버 풀에서 제2 서버를 동적으로 할당하는 코디네이터를 포함하고, 상기 스트리밍 데이터가 상기 송출자의 단말에서 송출됨에 응답하여, 상기 제1 서버 풀에서 임의의 제1 서버를 동적으로 할당하고, 상기 할당된 제1 서버를 통해 상기 송출되는 스트리밍 데이터를 수신하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템을 제공한다.
오픈형 생중계 플랫폼의 동작 방법에 있어서, 송출자 단말로부터 스트리밍 데이터가 송출됨에 응답하여 제1 서버 풀에서 할당된 임의의 제1 서버로부터 상기 스트리밍 데이터의 인코딩을 위한 제2 서버의 할당 요청을 수신하는 단계; 및 상기 수신된 할당 요청에 따라 제2 서버 풀에서 임의의 제2 서버를 동적으로 할당하는 단계를 포함하고, 상기 동적으로 할당된 제2 서버가 상기 제1 서버로부터 상기 스트리밍 데이터를 전달받아 인코딩하는 것을 특징으로 하는 동작 방법을 제공한다.
상기 동작 방법을 컴퓨터에 실행시키기 위한 프로그램이 기록되어 있는 것을 특징으로 하는 컴퓨터에서 판독 가능한 기록매체를 제공한다.
논리적 스트리밍 클라우드를 통해 실제로 방송의 송출이 발생하는 시점에 동적으로 리소스를 할당할 수 있다.
동적이고 자율적인 코디네이션 시스템(코디네이터)을 통해 중앙 집중적인 제어 없이 방송 송출이 발생하는 시점에 송출 요청을 처리하기 위한 퍼블리싱 포인트 서버와 방송의 스트리밍 데이터를 인코딩하기 위한 인코딩 서버를 개별적으로, 그리고 동적으로 할당함에 따라 미리 특정 방송을 위해 서버가 예약된 상태로 대기할 필요 없이 모든 서버들을 효율적으로 활용할 수 있다.
퍼블리싱 포인트 서버나 인코딩 서버의 장애 시 서버들의 풀에서 새로운 퍼블리싱 포인트 서버나 인코딩 서버를 재할당함에 따라 장애가 발생한 서버를 자동적으로 복구할 수 있다.
국가나 지역 단위로 구별되는 구역(region)별로 논리적 스트리밍 클라우드를 구현하고, 국가별 논리적 스트리밍 클라우드의 서버들을 코디네이션 시스템을 통해 관리할 수 있으며, 서로 다른 구역간에 방송의 송출과 시청이 이루어지는 경우, 프록시 가속을 통해 네트워크 속도가 느린 사용자 구간을 최소화할 수 있다.
코디네이션 시스템을 통해 물리적 머신의 인코딩 성능에 따라 하나의 물리적 머신에서 동작될 인코딩 서버의 수를 동적으로 조절함으로써 물리적 머신을 안정적이고 효율적으로 사용할 수 있다.
스트리밍을 위한 서로 다른 복수의 서비스들 각각에서 제공되는 복수의 방송들에 대해서도 각각의 방송들에 대해 서비스와 상관 없이 독립적으로 채널을 관리함에 따라 서로 다른 서비스에서의 간섭 없이 안정적으로 서로 다른 서비스들 각각에서 제공되는 복수의 방송들 각각을 해당 서비스의 시청자들에게 제공할 수 있다.
채널별로 우선순위를 부여하고, 부여된 유선순위를 이용하여 중요 채널의 방송 송출을 보장할 수 있다.
도 1은 본 발명의 일실시예에 따른 오픈형 생중계 플랫폼의 전체 구성의 예를 도시한 도면이다.
도 2는 본 발명의 일실시예에 따른 라이브 스트리밍 팜의 구성의 예를 도시한 도면이다.
도 3은 본 발명의 일실시예에 따른 L4 스위치의 로드 밸런싱 예를 도시한 도면이다.
도 4는 본 발명의 일실시예에 따른 인코더 서버 풀의 구성의 예를 도시한 도면이다.
도 5는 본 발명의 일실시예에 따른 VOD 팜의 구성의 예를 도시한 도면이다.
도 6 내지 도 8은 본 발명의 일실시예에 따른 오픈형 생중계 플랫폼의 동작 방법의 예를 도시한 도면들이다.
도 9는 본 발명의 일실시예에 있어서, 생중계를 위한 송출 주소와 시청 주소의 예를 도시한 도면이다.
도 10은 본 발명의 일실시예에 있어서, 방송 송출 요청을 처리하는 과정의 예를 도시한 도면이다.
도 11은 본 발명의 일실시예에 있어서, 인코딩 과정의 예를 도시한 도면이다.
도 12는 본 발명의 일실시예에 있어서, 송출 발생 시 각 서버들이 동적으로 할당되는 과정의 예를 도시한 도면이다.
도 13 및 도 14는 본 발명의 일실시예에 있어서, 퍼블리싱 포인트 서버에 대한 자율적인 장애복구 과정의 예를 도시한 도면들이다.
도 15 및 도 16은 본 발명의 일실시예에 있어서, 인코더 서버에 대한 자율적인 장애복구의 과정의 예를 도시한 도면들이다.
도 17은 본 발명의 일실시예에 있어서, 구역에 따른 오픈형 생중계 플랫폼의 구현 예를 도시한 도면이다.
도 18은 본 발명의 일실시예에 있어서, 프록시 가속의 예를 설명하기 위한 도면이다.
도 19는 본 발명의 일실시예에 있어서, 오픈형 생중계 플랫폼의 멀티-테넌트의 개념을 설명하기 위한 도면이다.
도 20은 본 발명의 일실시예에 따른 오픈형 생중계 플랫폼의 동작 방법의 예를 도시한 흐름도이다.
도 21은 본 발명의 일실시예에 따른 오픈형 생중계 플랫폼의 장애복구 방법의 예를 도시한 흐름도이다.
이하, 실시예를 첨부한 도면을 참조하여 상세히 설명한다.
도 1은 본 발명의 일실시예에 따른 오픈형 생중계 플랫폼의 전체 구성의 예를 도시한 도면이고, 도 2는 본 발명의 일실시예에 따른 라이브 스트리밍 팜의 구성의 예를 도시한 도면이며, 도 3은 본 발명의 일실시예에 따른 L4 스위치의 로드 밸런싱 예를 도시한 도면이고, 도 4는 본 발명의 일실시예에 따른 인코더 서버 풀의 구성의 예를 도시한 도면이다. 또한, 도 5는 본 발명의 일실시예에 따른 VOD 팜의 구성의 예를 도시한 도면이다.
본 실시예에 따른 오픈형 생중계 플랫폼(100)은 도 1에 도시된 바와 같이, 라이브 스트리밍 팜(Live Streaming Farm, 110), 코디네이터(Coordinator, 120) 및 VOD(Video On Demand) 팜(130)을 포함할 수 있다.
라이브 스트리밍 팜(110)은 송출자(140)로부터 송출되는 스트리밍 데이터를 처리하여 시청자(150)에게 중계하는 역할을 수행할 수 있다. 이를 위해, 라이브 스트리밍 팜(110)은 도 2에 도시된 바와 같이, 제1 L4 스위치(210), 퍼블리싱 포인트 서버 풀(Publishing Point Server Pool, 220), 인코더 서버 풀(Encoder Server Pool, 230), 분산 파일 시스템(Distributed File System, 240), 프록시 서버 풀(Proxy Server Pool, 250) 및 제2 L4 스위치(260)를 포함할 수 있다. 도 1에서는 하나의 송출자(140)와 하나의 시청자(150)를 나타내고 있으나, 이러한 송출자(140)와 시청자(150)는 복수의 송출자들과 복수의 시청자들을 의미할 수 있으며, 실질적으로는 방송을 송출하는 송출자의 단말과 방송을 수신하는 시청자의 단말을 의미할 수 있다.
제1 L4 스위치(210)는 도 3에 도시된 바와 같이, 퍼블리싱 포인트 서버 풀(220)에 포함되는 복수의 퍼블리싱 포인트 서버들(310)의 로드 밸런싱을 위해 이용될 수 있다. 예를 들어, 제1 L4 스위치(210)는 송출자(140)로부터 송출되는 스트리밍 데이터를 복수의 퍼블리싱 포인트 서버들(310) 중 어느 퍼블리싱 포인트 서버로 전달할 것인가를 결정할 수 있다.
퍼블리싱 포인트 서버 풀(220)은 도 3을 통해 설명한 바와 같이, 복수의 퍼블리싱 포인트 서버들(310)의 풀(pool)로서 퍼블리싱 포인트 서버 각각은 제1 L4 스위치(210)를 통해 전달되는 송출자(140)들의 송출 요청을 처리하고, 인코더 서버 풀(230)이 포함하는 인코더 서버에게 스트리밍 데이터를 전달할 수 있다. 이때, 하나의 퍼블리싱 포인트 서버가 다수의 송출 요청을 처리할 수 있다. 또한, 하나의 퍼블리싱 포인트 서버는 하나의 물리적인 머신으로 구현될 수도 있지만, 하나의 물리적인 머신상에 다수의 퍼블리싱 포인트 서버들이 구현될 수도 있다. 예를 들어, 세 개의 물리적인 머신에 각각 세 개의 퍼블리싱 포인트 서버들이 포함되도록 구현되는 경우, 총 9 개의 퍼블리싱 포인트 서버들이 퍼블리싱 포인트 서버 풀(220)에 포함될 수 있다. 도 3에서는 퍼블리싱 포인트 서버 풀(220)이 세 개의 퍼블리싱 포인트 서버를 포함하는 예를 나타내고 있으나, 퍼블리싱 포인트 서버는 필요에 따라 자유롭게 퍼블리싱 포인트 서버 풀(220)에 추가되거나 또는 퍼블리싱 포인트 서버 풀(220)에서 제외될 수 있다.
인코더 서버 풀(230)은 도 4에 도시된 바와 같이 복수의 인코더 서버들(410)을 포함하는 풀일 수 있다. 복수의 인코더 서버들(410)은 도 4에 도시된 바와 같이 세 개의 인코더 서버를 포함하는 예를 나타내고 있으나, 인코더 서버는 필요에 따라 자유롭게 인코더 서버 풀(230)에 추가되거나 또는 인코더 서버 풀(230)에서 제외될 수 있다. 또한, 복수의 인코더 서버들(410) 각각은 이미 설명한 바와 같이 하나의 물리적인 머신으로 구현될 수도 있으나, 하나의 물리적인 머신상에 다수의 인코더 서버들이 포함되도록 구현될 수도 있다. 예를 들어, 세 개의 물리적인 머신에 각각 네 개의 인코더 서버들이 포함되도록 구현되는 경우, 총 12 개의 인코더 서버들이 인코더 서버 풀(220)에 포함될 수 있다.
또한, 하나의 물리적인 머신은 적어도 하나의 퍼블리싱 포인트 서버와 적어도 하나의 인코더 서버를 포함하도록 구현될 수도 있다. 다시 말해, 퍼블리싱 포인트 서버, 인코더 서버, 그리고 이후 설명될 프록시 서버 등은 각각 개별적인 물리적인 머신의 형태로 구현될 수도 있으나, 하나의 물리적인 머신상에 복수의 서버들이 포함되는 형태로 구현될 수도 있다.
복수의 인코더 서버들(410) 각각은 하나의 인코더 서버와 하나의 업로더의 쌍으로 구현될 수 있다. 예를 들어, 도 4에서는 하나의 인코더 서버가 인코더 서버 1(411)과 업로더 1(412)의 쌍으로 구현된 예를 나타내고 있다.
인코더 서버는 퍼블리싱 포인트 서버로부터 수신되는 스트리밍 데이터를 기 설정된 프로파일로 인코딩할 수 있다. 예를 들어, HLS(HTTP Live Streaming) 알고리즘을 이용하여 시청자(150)에게 생중계 방송을 제공하는 경우, 인코더 서버는 퍼블리싱 포인트 서버로부터 수신되는 스트리밍 데이터를 인코딩하여 TS(Transport Segment) 파일을 생성할 수 있다.
업로더는 인코딩 결과로 생성된 TS 파일들을 라이브 스트리밍 팜(110)이 포함하는 분산 파일 시스템(240), 그리고 도 5에 도시된 VOD 팜(130)이 포함하는 분산 파일 시스템(520)에 각각 업로드할 수 있다. 또한, 업로더는 생성된 TS 파일들로 각 서비스 형태에 따른 재생정보파일(일례로, 어떤 미디어를, 어떻게 재생할 건가에 대한 정보를 저장한 파일로 HLS(HTTP Live Streaming) 알고리즘에서는 m3u8 파일)들을 생성하여 라이브 스트리밍 팜(110)이 포함하는 분산 파일 시스템(240)에 업로드할 수 있다. 이때, 서비스 형태에 따른 재생정보파일은 타임머신 기능을 제공하기 위한 재생정보파일(일례로, 타임머신 용 m3u8 파일), 라이브 방송을 위한 재생정보파일(일례로, 라이브 용 m3u8 파일) 및/또는 VOD 방송을 위한 재생정보파일(일례로, VOD 용 m3u8 파일)을 포함할 수 있다.
분산 파일 시스템(240)은 시청자(150)에게 스트리밍하기 위해 인코딩된 파일들(일례로, TS 파일들)과 재생정보파일들(일례로, m3u8 파일들)을 저장하고 제공할 수 있다.
프록시 서버 풀(250)는 복수의 프록시 서버들을 포함할 수 있으며, 제2 L4 스위치(260)를 통해 선택되는 프록시 서버가 외부의 스트리밍 요청을 수신하여 분산 파일 시스템(240)에 전달하는 역할을 수행할 수 있다. 이 경우, 분산 파일 시스템(240)은 전달된 외부의 스트리밍 요청에 따라 저장된 파일들(인코딩된 파일들(일례로, TS 파일들)과 재생정보파일들(일례로, m3u8 파일들))을 앞서 선택된 프록시 서버를 통해 제공함으로써, 생중계 서비스가 시청자(150)에게 제공될 수 있다.
코디네이터(120)는 오픈형 생중계 플랫폼(100)이 포함하는 서버들의 상태를 관리하고, 인코더 서버를 할당하며, 현재 송출 중인 채널의 정보 등 오픈형 생중계 플랫폼(100)의 전반적인 상태 및 설정들을 관리할 수 있다. 예를 들어, 오픈형 생중계 플랫폼(100)이 포함하는 서버들은 실행 시 코디네이터(120)에 자신을 등록하는 과정을 거칠 수 있으며, 코디네이터(120)는 등록된 서버들을 관리할 수 있다. 또한, 코디네이터(120)는 퍼블리싱 포인트 서버의 요청에 따라 인코더 서버를 할당할 수 있다. 이러한 코디네이터(120)는 일례로, 분산 환경에서 노드 간의 정보 공유, 락(Lock), 이벤트 등 보조 기능을 제공하는 프레임워크인 주키퍼(Zookeeper) 시스템을 이용하여 구현될 수 있다.
VOD 팜(130)은 생중계 영상의 VOD 파일을 생성 및 저장하고 VOD 서비스를 제공하는 기능을 담당할 수 있으며, 도 5에 도시된 바와 같이, VOD 생성 풀(510), 분산 파일 시스템(520), 프록시 서버 풀(530) 및 제3 L4 스위치(540)를 포함할 수 있다.
VOD 생성 풀(510)은 VOD 파일 생성 요청을 받는 경우, 분산 파일 시스템(520)에서 인코딩된 파일들(일례로, TS 파일들)을 다운로드 받아 VOD 파일(일례로, MP4 파일)을 생성할 수 있다. 또한, VOD 생성 풀(510)은 생성된 VOD 파일을 다시 분산 파일 시스템(520)에 업로드할 수 있다. VOD 생성 풀(510)은 복수의 VOD 생성 서버를 포함할 수 있다.
분산 파일 시스템(520)은 VOD 파일을 위한 인코딩된 파일들과 VOD 생성 풀(510)에 의해 생성된 VOD 파일을 저장 및 제공할 수 있다.
프록시 서버 풀(530)은 복수의 프록시 서버들을 포함할 수 있다. 제3 L4 스위치(540)는 외부의 VOD 파일 요청이 수신되면, 프록시 서버 풀(530)이 포함하는 복수의 프록시 서버들 중 하나의 프록시 서버를 선택하여 외부의 VOD 파일 요청을 전달할 수 있으며, 선택된 프록시 서버는 외부의 VOD 파일 요청을 분산 파일 시스템(520)으로 전달할 수 있다. 이 경우, 분산 파일 시스템(520)은 요청된 VOD 파일을 프록시 서버를 통해 외부로 제공할 수 있다.
도 6 내지 도 8은 본 발명의 일실시예에 따른 오픈형 생중계 플랫폼의 동작 방법의 예를 도시한 도면들이다.
도 6은 라이브 스트리밍을 위한 전체 과정들(과정(1-1) 내지 과정(1-10)) 중 과정(1-1) 내지 과정(1-6)을 도시하고 있다.
과정(1-1)은 송출자(140)가 제1 L4스위치(210)로 스트리밍 데이터를 송출하는 과정의 예일 수 있다.
과정(1-2)은 제1 L4 스위치(210)가 퍼블리싱 포인트 서버 풀(220)에 포함된 임의의 퍼블리싱 포인트 서버(610)를 선택하고, 선택된 퍼블리싱 포인트 서버(610)로 송출 요청을 전달하는 과정의 예일 수 있다.
과정(1-3)은 퍼블리싱 포인트 서버(610)가 코디네이터(120)에게 스트리밍을 위한 인코더 서버 풀(230)에 포함된 인코더 서버들 중 어느 하나의 할당을 요청하는 과정의 예일 수 있다.
과정(1-4)은 코디네이터(120)가 인코더 서버 풀(230)에서 스트리밍에 사용될 임의의 인코더 서버(620)를 선택하고, 스트리밍 시작 이벤트와 함께 퍼블리싱 포인트 서버(610)에 대한 정보를 선택된 인코더 서버(620)로 전달하는 과정의 예일 수 있다.
과정(1-5)은 코디네이터(120)에 의해 선택된 인코더 서버(620)가 퍼블리싱 포인트 서버(610)에 접속하여 스트리밍 데이터를 전달받고, 전달받은 스트리밍 데이터를 기 설정된 프로파일로 인코딩하는 과정의 예일 수 있다.
과정(1-6)은 인코더 서버(620)가 인코딩된 데이터(일례로, 인코딩에 따라 생성된 TS 파일들)를 지정된 경로(일례로, 도 6의 임시저장소(630))에 저장하는 과정의 예일 수 있다.
도 7은 라이브 스트리밍을 위한 전체 과정들(과정(1-1) 내지 과정(1-10)) 중 과정(1-7) 내지 과정(1-10)을 도시하고 있다. 과정(1-6)과 과정(1-7)은 도 6 및 도 7에 도시된 (A)를 통해 연결될 수 있다.
과정(1-7)은 업로더(710)가 도 6에 도시된 임시저장소(630)로부터 인코딩된 데이터(TS 파일들)를 획득하고, 인코딩된 데이터에 대응하는 재생정보파일(일례로, m3u8 파일들)을 생성하는 과정의 예일 수 있다. 이미 설명한 바와 같이 업로더(710)는 인코더 서버(620)와 하나의 쌍을 이룰 수 있다.
과정(1-8)은 업로더(710)가 인코딩된 데이터를 라이브 스트리밍 팜(110)의 분산 파일 시스템(240)과 VOD 팜(130)의 분산 파일 시스템(520)에 각각 업로드하고, 생성된 재생정보파일을 라이브 스트리밍 팜(110)의 분산 파일 시스템(240)에 업로드하는 과정의 예일 수 있다. 이때, 인코딩된 데이터를 VOD 팜(130)의 분산 파일 시스템(520)에 업로드하는 과정은 도 7 및 도 8에 도시된 (C)를 통해 연결될 수 있다.
과정(1-9)은 프록시 서버 풀(250)에 포함된 프록시 서버들 중 선택된 하나인 프록시 서버(720)가 라이브 스트리밍 팜(110)의 분산 파일 시스템(240)으로부터 인코딩된 데이터와 재생정보파일을 요청하여 전달받는 과정의 예일 수 있다.
과정(1-10)은 프록시 서버(720)가 전달받은 인코딩된 데이터와 재생정보파일을 시청자(150)에게 전달하여 라이브 스트리밍을 진행하는 과정의 예일 수 있다.
도 8은 VOD 파일의 생성 및 VOD 서비스의 제공을 위한 전체 과정들(과정(2-1) 내지 과정(2-5))을 도시하고 있다. 이러한 도 8은 (B) 및 (C)를 통해 도 6 및 도 7과 연결될 수 있다.
과정(2-1)은 VOD 생성 풀(510)에 포함된 VOD 생성 서버들 중 하나인 VOD 생성 서버(810)가 코디네이터(120)로부터 VOD 생성 요청을 수신하는 과정의 예일 수 있다.
과정(2-2)은 VOD 생성 서버(810)가 VOD 팜(130)에 포함된 분산 파일 시스템(520)으로부터 VOD 파일을 생성하기 위해 인코딩된 데이터를 다운로드 받는 과정의 예일 수 있다. 여기서 인코딩된 데이터는 도 7의 과정(1-8)을 통해 업로더(710)가 분산 파일 시스템(520)에 저장한 데이터일 수 있다.
과정(2-3)은 VOD 생성 서버(810)가 다운로드 받은 데이터를 이용하여 VOD 파일을 생성하여 분산 파일 시스템(520)에 업로드하는 과정의 예일 수 있다.
과정(2-4)는 프록시 서버 풀(530)에 포함된 프록시 서버들 중 하나인 프록시 서버(820)가 VOD 요청자(830)의 요청에 따라 VOD 파일을 분산 파일 시스템(520)으로부터 다운로드하는 과정의 예일 수 있다.
과정(2-5)는 프록시 서버(820)가 VOD요청자(830)에게 다운로드 받은 VOD 파일을 제공하는 과정의 예일 수 있다.
이러한 과정(2-1) 내지 과정(2-5)를 통해 라이브 스트리밍된 방송을 위한 VOD 파일이 생성 및 제공될 수 있다.
본 발명의 실시예들에 따른 오픈형 생중계 시스템은 아래와 같이 1 내지 6의 특징들을 갖는다.
1. 논리적 스트리밍 클라우드(Logical Streaming Cloud)
본 발명의 실시예들에 따른 오픈형 생중계 시스템(100)을 이용하여 방송을 송출하기 위해, 송출자(140)는 방송을 등록해야 한다. 이때, 방송을 등록하게 되면, 하나의 채널이 생성될 수 있고, 생성된 채널에는 방송의 송출을 위해 필요한 스트림 키가 제공될 수 있다. 송출자(140)는 이러한 스트림 키를 이용하여 항상 동일한 주소로 방송을 송출할 수 있으며, 오픈형 생중계 시스템(100)은 항상 동일한 주소로 해당 채널의 방송을 시청자(150)에게 제공할 수 있다. 다시 말해, 송출자(140)는 항상 동일한 주소로 방송을 송출할 수 있으며, 시청자(150)는 송출자(140)의 특정 방송을 항상 동일한 주소로 시청할 수 있게 된다.
도 9는 본 발명의 일실시예에 있어서, 생중계를 위한 송출 주소와 시청 주소의 예를 도시한 도면이다. 도 9는 송출자(140)가 RTMP(Real Time Messaging Protocol)을 이용하여 방송을 송출함에 있어서, 송출자(140)에게 할당된 스트림 키 'xyzc123'을 이용하여 생성되는 송출 주소 'rtmp://tv.bbb.com/xyzc123'로 방송을 송출하는 예를 나타내고 있다. 또한, 도 9는 시청자(150)가 HLS(HTTP Live Streaming) 프로토콜을 이용하여 방송을 시청함에 있어서, 송출자(140)의 이름 'aaa'를 이용하여 생성된 시청 주소 'http://streamfarm.bbb.com/aaa.m3u8'로 해당 방송을 시청하는 예를 나타내고 있다. 따라서, 시청자(150)는 마치 TV의 특정 방송사의 방송을 특정 채널에서 시청할 수 있는 개념과 유사한 개념으로 특정 방송에 접근할 수 있게 된다.
방송 등록 시 생성되는 채널은 방송에 대한 정보만을 생성하고, 물리적인 서버와 연결되지 않기 때문에 생성 개수에 제한이 없으며, 생성 개수의 증가가 시스템에 전혀 영향을 주지 않는다. 다시 말해, 채널을 생성하더라도 해당 채널을 위해 오픈형 생중계 플랫폼(100)의 리소스가 할당되지 않는다. 실제로 오픈형 생중계 플랫폼(100)의 리소스가 이용되는 시점은 방송의 송출이 발생하는 시점으로, 이러한 구조는 임의의 송출자들이 다수의 방송을 등록하고, 실제 방송 시간이 짧은 오픈형 라이브 서비스 구조에 매우 적합하다.
2. 동적이고 자율적인 조정 시스템(Dynamic and Autonomous Coordination System)
오픈형 생중계 플랫폼(100)의 서버들은 송출이 발생하는 시점에 동적으로 할당되며, 송출이 발생하기 전까지는 풀에서 대기상태로 존재하게 된다. 송출의 요청이 발생하게 되면, L4 스위치(제1 L4 스위치(210))에 의해 퍼블리싱 포인트 서버 풀(220)에서 임의의 퍼블리싱 포인트 서버가 선택되며, 코디네이션(120)에 의해 인코딩 서버 풀(230)에서 인코더 서버 선택 알고리즘에 다라 인코더 서버가 선택될 수 있다.
인코더 서버 선택 알고리즘은 아래 (a), (b), (c)와 같다.
(a) 퍼블리싱 포인트 서버와 같은 로컬 머신에 있는 인코더 서버 중에 대기 상태인 인코더 서버를 선택.
(b) 상술한 (a)를 만독하는 인코더 서버가 없는 경우, 퍼블리싱 포인트 서버와 같은 구역(region)에 있는 인코더 서버 중 대기 상태인 인코더 서버를 선택.
(c) 상술한 (a)나 (b)를 만족하는 인코더 서버가 없는 경우, 방송 송출을 요청한 채널보다 우선 순위가 낮은 채널의 방송을 송출 중인 인코더 서버를 선택. (이 경우, 선택된 인코더 서버는 현재 처리 중인 채널의 작업을 종류하고, 새로 요청된 방송의 송출 요청을 처리함.)
오픈형 생중계 플랫폼(100)는 중앙 집중적인 제어 없이 각 단계별로 자율적으로 방송 송출 요청을 처리할 수 있다.
도 10은 본 발명의 일실시예에 있어서, 방송 송출 요청을 처리하는 과정의 예를 도시한 도면이다. 도 10의 실시예는 송출자(140)로부터의 방송 송출 요청에 따라, 제1 L4 스위치(210)가 퍼블리싱 포인트 서버 1(1010)을 선택하고, 선택된 퍼블리싱 포인트 서버 1(1010)로 방송 송출 요청을 전달하는 예를 나타내고 있다. 또한, 도 10의 실시예에서 선택된 퍼블리싱 포인트 서버 1(1010)은 요청된 방송을 코디네이터(120)에 알리고 요청된 방송이 등록된 정상적인 방송인지 여부를 코디네이터(120)를 통해 확인한 후, 송출자(140)로부터 송출되는 방송의 스트리밍 데이터를 받아주는 역할을 수행할 수 있다. 코디네이터(120)는 도 6을 통해 설명한 바와 같이, 정상적인 방송에 대한 방송 송출 요청에 대해, 퍼블리싱 포인트 서버 1(1010)을 위한 인코더 서버를 할당할 수 있다.
도 11은 본 발명의 일실시예에 있어서, 인코딩 과정의 예를 도시한 도면이다. 도 11의 실시예는 코디네이터(120)가 정상적인 방송에 대한 방송 송출 요청에 따라 인코더 서버를 선택(도 11의 실시예에서는 인코더 서버 1(1110))하고, 선택된 인코더 서버 1(1110)의 작업 목록에 방송 송출 작업을 등록하는 예를 나타내고 있다. 이때, 대기 상태의 인코더 서버들 각각은 자신의 작업 목록을 모니터링할 수 있다. 다시 말해, 인코더 서버 1(1110)은 자신의 작업 목록인 '인코더 서버 1 작업 목록'(1120)을 모니터링하고 있다가, 코디네이터(120)에 의해 방송 송출 작업이 등록됨에 따라, 등록된 정보를 이용하여 스트리밍 데이터를 수신할 수 있으며, 수신된 스트리밍 데이터에 대한 인코딩 작업을 수행할 수 있다. 예를 들어, 인코더 서버 1(1110)은 등록된 정보를 통해 퍼블리싱 포인트 서버 1(1010)을 식별할 수 있으며, 식별된 퍼블리싱 포인트 서버 1(1010)로 스트리밍 데이터를 요청할 수 있다. 퍼블리싱 포인트 서버 1(1010)은 인코더 서버 1(1110)의 요청에 따라 송출자(140)로부터 제1 L4 스위치(210)를 통해 전달받은 스트리밍 데이터를 인코더 서버 1(1110)로 전송할 수 있다. 이때, 인코더 서버 1(1110)은 퍼블리싱 포인트 서버 1(1010)로부터 수신되는 스트리밍 데이터를 인코딩할 수 있다.
도 12는 본 발명의 일실시예에 있어서, 송출 발생 시 각 서버들이 동적으로 할당되는 과정의 예를 도시한 도면이다. 도 12에 도시된 과정 ①, 과정 ②, 과정 ③, 과정 ④ 및 과정 ⑤는 앞서 도 6을 통해 설명한 과정 (1-1) 내지 과정 (1-5)에 대응될 수 있다.
과정 ①은 송출자(140)가 방송 송출을 시도하는 과정의 예일 수 있다.
과정 ②는 제1 L4 스위치(210)가 퍼블리싱 포인트 서버 풀(220)에 포함된 퍼블리싱 포인트 서버들 중 하나인 퍼블리싱 포인트 서버(1210)를 선택하여 송출 요청을 전달하는 과정의 예일 수 있다.
과정 ③은 송출 요청을 받은 퍼블리싱 포인트 서버(1210)가 코디네이터(120)에게 방송 송출 요청에 대해 등록을 하면서 인코딩 서버의 할당을 요청하는 과정의 예일 수 있다.
과정 ④는 코디네이터(120)가 인코더 서버 풀(230)에 포함된 인코더 서버들 중 하나인 인코더 서버(1220)을 선택하고 스트리밍 요청 정보를 등록하는 과정의 예일 수 있다. 여기서 스트리밍 요청 정보를 등록하는 것은 도 11을 통해 설명한 바와 같이, 선택된 인코더 서버(1220)의 작업 목록에 방송 송출 작업을 등록하는 것에 대응될 수 있다.
과정 ⑤는 인코더 서버(1220)가 퍼블리싱 포인트 서버(1210)에 접속하여 스트리밍 데이터를 요청하고, 요청된 스트리밍 데이터를 퍼블리싱 포인트 서버(1210)로부터 수신하여 설정된 화질 등과 같은 기 설정된 프로파일에 따라 인코딩하는 과정의 예일 수 있다. 이때, 인코더 서버(1220)는 화질 별 TS 파일을 생성할 수 있다.
방송의 송출이 종료되면, 할당된 퍼블리싱 포인트 서버(1210)와 인코더 서버(1220)는 다시 사용 가능한 상태인 대기 상태로 퍼블리싱 포인트 서버 풀(220)과 인코더 서버 풀(230)에서 대기하게 된다.
이처럼, 본 발명의 실시예들에서는 방송의 송출이 실제로 발생하는 경우에만 퍼블리싱 포인트 서버와 인코더 서버가 동적으로 할당되기 때문에 특정 방송을 위한 서버가 미리 예약된 상태(미리 할당된 상태)로 대기할 필요가 없어 모든 서버들이 효율적으로 사용될 수 있다. 또한, 서버를 각 서버 풀에 추가하는 것만으로도 오픈형 생중계 플랫폼(100)의 수용력(capacity)을 높일 수 있기 때문에, 쉽게 오픈형 생중계 플랫폼(100)의 수용력(capacity)을 증가시킬 수 있다.
3. 자동 장애 복구 메커니즘(Automatic failover mechanism)
오픈형 생중계 플랫폼(100)에서는 퍼블리싱 포인트 서버와 인코더 서버가 서로 분리되어 있으며, 특정 채널에 서버가 연관되어 있지 않기 때문에 비정상적인 동작에 대해 빠르게 복구가 가능해진다.
도 13 및 도 14는 본 발명의 일실시예에 있어서, 퍼블리싱 포인트 서버에 대한 자율적인 장애복구 과정의 예를 도시한 도면들이다.
도 13은 도 12을 통해 설명한 퍼블리싱 포인트 서버(1210)가 비정상 종료된 상황의 처리를 나타내고 있다. 퍼블리싱 포인트 서버(1210)가 비정상 종료되는 경우, 코디네이터(120)는 이러한 퍼블리싱 포인트 서버(1210)의 비정상 종료를 감지할 수 있으며, 퍼블리싱 포인트 서버(1210)에 대해 할당된 인코더 서버(1220)로 송출 종료 이벤트를 전달할 수 있다. 이 경우, 인코더 서버(1220)는 다시 다른 방송의 송출(스트리밍)을 위한 대기상태로 전환될 수 있다.
도 14는 송출자(140)에 의해 송출이 재시도되는 경우, 제1 L4 스위치(210)에 의해 다른 퍼블리싱 포인트 서버(1410)가 선택되고, 다른 퍼블리싱 포인트 서버(1410)의 요청에 따라 코디네이터(120)가 새로운 인코더 서버(1420)를 할당함에 따라 퍼블리싱 포인트 서버(1410)와 인코더 서버(1420)에 의해 스트리밍이 재개되는 과정을 나타내고 있다. 다시 말해, 기존 퍼블리싱 포인트 서버(1210)에 장애가 발생하는 경우, 송출 재시도에 따라 최초 송출 요청과 동일한 과정이 진행되어 장애복구가 이루어질 수 있다.
도 15 및 도 16은 본 발명의 일실시예에 있어서, 인코더 서버에 대한 자율적인 장애복구의 과정의 예를 도시한 도면들이다.
도 15는 도 12를 통해 설명한 인코더 서버(1220)가 비정상 종료된 상황의 처리를 나타내고 있다. 인코더 서버(1220)가 비정상 종료되는 경우, 코디네이터(120)는 이러한 인코더 서버(1220)의 비정상 종료를 감지할 수 있으며, 현재 할당 가능한 다른 인코더 서버의 할당을 시도하게 된다.
도 16은 코디네이터(120)가 새로운 인코더 서버(1420)를 퍼블리싱 포인트 서버(1210)에 할당함에 따라 퍼블리싱 포인트 서버(1210)와 새로운 인코더 서버(1420)를 통해 송출이 재개되어 빠르게 방송 송출에 대한 장애가 복구될 수 있음을 나타내고 있다.
이러한 실시예들에서 퍼블리싱 포인트 서버와 인코더 서버간의 스트리밍 방식은 할당된 인코더 서버가 해당하는 퍼블리싱 포인트 서버에 접속하여 스트리밍 데이터를 받아오는 방식(PULL 방식)이기 때문에, 퍼블리싱 포인트 서버에서 인코더 서버의 장애 상황에 대응할 필요가 없으며, 송출 재시도와 같은 동작도 요구되지 않는다.
다만, 서버의 장애복구 시 플레이어의 재생 처리를 위한 동작이 추가되어야 할 필요성이 있다. 예를 들어, 퍼블리싱 포인트 서버나 인코더 서버의 장애복구 발생 시, 시청자(150)에게 제공되는 스트리밍 데이터가 연속되지 않게 되기 때문에 이에 대한 처리를 통해 플레이어에서 정지 없이 재생이 가능하도록 할 수 있다. 이를 위해, 업로더(일례로, 도 16에서 인코더 서버(1420)와 쌍을 이루게 되는 업로더)는 처음 m3u8 파일을 생성하기 전에 해당 채널을 위한 m3u8 파일의 존재 유무를 먼저 확인한 후, 이미 m3u8 파일이 존재하는 경우 HLS 규약에 따라 '#EXT※DISCONTINUITY'를 추가한 후 이미 존재하는 m3u8 파일에 TS 리스트를 첨부하게 된다. 플레이어는 m3u8 파일에 '#EXT※DISCONTINUITY'가 존재하는 경우, 이전 스트리밍 데이터와 연속되지 않음을 감지하고, 이후 데이터를 처리하게 되어 서버의 장애복구가 발생하더라도 재생에 문제가 발생하지 않게 된다.
4. 근본적인 글로벌 플랫폼(Basically global platform)
오픈형 생중계 플랫폼(100)은 국가나 지역 단위를 구역(region)으로 구별하고, 구역에 따라 라이브 스트리밍 팜들을 구성할 수 있다.
도 17은 본 발명의 일실시예에 있어서, 구역에 따른 오픈형 생중계 플랫폼의 구현 예를 도시한 도면이다. 도 17은 제1 국가의 구역에 구현된 제1 라이브 스트리밍 팜(1710)과 제1 VOD 팜(1720), 그리고 제2 국가의 구역에 구현된 제2 라이브 스트리밍 팜(1730)과 제2 VOD 팜(1720)이 각각 코디네이터(120)와 연결되는 구현 예를 나타내고 있다. 이 경우, 서로 다른 구역에서 방송의 송출 및 시청을 할 수 있다. 이때, 빠른 방송 스트리밍을 위해 프록시 가속의 개념이 사용될 수 있다. 프록시 가속이란 송출과 시청 구역이 서로 다른 경우 네트워크 속도가 느린 사용자 구간을 최소화하고, 속도가 빠른 서버간 전용선 구간을 이용하여 스트리밍 서비스를 제공하는 방식이다.
도 18은 본 발명의 일실시예에 있어서, 프록시 가속의 예를 설명하기 위한 도면이다. 도 18은 제1 국가의 송출자(1810)의 방송을 제1 국가에 구현된 퍼블리싱 포인트 서버 풀(1820), 인코더 서버 풀(1830), 분산 파일 시스템(1840) 및 프록시 서버(1850)를 통해 제1 국가에 위치한 제1 시청자(1860)에게 제공하는 예를 나타내고 있다. 이때, 도 18에 도시된 바와 같이, 흰색 화살표는 사용자 네트워크 구간을, 회색 화살표는 서버간 네트워크 구간을, 검은색 화살표는 구역(region)간 서버 전용 네트워크 구간을 각각 나타내고 있다.
제1 시청자(1860)는 제1 국가에 위치하기 때문에 프록시 서버(1850)를 통해서도 빠른 방송 스트리밍을 제공받을 수 있다. 한편, 제2 국가에 위치하는 제2 시청자(1870)가 프록시 서버(1850)를 통해 방송 스트리밍을 제공받는 경우, 네트워크 속도가 느린 사용자 구간이 매우 길어지기 때문에 빠른 방송 스트리밍을 제공받기가 어렵다. 따라서, 본 실시예에서는 제1 국가에 구현된 프록시 서버(1850)가 방송 스트리밍을 검은색 화살표로 표시된 프록시 가속을 위한 전용선 구간을 통해 제2 국가에 구현된 프록시 서버(1880)로 빠르게 전송하고, 제2 국가에 위치하는 제2 시청자(1870)가 제2 국가에 구현된 프록시 서버(1880)를 통해 바송 스트리밍을 제공받을 수 있다. 이 경우, 네트워크 속도가 느린 사용자 구간이 최소화되기 때문에 제2 국가에 위치하는 제2 시청자(1870)에게도 제1 국가의 송출자(1810)의 방송 스트리밍을 빠르게 서비스할 수 있게 된다.
5. 효과적인 머신 활용(Efficient machine utilization)
오픈형 생중계 플랫폼(100)에서는 인코딩을 담당하는 물리적 머신의 인코딩 성능에 따라 하나의 물리적인 머신에서 동작할 수 있는 인코더 서버의 수를 설정할 수 있다. 예를 들어, 하나의 물리적 머신이 720p 해상도를 갖는 5개의 스트리밍 데이터를 동시에 인코딩할 수 있으며, 1080p 해상도를 갖는 스트리밍 데이터는 동시에 하나만 인코딩할 수 있다고 가정하자. 이 경우, 오픈형 생중계 플랫폼(100)에서는 해당 물리적 머신에 5개의 인코더 서버를 설치하고, 720p 해상도를 갖는 스트리밍 데이터를 인코딩하는 경우에는, 설치된 5 개의 인코더 서버가 모두 동작하도록 인코더 서버들을 할당할 수 있다. 만약, 1080p 해상도를 갖는 스트리밍 데이터를 하나의 인코더 서버가 인코딩하고 있는 경우, 나머지 4 개의 인코더 서버는 코디네이터(120)에 의해 할당되지 않도록 제어할 수 있다.
6. 멀티-테넌트(Multi-tenant)
오픈형 생중계 플랫폼(100)은 서로 다른 여러 서비스에서 동시에 사용이 가능하며, 각 채널들은 생성 시점에 특정 서비스 카테고리에 속할 수 있다. 그러나, 오픈형 생중계 플랫폼(100)은 채널에 소속된 서비스와 상관없이 스트리밍 데이터를 독립적으로 관리하기 때문에, 동시에 서로 다른 서비스에서 서로 간섭 없이 안정적으로 오픈형 생중계 플랫폼(100)을 이용할 수 있게 된다.
도 19는 본 발명의 일실시예에 있어서, 오픈형 생중계 플랫폼의 멀티-테넌트의 개념을 설명하기 위한 도면이다. 도 19는 동일한 서비스를 이용하는 서로 다른 송출자들이 아니라, 제1 서비스(1910), 제2 서비스(1920) 및 제3 서비스(1930)와 같이, 서비스 제공자가 서로 다른 서비스들의 송출자들이 방송을 송출하는 경우를 나타내고 있다. 이 경우, 본 발명의 실시예들에 따른 라이브 스트리밍 팜(1940)은 각 채널을 서비스와는 무관하게 독립적으로 관리(앞서 설명한 바와 같이 송출자가 하나의 방송에 대해 할당되는 스트림 키를 이용하여 생성되는 동일한 주소를 통해 방송을 송출하고, 해당 방송을 시청하기 위해 할당되는 동일한 주소를 통해 시청자들이 방송을 시청)하기 때문에 서비스간의 간섭 없이 방송을 중계할 수 있다. 따라서, 제1 서비스 시청자(1950), 제2 서비스 시청자(1960) 및 제3 서비스 시청자(1970)가 각각의 서로 다른 서비스의 방송 스트림을 제공받을 수 있게 된다.
7. 우선순위 기반 스트리밍 스케줄링(Priority based Streaming scheduling)
오픈형 생중계 플랫폼(100)은 서버들을 효율적으로 사용하면서도, 언제든지 중요 방송의 송출이 가능하도록 하기 위해 채널에 '우선순위'를 부여할 수 있다. 채널의 우선순위는 채널 생성 시 설정될 수 있으며, 일반적인 상황에서는 방송 송출에 전혀 영향을 주지 않는다. 그러나, 더 이상 방송 송출을 위해 사용될 수 있는 리소스(서버들)가 없는 경우에는 채널에 부여된 '우선순위'를 이용하여 중요 방송의 송출을 보장할 수 있다.
예를 들어, 현재 오픈형 생중계 플랫폼(100)의 모든 리소스(서버들)가 사용 중인 상태에서 새로운 방송 송출이 요구되는 경우, 오픈형 생중계 플랫폼(100)은 새로운 방송 송출을 요청한 채널보다 우선 순위가 낮은 채널들 중에서 임의의 채널을 선택하여 송출을 종료시키고, 새로 요청한 채널의 방송 송출을 서비스할 수 있다. 이러한 동작은 현재 시스템의 모든 리소스(서버들)이 사용중인 경우에도 중요 방송들의 방송 송출을 보장해줄 수 있다.
우선순위는 순위가 높은 순서로 'Super', 'High', 'Low', 'Zero' 등과 같이 복수의 레벨로 분류되어 채널마다 할당될 수 있다.
일실시예에 따른 오픈형 생중계 플랫폼(100)은 송출자의 단말로부터 송출되는 스트리밍 데이터를 수신하기 위한 적어도 하나의 제1 서버를 관리하는 제1 서버 풀, 상기 제1 서버 풀에서 할당된 제1 서버로부터 상기 스트리밍 데이터를 전달받아 인코딩하기 위한 적어도 하나의 제2 서버를 관리하는 제2 서버풀 및 상기 제1 서버 풀 및 상기 제2 서버 풀의 서버들의 상태를 관리하고, 상기 제1 서버 풀에서 할당된 제1 서버의 요청에 따라 상기 제2 서버 풀에서 제2 서버를 동적으로 할당하는 코디네이터를 포함할 수 있다. 여기서, 송출자의 단말은 송출자(140)에, 제1 서버 풀은 퍼블리싱 포인트 서버 풀(220)에, 제2 서버 풀은 인코더 서버 풀(230)에, 코디네이터는 코디네이터(120)에 각각 대응할 수 있다. 이때, 오픈형 생중계 플랫폼(100)은 스트리밍 데이터가 상기 송출자의 단말에서 송출됨에 응답하여, 상기 제1 서버 풀에서 임의의 제1 서버를 동적으로 할당하고, 상기 할당된 제1 서버를 통해 상기 송출되는 스트리밍 데이터를 수신할 수 있다. 이러한, 오픈형 생중계 플랫폼(100)은 송출자의 방송 송출이 발생하는 시점에 동적으로 서버들을 할당할 수 있게 되어 효율적으로 리소스를 활용할 수 있게 된다.
다른 실시예에서, 코디네이터는 상기 송출자의 방송이 등록되는 경우, 상기 방송을 위한 채널을 생성하고, 상기 채널에 대해 할당되는 고유 키를 이용하여 상기 방송의 스트리밍 데이터의 송출을 위한 송출 주소를 생성할 수 있으며, 오픈형 생중계 플랫폼(100)은 상기 송출 주소를 통해 상기 방송의 스트리밍 데이터가 송출됨에 응답하여 상기 제1 서버 풀에서 임의의 제1 서버를 동적으로 할당할 수 있다. 이 경우, 특정 방송에 대해 항상 동일한 송출 주소로 스트리밍 데이터를 송출할 수 있게 된다. 이와 유사하게 송출자에 대한 정보를 이용하여 생성되는 시청 주소를 이용하여 시청자들이 특정 방송을 항상 동일한 시청 주소를 통해 시청할 수 있도록 서비스를 제공할 수도 있다.
또 다른 실시예에서 상기 코디네이터는, 상기 할당된 제2 서버의 작업 목록에 방송 송출 작업을 등록할 수 있다. 이때, 상기 제2 서버 풀에서 관리되는 적어도 하나의 제2 서버 각각은 자신의 작업 목록을 모니터링할 수 있으며, 자신의 작업 목록에 방송 송출 작업이 등록된 제2 서버는 상기 작업 목록에 등록된 정보를 이용하여 상기 제1 서버 풀에서 할당된 제1 서버를 식별하여 상기 할당된 제1 서버로부터 상기 스트리밍 데이터를 수신 및 인코딩할 수 있게 된다.
또 다른 실시예에서, 오픈형 생중계 플랫폼(100)은 상기 스트리밍 데이터가 상기 송출자의 단말에서 송출됨에 응답하여, 상기 제1 서버 풀에서 임의의 제1 서버를 동적으로 선택하여 상기 송출자의 단말로부터 송출되는 스트리밍 데이터를 상기 선택된 제1 서버로 전달하는 스위치를 더 포함할 수 있다. 이러한 스위치는 앞서 설명한 제1 L4 스위치(210)에 대응할 수 있다.
또 다른 실시예에서, 상기 제1 서버 풀에서 관리되는 적어도 하나의 제1 서버와 상기 제2 서버 풀에서 관리되는 적어도 하나의 제2 서버 각각은 실행 시 상기 코디네이터에 등록될 수 있다. 이 경우, 상기 코디네이터는, 상기 등록된 적어도 하나의 제1 서버 및 적어도 하나의 제2 서버의 상태를 모니터링할 수 있다. 이러한 모니터링은 할당된 제1 서버나 할당된 제2 서버의 장애를 감지하는데 이용될 수 있다.
또 다른 실시예에서, 상기 코디네이터는, 상기 할당된 제1 서버의 장애를 감지하는 경우, 상기 할당된 제2 서버로 스트리밍 종료 이벤트를 전달하여 상기 할당된 제2 서버를 대기 상태로 전환시키고, 상기 송출자의 단말로부터 상기 스트리밍 데이터가 재송출됨에 따라 상기 제1 서버 풀에서 할당되는 다른 제1 서버의 요청에 따라 상기 제2 서버 풀에서 새로운 제2 서버를 할당할 수 있다. 이 경우, 다른 제1 서버와 새로운 제2 서버를 통해 스트리밍 데이터의 수신 및 인코딩이 이루어지기 때문에 기존 제1 서버의 장애에 대응할 수 있게 된다.
또 다른 실시예에서, 상기 코디네이터는, 상기 할당된 제2 서버의 장애를 감지하는 경우, 상기 제2 서버 풀에서 새로운 제2 서버를 할당할 수 있다. 이때, 상기 할당된 새로운 제2 서버는 상기 할당된 제1 서버에 접속하여 상기 할당된 제1 서버로부터 상기 스트리밍 데이터를 수신하고, 상기 수신되는 스트리밍 데이터를 인코딩할 수 있다. 이 경우, 기존의 제1 서버와 할당된 새로운 제2 서버를 통해 스트리밍 데이터의 수신 및 인코딩이 이루어지기 때문에 기존 제1 서버의 장애에 대응할 수 있게 된다. 이미 설명한 바와 같이, 할당된 새로운 서버가 제1 서버로 풀(PULL) 방식으로 스트리밍 데이터를 요청하기 때문에 제1 서버로서의 퍼블리싱 포인트 서버는 제2 서버로서의 인코더 서버의 장애나 장애복구를 고려할 필요가 없게 된다.
또 다른 실시예에서, 오픈형 생중계 플랫폼(100)은 상기 동적으로 할당된 제2 서버에 의해 인코딩된 스트리밍 데이터를 저장하는 분산 파일 시스템 및 시청자 단말의 방송 시청 요청을 수신하고 상기 분산 파일 시스템에서 상기 인코딩된 스트리밍 데이터를 상기 시청자 단말로 제공하기 위한 적어도 하나의 제3 서버를 관리하는 제3 서버 풀을 더 포함할 수 있다. 여기서, 분산 파일 시스템은 도 2를 통해 설명한 분산 파일 시스템(240)에 제3 서버 풀은 도 2를 통해 설명한 프록시 서버 풀(250)에, 시청자 단말은 도 1을 통해 설명한 시청자(150)에 각각 대응할 수 있다. 이 경우, 상기 시청자 단말의 방송 시청 요청에 응답하여 상기 제3 서버 풀에서 임의의 제3 서버를 동적으로 할당하고, 상기 할당된 제3 서버를 통해 상기 분산 파일 시스템에서 상기 인코딩된 스트리밍 데이터를 상기 시청자 단말로 제공할 수 있다.
또 다른 실시예에서, 오픈형 생중계 플랫폼(100)은 상기 시청자 단말의 방송 시청 요청에 응답하여 상기 제3 서버 풀에서 임의의 제3 서버를 동적으로 선택하여 상기 방송 시청 요청을 상기 선택된 제3 서버로 전달하는 스위치를 더 포함할 수 있다. 여기서 스위치는 도 2를 통해 설명한 제2 L4 스위치(260)에 대응할 수 있다.
또 다른 실시예에서, 국가 및 지역 중 적어도 하나에 따라 구분되는 구역(region)마다, 상기 제1 서버 풀, 상기 제2 서버 풀, 상기 분산 파일 시스템 및 상기 제3 서버 풀이 구성될 수 있다. 이러한 구성은 각각의 구역별로 네트워크 속도가 느린 사용자 구간을 줄일 수 있게 해준다.
또 다른 실시예에서, 서로 다른 구역의 제3 서버들간에 전용선이 연결될 수 있다. 이 경우, 제1 구역에서 송출되는 스트리밍 데이터는 제1 구역의 제1 서버로 전달되어 제1 구역의 제2 서버에 의해 인코딩되고, 제1 구역의 제3 서버를 통해 제1 구역에 위치하는 시청자에게 제공될 수 있다. 또한, 제1 구역에서 송출되는 스트리밍 데이터는 제1 구역의 제3 서버와 전용선으로 연결된 제2 구역의 제3 서버를 통해 제2 구역에 위치하는 시청자에게 더 제공될 수 있다. 따라서, 제2 구역에 위치하는 시청자가 제1 구역에서 송출되는 방송을 시청하는 경우에도 네트워크 속도가 느린 사용자 구간을 최소화할 수 있게 된다.
또 다른 실시예에서, 오픈형 생중계 플랫폼(100)은 상기 코디네이터로부터의 VOD 파일 생성 요청에 따라 상기 할당된 제2 서버를 통해 인코딩된 스트리밍 데이터를 이용하여 VOD 파일을 생성하기 위한 적어도 하나의 제4 서버를 관리하는 제4 서버 풀 및 요청자 단말로부터 상기 VOD 파일에 대한 요청을 수신하고 상기 요청에 따라 상기 생성된 VOD 파일을 상기 요청자 단말로 제공하기 위한 적어도 하나의 제5 서버를 관리하는 제5 서버 풀을 더 포함할 수 있다. 여기서 제4 서버 풀은 앞서 설명한 VOD 생성 서버 풀(510)에, 제5 서버 풀은 프록시 서버 풀(540)에 각각 대응할 수 있다.
도 20은 본 발명의 일실시예에 따른 오픈형 생중계 플랫폼의 동작 방법의 예를 도시한 흐름도이다. 본 실시예에 따른 동작 방법은 실질적으로 오픈형 생중계 플랫폼(100)이 포함하는 코디네이터(120)에 의해 수행될 수 있다. 코디네이터(120)는 적어도 하나의 프로세서와 적어도 하나의 메모리를 포함하는 물리적 머신에 의해 구현될 수 있다.
단계(2010)에서 코디네이터(120)는 송출자의 방송이 등록되는 경우, 방송을 위한 채널을 생성하고, 채널에 대해 할당되는 고유 키를 이용하여 방송의 스트리밍 데이터의 송출을 위한 송출 주소를 생성할 수 있다.
단계(2020)에서 코디네이터(120)는 송출 주소를 통해 송출자 단말로부터 스트리밍 데이터가 송출됨에 응답하여 제1 서버 풀에서 할당된 임의의 제1 서버로부터 스트리밍 데이터의 인코딩을 위한 제2 서버의 할당 요청을 수신할 수 있다.
단계(2030)에서 코디네이터(120)는 수신된 할당 요청에 따라 제2 서버 풀에서 임의의 제2 서버를 동적으로 할당할 수 있다. 이때, 동적으로 할당된 제2 서버가 제1 서버로부터 스트리밍 데이터를 전달받아 인코딩할 수 있다. 이를 위해, 코디네이터(120)는 단계(2030)에서 임의의 제2 서버의 작업 목록에 스트리밍 데이터에 대한 방송 송출 작업을 등록할 수 있다. 제2 서버 풀에서 관리되는 적어도 하나의 제2 서버 각각은 자신의 작업 목록을 모니터링할 수 있으며, 이때 자신의 작업 목록에 방송 송출 작업이 등록된 제2 서버가 자신의 작업 목록에 등록된 정보를 이용하여 제1 서버 풀에서 할당된 제1 서버를 식별하여 할당된 제1 서버로부터 스트리밍 데이터를 수신 및 인코딩할 수 있다.
인코딩된 스트리밍 데이터는 분산 파일 시스템에 저장될 수 있으며, 시청자 단말의 요청에 따라 제3 서버 풀에서 동적으로 할당된 제3 서버에서 분산 파일 시스템에 저장된 인코딩된 스트리밍 데이터를 다운로드하여 시청자 단말로 제공할 수 있다.
단계(2040)에서 코디네이터(120)는 제4 서버 풀에서 VOD 파일의 생성을 위한 임의의 제4 서버를 할당할 수 있다. 이때, 할당된 제4 서버에서 상기 인코딩된 스트리밍 데이터를 이용하여 VOD 파일을 생성할 수 있다.
도 21은 본 발명의 일실시예에 따른 오픈형 생중계 플랫폼의 장애복구 방법의 예를 도시한 흐름도이다. 도 21의 장애복구 방법은 도 20의 동작 방법에 포함될 수 있으며, 도 20의 동작 방법과는 병렬적으로 실행될 수 있다.
단계(2110)에서 코디네이터(120)는 제1 서버 풀에서 관리되는 적어도 하나의 제1 서버와 제2 서버 풀에서 관리되는 적어도 하나의 제2 서버의 상태를 모니터링할 수 있다. 이미 설명한 바와 같이 코디네이터(120)는 오픈형 생중계 플랫폼(100)의 모든 서버들의 상태를 관리할 수 있다.
단계(2120)에서 코디네이터(120)는 제1 서버의 장애를 감지할 수 있으며, 제1 서버의 장애가 감지되는 경우 단계(2130)를 제1 서버의 장애가 감지되지 않는 경우 단계(2150)를 수행할 수 있다.
단계(2130)에서 코디네이터(120)는 할당된 제2 서버로 스트리밍 종료 이벤트를 전달하여 할당된 제2 서버를 대기 상태로 전환시킬 수 있다. 대기 상태의 제2 서버는 다른 방송의 인코딩을 위해 대기할 수 있다.
단계(2140)에서 코디네이터(120)는 송출자의 단말로부터 스트리밍 데이터가 재송출됨에 따라 제1 서버 풀에서 할당되는 다른 제1 서버의 요청에 따라 제2 서버 풀에서 새로운 제2 서버를 할당할 수 있다. 선택에 따라 새로운 제2 서버는 앞서 대기 상태로 전환된 기존의 제2 서버가 될 수도 있고, 기존의 제2 서버와는 다른 제2 서버가 될 수도 있다. 단계(2140) 이후 코디네이터(120)는 다시 단계(2110)을 수행하여 서버들의 상태를 모니터링할 수 있다.
단계(2150)에서 코디네이터(120)는 제2 서버의 장애를 감지할 수 있다. 이때, 제2 서버의 장애가 감지되는 경우 코디네이터(120)는 단계(2160)를 수행할 수 있으며, 제2 서버의 장애가 감지되지 않는 경우 다시 단계(2110)을 수행하여 서버들의 상태를 모니터링할 수 있다.
단계(2160)에서 코디네이터(120)는 제2 서버 풀에서 새로운 제2 서버를 할당할 수 있다. 이 경우, 할당된 새로운 제2 서버가 상기 할당된 제1 서버에 접속하여 상기 할당된 제1 서버로부터 상기 스트리밍 데이터를 수신하고, 상기 수신되는 스트리밍 데이터를 인코딩할 수 있다. 단계(2160) 이후 코디네이터(120)는 다시 단계(2110)을 수행하여 서버들의 상태를 모니터링할 수 있다.
이처럼 본 발명의 실시예들에 따르면, 논리적 스트리밍 클라우드를 통해 실제로 방송의 송출이 발생하는 시점에 동적으로 리소스를 할당할 수 있다. 또한, 동적이고 자율적인 코디네이션 시스템(코디네이터)을 통해 중앙 집중적인 제어 없이 방송 송출이 발생하는 시점에 송출 요청을 처리하기 위한 퍼블리싱 포인트 서버와 방송의 스트리밍 데이터를 인코딩하기 위한 인코딩 서버를 개별적으로, 그리고 동적으로 할당함에 따라 미리 특정 방송을 위해 서버가 예약된 상태로 대기할 필요 없이 모든 서버들을 효율적으로 활용할 수 있다. 또한, 퍼블리싱 포인트 서버나 인코딩 서버의 장애 시 서버들의 풀에서 새로운 퍼블리싱 포인트 서버나 인코딩 서버를 재할당함에 따라 장애가 발생한 서버를 자동적으로 복구할 수 있다. 또한, 국가나 지역 단위로 구별되는 구역(region)별로 논리적 스트리밍 클라우드를 구현하고, 국가별 논리적 스트리밍 클라우드의 서버들을 코디네이션 시스템을 통해 관리할 수 있으며, 서로 다른 구역간에 방송의 송출과 시청이 이루어지는 경우, 프록시 가속을 통해 네트워크 속도가 느린 사용자 구간을 최소화할 수 있다. 또한, 코디네이션 시스템을 통해 물리적 머신의 인코딩 성능에 따라 하나의 물리적 머신에서 동작될 인코딩 서버의 수를 동적으로 조절함으로써 물리적 머신을 안정적이고 효율적으로 사용할 수 있다. 또한, 스트리밍을 위한 서로 다른 복수의 서비스들 각각에서 제공되는 복수의 방송들에 대해서도 각각의 방송들에 대해 서비스와 상관 없이 독립적으로 채널을 관리함에 따라 서로 다른 서비스에서의 간섭 없이 안정적으로 서로 다른 서비스들 각각에서 제공되는 복수의 방송들 각각을 해당 서비스의 시청자들에게 제공할 수 있다. 또한, 채널별로 우선순위를 부여하고, 부여된 유선순위를 이용하여 중요 채널의 방송 송출을 보장할 수 있다.
이상에서 설명된 시스템 또는 장치는 하드웨어 구성요소, 또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 어플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.
소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치에 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록매체에 저장될 수 있다.
실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 매체는 컴퓨터로 실행 가능한 프로그램을 계속 저장하거나, 실행 또는 다운로드를 위해 임시 저장하는 것일 수도 있다. 또한, 매체는 단일 또는 수개 하드웨어가 결합된 형태의 다양한 기록수단 또는 저장수단일 수 있는데, 어떤 컴퓨터 시스템에 직접 접속되는 매체에 한정되지 않고, 네트워크 상에 분산 존재하는 것일 수도 있다. 매체의 예시로는, 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체, CD-ROM 및 DVD와 같은 광기록 매체, 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical medium), 및 ROM, RAM, 플래시 메모리 등을 포함하여 프로그램 명령어가 저장되도록 구성된 것이 있을 수 있다. 또한, 다른 매체의 예시로, 애플리케이션을 유통하는 앱 스토어나 기타 다양한 소프트웨어를 공급 내지 유통하는 사이트, 서버 등에서 관리하는 기록매체 내지 저장매체도 들 수 있다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다.
이상과 같이 실시예들이 비록 한정된 실시예와 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기의 기재로부터 다양한 수정 및 변형이 가능하다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.
그러므로, 다른 구현들, 다른 실시예들 및 청구범위와 균등한 것들도 후술하는 청구범위의 범위에 속한다.

Claims (21)

  1. 오픈형 생중계 플랫폼을 위한 시스템에 있어서,
    송출자의 단말로부터 송출되는 스트리밍 데이터를 수신하기 위한 적어도 하나의 제1 서버를 관리하는 제1 서버 풀;
    상기 제1 서버 풀에서 할당된 제1 서버로부터 상기 스트리밍 데이터를 전달받아 인코딩하기 위한 적어도 하나의 제2 서버를 관리하는 제2 서버풀; 및
    상기 제1 서버 풀 및 상기 제2 서버 풀의 서버들의 상태를 관리하고, 상기 제1 서버 풀에서 할당된 제1 서버의 요청에 따라 상기 제2 서버 풀에서 제2 서버를 동적으로 할당하는 코디네이터
    를 포함하고,
    상기 스트리밍 데이터가 상기 송출자의 단말에서 송출됨에 응답하여, 상기 제1 서버 풀에서 임의의 제1 서버를 동적으로 할당하고, 상기 할당된 제1 서버를 통해 상기 송출되는 스트리밍 데이터를 수신하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  2. 제1항에 있어서,
    상기 코디네이터는,
    상기 송출자의 방송이 등록되는 경우, 상기 방송을 위한 채널을 생성하고, 상기 채널에 대해 할당되는 고유 키를 이용하여 상기 방송의 스트리밍 데이터의 송출을 위한 송출 주소를 생성하고,
    상기 송출 주소를 통해 상기 방송의 스트리밍 데이터가 송출됨에 응답하여 상기 제1 서버 풀에서 임의의 제1 서버를 동적으로 할당하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  3. 제1항에 있어서,
    상기 코디네이터는,
    상기 할당된 제2 서버의 작업 목록에 방송 송출 작업을 등록하고,
    상기 제2 서버 풀에서 관리되는 적어도 하나의 제2 서버 각각은 자신의 작업 목록을 모니터링하고,
    자신의 작업 목록에 방송 송출 작업이 등록된 제2 서버가 상기 작업 목록에 등록된 정보를 이용하여 상기 제1 서버 풀에서 할당된 제1 서버를 식별하여 상기 할당된 제1 서버로부터 상기 스트리밍 데이터를 수신 및 인코딩하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  4. 제1항에 있어서,
    상기 스트리밍 데이터가 상기 송출자의 단말에서 송출됨에 응답하여, 상기 제1 서버 풀에서 임의의 제1 서버를 동적으로 선택하여 상기 송출자의 단말로부터 송출되는 스트리밍 데이터를 상기 선택된 제1 서버로 전달하는 스위치
    를 더 포함하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  5. 제1항에 있어서,
    상기 제1 서버 풀에서 관리되는 적어도 하나의 제1 서버와 상기 제2 서버 풀에서 관리되는 적어도 하나의 제2 서버 각각은 실행 시 상기 코디네이터에 등록되고,
    상기 코디네이터는,
    상기 등록된 적어도 하나의 제1 서버 및 적어도 하나의 제2 서버의 상태를 모니터링하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  6. 제1항에 있어서,
    상기 코디네이터는,
    상기 할당된 제1 서버의 장애를 감지하는 경우, 상기 할당된 제2 서버로 스트리밍 종료 이벤트를 전달하여 상기 할당된 제2 서버를 대기 상태로 전환시키고, 상기 송출자의 단말로부터 상기 스트리밍 데이터가 재송출됨에 따라 상기 제1 서버 풀에서 할당되는 다른 제1 서버의 요청에 따라 상기 제2 서버 풀에서 새로운 제2 서버를 할당하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  7. 제1항에 있어서,
    상기 코디네이터는,
    상기 할당된 제2 서버의 장애를 감지하는 경우, 상기 제2 서버 풀에서 새로운 제2 서버를 할당하고,
    상기 할당된 새로운 제2 서버는 상기 할당된 제1 서버에 접속하여 상기 할당된 제1 서버로부터 상기 스트리밍 데이터를 수신하고, 상기 수신되는 스트리밍 데이터를 인코딩하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  8. 제1항에 있어서,
    상기 동적으로 할당된 제2 서버에 의해 인코딩된 스트리밍 데이터를 저장하는 분산 파일 시스템; 및
    시청자 단말의 방송 시청 요청을 수신하고 상기 분산 파일 시스템에서 상기 인코딩된 스트리밍 데이터를 상기 시청자 단말로 제공하기 위한 적어도 하나의 제3 서버를 관리하는 제3 서버 풀
    을 더 포함하고,
    상기 시청자 단말의 방송 시청 요청에 응답하여 상기 제3 서버 풀에서 임의의 제3 서버를 동적으로 할당하고, 상기 할당된 제3 서버를 통해 상기 분산 파일 시스템에서 상기 인코딩된 스트리밍 데이터를 상기 시청자 단말로 제공하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  9. 제8항에 있어서,
    상기 시청자 단말의 방송 시청 요청에 응답하여 상기 제3 서버 풀에서 임의의 제3 서버를 동적으로 선택하여 상기 방송 시청 요청을 상기 선택된 제3 서버로 전달하는 스위치
    를 더 포함하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  10. 제8항에 있어서,
    국가 및 지역 중 적어도 하나에 따라 구분되는 구역(region)마다, 상기 제1 서버 풀, 상기 제2 서버 풀, 상기 분산 파일 시스템 및 상기 제3 서버 풀이 구성되는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  11. 제10항에 있어서,
    서로 다른 구역의 제3 서버들간에 전용선이 연결되고,
    제1 구역에서 송출되는 스트리밍 데이터는 제1 구역의 제1 서버로 전달되어 제1 구역의 제2 서버에 의해 인코딩되고, 제1 구역의 제3 서버를 통해 제1 구역에 위치하는 시청자 단말로 제공되고, 제1 구역의 제3 서버와 전용선으로 연결된 제2 구역의 제3 서버를 통해 제2 구역에 위치하는 시청자 단말로 더 제공되는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  12. 제1항에 있어서,
    상기 코디네이터로부터의 VOD 파일 생성 요청에 따라 상기 할당된 제2 서버를 통해 인코딩된 스트리밍 데이터를 이용하여 VOD 파일을 생성하기 위한 적어도 하나의 제4 서버를 관리하는 제4 서버 풀; 및
    요청자 단말로부터 상기 VOD 파일에 대한 요청을 수신하고 상기 요청에 따라 상기 생성된 VOD 파일을 상기 요청자 단말로 제공하기 위한 적어도 하나의 제5 서버를 관리하는 제5 서버 풀
    을 더 포함하는 것을 특징으로 하는 오픈형 생중계 플랫폼을 위한 시스템.
  13. 오픈형 생중계 플랫폼의 동작 방법에 있어서,
    송출자 단말로부터 스트리밍 데이터가 송출됨에 응답하여 제1 서버 풀에서 할당된 임의의 제1 서버로부터 상기 스트리밍 데이터의 인코딩을 위한 제2 서버의 할당 요청을 수신하는 단계; 및
    상기 수신된 할당 요청에 따라 제2 서버 풀에서 임의의 제2 서버를 동적으로 할당하는 단계
    를 포함하고,
    상기 동적으로 할당된 제2 서버가 상기 제1 서버로부터 상기 스트리밍 데이터를 전달받아 인코딩하는 것을 특징으로 하는 동작 방법.
  14. 제13항에 있어서,
    상기 임의의 제2 서버를 동적으로 할당하는 단계는,
    상기 임의의 제2 서버의 작업 목록에 상기 스트리밍 데이터에 대한 방송 송출 작업을 등록하고,
    상기 제2 서버 풀에서 관리되는 적어도 하나의 제2 서버 각각은 자신의 작업 목록을 모니터링하고,
    자신의 작업 목록에 방송 송출 작업이 등록된 제2 서버가 자신의 작업 목록에 등록된 정보를 이용하여 상기 제1 서버 풀에서 할당된 제1 서버를 식별하여 상기 할당된 제1 서버로부터 상기 스트리밍 데이터를 수신 및 인코딩하는 것을 특징으로 하는 동작 방법.
  15. 제13항에 있어서,
    상기 인코딩된 스트리밍 데이터는 분산 파일 시스템에 저장되고,
    시청자 단말의 요청에 따라 제3 서버 풀에서 동적으로 할당된 제3 서버에서 상기 분산 파일 시스템에 저장된 상기 인코딩된 스트리밍 데이터를 다운로드하여 상기 시청자 단말로 제공하는 것을 특징으로 하는 동작 방법.
  16. 제13항에 있어서,
    상기 송출자의 방송이 등록되는 경우, 상기 방송을 위한 채널을 생성하고, 상기 채널에 대해 할당되는 고유 키를 이용하여 상기 방송의 스트리밍 데이터의 송출을 위한 송출 주소를 생성하는 단계
    를 더 포함하고,
    상기 송출 주소를 통해 상기 방송의 스트리밍 데이터가 송출됨에 응답하여 상기 제1 서버 풀에서 임의의 제1 서버가 동적으로 할당되는 것을 특징으로 하는 동작 방법.
  17. 제13항에 있어서,
    상기 제1 서버 풀에서 관리되는 적어도 하나의 제1 서버와 상기 제2 서버 풀에서 관리되는 적어도 하나의 제2 서버의 상태를 모니터링하는 단계
    를 더 포함하는 것을 특징으로 하는 동작 방법.
  18. 제17항에 있어서,
    상기 할당된 제1 서버의 장애를 감지하는 경우, 상기 할당된 제2 서버로 스트리밍 종료 이벤트를 전달하여 상기 할당된 제2 서버를 대기 상태로 전환시키는 단계; 및
    상기 송출자의 단말로부터 상기 스트리밍 데이터가 재송출됨에 따라 상기 제1 서버 풀에서 할당되는 다른 제1 서버의 요청에 따라 상기 제2 서버 풀에서 새로운 제2 서버를 할당하는 단계
    를 더 포함하는 것을 특징으로 하는 동작 방법.
  19. 제17항에 있어서,
    상기 할당된 제2 서버의 장애를 감지하는 경우, 상기 제2 서버 풀에서 새로운 제2 서버를 할당하는 단계
    를 더 포함하고,
    상기 할당된 새로운 제2 서버는 상기 할당된 제1 서버에 접속하여 상기 할당된 제1 서버로부터 상기 스트리밍 데이터를 수신하고, 상기 수신되는 스트리밍 데이터를 인코딩하는 것을 특징으로 하는 동작 방법.
  20. 제13항에 있어서,
    제4 서버 풀에서 VOD 파일의 생성을 위한 임의의 제4 서버를 할당하는 단계
    를 더 포함하고,
    상기 할당된 제4 서버에서 상기 인코딩된 스트리밍 데이터를 이용하여 VOD 파일을 생성하는 것을 특징으로 하는 동작 방법.
  21. 제13항 내지 제20항 중 어느 한 항의 방법을 컴퓨터에 실행시키기 위한 프로그램이 기록되어 있는 것을 특징으로 하는 컴퓨터에서 판독 가능한 기록매체.
PCT/KR2018/013152 2017-11-02 2018-11-01 오픈형 생중계 플랫폼 WO2019088721A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020170145200A KR102024637B1 (ko) 2017-11-02 2017-11-02 오픈형 생중계 플랫폼
KR10-2017-0145200 2017-11-02

Publications (1)

Publication Number Publication Date
WO2019088721A1 true WO2019088721A1 (ko) 2019-05-09

Family

ID=66332418

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/013152 WO2019088721A1 (ko) 2017-11-02 2018-11-01 오픈형 생중계 플랫폼

Country Status (2)

Country Link
KR (1) KR102024637B1 (ko)
WO (1) WO2019088721A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111277908A (zh) * 2020-01-16 2020-06-12 北京达佳互联信息技术有限公司 数据处理方法、装置、服务器、直播系统及存储介质
CN112752115A (zh) * 2020-12-29 2021-05-04 广州博冠信息科技有限公司 直播数据传输方法、装置、设备及介质
CN113315981A (zh) * 2021-04-27 2021-08-27 北京达佳互联信息技术有限公司 任务数据更新方法、装置、系统、电子设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040001355A (ko) * 2002-06-27 2004-01-07 주식회사 케이티 멀티미디어 컨텐츠 분배망 구성 방법 및 그를 이용한멀티미디어 컨텐츠 서비스 방법
JP2004054448A (ja) * 2002-07-18 2004-02-19 Nippon Telegr & Teleph Corp <Ntt> ポータルサーバによるストリームサーバ・コンテンツ選択方法，ストリーム配信のためのポータルサーバおよびそのプログラム
KR20110076831A (ko) * 2009-12-28 2011-07-06 (주)주인네트 분산 네트워크 ｐｖｒ 시스템 및 그 서비스 방법
KR20140071545A (ko) * 2012-11-22 2014-06-12 주식회사 미리내소프트 서버 부하 균형 관리를 통한 방송 서비스 제공 시스템
KR20140078507A (ko) * 2012-12-17 2014-06-25 주식회사 캐스트이즈 수요 적응형 스트리밍

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090059244A (ko) * 2007-12-06 2009-06-11 주식회사 프리먼트 라이브 멀티 채널 동영상의 대용량 분산처리를 위한 자동분류 방법 및 그 시스템

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040001355A (ko) * 2002-06-27 2004-01-07 주식회사 케이티 멀티미디어 컨텐츠 분배망 구성 방법 및 그를 이용한멀티미디어 컨텐츠 서비스 방법
JP2004054448A (ja) * 2002-07-18 2004-02-19 Nippon Telegr & Teleph Corp <Ntt> ポータルサーバによるストリームサーバ・コンテンツ選択方法，ストリーム配信のためのポータルサーバおよびそのプログラム
KR20110076831A (ko) * 2009-12-28 2011-07-06 (주)주인네트 분산 네트워크 ｐｖｒ 시스템 및 그 서비스 방법
KR20140071545A (ko) * 2012-11-22 2014-06-12 주식회사 미리내소프트 서버 부하 균형 관리를 통한 방송 서비스 제공 시스템
KR20140078507A (ko) * 2012-12-17 2014-06-25 주식회사 캐스트이즈 수요 적응형 스트리밍

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111277908A (zh) * 2020-01-16 2020-06-12 北京达佳互联信息技术有限公司 数据处理方法、装置、服务器、直播系统及存储介质
CN111277908B (zh) * 2020-01-16 2021-04-06 北京达佳互联信息技术有限公司 数据处理方法、装置、服务器、直播系统及存储介质
US11570520B2 (en) 2020-01-16 2023-01-31 Beijing Dajia Internet Information Technology Co., Ltd. Method for data processing and live broadcast system
CN112752115A (zh) * 2020-12-29 2021-05-04 广州博冠信息科技有限公司 直播数据传输方法、装置、设备及介质
CN112752115B (zh) * 2020-12-29 2023-09-08 广州博冠信息科技有限公司 直播数据传输方法、装置、设备及介质
CN113315981A (zh) * 2021-04-27 2021-08-27 北京达佳互联信息技术有限公司 任务数据更新方法、装置、系统、电子设备及存储介质
CN113315981B (zh) * 2021-04-27 2023-09-05 北京达佳互联信息技术有限公司 任务数据更新方法、装置、系统、电子设备及存储介质

Also Published As

Publication number Publication date
KR20190050068A (ko) 2019-05-10
KR102024637B1 (ko) 2019-09-24

Similar Documents

Publication Publication Date Title
WO2019088721A1 (ko) 오픈형 생중계 플랫폼
WO2011136481A2 (ko) 고화질 미디어 방송을 위한 피투피 라이브 스트리밍 시스템 및 방법
EP3304942A1 (en) Method and apparatus for sharing application
WO2012011726A2 (en) Method and apparatus for providing drm service
WO2012023829A2 (en) Method and apparatus for transmitting and receiving data based on secured path bandwidth in network established by using audio/video interface
WO2016171401A1 (ko) 공동 편집 문서를 공유하는 방법 및 장치
WO2010071269A1 (en) Request signal of an image program according to specific input sources based on the received list to the external display devices
WO2013180440A1 (en) A method and system for self-broadcasting in a social experience environment
WO2016129963A1 (ko) 멀티뷰 스트리밍 서비스 지원 방법 및 이를 지원하는 장치
WO2018080123A1 (ko) 멀티 화면을 위한 영상 송출 장치
WO2011136537A2 (en) Method and apparatus for transmitting content to plurality of devices
WO2014204192A1 (en) Apparatus and method for receiving broadcast content from a broadcast stream and an alternate location
WO2016061887A1 (zh) 一种视频转换方法、装置、播放系统及终端
WO2021125502A1 (ko) 컨테이너 기반의 클라우드 서비스 제공 시스템 및 그 방법
WO2019112360A1 (ko) 지연 생중계를 위한 방법 및 시스템
WO2013069981A1 (en) Communication system and operating method using home gateway
WO2020153797A1 (en) Method and apparatus for managing data in a network based on swarm intelligence
WO2012141501A2 (ko) Cas 서비스를 제공하기 위한 cas 서비스 시스템 및 그 운용방법
WO2017155371A1 (ko) 디지털 방송 시스템에서의 서비스 제공장치 및 방법
WO2019107955A1 (ko) 분산 트랜스코딩의 시간 단축을 위한 최적화 방법 및 그 시스템
WO2019107914A1 (ko) 분산 트랜스코딩 방법 및 분산 트랜스코딩 시스템
WO2020138567A1 (ko) 컨텐츠 스트리밍 장치, 시스템 및 방법
WO2013154364A1 (ko) 스트리밍 재생 방법 및 이를 이용한 컴퓨팅 장치
WO2013180348A1 (ko) 화면 가상화 기반 애플리케이션 구동 시스템 및 방법
WO2016080585A1 (en) System and method for providing cloud based user interfaces

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18872013

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18872013

Country of ref document: EP

Kind code of ref document: A1