Scale up vs Scale out(+Scale out의 데이터 정합성 문제 해결)

서버를 운영하다 보면 갑작스러운 이용자의 증가, 사업 확장 등의 이유로 트래픽이 과부하되는 경우가 있습니다. 이 경우 이용에 불편이 생기고 서버에 장애를 일으킬 수 있기 때문에 서버를 확장해야 합니다.

 

서버를 확장하는 방법에는 Scale up과 Scale out의 방법이 존재합니다. 이 두 가지 방법의 개념과 장단점을 알아보고 세션을 사용하는 경우 Scale out의 데이터 정합성 문제를 어떻게 해결하는지 정리해 보았습니다.

 

추가적으로 제 개인 프로젝트에서는 왜 Scale out 방법을 선택했으며 Scale out의 데이터 정합성 문제는 어떻게 해결했는지 설명해 보겠습니다.

 

 

Scale Up

Scale Up

스케일업은 한 대의 서버를 구성하는 부품(RAM/CPU/Disk)을 추가하거나, 기존 서버의 사양을 업그레이드하여 시스템을 확장하는 방식입니다. 장단점은 아래와 같습니다.

 

장점

• 추가적인 네트워크 연결 없이 한 대의 서버를 관리하면 되므로 관리 요소가 늘어나지 않음

단점

• 서버 확장 또는 서버 교체 시 다운 타임이 발생하여 서비스 제공 불가능
• 부품이 가지는 처리 능력 향상의 한계 존재
• 단일 서버이기 때문에 서버 장애 발생 시 치명적

 

Scale Out

Scale Out

스케일아웃은 서버를 여러 대 추가하여 시스템을 확장하는 방식입니다. 장단점은 아래와 같습니다.

 

장점

• 여러 서버를 동시에 운영하는 구조이기 때문에, 하나의 서버에 문제가 생겨 장애가 발생하더라도 다른 서버에서 트래픽 처리가 가능하므로 서비스에 미치는 영향 감소

단점

• 여러 서버를 관리해야 하기 때문에 관리 요소가 늘어남
• 각각의 서버가 동일한 데이터를 가지고 있어야 하므로 데이터에 대한 정합성(data consistency) 보장 필요

 

🤔 그럼 세션을 사용하는 경우 Scale out 방식의 문제점인 데이터 정합성을 어떻게 보장할 수 있을까요?

먼저 각각의 서버가 동일한 데이터를 갖고 있지 않아 생기는 문제를 로그인의 상황을 통해 확인해 보겠습니다.

만약 처음 로그인 시 로드밸런서에 의해 1번 서버에 SESSIONID를 저장하고, 다음 요청 시 사용자의 정보를 조회하는 요청을 보냈을 때 2번 서버로 요청이 가게 되면 세션의 정보가 없기 때문에 조회에 실패하게 됩니다. 2번 서버에는 세션 정보가 없기 때문입니다.

이 문제를 해결하기 위해 Sticky Session, Session Clustering, Session Storage 분리와 같은 방법을 사용합니다.

 

Sticky Session

Sticky Session은 로드밸런서가 특정 세션의 요청을 처음 처리한 서버로만 보내는 방법입니다.

Sticky Session

위 이미지대로라면 syoh의 요청은 처음 처리했던 1번 서버로만, maverick의 요청은 처음 처리했던 3번 서버로만 보내게 되는 것입니다.

이 방법은 cookie 또는 클라이언트의 IP tracking을 기반으로 동일한 클라이언트인지 판단하여 세션이 생성된 서버로 라우팅 하는 방식으로 동작합니다.

장점은 서버 간 세션 동기화가 필요 없기 때문에 분산 저장 또는 중앙 저장소 구성과 같은 추가적인 작업이 필요하지 않습니다. 이는 별도의 복잡한 세션 관리 솔루션을 도입하지 않기 때문에 성능의 향상으로도 이어질 수 있습니다.

단점은 특정 서버에 요청이 몰리게 되는 경우 서버에 과부하가 걸리게 되어 전체 시스템 성능이 저하될 수 있습니다. 또한 새로운 서버를 추가해도 기존 세션이 특정 서버에 고정되어 있기 때문에 Scale out의 장점인 확장된 서버를 활용할 수 없게 됩니다. 로드밸런서의 세션 고정 설정에 의존하기 때문에 로드밸런서에 문제가 발생할 경우 이 또한 세션 관리에 혼란이 생기게 됩니다.

 

Session Clustering

Session Clustering은 여러 WAS에 대한 세션을 하나의 세션으로 관리하는 방법입니다.

WAS마다 Session Clustering의 방식이 다른데 대표적 WAS인 톰캣(Tomcat)에서 관리하는 방법을 알아보겠습니다.

 

all-to-all session replication

all-to-all session replication

all-to-all 세션 복제는 DeltaManager를 사용하여 모든 WAS에 동일한 세션을 복제하여 저장하는 방법입니다.

장점은 서버 간 세션 동기화가 되어있기 때문에 특정 서버에 장애가 발생해도 중단 없이 서비스를 지속할 수 있습니다.

하지만 모든 서버가 모든 세션을 복제하므로 네트워크 트래픽이 증가하게 됩니다. 서버가 추가되면 네트워크 트래픽뿐만 아니라 복제 비용도 기하급수적으로 늘어나게 되고, 이는 곧 성능 저하로 이어지게 됩니다.

따라서 Tomcat 클러스터링/세션 복제 방법에 대한 공식문서에서  all-to-all 세션 복제는 소규모 클러스터에 적합하지만 WAS가 4개 이상인 대규모 클러스터에는 권장하지 않습니다.

 

 

primary-secondary session replication

primary-secondary session replication

primary-secondary 세션 복제는 BackupManager가 세션을 모든 서버에 복제하지 않고 백업(secondary) 서버에만 복제하여 저장하는 방법입니다.

서버가 추가되어도 복제 트래픽이 기하급수적으로 증가하지 않기 때문에 all-to-all 세션 복제보다 성능에 대한 부담이 적어 대규모 클러스터에 적합합니다.

하지만 primary 서버와 secondary 서버가 동시에 장애가 발생하는 경우 세션 데이터 복구가 불가능할 수 있으며, 불필요한 복제로 서버의 메모리 사용량이 증가하여 마찬가지로 성능 저하가 발생합니다.

 

세션 저장소(Session Storage)

세션 저장소는 세션을 서버의 메모리에 저장하지 않고, 외부 저장소에 저장하고 필요할 경우 조회하는 방법입니다.

Session Storage

장점은 서버가 추가되어도 추가한 서버에 세션 저장소 정보를 명시해 주면 되기 때문에 기존 서버를 수정하지 않아도 됩니다. 또한 특정 서버에 장애가 발생하더라도 세션 저장소는 독립되어 별도로 존재하기 때문에 세션을 활용한 서비스에 영향을 주지 않습니다.

단점은 세션 저장소의 예기치 못한 종료로 모든 세션 데이터를 소실할 수 있다는 것입니다.

 

💭 내가 선택한 데이터 정합성 문제 해결 방법

https://github.com/f-lab-edu/go-table

GitHub - f-lab-edu/go-table: 선착순 식당 예약 서비스

제가 진행한 프로젝트는 캐치테이블, 테이블링과 같은 식당 예약 서비스로 한정된 인원만이 예약 가능한 시스템입니다. 따라서 트래픽이 과부하될 경우 서버의 확장을 통해 유연한 대응이 가능한 Scale out의 방식이 적절하다고 판단했습니다.

또한 go-table이 대규모 서비스가 될 것임을 가정함으로써 서버 부하 감소와 데이터 정합성을 해결하기 위해 별도의 Session Storage를 두는 방법을 선택했습니다.

추가적으로 Session Storage를 다양한 방법으로 구성할 수 있는데, 이는 다음 글에서 작성하도록 하겠습니다.

 

 

 

참고

https://learn.microsoft.com/ko-kr/dotnet/architecture/cloud-native/infrastructure-resiliency-azure

Azure 플랫폼 복원력 - .NET

 

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

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