22. Intro: Scalability - app layer

 

## 우리는 지난 시간에 로드밸런서 고정 세션을 사용합니다.

그리고 이것은 고정된 수의 서버에 적합합니다.

 

## 하지만 오토 스케일링을 사용하여 새로운 애플리케이션을 디자인하거나
애플리케이션을 다시 엔지니어링할 기회가 있다면,

세션을 처리하는 가장 좋은 방법은 이미지를 중앙 집중화하는 것처럼 세션을 중앙 집중화하는 것입니다.

--> DynamoDB 및 IAM 역할을 활용

 

 

 

 

 

 

Welcome to Module four now in this module, we want to add scalability to our application, right?

And we look at the application layer in this module and in the next one, we look at the scalability

for the data layer.

But if you look at the previous module, we had fault tolerance, we addressed fault tolerance.

And this was for multi-tier architecture.

Is what we looked at.

And this is pretty good because because we use multiple instances, we use multiple Azeez, we have

replication and so on.

And so there's no data loss.

Right.

And there's no downtime.

So this is something to be solved in the previous module.

But if you look at this architecture that we had, then it's quite rigid and you have to servers.

And what if there are more users or more requests coming into the application and those two servers

may become overloaded and then there will be performance degradation.

And also sometimes the application can crash.

Right.

So so in this module, we want to solve this problem by the scalability challenge.

And remember, scalability means we have the same performance.

Right.

No matter what the law is, that's what we want to achieve.

Right.

So one good way of doing that is to use auto scaling groups or groups of easy to instances.

And it is very simple to to scale the group so we can scale out.

We can scale out, which means we can add more servers and we can scale in which which means we can

reduce the number of cells, right.

So the scale in also is important because although we want more performance, we also want to reduce

cost when there's no load without scaling.

And what happens is because we can scale out, we get the performance when we need to and because we

can scale in easily, we get the cost efficiency by using auto scaling groups.

So, so, so, so what will happen is let's say there's more load.

You can auto scaling, we'll scale out, which means we'll have more cells like this.

You can have any number of cells.

Right.

And this will take care of the performance aspect as the load increases and when the load goes away,

then the cells will be produced automatically.

So these will be removed.

Right, and this takes care of the cost efficiency side, right?

And there are many ways of scaling back, using manual scaling.

Right.

You can manually say how many service you want.

Right.

Or you can have scheduled policies.

You can also have dynamic policies or policies, so you can scale the group in many different ways.

OK, but effectively we have most of us where we need to have less of us, but we don't need those cells.

Right.

So this is something we do.

However, when we do that, there's a new problem.

So the problem is, again, to do with sessions.

So last time as well, the last module we saw, we had a problem with sessions which we solved using

sticky sessions.

But this time it's a different problem.

OK, so what happens is let's say the user user goes to be load balancer and we load balancer since

this user to this particular server.

But the user has a session.

Right.

And because we have sticky sessions, what happens is the user is sent to the same server right now

because of the scale in operation.

This server may go away.

Right.

And the session will be lost.

And the next time the user comes to the application, this time the user may be sent to a server, which

is still available.

Right.

And there's no session there's no session on this server for this particular user.

So the user will will, you know, abruptly lose the session and may have to log in again.

And this may happen again and again and again during our particular day.

Right.

And this can be this is very bad from a user perspective.

Right.

And we need to we need a better solution.

So we use sticky sessions last time.

And this is OK for a fixed number of servers.

And this is especially OK for legacy applications, which store sessions on the on the final system.

Right.

But if you're designing a new application or if you have the opportunity to reengineer your application,

the best way to handle sessions is to centralize it, just like we centralize the images.

Right.

So so we should centralize.

Sessions, this is the best way.

And what we will do in this module is use a Benwood, which is is no Secret Service and will create

a sessions table in them.

Would it be?

Right, and our application will will interact with the technology and will create and update sessions

in this in this table.

And this way our servers become disposable.

This is an architectural principle, a best practice, if you will, and the solar becomes disposable.

And this is basically you have to do this with many other things as well, like log files.

So we should have nothing of value in the server and it should become disposable and service can come

and go.

And there's no Impacto.

So in this module, we create the the table and we set up the application to to use the emotively.

And we'll also have to set up I am I am is identity and access management and we'll have to create a

role and this role will have to be attached to be easy to instance.

And what the role does is it allows our application to use the Dunwoodie service and the table.

So because we need permissions, the application needs permissions to access and motive and the role

will have those permissions.

And once you attach it to the instance, the application can can can assume that role and will have

access to them.

Would it be OK?

So.

So these are the three things we need to do here.

First, the scaling group.

But because of that, we'll have to centralize the sections in them and we'll also have to set up a

role so that our application can actually talk to animal.

OK, so so in the next set of videos.

Right.

And and there's also other material.

Let's let's see how to implement this scalability for our app.