Hear you.
And welcome back.
Now, in today's video, we'll be discussing about the sticky sessions.
Now, before we go ahead and understand about this topic, let's look into a typical challenge.
Now, generally in a load balancer based setup, the traffic from the users are distributed among multiple
backend servers.
For example, let's say a user one first request that he makes, it might go to server one.
The second request that he makes, it might go to the server two and so on.
So the traffic gets distributed.
Same goes with the user too.
Same goes with the user.
Three.
Now, if a subsequent requests are routed to different servers altogether, then the session information
is also lost.
For example, let's say that you are going to a bank.
You have some issues.
You went to the bank, you explained the entire problem to a person, a now person.
A has asked you to come tomorrow so that an appropriate solution can be applied.
Now, you went tomorrow and the person was not there.
So what happened?
You now went to a person.
B, now person B does not know really about your problem.
So again, you have to explain the entire problem to person B So this is what really happens in the
load balancer based setup as well.
Now, generally for static website, it does not really create a big issue because a website is static.
Both the server has same set of pages for the dynamic websites.
It really becomes a problem.
Now one of the ways in which this can be solved is through the sticky session.
So Sticky session refers to a feature of many load balancers to root the request for a particular session
to same physical machine that service the first request of that session.
So a user, a first request that he made went to the server one.
Now subsequent request request to request three request for all of the requests that he'll make.
All of those requests will go to the server one itself.
Again, taking an example of a bank, you went on a day one, you met person a day two again, you met
person A day for again, you met person A So you are meeting the same person in the bank and he knows
about all of your ongoing issues as well as all of your past issues.
So he'll be able to help you in a much more efficient way.
So this is where the sticky session also comes into picture.
Now, sticky sessions are also supported in side of load balances.
So let's discuss about application load balancer first.
So by default, the application load balances out each request independently to a registered target
based on a chosen load balancing algorithm.
Very similar to what we were discussing in the first slide with the request might first go to server
one, then it might go to server two and so on.
However, in case if you need, you can also make use of a sticky session feature to enable the load
balancer to bind a user's session to a specific target.
Now if you see you have web browser, one web browser, two web browser, one makes a request, one
or two are three to the load balancer, load balancer will direct.
All of the requests are one or two are three to the same EC two instance.
Now this setup is applicable after the sticky session is enabled.
Otherwise the load balancer might direct the request r one to e.
c2122e.
c2232, e, c23 and so on.
So let's do one thing.
Let's go ahead and look into it.
Now for today's setup, I have two load balancers available.
One is the application load balancer and second one is the classic load balancer and we'll look into
how we can enable sticky sessions here.
First, let's go ahead and explore the application load balancer.
Now, at this stage you do not really have a sticky session enable.
Let's go ahead and copy this up.
Now, before we go ahead and explore this, let me also show you the instances.
So there are two EC, two instances that are running Engine X and the load balancer, both the classic
as well as the application are associated with these C two instances.
So let me go ahead and paste the URL of the application load balancer.
First, it went to the EC two instance, number two, which has a page class website to.
If I refresh it went to the website one which is easy to instance.
One let's refresh.
Now it went to website two.
So classic state of load balancing where multiple requests are routed to different servers all together.
Now let's say that we do not really want it.
So what we can do, we can enable sticky sessions.
However, before we enable sticky sessions.
Let me show you the exact response headers of HTTP.
So these are all the response headers.
Now we'll keep a note of it and we'll be looking into the response headers after the sticky session
is enabled.
So now within the load balancer, specifically for the application load balancer, let's go to the target
group that is associated with our ALB.
There is only one target group that is associated.
Let's go ahead and edit the attributes of the target group and you have an option of stickiness.
Let's enable stickiness.
And now it is asking for the stickiness duration, which can be from one second to seven days.
You can also select things accordingly.
Let me say stickiness of one day.
So I'll go ahead and I'll save the change.
So now that we have sticky sessions, enable the request will go to a specific EC two instances only
for the duration of our sticky session.
Let's go ahead and explore that.
So let me refresh the page.
It's going to website two.
Let's refresh again.
Again, website two, Let's refresh third time website two, fourth time website two and fifth time
website two.
So this is what the sticky sessions allows us to do.
Now, in a similar way, let's again make a call request.
And now you see into the response headers between the first one and the second one.
One of the additional thing that is added is a cookie.
The name of the cookie is a plus AILBHE and then you have the cookie related information.
So once you enable the sticky sessions, you also have to add a cookie.
Now, cookie is something which your web browser will send back to the load balancer.
Load balancer will read the cookie and it will identify that this user was directed to the EC two instance
one.
So once it reads the cookie again, it will direct the user to the EC two instance one itself.
So this is how the load balancer knows that a specific client needs to be directed to a specific server
grid.
Now, when it comes to the application load balancer, you can set the sticky session at the target
group level.
However, for the classic load balancer, you can go ahead.
And enable the stickiness.
So currently the stickiness is disabled.
You can go ahead and enable the stickiness here itself.
Similar to the application load balancer, you can specify the expiration period.
So let's quickly revise the workflow.
So whenever a client makes a request to the load balancer, load balancer will create a cookie.
So in this case, the cookie states target is equal to EC two one.
So the request is directed to the EC two one and the cookie is sent back to the client.
Now client when he makes next request to the load balancer, the client needs to send the cookie that
was sent to it by the load balancer.
After the client sends back the cookie to the load balancer.
The load balancer can understand that this cookie was associated with the EC two one, and the second
request will also be sent to the EC.
Two one.
If the cookie is not really sent again, it depends upon the algorithm used.
If the cookie is not really sent, the elastic load balancer might not really know and it might direct
that request to the EC two instance too.
So this is the high level workflow on one of the ways in which the sticky sessions are established.
Now let's quickly look into the advantages of sticky sessions.
First one is that when the sticky sessions are used, the servers do not really need to exchange the
session data, which can minimize the data transfer.
Otherwise, a session data needs to be exchanged between all of the servers so that they can remember
what exactly the user had come for.
Second is sticky sessions can allow better utilization of your RAM cache that can lead to better responsiveness.
Now, let's also look into some of the disadvantages.
First one is that with sticky sessions, the overall load balancing of traffic between servers can be
affected.
Very important.
Part two Remember, it can happen that a specific server can be overloaded if it accumulates too many
sessions or if specific sticky sessions require high number of resources.
So if ten users are directed to the EC2 instance, one let's say sticky session is enabled for three
days of duration.
And if all of the ten servers are directed to the EC two instance one however, the EC two instance
two is completely empty.
There are no sessions or there are no connections at all.
So now what will happen?
The EC two instance one is overloaded because all of the users that had the existing cookie are directed
to the EC two instance one.
So this can be a disadvantage of sticky sessions.
Great.
So this is a very high level overview about the basics of sticky sessions and with this will conclude
today's video.