Application Load Balancer 세션 고정 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

스티키 세션은 쿠키를 사용하여 클라이언트가 쿠키의 수명 동안 동일한 인스턴스에 대한 연결을 유지할 수 있도록 합니다. 스티키 세션을 사용하면 사용자 세션을 특정 인스턴스에 바인딩하도록 로드 밸런서를 구성합니다. 즉, 세션 중에 사용자로부터 수신되는 모든 요청이 동일한 인스턴스로 전송됩니다. 그러나 연결에 대한 이러한 가정은 시간이 지남에 따라 불균형을 초래할 수 있습니다.

다음과 같은 경우 스티키 세션이 실패할 수 있습니다.

• 등록된 대상에서 쿠키를 생성하지 않음
• 클라이언트가 요청 헤더에서 쿠키를 반환하지 않음
• 쿠키의 형식이 올바르지 않음
• 기간 기반 세션이 지나감
• 세션 요청이 여러 로드 밸런서를 통과하고 있음
• 목표 상태가 비정상으로 변경됨
• AWS 서비스가 고착성을 사용 중지함

참고: 시작에 앞서 요건 및 고려 사항 섹션을 Application Load Balancer에 대한 스티키 세션에서 검토해야 합니다.

해결 방법

애플리케이션 기반 세션 고정성

1.    로드 밸런서에서 HTTP 오류를 확인합니다. 지침은 Application Load Balancer 문제 해결을 참조하세요.

2.    백엔드 인스턴스 또는 로드 밸런서에 배치된 쿠키를 확인하려면 다음과 유사한 curl 명령을 실행합니다.

참고: DNS 이름을 로드 밸런서 이름으로 변경합니다.

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-EXAMPLE-ELB-1430759361.eu-central-1.elb.amazonaws.com

참고: Linux curl 유틸리티는 Windows OS에도 설치할 수 있습니다.

출력 예시:

...

< Set-Cookie: PHPSESSID=k0qu6t4e35i4lgmsk78mj9k4a4; path=/

< Set-Cookie:

AWSALBAPP-0=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/

...

3.    등록된 대상의 애플리케이션 쿠키 생성 여부를 확인하려면 다음과 유사한 HTTP 요청을 인스턴스 IP 주소로 전송합니다.

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null 172.31.30.168

출력 예시:

...

< Set-Cookie: PHPSESSID=5pq74110nuir60kpapj04mglg4; path=/

...

4.    등록된 대상에서 생성된 쿠키 이름이 2단계와 3단계의 로드 밸런서에 있는 쿠키와 동일한 이름인지 확인합니다.

5.    대상이 애플리케이션 쿠키를 생성하고, 로드 밸런서가 AWSALBAPP 쿠키를 생성한 경우, 클라이언트가 후속 요청에서 두 쿠키를 모두 전송하는지 확인합니다. 클라이언트가 애플리케이션 또는 AWSELB 쿠키를 포함하지 못하면 고정성이 작동하지 않습니다. 클라이언트가 애플리케이션과 AWSALBAPP 쿠키 모두 전송하는지 확인하려면 클라이언트에서 패킷 캡처를 수행합니다. 분석을 위해 tcpdump 또는 Wireshark 유틸리티를 사용하거나, 브라우저의 웹 디버깅 도구를 사용하여 요청 헤더에서 쿠키 정보를 검색합니다.

참고: AWS Support에서 작업하는 경우 HAR 파일을 생성하여 이 정보를 수집할 수 있습니다. HAR 파일은 사용자 이름, 암호 및 키와 같은 민감한 정보를 캡처할 수 있으므로 HAR 파일에서 민감한 정보를 제거해야 합니다.

6.    로드 밸런서가 요청을 라우팅한 백엔드 인스턴스를 확인합니다. 다음과 유사한 스크립트를 실행하여 인스턴스 메타데이터를 사용해 인스턴스 ID를 표시할 수 있습니다.

<?php $instance_id =file_get_contents('http://169.254.169.254/latest/meta-data/instance-id');
echo "instance id = " . $instance_id . "\\xA";
?>

7.    탄력적 로드 밸런싱 액세스 로그를 검토하여 동일 사용자 요청이 등록된 다른 대상으로 라우팅되는지 확인합니다. 지침은 Application Load Balancer의 액세스 로그를 참조하세요.

8.    고정성이 활성화된 대상 그룹에 속한 모든 대상의 상태가 정상인지 확인합니다. 대상 상태가 ‘비정상(unhealthy)’으로 변경되면 고정성이 중단되고, 로드 밸런서가 해당 대상에 대한 요청 라우팅을 중지합니다. 그러면 로드 밸런서가 정상 상태의 새 대상을 자동으로 선택하고, 스티키 세션을 설정합니다. 로드 밸런서는 상태가 ‘비정상(unhealthy)’인 경우에도 요청을 새 대상으로 계속 라우팅합니다. 상태 확인에 대한 자세한 내용은 대상 그룹에 대한 상태 확인을 참조하세요.

9.    로드 밸런서에 고정성을 사용 중지했을 수 있는 AWS 서비스(예: Amazon Elastic Kubernetes Service(Amazon EKS))가 있는지 확인합니다. API 이름이 “ModifyTargetGroupAttributes”이며 속성이 “stickiness.enabled”인 CloudTrail 이벤트 보기를 확인합니다.

기간 기반 세션 고정성

1.    로드 밸런서 DNS 이름과 유사한 다음 명령을 실행하여, 응답에 AWSALB 쿠키가 있는지 확인합니다.

[ec2-user@ip-172-31-22-85 ~]$ curl -vko /dev/null internal-TESTELB-1430759361.eu-central-1.elb.amazonaws.com

출력 예시:

...< Set-Cookie: 
AWSALB=438DC7A50C516D797550CF7DE2A7DBA19D6816D5E6FB20329CD6AEF2B40030B12FF2839757A60E2330136A2182D27D049FB9D887FBFE9E80FB0724130FB3A86A4B0BAC296FDEB9E943EC9272FF52F5A8AEF373DF33;PATH=/
...

참고: 응답에 AWSALB 쿠키가 없으면 클라이언트와 백엔드 인스턴스 간에 고정성이 없습니다.

2.    로드 밸런서가 AWSALB 쿠키를 생성했다면 클라이언트가 후속 요청에서 이 쿠키를 전송하는지 확인합니다. 클라이언트가 AWSALB 쿠키를 포함시키는 데 실패하면 고정성이 작동하지 않습니다. 클라이언트의 AWSALB 쿠키 전송 여부를 확인하려면, 클라이언트 측에서 패킷 캡처를 수행합니다. 분석을 위해 tcpdump 또는 Wireshark 유틸리티를 사용하거나, 브라우저의 웹 디버깅 도구를 사용하여 요청 헤더에서 쿠키 정보를 검색합니다.

참고: AWS Support에서 작업하는 경우 HAR 파일을 생성하여 이 정보를 수집할 수 있습니다. HAR 파일은 사용자 이름, 암호 및 키와 같은 민감한 정보를 캡처할 수 있으므로 HAR 파일에서 민감한 정보를 제거해야 합니다.

3.    로드 밸런서에 구성된 기간을 확인합니다. 쿠키 만료 기간이 경과하면 로드 밸런서에서 새 쿠키를 발행할 때까지 클라이언트 세션이 등록된 대상에 더 이상 고정되지 않습니다.

4.    요청이 여러 로드 밸런서를 통과하는 경우 하나의 로드 밸런서에서만 고정성이 활성화되어 있는지 확인합니다. 둘 이상의 로드 밸런서가 쿠키를 생성하면 로드 밸런서가 원래 쿠키를 대체하고 고정성이 작동하지 않습니다.

Classic Load Balancer의 경우 Classic Load Balancer 세션 고정성 기능 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요.

---

관련 정보

탄력적 로드 밸런싱이 내 로드 밸런서 트래픽을 불균등하게 라우팅하는 이유는 무엇입니까?

Classic Load Balancer에 대한 스티키 세션 구성

Application Load Balancer에 대해 가중치 기반 대상 그룹을 설정하려면 어떻게 해야 합니까?