대용량 트래픽을 위해 확장성 있는 세션 구조 설계 #1

[ 세션 불일치 ]

서비스를 운영을 하다 보면 이벤트 기간이나 특정 이유로 인해 사용자의 접속이 갑자기 증가할 때가 있습니다. 그렇다면 기존에 운영하던 서버 하나만으로는 급증하는 트래픽을 견딜 수 없을 것이고 서버를 확장해야만 합니다.

 

서버를 확장하는 방법으로는 서버의 하드웨어 성능을 향상하는 scale up과 서버를 여러대로 증가시켜 트래픽을 분산 처리하는 scale out 이 있습니다. 하드웨어 확장성의 한계가 있는 scale up 보다는 지속적으로 확장성 있는 scale out이 효과적으로 보입니다.

 

scale out 방식으로 서버를 여러대로 늘린다면 로드밸런서가 클라이언트의 요청을 각 서버에 분배해줍니다. 하지만 여기서 세션 불일치 문제가 일어납니다.

 

 

 

예를 들어 클라이언트가 서버1에 로그인을 해서 세션에 정보를 저장을 하고 다음 작업 요청은 로드밸런서에 의해서 서버 3으로 분배가 된다면 서버 3에는 해당 클라이언트의 세션 정보가 없기 때문에 로그인을 하라는 요청을 보내게 됩니다.

 

이는 클라이언트는 로그인을 했지만 다른 서버에는 정보가 저장되지 않았기 때문에 발생하는 문제점 입니다. 그렇다면 세션의 정합성 문제를 어떻게 해결하면 좋을까요?

 

로드밸런싱이란?

서버에 가해지는 부하를 분산시켜주는 장치를 말한다. 클라이언트와 서버풀 사이에 위치하며, 한 대의 서비스로 부하가 집중되지 않도록 한다.

 

[ Sticky Session ]

Sticky Session 은 클라이언트에 첫 요청에 서버1로 분배가 되었다면 같은 클라이언트에 대하여 그다음 요청 또한 서버 1로 분배합니다. 즉, 첫 요청 이후 모든 요청을 특정 서버로 고정시키는 방법입니다.

 

일반적으로 특정 서버로 고정시키는 방법은 쿠키를 사용하는 방식과 클라이언트의 IP tracking 하는 방식이 있습니다. AWS ELB는 Http 응답 헤더에 쿠키로 해당 클라이언트가 가야 하는 서버의 정보를 저장합니다. 그리고 그 이후 해당 쿠키를 이용하여 로드밸런서가 특정 서버로 요청을 고정시킵니다.

 

하지만 사용자들의 서비스 이용시간은 제각각 입니다. 어느 사람은 오래 이용할 수도 있고 어느 사람은 서비스를 짧게 이용할 수도 있습니다. 그렇게 계속 지속된다면 한 서버에 트래픽이 몰리게 되어 과부하가 올 수 있습니다.

 

또한 서버가 갑자기 죽어버린다면 해당 클라이언트의 세션정보가 모두 유실되어 가용성이 떨어진다는 단점이 있습니다 클라이언트에게 지속적으로 서비스를 제공하기 위해서는 가용성은 중요한 사안입니다.

 

[ Session Clustering ]

 

Clustering 이란?

여기서 Clustering이란 여러대의 서버가 동시에 한 가지 업무를 수행하도록 만드는 것이다. 여러 대의 서버를 클러스터링 하여 작업 중에 서버 하나가 장애가 나도 지속적인 서비스를 제공해줄 수 있다.

 

Session Clustering 은 각각의 서버에 같은 세션 정보를 공유합니다.  그 방식을 Tomcat Document를 참고하여 알아보았습니다. 

 

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

Apache Tomcat 9 (9.0.43) - Clustering/Session Replication How-To

톰캣에서 세션을 복제하는 방법으로 3가지를 사용할 수 있습니다.

1. 메모리에 저장된 세션정보를 복제하는 방법 (In-memory-replication)
2. 데이터베이스를 이용하여 세션을 공유하는 방법
3. 파일 시스템을 이용하여 세션을 공유하는 방법

all-to-all replication

메모리에 세션 정보를 저장해놓습니다. 만약 한 서버에서 세션 정보가 변경된다면 DeltaManager는 변경 내용을 모든 서버에 복제시킵니다. 이 방식을 사용하면 정합성과 가용성 이슈를 해결 가능합니다.

 

서버가 많아질 수록 세션 정보를 복제하기 위한 네트워크 비용은 커지고 성능 저하로 이어집니다. 그래서 톰캣에서는 노드가 4개 이하일 경우에만 추천하는 방식입니다. 이는 확장성에 문제가 있어 보입니다.

primary-secondary session

all-to-all replication 과 마찬가지로 메모리에 세션정보를 저장합니다.

 

다른 점으로는 클라이언트의 요청으로 세션에 정보가 저장되면 그 서버는 Primary가 되어 Secondary 서버에 세션 정보를 복제합니다. 그리고 나머지 서버에는 세션 정보를 복제하는 것이 아닌 세션 ID와 Primary의 위치 정보를 저장합니다.

 

그러면 서버1나 서버 2로 요청이 온다면 요청을 바로 처리할 수 있습니다. 하지만 Proxy인 서버 3으로 요청이 온다면 해당 요청을 서버 1에 요청하여 서비스를 제공하게 됩니다. 

 

네트워크 통신의 수는 all-to-all replication과 동일합니다. 메모리도 덜 사용하고 네트워크 대역폭도 줄일 수 있습니다. 하지만 Proxy 서버에 세션 정보를 요청한다면 Primary 서버의 세션 정보를 가져와서 처리해야 하는 단점이 있습니다. 

 

[ 세션 저장소를 분리 ]

세션 저장소를 분리하여 모든 서버가 하나의 저장소를 공유를 하며 데이터 정합성을 유지할 수 있습니다.

 

이로써 각 서버는 세션 정보를 가지지 않게 됩니다. 어떤 서버에서든 하나의 저장소에 저장된 세션 정보를 공유하기 때문에 Sticky Session 방식 또한 필요하지 않습니다.

 

또한 메모리에 저장함으로써 오는 가용성 문제와 네트워크 비용으로 인해 서버가 늘어날 수록 성능 저하가 오는 문제점을 해결하였습니다.

 

즉, 세션 저장소를 분리함으로써 서버는 세션의 상태를 가지지 않기 때문에 지속적으로 확장할 수 있으며 하나의 서버에서 장애가 발생하더라도 세션 저장소는 영향이 없기 때문에 다른 서버에서 작업을 처리할 수 있을 것이며 저장소 하나에만 통신을 하게 되기 때문에 네트워크 비용이 발생하지만 세션을 복제하며 발생하는 비용보단 현저히 적기 때문에 네트워크 비용으로 인한 성능적인 부분도 해결할 수 있습니다.

 

하지만 세션 저장소가 장애가 난다면 세션 정보가 모두 유실되게 될 것입니다. 그래서 저장소 또한 복제하여 가용성을 확보해야할 것입니다.

 

세션을 저장하기 위한 저장소는 다양하게 있습니다. 그러면 효율적으로 관리하기 위한 최적의 저장소는 무엇일까요?

대용량 트래픽을 위한 세션 관리하기 #2 에서 알아보겠습니다!

 

정리

세션을 서버의 메모리에서 관리했을 때 scale out으로 확장하면 세션 불일치 문제가 발생한다.

 

Sticky Session 방식은 한 클라이언트에 대하여 같은 서버에서만 요청을 처리하기 때문에 데이터의 정합성 이슈를 해결할 수 있다. 하지만 세션 정보를 가지고 있던 서버가 장애가 발생하면 정보가 유실되어 지속적인 서비스를 제공하지 못하게 되며 사용자마다 서비스 이용시간이 다르기 때문에 특정 서버에 과부하가 올 수 있다는 단점이 있다.

 

일반적인 Session Clustering 방식에서는 세션 정보 변경시마다 모든 서버에 복제를 하기 때문에 네트워크 비용이 발생하고 서버가 더 많이 확장될수록 성능적인 이슈가 있어 서버의 확장성에 한계가 생긴다.

 

세션 저장소를 분리한다면 서버는 세션 정보를 갖지 않기 때문에 원하는 만큼 확장이 가능하며 네트워크 비용도 크게 발생하지 않는다. 또한 특정 서버가 장애가 나더라도 다른 서버에서 서비스를 지속적으로 제공하여 가용성을 확보할 수 있다.

 

프로젝트

github.com/f-lab-edu/star-dabang

f-lab-edu/star-dabang