웹서버구축 후 성능 슬래시를 위한 항상성 설정 방법은?

Q1. 세션 항상성(Session Persistence)이란 무엇인가요?
A1. 로드밸런서를 통과하는 클라이언트의 요청을 항상 동일한 백엔드 서버로 전달해, 서버에 저장된 세션정보(쿠키·인메모리 등)를 유지하는 기법입니다.

Q2. 세션 항상성이 왜 필요한가요?
A2.
- 로그인 상태·장바구니 정보·멀티스텝 폼 등 서버 메모리에 저장된 사용자 상태를 유지
- 첫 요청 처리 서버와 다른 서버로 분산될 때 발생하는 상태 불일치 방지
- 무상태(stateless) 설계가 어려운 기존 애플리케이션의 수평 확장 지원

Q3. 세션 항상성 방식에는 어떤 종류가 있나요?
A3.
1) 소스 IP 해시(Source IP Hash): 클라이언트 IP를 해시해 특정 서버에 고정
2) 애플리케이션 쿠키(App Cookie): 애플리케이션이 발행한 고유 쿠키값으로 라우팅
3) 로드밸런서 쿠키(LB Cookie): HAProxy·NGINX 등 LB가 발급한 쿠키로 라우팅
4) URL 파라미터: 쿼리스트링에 서버 식별자를 심어 전달(비권장)

Q4. NGINX에서 세션 항상성 설정 예시
A4.
1) IP 해시 방식
upstream backend {
ip_hash;
server srv1.example.com;
server srv2.example.com;
}
2) LB 쿠키 방식(NGINX Plus)
upstream backend {
zone bk 64k;
server srv1.example.com;
server srv2.example.com;
sticky cookie srv_id expires=1h path=/;
}
3) 오픈소스용 모듈(nginx-sticky-module) 사용 시
upstream backend {
sticky name=SERVERID expires=1h domain=.example.com path=/;
server srv1;
server srv2;
}

Q5. HAProxy에서 세션 항상성 설정 예시
A5.
1) 소스 IP 해시
backend web_back
balance source server s1 10.0.0.1:80 check
server s2 10.0.0.2:80 check
2) 쿠키 방식
backend web_back
balance roundrobin
cookie SRV insert indirect nocache
server s1 10.0.0.1:80 check cookie s1
server s2 10.0.0.2:80 check cookie s2

Q6. AWS ELB/ALB에서 세션 지속성 설정
A6.
- Classic Load Balancer: “Stickiness” → 쿠키 기반(ELB 쿠키 또는 애플리케이션 쿠키) 활성화
- Application Load Balancer(ALB): “Target group” → Attributes → “Stickiness” 켜기 → TTL 설정
- Network Load Balancer(NLB): TCP 수준에서의 IP 해시 기반 세션 지속성(기본 제공)

Q7. Azure Load Balancer / Application Gateway 에서
A7.
- Azure Load Balancer: 기본적으로 5‐tuple 해시(소스 IP·포트 등) 사용, 고정성 유지
- Azure Application Gateway: “Cookie-based affinity” 설정 가능
- App Service “Always On”: 애플리케이션 풀 비활성화를 방지해 콜드 스타트를 제거

Q8. 세션 무상태화(Stateless) vs. 분산 세션 저장소
A8.
- 무상태화: JWT 토큰, HTML5 로컬 스토리지, 클라이언트‐사이드 세션 권장
- 분산 세션 스토어: Redis, Memcached, DynamoDB 등에 세션 저장
• LB 레벨 세션 항상성 제거 → 서버 간 요청 자유 분산
• 캐시 클러스터 관리 필요, 네트워크 레이턴시 고려

Q9. 세션 항상성 적용 시 주의사항은?
A9.
- 장애 복구: 특정 서버 장애 시 세션 정보 손실 위험 → 분산 세션 저장 도입 검토
- 부하 편중: 특정 서버에 트래픽 몰림 → 적절한 Health Check 및 가중치 조정
- TTL/Timeout: 너무 길면 캐시 오버플로·메모리 누수, 너무 짧으면 세션 만료
- 보안: 쿠키 암호화·Secure·HttpOnly 속성 설정

Q10. 성능 스케일링 관점에서 최적의 전략은?
A10.
1) 가능하면 애플리케이션 무상태화(stateless)
2) 분산 세션 저장소(예: Redis)로 중앙집중관리
3) LB 수준에서는 단기 세션 지속성(IP 해시 혹은 짧은 TTL 쿠키)
4) 자동 확장(오토스케일) 시 콜드 스타트 방지 설정(“Always On”) 병행
5) 충분한 모니터링(CPU·메모리·세션 테이블)과
로깅으로 트래픽 패턴 분석 및 튜닝 지속

웹서버를 단일 대역폭·단일 노드로만 운영하다 보면 사용자 세션이 특정 노드에 묶이거나(Sticky Session) 응답 지연, 부하 편중, 장애 시 세션 소실 등의 문제가 발생할 수 있습니다.

이를 해결하기 위해 ‘세션 항상성(Session Persistence)’을 설정하면, 한 번 연결된 클라이언트의 후속 요청을 동일한 백엔드 서버로 유도해 불필요한 로그인·인증ㆍ세션 조회 오버헤드를 줄이고, 전체적인 응답 속도 및 안정성을 높일 수 있습니다.

다음에서는 주요 방식과 각 기술별 설정 예시, 장ㆍ단점, 운영 시 고려사항을 글로 풀어 설명합니다.

1. 세션 항상성의 개념과 필요성 • 동일 클라이언트의 연속 요청을 항상 같은 웹서버(혹은 애플리케이션 서버)로 전달함으로써 세션 공유나 재조회 오버헤드를 방지 • 부하 분산 장비가 라운드로빈·최소커넥션 등으로 단순 분배할 때 세션 일관성이 깨져 로그인 상태 초과 재인증, 캐시 미적중(cache miss) 증가 등 성능 저하 발생 • 특히 로그인·장바구니·쇼핑 결제처럼 상태 저장(stateful) 처리가 많은 서비스에서 효과적

2. 세션 항상성 구현 방식 1) IP 해시 기반 – 클라이언트의 출발지 IP를 해시 함수에 넣어 분산 대상 서버를 결정 – 장점: 별도 서버 사이드 작업 없이 로드밸런서(또는 리버스 프록시)만으로 설정 가능 – 단점: 공유 NAT 환경·프록시 뒤 클라이언트에서는 동일 IP가 뭉쳐서 한 서버에 과부하 발생, 모바일 네트워크처럼 IP가 자주 바뀔 때 불안정

2) 쿠키 기반 – LB가 발급한 전용 쿠키(예: MyLBSESSION=backend1)나 애플리케이션이 쓰는 세션 쿠키(JSESSIONID 등)에 서버 식별 정보를 추가 – 장점: 사용자가 여러 IP를 오가더라도 쿠키가 유지되는 한 세션 일관성 확보 – 단점: 쿠키 조작·삭제 시 세션 라우팅 정보 손실, HTTPS 환경에서 별도 보안 설정 필요

3) URL 파라미터 방식 – URL 뒤에 서버 식별 토큰을 붙여(예: www.example.com/app;node1/…) 라우팅 – 장점: 쿠키 비허용 클라이언트에서도 동작 – 단점: URL 구조가 복잡해지고 링크 복사·API 호출 시 파라미터 누락 위험

4) 애플리케이션 레벨(토큰·헤더) 방식 – JWT나 자체 토큰에 서명된 서버 ID를 넣고, LB가 HTTP 헤더(X-Server-ID 등)를 검사해 분기 – 장점: 복제된 세션 없이도 세션 정보 자체를 토큰에 담아 stateless하게 처리 가능 – 단점: 애플리케이션 개발·보안 설계가 추가로 필요

3. 주요 솔루션별 설정 예시 1) Nginx – IP 해시 방식 upstream backend { ip_hash; server

10.0.0.1:8080; server

10.0.0.2:8080; } – 쿠키 기반(ngx_http_upstream_module + sticky 모듈) upstream backend { sticky name=MYSESSION cookie path=/ expires=1h domain=example.com; server

10.0.0.1:8080; server

10.0.0.2:8080; } – 설정 시 keepalive, proxy_cache 등과 함께 조합하면 커넥션 재사용으로 추가 성능 향상 가능

2) HAProxy – source(IP) 해시 backend web_back balance source server web1

10.0.0.1:80 check server web2

10.0.0.2:80 check – 쿠키 스티키 backend web_back cookie SERVERID insert indirect nocache server web1

10.0.0.1:80 cookie web1 check server web2

10.0.0.2:80 cookie web2 check

3) LVS(Linux Virtual Server) – ip_vs, ip_vs_rr 모듈 사용 시 ipvsadm -A -t 192.168.0.100:80 -s rr ipvsadm -a -t 192.168.0.100:80 -r

10.0.0.1:80 -g -m -p 300 ipvsadm -a -t 192.168.0.100:80 -r

10.0.0.2:80 -g -m -p 300 세션 항상성(소스 IP) 유효기간 300초(-p) 설정

4) 클라우드 매니지드 LB (AWS ELB/ALB, Azure Application Gateway 등) – AWS ELB: “Stickiness” 활성화 → duration-based 또는 application cookie 방식 선택 – Azure: HTTP setting > session affinity > Application-based Cookie 또는 IP-based 선택

4. 운영 시 고려사항 및 주의점 • Sticky Session을 늘린다고 무턱대고 확장성이 좋아지는 것은 아님 – 특정 서버에 과부하가 걸리면 부하 균등화 효과가 떨어지고, 장애 복구 시 세션 손실이 일어날 수 있음 • 상태(stateful) 애플리케이션보다는 가급적 세션 클러스터링(Redis/Memcached) 또는 JWT 기반 stateless 설계를 병행하는 편이 장기적으로 유리 • 쿠키 보안(HTTPS, HttpOnly, SameSite) 설정을 반드시 검토해야 세션 탈취 위험을 줄일 수 있음 • LB 장애나 설정 변경 시 세션 흐름이 끊기지 않도록 헬스체크·롤링 업데이트 전략을 마련할 것

5. 세션 항상성은 사용자 경험과 시스템 부하를 모두 잡을 수 있는 유용한 기법이지만, 무조건적인 적용은 오히려 스케일 아웃 효과를 저해할 수 있습니다.

IP 해시·쿠키·토큰 방식의 특징을 이해해 서비스 패턴에 맞게 선택하고, 애플리케이션 차원에서 세션 공유·무상태 설계(Stateless)를 병행하면 안정적이면서도 확장성 있는 웹 인프라를 구축할 수 있습니다.