Scale Out 정합성 문제
앞선 블로그 포스팅에서 저희 서비스의 환경에 맞춰 ScaleOut 아키텍처를 선택했습니다.
하지만 현 서비스에서 유저의 정보를 Session으로 저장하는것으로 설계했는데 정합성의 문제점이 발생했습니다.
클라이언트의 Request들을 로드밸런서가 라운드로빈 방식으로 적절하게 관리했다고 가정해보겠습니다.
여기서 A클라이언트가 Request를 보내면 Load Balancer가 라운드로빈 방식으로 분배를 해줍니다. 이때 A유저가 로그인 요청을 보내면 A Server에 A 유저의 정보를 Session으로 저장합니다.
이번엔 A 유저가 자신의 정보를 호출하는 Request를 보내면 Load Balancer에서는 C Server로 전달하기 때문에 A 유저의 정보가 없어서 에러페이지가 뜨게 됩니다.
이러한 Session 불일치 문제를 해결하기 위해 3가지 방법 중 역시나 트레이드오프를 고려하여 선택을 하겠습니다.
Sticky Session
직역을 하면 고정된 세션이라는 뜻으로 A 유저의 모든 서비스 활동을 A Server에서 고정되어 사용하는 방법입니다.
Sticky Session 장점
- 특정 세션의 요청을 처음 처리한 서버로만 보내기 때문에 정합성 이슈를 해결할 수 있습니다.
Sticky Session 단점
- 특정서버(A Server)에만 트래픽이 몰릴 수 있다는 단점이 있습니다.
- A Server가 다운되면 저장된 Session이 유실될 수 있습니다.
Session Clustring
여러 대의 컴퓨터들이 하나의 시스템처럼 동작하도록 만드는 것을 클러스트링이라고 합니다.
A 클라이언트의 세션정보를 복사하여 A/B/C Server에 저장합니다.
Session Clustring 장점
- 서버 한대가 시스템장애가 발생해도 다른 서버에서 그 역할을 대신 수행할 수 있습니다.
- 위 그림처럼 A 클라이언트가 어떤 서버에 접속하더라도 정합성 이슈가 해결됩니다.
Session Clustring 단점
- 모든 서버가 동일한 세션 객체를 가져야 하기 때문에 많은 메모리가 필요합니다.
- 서버 증설에 따라 모든 서버에 세션을 저장해야하기 때문에 트래픽이 증가할 수 있습니다.
Session Storage
Session Storage는 별도의 세션 저장소를 이용하는 방법입니다.
데이터스토리지의 메인 메모리에 설치되어 운영되는 방식의 Inmemory DB를 사용합니다.
Inmemory DB의 장점은 메모리로 접근하기 때문에 디스크 접근보다 속도가 빠르고 내부 최적화 알고리즘을 사용하여 더 적은 CPU 명령을 실행합니다.
Session Storage 장점
- 세션 스토리지를 분리함으로서 세션의 정합성을 유지할 수 있습니다.
- 서버 한대가 장애가 발생하더라도 별도의 세션 저장소가 존재하기 때문에 서비스를 계속해서 제공하여 가용성을 확보할 수 있습니다.
Session Storage 단점
- 메모리 자체가 휘발성이기 때문에 DB 서버가 종료되면 Session 손실의 위험이 있습니다.
- 네트워크 통신 기회비용이 발생할 수 있습니다.
결과적으로 저희 서비스 Gift-club은 Scale Out 아키텍처에 이어서 Session Storage 분리 방법을 사용하여 정합성을 해결하고 Session Storage를 여러대로 복제하여 가용성을 해결하려 합니다.
Session Clustring과 고민을 했지만 같은 네트워크 통신 기회비용이 발생한다면 InmemoryDB인 Redis를 사용하여 성능을 향상시키는 방법을 선택했습니다.
다음 블로그 포스팅에서는 InmemoryDB에 대해서 알아보고 Redis로 결정한 이유와 실제 프로젝트에 적용해보겠습니다.
참고문헌
https://aws.amazon.com/ko/blogs/aws/new-elastic-load-balancing-feature-sticky-sessions/
https://smjeon.dev/web/sticky-session/
http://docs.motechproject.org/en/latest/deployment/sticky_session_apache.html
