[AWS] NLB-ALB-EC2 구조에서 ALB의 고정 세션(Stickiness) 기능 활용하기 (+ALB Access Logs)

☄️ To-Be Architecture

To-Be Architecture

- NLB의 Target Group으로 ALB를 생성한다.
- ALB의 Target Group으로 Nginx를 서비스 중인 EC2를 생성한다.
- ALB에서 Stickiness를 활성화하고, NLB로 직접 인입하는 트래픽도 같은 destination으로 도달하는지 확인해보자.

---

1️⃣ EC2 구성

Nginx를 설치한 EC2 4개를 구성하고 각 서버의 index.html 파일을 구분하기 좋게 변경한다.

sudo su -

yum install nginx
# OS가 Amazon Linux2인 경우의 nginx 설치 명령어
# amazon-linux-extras install -y nginx1

#(선택사항)각 서버를 구분하기 좋게 html 변경
vi /usr/share/nginx/html/index.html

# nginx 서비스 시작
systemctl start nginx
systemctl enable nginx

본 포스팅에서는 구분을 위해 아래와 같이 index.html에서 header를 각 서버의 번호로 변경하였다.

2️⃣ ALB 구성

internet-facing type으로 ALB를 생성한다. (테스트를 위한 internet-facing이며, internal로 생성해도 무관하다.)
1번의 EC2 4대를 포함하는 Target Group을 생성한 후, ALB에 연결한다.
참고로, Target Type이 instance인 Target Group의 default 설정은 Stickiness가 비활성화되어 있으며 Loabalancing algorithm은 Round Robin이다.
ALB의 Target Group 설정 > Attributes 탭에서 Stickiness를 enable 하자.

통신을 위해 ALB의 보안 그룹에 소스에 대해 80번 포트를 오픈하는 인바운드 규칙을 추가한다.
Stickiness를 enable 한 후, 같은 브라우저에서 ALB의 endpoint를 호출하면 계속 같은 화면이 나온다.
아래와 같이 크롬 브라우저에서 ALB endpoint 호출 시, 계속해서 2번 서버가 호출되어 ALB의 Sticky Session이 정상적으로 동작하고 있음을 알 수 있었다.

ALB 호출 시 웹페이지 > 2번 서버 호출됨

3️⃣ NLB 구성

• Target Type이 Application Load Balancer인 타겟그룹을 생성하고, 2번에서 생성한 ALB를 연결한다. (⇒ 참고 문서)
  • 단, ALB에 타겟그룹 생성 시 지정한 포트와 동일한 포트의 리스너가 있어야 한다.
  • 단, 프로토콜은 TCP만 허용된다.
• ALB가 Target인 Target Group 설정에서 Attributes는 아래와 같이 편집이 비활성화되어 있다.
  • Stickeness가 Disabled 되어 있고, 변경이 불가능하다.

2번에서 테스트한 같은 브라우저에서 NLB endpoint를 호출해보자. 계속 같은 URL 호출 시, 3번 서버가 계속 호출되는 것을 알 수 있었다. ⇒ NLB 호출 시에도 ALB의 Sticky Session이 잘 동작함을 확인할 수 있다.

ALB 호출 시 웹페이지 > 3번 서버 호출됨

---

💡 결론

NLB의 대상 그룹이 ALB인 경우, TCP 트래픽을 사용하고 프로토콜, 원본 IP 주소, 원본 포트, 대상 IP 주소, 대상 포트, TCP 시퀀스 번호에 따라 흐름 해시 알고리즘을 사용하여 대상을 선택한다. 각 개별 TCP 연결은 연결 주기( the life of the connection) 동안 단일 대상으로 라우팅된다. (⇒ 참고 문서)
동일한 TCP 연결에서 오는 모든 요청이 동일한 대상으로 라우팅되므로 NLB의 고정은 기본적으로도 사용 가능하다. 동일한 소스 IP에서 오는 여러 TCP 연결의 모든 트래픽이 동일한 대상에 도달하도록 하려면 NLB의 대상 그룹에서 고정성을 활성화하는 방법이 있다. (⇒ 참고 문서)
NLB의 대상그룹이 ALB이고 ALB의 Stickiness가 활성화되어 있는 경우, NLB로 인입되는 트래픽에 대해서도 고정 세션이 정상적으로 동작한다.

---

✅ ELB의 Access Log를 통해 Sticky Session 동작 여부를 확인해보자

고정 세션이 잘 동작하는지 알기 위해서는 같은 Source에 대해 같은 Destinaion으로 트래픽이 도착하는지 확인하면 된다.
본 포스팅에서는 EC2에 Nginx를 구동하여 같은 웹페이지가 계속 호출되는 것을 통해 고정 세션 동작 여부를 확인하였다.
이외에, Access Log에서 같은 Source일 떄 같은 Destination이 호출되는 것을 확인하는 방법도 있다.
그러나 본 포스팅과 같이 NLB의 Target Group이 ALB인 경우, NLB에 Access Log를 설정할 수 없다.
NLB는 TLS 리스너가 있고 액세스 로그가 TLS 요청에 관한 정보만 포함하는 경우에만 액세스 로그가 생성된다. ALB를 타겟 그룹으로 하는 경우에는 TCP 프로토콜만 허용되므로 해당 NLB의 Access Log는 생성할 수 없다. (⇒ 참고 문서)
참고를 위해, ALB에 대해서만 Access Log를 설정해보자.

1. S3 버킷 생성

AWS Elastic LoadBalancer의 access log를 저장할 S3 버킷을 생성한다.

2. S3 Bucket Policy 적용

1번에서 생성한 S3 Bucket에 위와 같은 Bucket Policy를 지정한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::elb-account-id:root"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::bucket_name/prefix/AWSLogs/aws-account-id/*"
        }
    ]
}

“Principal”의 “AWS” 값에 해당하는 elb-account-id는 Region마다 다르다.
(Seoul elb-account-id : 600734575887 ⇒ 참고 문서)

3. ELB Access logs 활성화

ALB의 Description 탭의 Attributes 섹션에서 Access Logs를 활성화한다.

AWS ELB > Attributes Settins > Enable Access Logs

s3 location을 1에서 생성한 버킷으로 지정한다. 원하는 경우, prefix를 지정한다.

4. S3 버킷 내 로그 파일 확인

prefix로 지정한 폴더 객체 및 폴더 내부에 Access Logs 파일들이 생성되어 있다.
같은 Source IP에 대해 같은 Destination IP로 연결됨을 통해 ALB의 Sticky Session이 잘 동작 중임을 알 수 있다.

🔗 참고 링크

1. AWS Docs: 대상으로의 Application Load Balancer
2. AWS Docs: Network Load Balancer 개요
3. AWS Docs: Network Load Balancer > 대상 그룹 > 고정 세션
4. AWS Docs: Network Load Balancer의 액세스 로그
5. AWS Docs: Classic Load Balancer > Enable Access Logs > Attach a policy to your S3 bucket