siklog
[NCP/Load Balancer] ALB Sticky Session 작동 확인 본문
Sticky Session 은
특정 세션의 요청을 처음 처리한 서버로만 전송하는 것을 의미한다.
즉, 세션을 이용하여 트래픽을 분산하는 것이다.
만약 A라는 서버에서 서비스되는 웹사이트가 있다면 이 웹 사이트로 로그인을 할때 session을 서버에서 생성을 하게 된다.
이때 로드 밸런서에 연결된 다른 B서버에서 서비스되는 웹사이트로 접속하면 세션이 공유되지 않아 새로 로그인을 요청하게 된다.
말하자면 사용자 입장에서는 방금 로그인을 했는데 다시 로그인을 또 해야 하는 상황이 발생하는 것이다.
이러한 세션 관리의 문제 현상을 없애기 위해 Sticky Session 을 이용한다고 보면 된다.
NCP의 ALB에서는 Target Group 별로 Sticky Session을 설정할 수 있는 부분이 있는데,
Target Group에서도 Target VM 대상 Sticky Session 설정이 가능하지만 Target Group 별로 설정은 ALB만 가능하다. (작동하는 위치가 다름)
즉, Listener -> Rule 에서 지정할 수 있는 Sticky Session은 하나의 Rule Action에 여러 개의 Target Group이 있는 경우(TargetGroup Weight) 해당 TargetGroup 간의 Sticky Session을 설정할 수 있도록 제공하는 기능이다.
간단하게 두 서버와 타겟그룹을 만들어 ALB로 연결한 후 테스트해보았다.
Taget Group : target-1
Server : sticky-session-test001
Taget Group : target-2
Server : sticky-session-test002
ALB의 Listener에서 -> Rule 변경을 통해 두 타겟 그룹의 가중치를 동일하게 맞추고 Sticky Session 옵션을 체크해 주었다. (알고리즘은 Round Robin)
설정 후 ALB의 접속 도메인으로 접근해보면 Round Robin 알고리즘에도 불구하고 아래와 같이 target-1에 속한 sticky-session-test001 서버의 웹페이지만 계속 고정이 되어 Source IP Hash 알고리즘 처럼 실행이 되고 있는 것을 확인할 수 있다.
물론 curl로 확인해보면 정상적으로 Round Robin 되고 있는 것도 확인해 볼 수 있다.
타겟그룹 내에서도 Sticky Session 설정이 가능하나 TargetGroup에 있는 Sticky Session은 TargetGroup 내에 VM 간의 Sticky Session 이기 때문에 위 방식과는 용도가 다르다고 할 수 있고,
따라서 NLB나 NPLB의 경우는 타겟그룹 내에서 설정하는 방식으로만 이용이 가능하다.
아쉬운 점은 AWS의 경우 [Stickiness duration]에서 1초에서 7일 사이의 값을 지정할 수 있는 옵션을 제공하는데 반해 NCP의 Sticky Session 기능은 HTTP 헤더를 통해 작동하는 구조로 별도의 TTL을 설정하는 기능은 없다는 점이다.
때문에 고정된 VM이 만약 DOWN되거나 제거되는 상황 처럼 헤더 값이 바뀌지 않는 이상 계속 고정이 된다는 단점이 있다.
