Jitsi Videobridge acts as the media server hence is the component which consumes the most resources. Scaling it becomes a necessity when the traffic starts to increase in your system. The jitsi performance test shows that a single videobridge can handle 1000 streams on a c5.xlarge server at 550Mbps bitrate. This blog describes how to autoscale jitsi videobridge and please note scaling the whole platform is different which requires to have multiple shards, load balancing, geo cascading etc. which will be discussed in a future post.
When the number of streams increase the bandwidth and CPU usage of the server increases.
The number of streams increase with both the increase of number of participants and increase of number of parallel conferences. It will reach to a point where the server would max out which on most occasions be the bandwidth.
This would mean we would need more servers to handle the load. If the traffic does not vary we can simply add more servers to meet the traffic. But on most scenarios the traffic varies and the solution needs to adjust to the requirements. This is where a solution like autoscaling is necessary where the servers would spin up or shutdown according to the traffic conditions.
There are few platforms or methods to handle auto scaling.
In this blog we would be discussing the first method where we would completely relying on AWS services for handling the scaling end to end.
Mainly the following services would be used
AWS EC2 - All the servers would be c5.xlarge (i.e. considering both network and bandwidth capabilities) EC2 instances
AWS EC2 Autoscaling groups - These groups are responsible for handling the autoscaling functionality of the servers. We can set scaling up and scaling down policies, create launch configurations, adjust parameters like max, min capacities of the group. We will explain more in a bit.
AWS SQS - Keeps the details of performance of the servers as a message queue.
AWS Cloudwatch - Cloudwatch monitor the servers and fires alarm when the defined thresholds are reached.
Jitsi-Meet- Web component of the system and all the videobridges from the group connect to this
We won’t go into details but provide a high level overview of the steps involved.
Install Jitsi-Meet on a EC2 Server
Install JVB in a EC2 server, create a script in JVB which will check with SQS per every minute Finally create an AMI of JVB.
Create a launch configuration in EC2 - This configuration would be used to spin up new servers when scaling up. For the configuration use the AMI created on the previous step. Choose the instance type as per your requirements ( We recommend to go for c5.xlarge or above). Please provide the other information accordingly.
Create an autoscaling group
Go to the created autoscaling group and create a dynamic scaling policy. Select “Target Tracking scaling” and select Metric type as “Network out”. Give the threshold value considering the network bandwidth capabilities of the server (for example c5.xlarge supports 10Gbps and keeping a safe margin we can chose 70% of this which is 875000000 bytes). Create another policy with keeping network out as 375000000 bytes.
Create lifecycle hooks for both instance launch and instance terminate which will be used by the queue to get details about the server.
Create a queue using SQS
This blog only explains in high level how the autoscaling is handled in aws. The setup is complex to be explained in a single blog. We will discuss about other methods as well in future blog posts.
If you are interested in hiring us to scale your solution please contact us through firstname.lastname@example.org and please visit telzee.io for more details.