[Server] 대규모 트래픽 대응 방안 및 Session Clustering

 

📌 목차 

• Session / Cookie
• 대규모 트래픽으로 인한 서버 과부하 해결 방법
• Sticky Session / Session Clustering / Redis

 

📌 Session / Cookie 

 

⚡ Session 이란..? Session 을 사용 하는 이유..?

 

◾ HTTP 프로토콜을 사용하는 인터넷 사용자가 어떤 웹 사이트를 방문했을 때,

   클라이언트와 서버 사이의 연결을 확인하기 위한 정보이다.

◾ 세션은 서버 내부에 저장되며, 저장된 값은 반영구적이다.

   브라우저를 닫아 연결이 끊어지거나 서버에서 세션을 삭제하면 저장된 세션이 삭제된다.

◾ 세션은 각 클라이언트의 고유 ID 를 부여하는데, 이 ID 를 통해서 클라이언트를 구분하여 해당 요청에 맞는 응답을 한다.

 

→ 쉽게 말해서 우리가 웹 서버에 접속했을 때 통신의 연속성을 유지하기 위해서 세션이라는 정보를 통해 통신을 유지하는 것이다. 

    자원의 낭비를 막고 HTTP 프로토콜의 특징이자 약점( Connectionless 비연결지향 / Stateless 상태정보 유지 X Protocol  )을 보완하기 위함

 

 

⚡ Session 동작 순성

① Client 가 Server 에 요청

② Server 는 Request-Header 필드의 Cookie 에서 Session ID 확인

    Session ID 가 없을 경우, Server 에서 생성하여 Client 에 전송

③ Cookie 를 이용해 Session ID 를 Client 에 저장

④ Client 재접속, 재연결 시 Cookie 를 이용해 Session ID 값을 Server 에 전송

⑤ Server 는 Cookie 를 확인하고, Session 정보를 확인 한 후에 응답

 

 

⚡ Cookie / Session 의 차이

	Cookie	Session
저장 위치	Client	Server
생명 주기 ( 만료 시점 )	Cookie 저장 시 설정 ( 만료 지정 가능 )	Browser 종류 시 삭제
보안	취약 ( Local 에 저장되어 탈취, 변조에 취약 )	안전
속도	빠름	비교적 느림 ( 제공받은 Session ID 를 서버에서 다시 참조하여 쿠키보다는 느림. )

 

 

📌 대규모 트래픽으로 인한 서버 과부하 해결 방법 

사용자가 많이지고 트래픽이 늘어나게 되면 서버는 과부하( 서버의 리소스가 한계에 도달 )가 발생하게 된다.

트래픽이 하나의 서버에 몰려 과부하가 되는 것을 방지하기 위해서는

여러 대의 서버에 요청을 분산시켜야 하는데 아래와 같은 방법들이 있다.

 

⚡ 서버 과부하 해결 방안 

 

• 모니터링을 통한 자원 할당

 - 서버의 CPU 사용량, 메모리, 대역폭 등을 지속적으로 모니터링하여 자원을 적절히 할당 ( 서버 대수 증감 )

 - 클라우드 서비스 이용 ( AWS 오토 스케일링 ), 무료 모니터링 서비스 ( Netdata )

 

•  Load Balancer : 로드 밸런서

 - 서버 앞단에 로드밸러서를 설치하여 서버의 로드율 증가, 부하량, 속도 저하등을 고려해 트래픽을 분산

 - 로드밸런싱을 해주는 소프트웨어 및 하드웨어를 로드밸런서라고 한다

 - 서버에 장애 발생 시, 트래픽을 다른 서버로 리다이랙션하여 시스템 중단을 방지

 

•  블랙스완 프로토콜

 - 예측할 수 없는 사고 발생에 대비하여 시스템의 영향을 받는 부분을 파악하고, 관련 팀에 연락하여 빠르게 대응

 

•  서킷 프레이커

 - 서비스 간의 연쇄적인 오류 방지를 위해 서킷 브레이커 패턴 사용

 - 네트워크 요청의 실패율이 임계치를 넘으면 바로 오류를 반환하여 ( 무한 대기 X ) 더 이상의 서비스 장애를 막음

 

•  컨텐츠 관리

 - 불필요한 컨텐츠 제거 : 고용량, 미사용 자원 제거 ( 데이터 조회 시, 불필요한 컬럼 제외 )

 - CDN 을 통한 컨텐츠 제공: 정적 자원 (html, css, 이미지)을 CDN을 통하여 제공하여 메인 서버의 부하를 줄임

 - 컨텐츠 캐싱: 브라우저 캐시를 활용하여 네트워크 트래픽을 줄임
 - 컨텐츠 압축: 텍스트 기반 리소스를 압축하여 데이터 전송량을 줄임
 - 컨텐츠의 우하한 저하: 시스템의 부하를 줄이기 위해 필수적이지 않은 기능을 일시적으로 비활성화. 경량화된 페이지 제공

 

위와 같이 대규모 트래픽을 감당하기 위해서 다양한 방법으로 여러 대의 서버를 사용하게 된다.

그렇다면 두 대 이상의 WAS 를 사용하게 되었을 때, 세션은 어떻게 사용될까..?

 

📌 Sticky Session / Session Clustering / Redis 

⚡ Session Clustering 이란 ?

 

Session Clustering 은 아래에 명시한 것처럼 대체된 WAS 에서도 세션이 공유되는 기술을 의미한다.

( 동일한 세션으로 여러 WAS 에서 사용할 수 있도록 관리 )

 

예를 들어 L4 스위치 ( OSI 7 Layers, 개방형 통신을 위한 국제 표준 모델 중 L4 ) 가 사용자를 접속했던 WAS 로 유도해주지만

접속자 수가 초과될 경우 다른 WAS 를 사용하게 되는데, 이 때 발생할 수 있는 세션 불일치를 해결해줄 수 있도록 하는 것이다.

 

 

⚡ 언제 Session Clustering 을 사용할까..?

▶ 두 대 이상의 WAS 를 이용하는 경우 Load Balancing ( 대용량 트래픽 처리 시 요청을 분산시키는 것 )

▶ Failover ( 장애 발생 시 예비 시스템으로 자동 전환하는 것, 서버 이중화 )

▶ Auto Scailing ( AWS 에서 EC2 인스턴스를 자동으로 생성하고 삭제해주는 서비스 ) 등등..

 

 

⚡ 어떻게 Session 을 공유할까..?

 

위에서 언급했듯이 Load Balancer 등을 사용해 트래픽을 분산시킬 경우 세션 데이터를 관리하는데 어려움이 있다.

즉, 클라이언트의 연결 정보를 저장하는 세션이 로드밸런싱을 통해 하나의 서버 장비에 저장되는 경우

이후에 다른 서버에 연결시 세션이 유지되지 않는 것이다.

 

Load Balancing

 

이러한 문제점을 해결하고 세션을 유지하기 위한 방안들이 존재하는데 아래와 같다.

 

1. Sticky Session

 

Load Balancer 가 세션 기간 동안 동일한 클라이언트의 요청을 동일한 서버로만 라우팅하여 세션 정보를 이용할 수 있도록 하는 기능이다.

 

그림을 참고해보면 User 1 이 WAS 1~3 번중에서 1번에 세션을 생성하였다면, 이후 User 1 의 모든 요청은 WAS 1 로만 보낸다.

로드 밸런서는 User 가 처음 세션을 생성한 서버로 모든 요청을 Redirect 하여서 고정된 세션만 사용하게 하는 것이다.

 

이렇게 동작하기 위해서 로드 밸런서는 요청을 받으면 가장 먼저 요청에 쿠키가 존재하는지 확인하고 지정된 서버로 전송한다. 

쿠키가 없다면 로드밸런서가 기존 로드 밸런싱 알고리즘을 기반으로 서버를 선정한다.

 

장점

 • 여러 서버들은 세션 데이터를 공유할 필요가 없다.

 • 정합성 이슈에서 자유롭다.

 

단점

 • 특정 서버에 과부하가 발생할 가능성이 있고, 트래픽이 균등하게 배분될 수 없다.

   로드 밸런싱으로 인해 트래픽이 분산되기는 하지만 Sticky Session 을 사용했을 때,

   특정 서버로 몰린 사람들이 트래픽을 많이 발생시킬 경우 해당 서버만 과부하 걸릴 수 있다.

 

 • 특정 서버에 과부하가 걸리면 로드 밸런서는이를 감지하고 그 서버로 향하는 트래픽을 다른 서버로 다시 라우팅하는데,

   이 때, 기존 세션 데이터가 유실된다. ( 예로 클라이언트는 사용중 다시 재로그인하는 경우가 발생 )

 

위와 같은 단점을 극복하기 위해

정합성 이슈를 해결하고, 가용성 및 트래픽 분산까지 확보 할 수 있는 세션 관리 방식으로 Session Clustering 을 사용하게 된다.

 

2. Session Clustering

다중 서버 환경에서 로드 밸런서를 통해 어떤 서버로 접속하든지 세션을 동일하게 유지되도록 세션 데이터를 복사해 서버들에게 전파하는 방법이다.

 

◾ 클러스터 종류

 - 계산용 클러스터 ( HPC )

 - 부하분산 클러스터 ( LVS )

 - 고가용성 클러스터 ( HA )

 

 

세션 클러스터링은 서버들을 하나의 클러스터로 묶어 관리하고, 클러스터 내의 서버들이 세션을 공유할 수 있도록 하는 방식이다.

WAS 마다 세션 클러스터링을 지원하는 방식이 상이한데, 많이 사용하는 Tomcat 의 세션 클러스터링에 대한 설명이다.

 

Tomcat 의 Session Clustering 에는 DeltaManager 와 BackupManager 가 존재하는데,

각각의 클러스터링 방식은 아래와 같다.

 

▶ All - to - All Session Replication

All - to All 세션 복제란 하나의 세션 클러스터 내에서 변경된 요소가 발생할 경우,

Tomcat 의 DeltaManager Class 를 통해 다른 모든 서버로 복제가 되는 것을 말한다.

그림과 같이 모든 서버에 세션을 복제하면, 클라이언트가 어느 서버에 접속되든 정합성 이슈가 해결 가능하다.

그렇기 때문에 하나의 서버에 장애가 발생하더라도 서비스는 중단되지 않고 운영이 가능하다.

 

그러나 단점도 존재하는데,

모든 서버가 동일한 세션을 보유해야하기 때문에 메모리 낭비가 발생한다.

또한 세션의 데이터가 변경될 때마다 모든 서버에 값을 입력해야 하므로 서버 수에 비례하여 트래픽이 증가하는 등 성능 저하가 발생한다.

추가적으로 세션 전달 작업 중 모든 서버에 복제되기까지 시간차로 인한 세션 불일치 문제와 같은 예외가 발생할 가능성이 있다.

 

그러므로 이 방식은 소규모 클러스터에서 좋은 효율을 나타낸다.

 

그렇다면 이 또한 만족한 만한 방식은 없나..?

이를 해결하기 위한 방식으로 ' BackupManager '를 활용한 Primary-Secondary 세션 복제 방식이 있다.

 

▶ Primary-Secondary Session Replication

 

메인 서버 ( Primary ) 의 세션 데이터를 후보 서버 ( Secondary )에만 복제해두고

그 외의 서버에는 세션의 key 에 해당하는 값만 복제하는 방식이다.

객체 전체를 복제했던 All-to-All 방식보다는 시간 및 자원이 절약된다는 장점이 존재한다.

 

그러나 Primary / Secondary 서버 외에 다른 서버에 세션 정보를 요청하는 경우

그림과 같이 세션 JSESSIONID 에 해당하는 세션 객체를 얻기 위해 Primary 서버에 요청하는 과정이 필요하게 된다.

 

결국 이 방법 또한 장단점이 존재하게 된다.

 

 

3. Session Server - Redis 에서 Session Storage 를 통해 관리

그나마 세션의 정합성 문제를 해결하기 위해 가장 많이 사용되는 방법은 Session Storage 를 이용하는 것이다.

대표적으로 Redis, Memcached 등의 세션 저장소가 있다.

그림과 같이 세션 스토리지를 따로 두어 사용할 경우

서버가 늘어나더라도 세션 스토리지에 대한 정보만 각가에 저버에 입력해주면 세션을 공유할 수 있게 된다.

 

이런 방식을 사용한다면 로드 밸런싱 알고리즘만 잘 구현되어 있다는 가정 아래

Sticky Session 처럼 트래픽이 몰리는 현상은 고려하지 않아도 된다.

 

또한 하나의 서버에 장애가 발생하더라도 별도의 세션 저장소에서 세션을 가져다 사용하기 때문에 

다른 서버에 접속이 된 후 서비스를 계속해서 제공할 수 있다. 즉 가용성 및 정합성 문제도 해결된다.

 

하지만 세선 저장도 또한 장애에 대한 대응이 필요하기 때문에 백업 저장소가 필요하다.

 

 

 

 

📌 Reference

@ beneficial.log - Session이란 무엇인가

https://velog.io/@beneficial

@ zinna._.log - [CS] 대규모 트래픽으로 인한 서버 과부하의 해결

https://velog.io/@zinna_1109

@ AWS - 로드 밸런싱이란 무엇인가요?

https://aws.amazon.com/ko/what-is/load-balancing

@ SMILESHARK - 로드 밸런서(Load Balancer)란? : AWS와 로드밸런싱 개념 정리

https://www.smileshark.kr/post/what-is-a-load-balancer-a-comprehensive-guide-to-aws-load-balancer

@ 가비아 - 로드밸런서(Load Balancer)의 개념과 특징

https://m.post.naver.com/viewer/postView.naver?volumeNo=27046347&memberNo=2521903

@ 네트워크 엔지니어 환영의 기술블로그 - L4 스위치 쉽게 이해하기 #1(L4 스위치의 개요와 역할)

https://aws-hyoh.tistory.com/65

@ mirrorkyh.log - 세션 클러스터링이란?

https://velog.io/@mirrorkyh

@ junshock5 - 세션 클러스터링 이란?

https://junshock5.tistory.com/91

@ Inpa - 세션(Session) 불일치 문제 및 해결 방법

https://inpa.tistory.com

@ YD - 스티키 세션(Sticky Session), 세션 클러스터링(Session Clustering)이란..

https://woo0doo.tistory.com/26