본문 바로가기
[AWS]/Highly Available, Scalable, AWS Stack

21. Configure sticky sessions

by SAMSUNG CLOUD-OKY 2022. 1. 23.
반응형

 

로드 밸런서는 쿠키를 사용하여 자체 쿠키를 사용하여 단순히 고정되도록 만드는 것임을 기억하십시오.

응용 프로그램 세션에 대해 아무것도 모릅니다.

여기에서 두 가지 다른 일이 일어나고 있으며 동기화해야 함을 이해하십시오.

"로드 밸런서 세션 고정"과 "고유한 애플리케이션 세션 고정"

 

 

In this video let's set up sticky sessions right.

And let us start by understanding what the problem is.

Right.

And the problem is that when the user goes to the load balancer.

Right and the load balancer will send this user to one server initially the next the next page that

the user visits will go to the other server.

So let's say the user creates a session on this.

Server so this is server number one and we have two servers in this architecture.

Now what happens is when the user goes to another page on the application or maybe refreshes the same

page the user will be sent by the load balancer to the other server.

OK.

Because the load balancer does something simple which is say round robin distribution.

So it just sends the second request of the user to the other server and here the user has no session.

the session is not created on this.

Server, Right.

So these will be asked to log in once again.

You know if you are talking about a regular application right the user will see a log in page once again even

though the user may have logged in just a few seconds back.

Right so this is the problem.

And first let's verify that this problem does exist.

So what I'm going to do is I will edit the two session pages.

So we have two servers.

So we have session dot php in both I'll edit the pages and we'll add some sort of server identifier.

Maybe the server ID right so the instance ID

we can add to the session dot PHP page.

So we have a session dot PHP page so we edit the page this page on both instances right and we add the

instance ID of that instance to that page.

Right so same thing same thing with your same thing over here.

And this way when we visit the load balancer and the session dot PHP page once we will see this instance

ID and then refresh we will see the other instance ID the second time we refresh we will again come

back to this server.

So we'll see this instance id.

So this way we know that the the load balancer is sending us to the two servers in a round robin fashion right

after that we will create a session.

So we create a session on one of these servers.

Doesn't matter which one but we create a session by filling up that form and submitting our name because

we create a session and the session will be in let's say in the first server and then when we refresh ideally

the session.

Should should stick it should stick.

But we will find that it doesn't and when we will be sent to the other server where we will see the form

instead of the welcome message.

OK so let's let's try and verify verify this first one to verify that.

Right.

We'll then configure the load balancer and we will configure sticky sessions.

Indeed the load balancer.

So we just have to.

Just a simple configuration.

We just enable it and we can configure the duration.

And this should ideally match the duration of your sessions in your application.

But we will not worry so much about how to configure this.

But basically we can enable sticky sessions right and then we'll come back and verify

and verify that the session this time is sticky.

So this time when the user creates a session and we refresh we should go back to the same server and

we should see the welcome message rather than the form.

OK so this is what we want to do in this video.

Let's see let's see how to do this.

First we verify that the sessions are not sticky.

Then we configure sticky sessions and then verify that the problem has gone away.

OK.

All right.

Let's see this how to do first test verify that the sessions are not sticky.

So what I will do is really look at each of these instances right and we will essentially SSH into these

instances one by one.

Right.

So the first one and I will edit the sessions Page edit the sessions page in these servers.

Something like this.

OK.

And I'll add these server IP.

The public IP address to the H1 tag here.

So this way when we load this page we will see this IP address and we know that the response is from

this particular.

Server.

Right.

And so this is the first number.

We have edited let's now find the IP address of the second one

this one all right.

And let's do the same process.

S-sh OK.

And then we edit the session page on this server.

And of course we will add this sever's IP address to the H1 tag like this OK.

Now once we do this let's see what happens on the load balancer so.

So if you do a refresh on the load balancer and remember we are talking about the sessions page so let's go to that

page and you can see the response right now is from server 220 ending with 220.

The last three digits.

Now if I refresh you can see the IP address changes.

This one now is 133 right.

So if you keep doing this you'll see the load balancer is switching us from one server to the other and back.

OK so it seems to be doing a perfect round robin.

All right.

Now we need to verify if the sessions are sticky or not.

the application sessions are sticky or not.

So let me enter this form.

Which means we will be creating a session we are creating a session.

So let me submit this form here.

OK.

And notice that the session has been created.

But on the other server.

Ok because the load balancer keeps sending us from one side to the other.

So when we submit the form the session has actually been created.

On the other.

Server.

So let's do a refresh now and you can see we are seeing the welcome message in several 220 like this one.

Okay.

And now if I hit refresh again you can see it goes to 133 which means it is not recognizing the application

session load balancer and knows nothing about the application session and it keeps doing the round robin this

way.

Now we know that session stickiness is not there.

We don't have session stickiness at the moment.

Right.

So how do we solve this.

Well we can configure session stickiness in the target group but it's it's a load balancer feature.

But the configuration you can do by going to the target group here right and in the description tab

we will just scroll down and you'll find stickiness attribute right.

So this attribute we will edit and lets enable this for now let us not worry about the duration.

Let's just enable the stickiness.

And once that happens it may take a few seconds to take effect but but now let's try this again.

So let's see.

Let me refresh once again.

So it's now on 220.

Let me refresh once again.

Now we can see it stays on 220 it stays on it.

OK.

Right.

And you can see that I've refreshed multiple times and it's not moving away to the other to the other server.

So basically this is how you can verify that now the session is sticky.

Now remember we could have been on the other server where we had not created the application session

right so had we been on the other server.

right.

133 then if we kept refreshing there we would keep seeing the form because we've not really created

the applications session on that other server right.

So remember the load balancer is simply making it sticky right using its own cookie using a cookie.

It doesn't know anything about the application session.

Right so so so understand right that there are two different things happening here and you need to synchronize

the load balancers session stickiness with your own applications sessions stickiness.

This is something for you to experiment with and learn about.

By the end you can research this topic more as well.

But but hopefully now you're equipped to set this up.

Give this a try.

And and have some understanding of session stickiness and also the stickiness feature of the load balancer.

OK.

So good luck with this task.

 

 

 

 

반응형

댓글