Apache Tomcat(WAS) Session clustering 구성 전 숙지 사항
1. HTTP 프로토콜은 Stateless protocol이다.
☞ stateless protocol: 이전의 요청과 상관없이 각각의 요청은 독립적인 트랜잭션으로 취급하는 protocol
☞ 요청 간의 받은 사용자 데이터를 저장하는 수단을 기본적으로 제공하지 않음
☞ 사용자가 요청한 서버가 바뀌면 가지고 있는 session에 대한 정보는 사라짐 (EX. 해당 서버 장애)
2. 쿠키
☞ Cookie: 사용자가 사용중인 브라우저에 저장되는 정보로 작은 text로 이루어진 임시 파일
EX) 사이트 팝업 설정, 비로그인시 쇼핑몰 장바구니 등
☞ 브라우저에 저장되는 정보로 외부의 위협으로 인해 정보가 탈취될 가능성이 높으므로 보안에 민감한 정보는 포함되어 있지 않을 가능성이 높고 저장되어 있어서도 안됨
☞ 브라우저에 따라 저장되는 방식이 달라서 다른 브라우저로 접속하면 마치 다른 사용자인 것으로 인식함
☞ 이러한 쿠키는 계속 쌓이지 않고 특정기간이 지나면 만료됨
EX) 크롬의 기본 정책: 마지막 사용일자 기준 6개월 후 해당 쿠키 만료
3. 세션
☞ Session: 사용자가 브라우저를 닫고 서버가 해당 connection을 종료하기 전까지 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술
☞ 브라우저를 닫지 않는다면 세션 만료기간 전까지 해당 세션은 유효함
☞ "쇼핑몰 로그인 (main.jsp) --> 원하는 상품 검색 (xxx.jsp) --> 원하는 상품 구매 (ccc.jsp)" 이러한 다른 페이지에 접속하여도 로그인이 풀리지 않게 하기위해 처음에 서버가 만들어준 Session ID를 가지고 서로 Request와 Responce를한다.
☞ 자세한 과정은 아래의 그림을 참고하면 좋을 것 같습니다.
WAS Session clustering 왜 해야될까?
1. HTTP 프로토콜은 Stateless protocol이다.
앞에서도 이야기한 내용이지만 HTTP는 Stateless protocol이기 때문에 영구적으로 세션 정보를 저장할 방법이 없습니다.
만약 Cookie에 회원 정보와 같이 민감한 정보를 넣으면 더 위험하기도 하구요.
2. Session 불일치
추가로 A라는 JVM에서 제공한 Session ID를 가지고 사용자가 잘 사용중하다가 A JVM이 OOM 등 장애 상황으로 인해 프로세스가 종료되면 사용자는 B라는 JVM에 접속을 해야합니다.
그런데 A에서 제공한 Session ID와 B에서 제공하는 Session ID는 서로 다르기 때문에 사용자는 다시 로그인을 해야되는 상황이 발생합니다.
이와 같은 상황이 벌어진다면 서비스 장애 상황으로 판단되기 때문에 A라는 JVM에서 사용자에게 제공한 Session ID를 B라는 JVM에 복제해서 A라는 JVM이 shutdown되더라도 사용자가 정상적으로 사용할 수 있게 해줍니다.
이러한 세션 복제 작업을 Session Clustering (Session Replication)이라고 부릅니다.
WAS Session clustering 구성전 필요 사항
1. 직렬화(Serializable) 구현이 되어 있는지 확인
직렬화가 되어 있으면 JVM의 상주되어 있는 객체 데이터를 영속화하여 JVM이 종료되더라도 영속화된 데이터는 사라지지 않기 때문에 네트워크로 전송이 가능합니다.
그런데 이 네트워크로 전송할 때 직렬화가 안되어있다면 A라는 JVM에서 사용하였던 참조값 "0x121231"이 B라는 JVM에서는 해당 참조값(주소값)은 메모리 공간이 다르기 때문에 무의미한 가비지 값이 됩니다.
그래서 이 참조값이 가지는 객체의 내용을 바이트 단위로 변환하여 전송 및 저장이 가능한 상태로 만드는 직렬화 작업을 진행합니다. 이러한 바이트로 변환된 데이터를 다시 객체로 변환하는 작업은 역직렬화라고 부릅니다.
직렬화에 대한 자세한 내용은 아래의 주소에 고수님들이 작성한 글이 많은 도움이 될 것 같습니다.
- OKKY 댓글 중 Jason Wang님 댓글
- 우아한형제들 기술 블로그
2. 로드 밸런서가 sticky session mode로 구성되어 있는지 확인 (선택 사항)
☞ Sticky Session: 사용자가 처음으로 접속된 서버로 계속해서 접속(request)하는 것을 의미합니다.
3. 서버들의 NTP 동기화 정상 확인
네트워크를 이용하여 시간 동기화를 하는 NTP가 정상적으로 동기화가 되고 있는지 확인합니다.
ntp 서비스의 경우 "ntpq -p"를 이용하여 확인하고 chrony 서비스의 경우는 "chronyc sources"로 확인합니다.
4.workers.properties에 지정한 worker와 jvmRoute 일치 확인
workers.properties 파일에 지정한 worker의 IP와 AJP Port가 해당 WAS의 jvmRoute와 일치하는지 확인해야 합니다.
일치하지 않는다면 Session Clustering이 정상적으로 동작하지 않을 수도 있습니다.
5. Session Cluster에 사용될 방화벽 port open
Session Cluster에 지정한 Receiverport와 Membership에 대한 Port open되었는지 확인이 필요합니다.
가끔씩 환경상 UDP Multicast가 지원되지 않는 경우가 있는데 이의 경우 UDP Unicast 및 TCP를 이용하여 세션 복제를 진행해야됩니다.
위의 필요 사항들은 Apache Tomcat Clustering/Session Replication How-To 문서의 Cluster Basics을 참고하였습니다.
'WEB&WAS > Apache Tomcat' 카테고리의 다른 글
WAS) Tomcat과 Scouter APM 연동하기 (0) | 2022.11.06 |
---|---|
WAS) Tomcat Session clustering (2) - 구성 (0) | 2022.11.05 |
WAS) Tomcat Multi Instance 설치 스크립트 (0) | 2022.10.30 |
WAS) Tomcat Multi Instance (1) - 구조 및 장점 (0) | 2022.10.24 |
WAS) HugePage(Large page) 설정 및 확인 방법 (0) | 2022.10.23 |