5 Reasons to Autoscale with Red5 Pro

TrueTime Solutions
SHARE

Scaling an application to a very large audience can be tricky. Our autoscaling solution has successfully managed some of that process automatically. However, our latest version covers even more and does it, dare I say, automagically. Before we get too deep into that, let’s go over how the autoscaling infrastructure is created and configured. For… Continue reading 5 Reasons to Autoscale with Red5 Pro


Scaling an application to a very large audience can be tricky. Our autoscaling solution has successfully managed some of that process automatically. However, our latest version covers even more and does it, dare I say, automagically.

Before we get too deep into that, let’s go over how the autoscaling infrastructure is created and configured. For those that want to dig right into our new feature scroll down or jump right to our documentation.

Autoscaling Basics – Everything a Growing App Needs

A basic autoscaling cluster (nodegroup) consists of three server instances (nodes): origin (for broadcasters), edge (for subscribers) and a Stream Manager which negotiates the autoscaling process.

The Stream Manager requires the creation of two configurations: a launch configuration and the scale policy. The launch configuration tells the Stream Manager the type and capacity of the instance to use. The scale policy specifies how many instances are needed per instance role; origin or edge. Lastly, the nodegroup needs to be manually created and initialized with an origin using the stream manager REST api.

However, our latest release has simplified the process a bit.

New Approach – Now With More Convenience

Once the launch is completed, the launch configuration can be created prior to the event at any time, since it specifies the instance type to use and the capacity of each instance type. The process for creating a launch configuration is same as before: using the REST api.

As for the scale policy, the calculation of the required number of origins and edges is automatically calculated by the Stream Manager itself rather than manually specified. It simply needs an estimate of the expected minimum and maximum number of publishers and subscribers.

All this is achieved through the new smart group creation api. The api facilitates the automatic creation of the scale policy based on traffic estimates subsequently creating and initializing the nodegroup with an origin.

Resizing – Make Adjustments, not Disruptions

So what happens when a burst traffic of traffic necessitates increasing the capacity of an already existent nodegroup?

In the old days, the nodegroup would be deleted and a new scale policy for a new cluster would be created right before that happens. However, this posed a problem when the current group had an ongoing session on it.

Again, the new smart group api swoops in to save the day. Using the resize group action, you can specify the new traffic requirements like the minimum and maximum publishers/subscribers The stream manager will scale the group in real time by making necessary configurations changes without disrupting any live traffic.

Scheduler – Stay on Track

Now that we made the autoscaling process simpler and smarter, we needed to make it more convenient as well. Spinning up new instances is a great way to deal with an increase in network traffic, but it takes a few minutes to create those new servers.

Perhaps there’s a live streaming session happing very early in the morning on Monday but it’s likely that no one will be available to set it all up, because there’s a big company-wide party Sunday night. Or maybe (and more soberly) what if there’s a major event happening at a specific time (like HQ trivia for example) and there’s going to be a large audience tuning in at the same time. They can’t be sitting around waiting for new instances to spin up.

Fear not, for the Event Scheduler is here!

The stream manager event scheduler can allocate a job to automatic- excuse me, automagically create and resizing a nodegroup at any future date/time. You can schedule a job to create or update a cluster at a specific time. All that’s required is the estimated traffic that will be experienced. When the time arrives, streammanager will correspondingly create the cluster with the required serving capacity and have it ready for use.

Then, anticipating a rush hour boom, another event can be scheduled to increase the capacity of the cluster. Stream Manager will promptly scale your cluster at the requested time to the new capacity without disrupting the existing traffic.

Creativity – Future Innovations

You can always connect the Stream Manager scheduler using its api endpoints to any external system and control it from there. Maybe you have an existing system that uses Google Calendar api. You can have you system command stream manager scheduler using the REST api to schedule new events.

Have better ideas or a custom requirement? Please feel free to request a call with us or send a message to info@red5.net.