ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Sticky Session
    네트워크 2025. 2. 26. 14:06

    Sticky Session(Session Affinity)은 특정 사용자의 요청을 항상 동일한 서버로 라우팅하는 로드 밸런싱 기법이다. 즉, 사용자의 첫 번째 요청이 특정 서버에 연결되면 이후의 요청도 계속 해당 서버로 보내진다.

     

    어디에 쓰이나?

    • 세션 기반 애플리케이션
      → 사용자의 세션 정보를 서버 메모리에 저장하는 구조에서는, 요청이 다른 서버로 가면 세션 정보가 없어 로그인 유지가 어렵다. Sticky Session을 사용하면 문제를 해결할 수 있다.
    • 로드 밸런서와 함께 사용
      → 로드 밸런서(HAProxy, Nginx, AWS ALB 등)가 클라이언트의 세션을 기반으로 요청을 동일한 서버로 보낸다.

    🔹 Sticky Session의 구현 방식

    Sticky Session을 구현하는 주요 자료구조와 알고리즘을 보면:

     

    1. 해시 기반 라우팅 (Hash-based Routing)

    • 자료구조: HashMap (Key: Session ID, Value: Server)
    • 알고리즘:
      1. 클라이언트의 Session ID를 해시함수로 변환
      2. 특정 서버에 매핑하여 유지
      3. 이후 요청도 동일한 해시 결과를 가진 서버로 전달
    • 예제 코드 (Java, HashMap을 사용한 간단한 구현):
    import java.util.HashMap;
    import java.util.Map;

    public class StickySessionManager {
        private final Map<String, String> sessionMap = new HashMap<>();

        public String getServerForSession(String sessionId, String[] servers) {
            return sessionMap.computeIfAbsent(sessionId, id -> {
                int serverIndex = Math.abs(id.hashCode()) % servers.length;
                return servers[serverIndex];
            });
        }
    }
    → 이 코드는 Session ID를 해시하여 특정 서버에 매핑하는 방식이다.

     

    2. 쿠키 기반 라우팅 (Cookie-based Routing)

    • 자료구조: HashMap (Key: Session ID, Value: Server)
    • 알고리즘:
      1. 클라이언트가 쿠키에 서버 정보를 저장
      2. 이후 요청에서 쿠키를 기반으로 동일한 서버로 라우팅
      3. 서버가 다운되면 다른 서버로 매핑을 변경
    • 예제 (Nginx에서 Sticky Session 적용)
    upstream backend {
        server server1.example.com;
        server server2.example.com;
        sticky cookie srv_id expires=1h domain=.example.com path=/;
    }
    → 클라이언트 쿠키에 srv_id를 저장하여 이후에도 같은 서버로 요청을 보냄.

     

    3. IP 해시 기반 라우팅 (IP Hash Routing)

    • 자료구조: HashMap (Key: 클라이언트 IP, Value: 서버)
    • 알고리즘:
      1. 클라이언트의 IP 주소를 해싱하여 특정 서버에 매핑
      2. 이후 동일한 IP에서 온 요청을 같은 서버로 보냄
      3. 다만, NAT 환경에서는 IP가 바뀌어 Sticky Session이 깨질 수 있음.
    upstream backend {
        ip_hash;
        server server1.example.com;
        server server2.example.com;
    }

     

     

    🔹ALB와 NLB 의 Sticky Session

    ALB(Application Load Balancer) - 쿠키 기반 Sticky Session

    • ALB는 로드 밸런서 생성 쿠키 (AWSALB, AWSALBCORS) 또는 애플리케이션 제공 쿠키를 사용할 수 있다.
    • 쿠키 기반이므로 클라이언트가 다른 IP를 사용해도 동일한 서버로 라우팅된다.

    🔹 ALB Sticky Session 동작 방식

    1. 첫 번째 요청에서 ALB가 백엔드 서버(예: EC2)에 요청을 전달.
    2. ALB는 응답에 "AWSALB" 쿠키를 포함하여 클라이언트에게 반환.
    3. 이후 클라이언트가 같은 ALB를 통해 요청을 보낼 때, "AWSALB" 쿠키를 포함하여 보냄.
    4. ALB는 해당 쿠키 값을 확인하고 동일한 서버로 요청을 전달.

     

    NLB(Network Load Balancer) - IP 해시 기반 Sticky Session

    • Client IP Hashing을 사용하여 같은 IP에서 오는 요청을 동일한 서버로 전달.
    • 쿠키가 아니라 IP 주소 기반으로 서버를 선택하므로, 클라이언트의 IP가 변하면 다른 서버로 라우팅될 수 있음.

    🔹 NLB Sticky Session 동작 방식

    1. NLB는 클라이언트의 Source IP를 해싱하여 특정 서버에 매핑.
    2. 같은 클라이언트(같은 IP 주소)가 보낸 요청은 동일한 백엔드 서버로 전달.
    3. 클라이언트의 IP가 바뀌면 새로운 해시 값이 계산되어 다른 서버로 라우팅될 수 있음.

     

    '네트워크' 카테고리의 다른 글

    TCP의 신뢰성은 어떻게 보장받는가(nginx)  (0) 2025.02.21
Designed by Tistory.