AWS-NLB-Sticky-sessions-timeout

ALB에 대한 고찰이후 ELB관련 주제의 포스팅을 적는건 오랜만이다.

NLB의 Sticky 에 대해 한번 적어보려 한다.

Target group의 속성 이야기다.

NLB sticky는 추가된지 6개월정도 지났지만 아직도 일반적으로 아는 기능은 아니다.
너무 오랜기간 없었던 터라 없다고 아는 사람이 더 많은..ㅋㅋㅋ 그런 기능이다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/network/load-balancer-target-groups.html

먼저 Docs 를 링크하고..

NLB의 Routing algorithm 은 ip_hash 방식으로 동작 한다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html

The protocol
The source IP address and source port
The destination IP address and destination port
The TCP sequence number

6개의 조건이 일치하면 같은 target으로 연결해주나, 하나의 조건이라도 달라지면 다른 target으로 연결해주는 것이다. 이 tuple 들이이 일치하지 않더라도 같은 target으로 연결하게 하는 방법이 있다. 그것이 바로 sticky session 인것이다.

stictky session 에서 라우팅 조건은 souce ip 뿐이다. 1 tuple인것이다. 하지만 그렇다고 해서 영원히 같은 인스턴스로 연결해주는것은 아니다. 여기엔 시간 제한이 붙어있다.

-추가 - 수정합니다.
docs에는 souce ip 1tuple로 동작한다 적혀있지만 NLB-multi-AZ(HA)구성을 할경우엔 A RR-EIP가 두개가 붙으므로 예상과는 다르게 동작할것입니다. 또한 1tuple로 동작하는 부분또한 client ip + nlb node ip 로 구성되므로 2tuple 로 동작합니다.

예상과 같은 정상적인 결과를 얻기위해선 Weighted, failover 방식으로 route53을 설정해서 단일존으로 라우팅 해야 동일한 결과를 얻을 수 있습니다.
-도움주신 무무님 감사합니다.

docs 대로라면 1tuple이라 생각했는데 요소는 1tuple이 아니라

Connection idle timeout 이다

NLB의 Connection idle timeout 은 TCP 350 초 UDP 120초다.
- UDP는 태우님이 물어보셔서 추가로 알아봤다.

https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#connection-idle-timeout

Elastic Load Balancing sets the idle timeout value for TCP flows to 350 seconds. You cannot modify this value. Clients or targets can use TCP keepalive packets to reset the idle timeout.

Connection idle timeoutElastic Load Balancing sets the idle timeout value for UDP flows to 120 seconds.

그래서 동작은 이렇다.

sticky session 을 켜고 연결이 지속되는 동안은 무조건 같은 target으로 연결되고 마지막 연결부터 350초가 지나고 연결하면 대상/클라이언트 모두 TCP RST 응답을 받아서 sticky session 의 연결이 해제되고 다른 target과 연결되게 되고 다시 sticky로 동작하는거다.

최근에 질문을 받아서 다시한번 정리해봤다.

읽어주셔서 감사하다!

ALB sticky session 에 대한 고찰.

aws 에선 고가용성을 위한 로드벨런서를 지원한다.

로드벨런서의 이야기다.

오늘 3티어 구성에서 세션이 널뛰는 증상이 있었다. 그 이야기를 하기전에 먼저 설명부터 하겠다.

ELB 라는 이름으로 ALB/NLB/CLB로 불린다.

Application Load Balancer, Network Load Balancer, Classic Load Balancer 이다.

오늘 이야기할 로드벨런서는 ALB인데 그중에도 sticky session 이다.

한글 콘솔에서는 고정 세션이라 불린다. 고정세션은 라운드 로빈으로 작동하는 로드벨런서에 세션을 고정해서 사용자의 경험을 지속할수 있도록 도와주는 역할을 한다.

먼저 옵션을 설정하는 방법부터 보자

로드벨런서>대상그룹> 속성편집 을 누른다.

그럼 아래와 같은 창이뜨고 활성화를 누르면 고정세션의 시간을 활성화 할수 있다.

활성화 한 화면은 다음과 같다.

sticky session 이 정상적으로 붙은지 확인하는 방법은 아래와 같다.

아직 sticky session 설정을 추가하지 않은상태다.

sticky session 세션은 cookie로 생성이된다.

Application Load Balancer는 로드 밸런서가 생성한 쿠키만 지원합니다. 쿠키의 이름은 AWSALB입니다. 이러한 쿠키의 콘텐츠는 교체 키를 사용하여 암호화됩니다. 로드 밸런서가 생성한 쿠키는 해독하거나 변경할 수 없습니다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions

3tier로 구성하면 AWSALB 쿠키가 2개가 붙는다.

AWSALB fnCHt1XmAslF4YJP1DdrFja2gFlp58fwxawbSD63gMsYHbSY6ZvL47TP9JyNb1LAqNBb1mt3J0xTVTQrbyFV3KVQmFayhf0C+FIcsOoXDpadKRTlRxNiL2jaijXf N/A N/A N/A 131
JSESSIONID BA145F75466D30D122F5BF83873E0C13 N/A N/A N/A 45
_ga GA1.3.549999545.1568632026 N/A N/A N/A 32
Response Cookies 357
AWSALB 7/4O7AyBPsXTcT9Y3AEE+B3ueRztLwkdTz9TwF/bJ191ItEAMN1HoOk1xsVtWsOjbmuZb68s5gs+6xM2oowR3JgexIIVYIUPWwFkkOWliy3FkwsmeMzQmXsKAkV0 / 2019-10-28T10:50:30.000Z 179
AWSALB UUu3Vbr3MNNBSaaby5Z1dduf11BTf0148wbnE+20aF9Ak+QQWv0ZFGlsBsUZTOWRB9k99mVsAzr0PMgLAiciFD5mJW2FLmNn3ojwbh/EEQFdL5qe6NZCkAFKuLOz / 2019-10-28T10:50:30.000Z 178

alb-web-alb-was-rds 구성이면 쿠키가 좀붙는데 was 가 tomcat 라면

awsalb 쿠키 2개와 jsessoinid 라는 쿠키까지 붙는다.

여기서 awsalb 쿠키는 response 한 alb쿠키를 request 에 재활용한다.

awsalb 쿠키는 지속적으로 변한다. 하지만 sticky session 에의해서 jsessionid값은 연결된 was의 고유값을 지니며 jsessionid 가 변경되면 세션이 초기화 되서 재 매칭이 된다.

이걸 왜포스팅하냐면 sticky 가 정상적으로 붙는데 세션이 was1/2로 붙는 증상이 발생해서 확인하는 방법을 포스팅한거다..

아디오스!