2. scale out과 이후 서버 간 세션 관리 방법
(1) Scale out과 Scale up
Scale out
서버의 개수를 늘려서 많은 트래픽을 여러 서버가 나눠서 처리하는 방법
'수평 스케일'로 불리기도 한다
[ 장점 ]
- 이 방법은 운영 중인 서버에 영향을 끼치지 않으면서 서버의 중단 없이 처리 능력을 향상시킬 수 있다
- 여러 대의 서버를 동시에 운영하기 때문에 하나의 서버에 문제가 발생해도 다른 서버에서 트래픽을 처리할 수 있기 때문에 서비스가 보다 안정적이다
- Scale up이 갖는 '부품에 의한 능력 향상'의 한계가 사라진다
[ 단점 ]
여러 대의 서버를 관리해야 하기 때문에 관리 및 유지보수가 힘들다
각 서버가 갖는 데이터에 대한 정합성 보장이 필요하다 -> 데이터 통일 필요
클라이언트 요청을 어떤 서버에서 처리할 것인지와 한 서버에만 트래픽이 몰리는 것을 방지하기 위해 로드 밸런싱으로 트래픽 조절이 필요하다
Scale up
한 대의 서버를 구성하는 부품(CPU, RAM, DISK 등..)을 추가하거나 업그레이드하여 서버 자체의 처리 능력을 향상시키는 방법
[ 장점 ]
- 한 대의 서버를 업그레이드 하기 때문에 관리할 서버의 개수가 늘어나지 않고 손쉽게 적용이 가능하다
[ 단점 ]
- 서버를 확장하는 동안 멈추기 때문에 서비스 제공이 불가능하다
- 부품을 추가함으로써 서버 능력을 향상시키는 데에는 한계점이 존재한다
- 한 대의 서버로 운영하기 때문에 서버에 장애가 발생하면 서비스에 끼치는 영향이 크기 때문에 불안정하다
Scale up VS Scale out
| Scale up | Scale out | |
| 장점 | - 서버 관리가 쉽다 - 데이터 정합성 처리가 필요하지 않다 (서버가 한대니까) - 손쉬운 처리 능력 향상(부품 업그레이드) |
- 서버의 중단 없이 확장 가능 - 가용성 증가 - 부품에 의한 능력 향상 한계 X |
| 단점 | - 유연한 확장 불가능(확장 시 서버의 중단 필요) - 능력 향상의 한계 존재(부품의 한계) - 단일 장애점(서버가 한대라서 장애가 발생하면 서비스 사용 불가) |
- 관리 서버 증가(관리할 서버가 여러 대임) - 데이터 정합성 처리 필요(서버 간의 데이터 통일) - 트래픽 조정을 위한 로드 밸런싱 필요 |
(2) Scale out의 데이터 정합성 문제 해결 방법
scale out을 사용하면 여러 대의 서버를 사용하게 되는데, 이 때 서버간의 데이터 정합성이 필요하다
예를 들면 로그인에 대한 인증 기능을 세션 기반으로 구현했을 경우, 세션 정보의 불일치가 발생할 수 있다!
(내 면접 문제도 이거였음,,,)
아래 사진처럼 한 서버로 요청을 보내 세션을 저장하면 다른 서버들을 저장된 세션 정보를 몰라서 문제가 발생할 수 있따!
나는 미니 프로젝트이다 보니 이런 걸 고려할 필요가 없었다
심지어 로컬 서버여서 더더욱 고민조차 안해봄,,,,
그래서 지금 정리를 해보려고 한다!!
쉽게 생각하면 해결 방법은 이러하다
세션 정보를 모든 서버가 공유하거나,
클라이언트 요청을 세션 정보를 가지고 있는 서버한테만 보내면 되는거 아녀?
저렇게 쓰니까 되게 말투가 이상허네,,허허
암튼! 사실 저렇게 하면 되긴 된다!
그럼 어떻게 하느냐?! 그걸 공부할 것이다
여기서 세션 정보를 모든 서버가 공유하는 방법은 Session Clustering이고, 클라이언트 요청을 한 서버에만 보내도록 고정하는 방법을 Sticky Session이라고 한다
이제 이 둘을 차근차근 살펴보자~
Session Clustering
Session Clustering은 대표적 WAS(Web Application Server)인 Tomcat에서 제공해주는 방법을 이용하거나, Session을 저장할 때 서버가 아닌 외부 리소스에 저장시켜 공유하는 방법을 사용하면 된다!
먼저 Tomcat에서 제공하는 방법을 알아보자
(1) Tomcat의 Session Clustering
1. All-to-all Session Replication
- Tomcat에서 제공하는 DeltaManager가 생성된 세션을 모든 서버에 복제하는 방법이다
[ 장점 ]
- 특정 서버에 생성된 세션이 클러스터를 이루는 모든 서버에 세션에 복제되기 떄문에 클라이언트의 요청을 한 곳으로 지정할 필요 없이 어떤 서버로 요청을 보내도 동일한 세션 유지가 가능하다!
- 이용하고 있는 서버에 장애가 발생해도 다른 서버에서 세션을 유지하고 있기 때문에 클라이언트는 동일한 서비스 환경을 제공받을 수 있다
[ 단점 ]
- 세션을 모든 서버에 복제하기 위한 트래픽이 발생한다
- 서버가 늘어날수록 하나의 서버가 감당해야 할 세션과 복제를 위한 트래픽이 엄청 증가한다
- Tomcat 공식문서에서도 노드 4개 미만의 소규모 클러스터 환경에서 좋고, 대규모 클러스터 환경에서는 추천하지 않는다고 말한다
- 또한 DeltaManager를 사용한 방식은 어플리케이션이 배포되지 않은 노드에도 복제를 시도하기 때문에 불필요한 트래픽을 서버에 발생시켜 문제가 된다
Tomcat에서는 위와 같은 문제를 해결하기 위해 BackupManager를 이용한 방법을 제공한다!
2. Primary-secondary session replication
- BackupManager는 세션을 모든 서버에 복제하지 않고 백업 서버에만 복제를 한다
- 클라이언트 요청이 들어오면 해당 요청을 처리한 Primary 서버에 세션을 생성하고, Secondary 서버(백업 서버)에만 완전한 세션 복제를 진행한다
- 나머지 Proxy 서버에는 Session ID와 Primary/Secondary 서버의 주소만 가지고 있는다
- 만약 Proxy 서버에 클라이언트 요청이 들어오면 Primary 서버에 요청을 보내 완전한 세션 데이터를 복제한다
[ 장점 ]
- 이 방법은 세션을 모든 서버에 복제하지 않기 때문에 저장해야 할 세션 정보의 양이 상대적으로 줄어든다
[ 단점 ]
- Primary-Secondary 이외의 서버로 요청이 들어오면 여전히 완전한 세션 복제를 위한 과정이 수행된다
Tomcat은 세션 불일치 문제에 대한 여러가지 해결책을 제시한다
하지만 서버가 확장될수록 복제해야 할 서버가 늘어나고 추가적인 오버헤드가 커진다
또한 위의 모든 방법들을 서버가 세션이라는 상태(데이터)를 갖는다는 것은 변함이 없다!
"서버가 상태(데이터)를 갖는다"는 것은 Scale out 방식으로 확장했을 때 서버가 갖는 데이터를 확장하는 서버에도 똑같이 맞춰줘야 한다는 것이다
그럼 만약 서버가 상태를 갖지 않는다면 어떨까?
서버가 상태를 갖지 않는 Stateless 서버라면, Scale out 확장을 해도 데이터(세션)의 정합성을 맞추지 않아도 된다
또한 서버 장애 시 갖고있는 데이터가 없기 떄문에 정보의 손실을 신경쓰지 않아도 된다
즉, Scale out의 장점은 극대화시키고, 단점은 최소화하며 대용량 트래픽에 대응해 효율적으로 확장을 할 수 있다는 것이다!
이제 다음에서 볼 내용은 Stateless 서버로, 이를 만들기 위해서는 로컬 서버에 저장되는 데이터가 없어야 한다
이를 구현하기 위해서는 세션 저장소를 서버가 아닌 외부로 분리하는 것이 좋다!
Session Storage 분리
Session 저장소를 로컬 서버에서 분리하여 세션을 따로 저장하고, 필요할 때마다 조회하는 방법이다
Scale out 확장을 하더라도 세션을 저장하는 곳이 외부에 있어 세션 불일치 문제가 발생하지 않는다
또한 Sticky Session처럼 로드 밸런서를 통해 특정 트래픽을 분리하지 않아도 된다
하지만 세션 저장소를 분리하기 때문에 서버의 관리 포인트가 더 증가하고, 저장소 서버에 장애가 발생하는 경우 세션을 사용하는 모든 서버에 영향을 끼치는 위험이 있다
또한 세션을 외부에서 가져와서 사용하기 떄문에 로컬 메모리에 저장해 사용하는 것보다 성능적인 측면에서 비효율적일 수 있다
정리하고 보니까 서비스의 규모, 편리성, 관리 인력? 등을 잘 고민해서 선택하여 사용하는 것이 좋을 것 같구먼!!
(출처)
Scale out 확장 구조에서 Session 불일치 문제와 해결 방법
저번 글에서 서버의 확장은 어떤 것들이 있는지 알아봤습니다. 서버의 확장? Scale up과 Scale out이란? 웹 서버 애플리케이션을 개발하고 운영하다 보면 여러 가지 상황을 마주하게 됩니다. 그중 하
liasn.tistory.com
'야미스터디 > Etc' 카테고리의 다른 글
| [파이썬] Heap 자료구조 (import heapq) (0) | 2022.01.07 |
|---|---|
| 02장 파이썬 프로그래밍의 기초, 자료형 (1) (0) | 2022.01.05 |
| [C++ STL] priority_queue (우선순위 큐) (0) | 2022.01.03 |
| 01장 파이썬이란 무엇인가? (0) | 2021.12.26 |
| [C++ STL] map iterator(반복자) (0) | 2021.12.24 |
댓글