April 11, 2023

[TIL] 로드밸런싱의 이슈 중 세션 관리문제는 어떻게 해결할까?

로드밸런싱의 이슈 중 세션 관리문제는 어떻게 해결할까?

프로젝트 중에 서버 이중화와 로드밸런싱, 세션 문제에 대해서

회의를 했었던 적이 있었다. 다시 한번 기억하고 정리를 해야겠다고

생각을 했고, 그 당시엔 redis를 사용하지 않은 환경이였지만,

이번에 정리를 하면서, redis를 왜 쓰는지 이해할 수 있었다.

하드웨어적(네트워크 장치)으로 로드밸런싱

OSI 7 Layer 중에서 4계층(transport)에 해당하는 장비로

들어온 데이터를 로드밸런싱 해주는 장비이다.

L4, L7 스위치 등은 하드웨어로 구성해야하며 가격이 비싸다.

소프트웨어적으로 로드밸런싱을 하기 위한 방법으로는

Nginx를 로드 밸런서로 사용한다. 이유는 간단하고 저렴하기 때문이다.

Nginx를 사용하면, 서버에 소프트웨어만 설치하면 되므로 시간과 비용이 절약된다.

Nginx는 리버스 프록시를 활용하여 로드 밸런싱한다.

로드 밸런서가 세션id에 기반하여 특정 서버로 보내주는 방식

즉, 특정 세션의 요청을 처음 처리한 서버로만 보낸다.

특정 서버로 보내준다는 것만으로도 문제가 있어보인다.

특정서버만 과부화가 올 수 있고, 그 특정서버가 다운이 되면 모든 세션은 소실된다.

sticky session의 단점을 보완할 수 있는 방식으로 여러 WAS의 세션을 동일한 세션으로 관리하는 방식이다.

WAS는 각각의 세션을 가지고 있지만, 이를 하나로 묶어서 클러스터로 관리하는 것이다.

그렇게되면 하나의 WAS가 다운되어도 다른 WAS로 세션이 이동되어 관리한다.

하지만, scale out 관점에서 WAS가 추가된다면..?

추가될때마다 세션클러스터링에 관련된 옵션을 추가하고,

기존에 존재하던 WAS에 새로운 서버의 IP/Port를 입력해서 클러스터링 해줘야한다.

이렇게 된다면, 휴먼에러가 발생할 수도 있다.

새로운 서버를 띄우더라도 해당 서버에만 세션 서버의 정보를 적어주고 연결 해주면 되기 때문에

scale out시 기존 서버의 수정이 발생하지 않게 된다.