세션 불일치를 해결하려면 어떤 방법들이 있을까? [2]

이전 포스트에서 세션 불일치를 해결하는 방법을 알아봤습니다.

이어서 세션 불일치 해결 방법을 알아보도록 하겠습니다.

 

---

Session  Clustering

클러스터링은 무슨 의미일까요?

클러스터는 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합을 말합니다.

그러면 클러스터링은 여러 대의 컴퓨터들이 서로 연결되어서 마치 하나의 컴퓨터처럼 동작한다는 의미일 것입니다.

 

WAS에 따라서 session clustering방식은 다 다르지만, 제가 현재 사용하는 스프링 부트의 WAS는 Tomcat이라서 

Tomcat의 공식문서를 찾아봤습니다.

Tomcat can perform an all-to-all replication of session state using the DeltaManager or perform backup replication to only one node using the BackupManager.

출처: http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html

이 문서를 보면 All-To-All방식을 제공한다고 되어있습니다.

 

 

그러면, All-To-All 방식에 대해 알아보겠습니다.

All-To-All방식은 그림과 같이 한 서버에 저장된 하나의 세션정보를 다른 서버에 복사해 저장해두는 방식입니다.

이렇게 하면 데이터 불일치 문제도 해결할 수 있고, 전에 알아봤던 Sticky Session의 단점인 특정 서버에만 트래픽이 몰릴 수 있는 문제를 해결할 수 있습니다.

 

 

그렇다면, 이 방법은 단점이 없는 걸까요? 이 방법도 단점이 있습니다.

• 메모리 관리에 좋지 않습니다

한 세션이 들어오면 모든 서버에 세션을 복사해서저장해두기 때문에 모든 서버에 세션 정보들이 있습니다. 동일한 세션정보가 모든 서버에 저장되어 있어서 메모리 관리에는 효율적이지 못합니다.

• 성능 저하가 생길 수 있습니다

세션 데이터가 변경되면 모든 서버에 또 복사되어서 저장되기 때문에 네트워크 요청이 생길 것입니다. 그렇게 되면 성능 저하가 발생할 수 있습니다.

• 세션 불일치 문제가 또 발생할 수 있습니다

세션이 복사되는 과정에서 시간차가 생길 수 있습니다. 만약에, 복사해서 저장해두는 30초가 걸린다면, 그 시간에 세션이 불일치하는 문제가 발생할 수 있습니다.

 

 

 

이러한 단점때문에 Tomcat의 공식문서에는 작은 클러스터일 경우 효율적이라고 되어있습니다. 

The all-to-all replication is an algorithm that is only efficient when the clusters are small. For larger clusters, you should use the BackupManager to use a primary-secondary session replication strategy where the session will only be stored at one backup node.

출처: http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html

---

 

그렇다면 세션 불일치를 해결할 수 있고 이러한 단점들을 보완해줄 수 있는 다른 방법은 어떤 것이 있을지 

다음 포스팅에서 알아보도록 하겠습니다.

 

참고 자료:

http://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html

https://dev.to/gkoniaris/why-you-should-never-use-sticky-sessions-2pkj