HTTP protocol은 기본적으로 무상태성을 나타내기 때문에, 서버는 이전 요청과 현재 요청의 클라이언트가 같은지 알아보기 위해 Session을 사용한다.
하지만 세션의 경우 서로 다른 서버에 공유가 되지 않는다는 한계점이 있다.
특히 서버의 안정성 및 위험 부담, 부하 분산을 위해 이중화 이상의 서버 구조에서 로드 밸런싱을 많이 사용하고 있는 상황에서는 위와 같이 세션이 유지되지 않는다는 것은 불가피하다.
위와 같이 로드 밸런싱으로 세션이 분산되어 유지가 되지 않는 상황을 위해 있는 방법이 Sticky Session이다.
즉 첫 요청에 대한 응답을 준 서버로만 세션을 보내는 것이다.
하지만 위와 같은 Sticky session을 사용하게 된다면 로드 밸런싱의 효율이 떨어질 수 있으며, 트래픽 과중화가 일어날 수 있다. 또한 해당 서버가 죽어버리면 모든 세션 정보가 날라간다는 위험 부담 또한 가질 수 밖에 없다.
그렇기 때문에 Session-Clustering을 사용하게 되며, WebLogic 에서 또한 cluster 기능을 지원하며 세션 저장소를 하나로 묶어서 관리하게 된다.
다만 위 방법 또한 세션 저장소를 업데이트 해줘야 하기 때문에 메모리 수요가 많아지며 성능 저하를 불러일으킬 수 있다.
그렇기 때문에 또 나온 개념이 바로 Session Server이다.
WAS 서버마다 세션 저장소를 따로 두지 않고, 세션만 관리하는 별도의 서버를 하나 두는 방식이다. 그렇기 때문에 Clustering이 필요 없으며 세션 저장소를 업데이트 해줄 필요도 없다.
하지만 위 방법 또한 결국 데이터를 별도로 저장하기 위한 메모리가 추가적으로 필요해지며, 메모리 파편화가 일어날 수도 있다는 한계를 가지고 있다.
(출처 : https://sorjfkrh5078.tistory.com/287)
'WAS & WEB' 카테고리의 다른 글
Idempotent, ConnectRetrySecs, ConnectionTimeoutSecs, WLIOTimeoutSecs (0) | 2022.11.14 |
---|---|
파일 업로드 용량 제한 (0) | 2022.09.30 |
mod_wl_ohs.conf 테스트 (0) | 2022.07.21 |
mpm test (0) | 2022.07.12 |
Session & Cookie (0) | 2022.06.20 |