본문 바로가기

AWS/Load Balancer

[AWS/Load Balancer] Sticky Session 설정 추가하기 (Target Group)

반응형

 

로드밸런서 ALB를 생성하고, target group도 만들어서 인스턴스 연결해서 alb dns 주소 통해 접근할 수 있게 설정을 해봤는데요! 만약 없으시면 아래 게시글 참고해 주세요! 

 

2024.09.09 - [AWS/Load Balancer] - [AWS/ALB] AWS ALB 생성 및 ALB에 인스턴스 연결하기 (1/3)

2024.09.10 - [AWS/Load Balancer] - [AWS/Load Balancer] Target group 생성하기

 

Sticky Session이란 ? 

Load balancer는 서버에 들어오는 요청을 분산해 주는 역할을 하고 담당하고,

Sticky session은 요청자의 session을 특정 기간(cookie에 명시되어 있음) 동안 동일한 서버에 계속 요청하게 해준다

 

Sticky session의 장점 : 

  • 서버 사이드에서는 각 관리하는 session의 수를 줄이면서 ram으로부터 세션 데이터를 효율적으로 재사용할 수 있음 
    • 인스턴스 3개, 매일 들어오는 요청은 300개 기준이라고 했을 때 sticky session 미사용 시 각 인스턴스별 균등하게 300개의 세션 정보를 가지고 있어야 할 경우가 발생할 수 있음. Sticky session 사용 시 최적화된 상황으로는 각 인스턴스별 100개의 세션 정보만 가지고 있어도 됨
  • Application단에서 별도 구현 필요 없음, load balancer설정 추가로 해결 가능
    • 새로운 서버 접속으로 연결 시 기존 세션 데이터 사라져서 재로그인이 필요한 경우 별도 수정 없이 간단하게 sticky sesison 옵션만 추가해서 해결 가능 

Sticky session의 단점 : 

  • 특정 서버만 과부하가 걸릴 수 있음 
  • 만약 서버한대가 죽으면 Session에 관리하고 의존한 데이터가 날아감 

 

 

이제 Load balancer의 필수 기능인 Sticky session을 어떻게 추가할 수 있는지 알아보겠습니다 (Target group)

 

 


1. Target group 선택

EC2 -> Load Balancing -> Target Groups -> alb에 사용하고 있는 target group 선택 -> Actions -> Edit target group attributes

 

 

2. Sticky session 설정 추가 

Target selection configuration -> Turn on stickiness 후 기본 설정 유지 

테스트를 하기 위해서 기본 설정 유지하겠습니다! 

 

Load balancer 통해서 생성된 기본 cookie를 유지하겠습니다 

Cookie안에 해당 세션을 얼마나 유지할지 명시하는 옵션입니다! 

 

ALB에서 default로 생성된 cookie는 해더 안에 AWSALB입니다 

3. 확인하기 

ALB DNS 통해서 접속해서 개발자 도구를 켜서 해더에 AWSALB 쿠기가 들어가는지 확인해 보겠습니다 

 

개발자 도구 (윈도우 f12) 실행 -> Network -> Header 탭 -> Response headers 

여기에 AWSALB가 있네요! 정상적으로 적용되었습니다 ㅎㅎ 

 

 

etc. Sticky Session이 없을 시 

Load balancer의 target group에 Sticky session 옵션이 없으면 아래와 같이 header에 AWSALB 쿠기가 없습니다


AWS는 참 편리한 기능들이 많네요! 

Target group별 sticky session 옵션도 이렇게 간편하게 설정 가능하다니.. 

 

실무에서 유용하게 사용할 거 같네요! 

 

반응형